ASoC: Dynamic CODEC DAI

ASoC: Dynamic CODEC DAI

[Patrick Lai]

Problem overview:

The CODEC which I am working on transports digital audio through
SLIMBUS instead of I2S. The concept of CODEC DAI does not apply too
well with SLIMBUS architecture as CODEC DAIs are typically defined base
on a set of I2S digital audio interface(bit clock, world select, sd
lines). On the CODEC, there are 10 digital capture ports. They can be
independently configured as mono channels or can be run-time grouped
together to function like multi-channel CODEC DAIs. On top of that,
only some ports out of 10 ports can accept all analog mic inputs or
digital mic inputs. Hence, even though the CODEC satisfies the
concurrent use cases it was designed for, software would have to be
articulate on grouping the ports in order to utilize all ports. So, I
cannot simply code up CODEC DAI definitions in the CODEC driver for a
particular machine. For now, I am looking for compile time grouping of
these ports as use cases are known at the time machine is designed.

Proposal:
I want to minimize amount of change to soc framework at the same time
meeting my requirement.

Here is my proposed design

In CODEC driver, I will declare codec dai for each port.
Then, I will enhance ASoC framework to take a list of CODEC DAIs and
pass list of CODEC DAIs back to callback function such as startup,
hw_param, prepare, trigger. I believe this approach will not require
massive amount of change to framework.

Your feedback is appreciated.

Thanks
Patrick

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ASoC: Dynamic CODEC DAI

[Patrick Lai]

On 11/28/2011 4:49 PM, Patrick Lai wrote:
>
> Problem overview:
>
> The CODEC which I am working on transports digital audio through
> SLIMBUS instead of I2S. The concept of CODEC DAI does not apply too
> well with SLIMBUS architecture as CODEC DAIs are typically defined base
> on a set of I2S digital audio interface(bit clock, world select, sd
> lines). On the CODEC, there are 10 digital capture ports. They can be
> independently configured as mono channels or can be run-time grouped
> together to function like multi-channel CODEC DAIs. On top of that,
> only some ports out of 10 ports can accept all analog mic inputs or
> digital mic inputs. Hence, even though the CODEC satisfies the
> concurrent use cases it was designed for, software would have to be
> articulate on grouping the ports in order to utilize all ports. So, I
> cannot simply code up CODEC DAI definitions in the CODEC driver for a
> particular machine. For now, I am looking for compile time grouping of
> these ports as use cases are known at the time machine is designed.
>
> Proposal:
> I want to minimize amount of change to soc framework at the same time
> meeting my requirement.
>
> Here is my proposed design
>
> In CODEC driver, I will declare codec dai for each port.
> Then, I will enhance ASoC framework to take a list of CODEC DAIs and
To elaborate more on this statement,

I plan on enhancing definition of DAI link to take a list of
CODEC DAI instead of single CODEC DAI.

> pass list of CODEC DAIs back to callback function such as startup,
> hw_param, prepare, trigger. I believe this approach will not require
> massive amount of change to framework.
>
> Your feedback is appreciated.
>
> Thanks
> Patrick
>


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ASoC: Dynamic CODEC DAI

[Pierre-Louis Bossart]

> The CODEC which I am working on transports digital audio through
> SLIMBUS instead of I2S. The concept of CODEC DAI does not apply too
> well with SLIMBUS architecture as CODEC DAIs are typically defined base
> on a set of I2S digital audio interface(bit clock, world select, sd
> lines). On the CODEC, there are 10 digital capture ports. They can be
> independently configured as mono channels or can be run-time grouped
> together to function like multi-channel CODEC DAIs. On top of that,
> only some ports out of 10 ports can accept all analog mic inputs or
> digital mic inputs. Hence, even though the CODEC satisfies the
> concurrent use cases it was designed for, software would have to be
> articulate on grouping the ports in order to utilize all ports. So, I
> cannot simply code up CODEC DAI definitions in the CODEC driver for a
> particular machine. For now, I am looking for compile time grouping of
> these ports as use cases are known at the time machine is designed.

I may be reaching summits of cluelessness here, but isn't the logical
grouping/shuffling of channels needed on the cpu/host side only, possibly at
the machine-driver level? At the codec level you should only need to worry
about which channel/port goes to what output, and that would be similar to
TDM/AC97. I don't understand why all this should be part of a codec driver.
-Pierre

Re: ASoC: Dynamic CODEC DAI

[Patrick Lai]

On 11/28/2011 5:19 PM, Pierre-Louis Bossart wrote:
>> The CODEC which I am working on transports digital audio through
>> SLIMBUS instead of I2S. The concept of CODEC DAI does not apply too
>> well with SLIMBUS architecture as CODEC DAIs are typically defined base
>> on a set of I2S digital audio interface(bit clock, world select, sd
>> lines). On the CODEC, there are 10 digital capture ports. They can be
>> independently configured as mono channels or can be run-time grouped
>> together to function like multi-channel CODEC DAIs. On top of that,
>> only some ports out of 10 ports can accept all analog mic inputs or
>> digital mic inputs. Hence, even though the CODEC satisfies the
>> concurrent use cases it was designed for, software would have to be
>> articulate on grouping the ports in order to utilize all ports. So, I
>> cannot simply code up CODEC DAI definitions in the CODEC driver for a
>> particular machine. For now, I am looking for compile time grouping of
>> these ports as use cases are known at the time machine is designed.
>
> I may be reaching summits of cluelessness here, but isn't the logical
> grouping/shuffling of channels needed on the cpu/host side only, possibly at
> the machine-driver level?
This is exactly what I am planning to do. Have the machine driver 
handles the grouping. However, DAI link is consisted of one CODEC dai, 
one CPU DAI, and platform driver. Unlike I2s which number of channels 
per DAI is fixed, I can divide 10 available ports to several groups. 
Each group belongs to different DAI links so ports within same group 
form x number of channels stream and feed into CPU. However, how many 
ports per group and which ports to use is unknown to CODEC driver and 
would have to be decided by machine driver. . That's why I need to 
propose the design on ASoc framework.

At the codec level you should only need to worry
> about which channel/port goes to what output, and that would be similar to
> TDM/AC97. I don't understand why all this should be part of a codec driver.
Please excuse my lack of understanding about AC97. There is a codec
driver /sound/soc/codec/ac97.c. However, only one DAI is defined and
supports both playback/capture with 2 as max channels. I don't see how
static CODEC DAI definition is going to satisfy my requirements. I am
still bounded to DAI link structure definition which takes only one
CODEC DAI. In this case with ac97.c, I am still limited to work with
pre-defined CODEC DAI in ac97.c  Is there an example for grouping ac97
channels?

> -Pierre
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ASoC: Dynamic CODEC DAI

[Pierre-Louis Bossart]

> Please excuse my lack of understanding about AC97. There is a codec
> driver /sound/soc/codec/ac97.c. However, only one DAI is defined and
> supports both playback/capture with 2 as max channels. I don't see how
> static CODEC DAI definition is going to satisfy my requirements. I am
> still bounded to DAI link structure definition which takes only one
> CODEC DAI. In this case with ac97.c, I am still limited to work with
> pre-defined CODEC DAI in ac97.c  Is there an example for grouping ac97
> channels?

In theory AC97 can convey multiple slots (12 if I am not mistaken). It's
somewhat similar to SLIMbus, but with a fixed slot allocation, no bit clock
scalability and it's not truly bidirectional. The limitation to stereo
reflects codec limitations, not the standard.

Re: ASoC: Dynamic CODEC DAI

[Mark Brown]

On Mon, Nov 28, 2011 at 04:49:18PM -0800, Patrick Lai wrote:

> In CODEC driver, I will declare codec dai for each port.
> Then, I will enhance ASoC framework to take a list of CODEC DAIs and
> pass list of CODEC DAIs back to callback function such as startup,
> hw_param, prepare, trigger. I believe this approach will not require
> massive amount of change to framework.

The above is really vauge so it's hard to comment in any detail.  I'm
not sure it's worth trying to be too non-invasive, anything controlling
hardware is going to have to understand what's going on at the physical
level anyway and the host side is going to have to interoperate with the
Slimbus framework.  The core is also going to need to know about the
channel groups to allocate and destroy them as required.  It seems like
being more explicit might be easier.

Also note that the work on submitting your Silmbus driver core to
mainline appears totally stalled, there was just an initial posting but
no followup.

Re: ASoC: Dynamic CODEC DAI

[Patrick Lai]

On 11/29/2011 5:49 AM, Mark Brown wrote:
> On Mon, Nov 28, 2011 at 04:49:18PM -0800, Patrick Lai wrote:
>
>> In CODEC driver, I will declare codec dai for each port.
>> Then, I will enhance ASoC framework to take a list of CODEC DAIs and
>> pass list of CODEC DAIs back to callback function such as startup,
>> hw_param, prepare, trigger. I believe this approach will not require
>> massive amount of change to framework.
>
> The above is really vauge so it's hard to comment in any detail.
The thing is that in order for DAPM to figure out which path to enable,
AIF_IN and AIF_OUT widgets must be associated with stream name(e.g HiFi
  Playback) as part of CODEC DAI definition. Now, with the grouping
requirement, CODEC DAI definition with fixed number of channels will
not work as interconnect table defined in the CODEC driver establishes
relationship of AIF pins and codec dai stream name which now would have
to be machine base. Another approach would be having machine driver
define AIF pins, interconnect table and CODEC DAIs for CODEC driver. I
would think this approach would bear too much burden on the machine
driver developer. Instead, each slimbus port on the CODEC, by
definition, is a mono CODEC DAI. Extending DAI link definition to take
a list of CODEC dais allows machine driver to group the ports. Passing
back the CODEC DAI list to CODEC driver allows CODEC driver know which 
slimbus ports are associated with given pcm stream. As on the CPU side,
instead of burdening CPU driver from knowing what ports and enumeration
address of CODEC, we have concept of shared data channel IDs. So, both
CODEC driver and CPU driver communicate to SLIMBUS driver to set up
data channels using the channel ID. CPU and CODEC independently can
setup their own SLIMBUS ports. Machine driver assigns channel ID to
both CPU and CODEC drivers.

  I'm
> not sure it's worth trying to be too non-invasive, anything controlling
> hardware is going to have to understand what's going on at the physical
> level anyway and the host side is going to have to interoperate with the's
> Slimbus framework.  The core is also going to need to know about the
> channel groups to allocate and destroy them as required.
I presume you are referring to soc-core, with the approach I propose
above, I think soc-core does not have to be aware of SLIMBUS framework.
On the other hand, my approach will not be able to utilize run-time
grouping ability offered by SLIMBUS as ports are pre-assigned at
compile time. So, However, we are talking about drastic change. with
SLIMBUS, we can run-time create new pcm device as long as there are
enough SLIMBUS ports ignoring the fact that ports on my CODEC cannot
connect to all mic inputs. Entire framework built on static number of
pcm devices please correct me if I am wrong.


  It seems like
> being more explicit might be easier.
>
> Also note that the work on submitting your Silmbus driver core to
> mainline appears totally stalled, there was just an initial posting but
> no followup.
I guess slimbus driver guy is completely swamped now as SLIMBUS is new
and it takes a lot of effort to stablize.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ASoC: Dynamic CODEC DAI

[Liam Girdwood]

On Thu, 2011-12-01 at 18:56 -0800, Patrick Lai wrote:
> On 11/29/2011 5:49 AM, Mark Brown wrote:
> > On Mon, Nov 28, 2011 at 04:49:18PM -0800, Patrick Lai wrote:
> >
> >> In CODEC driver, I will declare codec dai for each port.
> >> Then, I will enhance ASoC framework to take a list of CODEC DAIs and
> >> pass list of CODEC DAIs back to callback function such as startup,
> >> hw_param, prepare, trigger. I believe this approach will not require
> >> massive amount of change to framework.
> >
> > The above is really vauge so it's hard to comment in any detail.
> The thing is that in order for DAPM to figure out which path to enable,
> AIF_IN and AIF_OUT widgets must be associated with stream name(e.g HiFi
>   Playback) as part of CODEC DAI definition. Now, with the grouping
> requirement, CODEC DAI definition with fixed number of channels will
> not work as interconnect table defined in the CODEC driver establishes
> relationship of AIF pins and codec dai stream name which now would have
> to be machine base. Another approach would be having machine driver
> define AIF pins, interconnect table and CODEC DAIs for CODEC driver. I
> would think this approach would bear too much burden on the machine
> driver developer. Instead, each slimbus port on the CODEC, by
> definition, is a mono CODEC DAI. Extending DAI link definition to take
> a list of CODEC dais allows machine driver to group the ports. Passing
> back the CODEC DAI list to CODEC driver allows CODEC driver know which 
> slimbus ports are associated with given pcm stream. As on the CPU side,
> instead of burdening CPU driver from knowing what ports and enumeration
> address of CODEC, we have concept of shared data channel IDs. So, both
> CODEC driver and CPU driver communicate to SLIMBUS driver to set up
> data channels using the channel ID. CPU and CODEC independently can
> setup their own SLIMBUS ports. Machine driver assigns channel ID to
> both CPU and CODEC drivers.

Fwiw, I'm looking at a similar channel mapping problem here for dyanmic
PCM and have the start of some working code. Basically I want to be able
to specify which channels from each PCM device are routed through each
DAI and DAPM widget.

This may be useful for Slimbus, so I've posted the abstract below :-

Features
========

1. Provide a method to identify unique channels streaming through a PCM,
DAI and DAPM widgets within a sound card.

2. Directly associate a PCM channel with a DAPM widget.

3. Simplicity wrt component drivers.

4. Provide multi-channel widgets for some users with easy to use
accesors to identify the the active channels (i.e. if the widget has
multiple power bits then we need to easily map channel to pm bit).


Assumptions
===========  

5. 64 Channels per ASoC sound card will be enough for everyone - 64 play
+ 64 capt also easy todo.


Initialisation
==============

6. There is a direct mapping between a PCM and AIF/DAC/ADC widgets.

7. Each widget has u64 channel mask. This mask is populated at runtime
by component PCM registration. Each channel is assigned a unique mask
that is set in each AIF/DAC/ADC widget. Channel mask bit is related to
PCM registration order and max supported playback and capture channels.

8. The AIF/DAC/ADC widget channels masks are then populated to their
reachable widgets so that each widget has a mask of all unique channels
it supports.


Runtime
=======

9. Widgets also have a u64 active status that is set for each channel on
stream events.

10. Widgets have accessors for active channel info.

11. PCMs have active supported and active channel masks too that are
propagated to their connected widgets at runtime. Based on hw_params
active channels etc.

12. Active channel mask can also be changed at runtime via kcontrols.
This should also be propagated to reachable widgets.

Regards

Liam

Re: ASoC: Dynamic CODEC DAI

[Patrick Lai]

On 12/2/2011 2:11 AM, Liam Girdwood wrote:
>
> Fwiw, I'm looking at a similar channel mapping problem here for dyanmic
> PCM and have the start of some working code. Basically I want to be able
> to specify which channels from each PCM device are routed through each
> DAI and DAPM widget.
>
Would you mind sharing the use case you have in mind? It is not clear
to me how your design proposal correlate to the problem I have in hand.
It looks to me that you are trying to address shuffling of pcm channels
correct me if I am wrong. For example, 5.1 content is composed with
certain speaker allocation in mind but the actual speaker allocation is
different. So, through the approach you are proposing, software can
rearrange the pcm channels according to actual speaker allocation.

My problem has more to do with ability to form PCM device at run-time
by grouping available slimbus ports at the CPU side and CODEC side
after knowing number of channels required. Furthermore, the CODEC I am
working on does not allow all mic inputs going to all audio interface
capture ports. Unless application can provide the mic input it is
interested before initiation of capture stream, it is hard to utilize
very slimbus port on the CODEC. Do you have work in progress code on
gitorious.org? Perhaps, I can take a look to understand more about your
proposed design and see what I can leverage.


>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: ASoC: Dynamic CODEC DAI

[Mark Brown]

On Sun, Dec 04, 2011 at 11:22:22PM -0800, Patrick Lai wrote:

> My problem has more to do with ability to form PCM device at run-time
> by grouping available slimbus ports at the CPU side and CODEC side
> after knowing number of channels required. Furthermore, the CODEC I am
> working on does not allow all mic inputs going to all audio interface
> capture ports. Unless application can provide the mic input it is
> interested before initiation of capture stream, it is hard to utilize
> very slimbus port on the CODEC. Do you have work in progress code on
> gitorious.org? Perhaps, I can take a look to understand more about your
> proposed design and see what I can leverage.

You get pretty much exactly the same problem on PCM links using TDM -
you can get a single link which you can combine into groups of channels
dynamically.  For example, you might use two channels for speaker and
two for headphones or you might use those four plus another two for 5.1
speaker all depending on use case.

Re: ASoC: Dynamic CODEC DAI

[Mark Brown]

On Thu, Dec 01, 2011 at 06:56:18PM -0800, Patrick Lai wrote:

> driver developer. Instead, each slimbus port on the CODEC, by
> definition, is a mono CODEC DAI. Extending DAI link definition to take
> a list of CODEC dais allows machine driver to group the ports. Passing

Why do this in the machine driver?  That's going to be limiting, it'll
mean that you've got a fixed allocation of channels at the time the
driver is written and can't restructure things on the fly as you switch
between use cases.  I'd much rather just describe the Slimbus link (and
possibly even let it be automatically enumerated) and keep as much
flexibility as possible.

Like I say everything involved is going to have to understand that it's
constructing a multi-channel link (even a fairly dumb CODEC is going to
have to know that the samples for a given multi channel audio stream
should be synchronized) so it seems better to actually implement this
properly rather than trying to keep the knowledge out of the core.

>  I'm
> >not sure it's worth trying to be too non-invasive, anything controlling
> >hardware is going to have to understand what's going on at the physical
> >level anyway and the host side is going to have to interoperate with the's
> >Slimbus framework.  The core is also going to need to know about the
> >channel groups to allocate and destroy them as required.

> I presume you are referring to soc-core, with the approach I propose
> above, I think soc-core does not have to be aware of SLIMBUS framework.

I think it needs to be able to understand the concept of a multi-drop
flexible link; I don't think it needs to know anything specific about
Slimbus but I think to fully exploit Slimbus (and any similar buses that
come along) it's going to have to be extended.  If it were a case of
doing something tasteful that's transparent to the core but was limited
in feature set that'd be one thing but once we start to extend the core
specifically for the limited solution we should at the very least be
making sure that the APIs we're offering drivers will allow us to do a
good solution later on without churning them too much.

> >Also note that the work on submitting your Silmbus driver core to
> >mainline appears totally stalled, there was just an initial posting but
> >no followup.

> I guess slimbus driver guy is completely swamped now as SLIMBUS is new
> and it takes a lot of effort to stablize.

Well, it's pretty important that that stuff goes in - if the underlying
APIs for Slimbus turn out not to match the model we've come up with well
then that'd cause problems too.