At Tue, 17 May 2011 12:48:59 -0500, pl bossart wrote:
During the ALSA/Embedded audio workshop two weeks ago we talked about using the MediaController API (merged in 2.6.39) to provide userspace with a graph-like representation of the transforms implemented in firmware or hardware. Two main applications were mentioned:
- volume control, at the moment in PulseAudio we get a flat list of
volume controls and we use a convoluted mixer logic to figure out if 'pcm playback volume' is done before or after 'master playback volume'.
- tuning applications. With literally dozens of controls exposed in
embedded solutions, a flat list is going to be very hard to use. It would make sense during the device tuning steps to figure out which controls is located where to better understand its impacts. This would help create UCM configuration files as well.
The current flat array implementation is a result after hard time with attempts of implementing the graph in mixer API at the time of ALSA 0.5.x. This ended up with a total mess of the code.
Maybe now we'd implement it differently, but I believe that the flat array itself is the best as the primary data form. We can provide some extended attributes to each control if needed.
At the moment the Media Controller does not provide means to set any values/parameters in a media_entity. We would need to cross-reference each media_entity with ALSA controls and use the existing control get/set interfaces. This raises 2 main questions:
- Is the list of ALSA controls is completely defined after the card
initialization step? Or do we have cases where ALSA controls are created dynamically after the init? I tend to believe the former is true but want to verify this with others on the mailing list. It's my understanding that only connections may be changed in such a graph.
- Laurent suggested a new ioctl to export media_entity information to
userspace, as a binary buffer containing a list of TLV (Type-Length-Value) field. However it looks like there's already an ELEM_BYTES control type. It might make more sense to expose this information using native ALSA controls, but again feedback from smart people on this list would be welcome.
You may use a TLV information provided for each control element, too. So far, this provides only the dB information. But it doesn't have to be restricted to that.
Takashi