[alsa-devel] ASoC: Dynamic CODEC DAI
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
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
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
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.
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.
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
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
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.
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.
participants (4)
-
Liam Girdwood -
Mark Brown -
Patrick Lai -
Pierre-Louis Bossart