[alsa-devel] ALSA and MediaController

[Takashi Iwai]

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