ALSA and MediaController

ALSA and MediaController

[pl bossart]

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.

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.

Thanks,
-Pierre

Re: ALSA and MediaController

[Mark Brown]

On Tue, May 17, 2011 at 12:48:59PM -0500, pl bossart wrote:

> - 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.

Currently it is static for at least ASoC but I'd expect this will change
as the DSP stuff gets more advanced.

Re: ALSA and MediaController

[Takashi Iwai]

At Tue, 17 May 2011 11:02:28 -0700,
Mark Brown wrote:
> 
> On Tue, May 17, 2011 at 12:48:59PM -0500, pl bossart wrote:
> 
> > - 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.
> 
> Currently it is static for at least ASoC but I'd expect this will change
> as the DSP stuff gets more advanced.

There are actually cases where controls are dynamically
created/removed.  We had it in some drivers, but I don't remember
whether we still keep it or changed in a different way.
Anyway, the alsa-lib API also can notify the event per
addition/removal of controls, too.


Takashi

Re: 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

Re: ALSA and MediaController

[Mark Brown]

On Tue, May 17, 2011 at 08:43:43PM +0200, Takashi Iwai wrote:

> 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.

Yeah, the discussion was to initially keep the array of controls and
associate that with a separate graph so that we have a way for userspace
to figure out how all the controls are plumbed together and what they
actually mean.  One of the main drivers for interest in the media
controller API was that it's already doing the graph drawing to
userspace bit.

> > - 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.

We also need to be able to add non-control nodes to what's visible to
the user, showing fixed function connections.

Re: ALSA and MediaController

[Raymond Yau]

2011/5/18 pl bossart <bossart.nospam@gmail.com>:
> 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.

How Media controller or PA handle hda jack retasking of those 3 jacks
motherboard (channel mode or smart 5.1 switch) ?

For those mini ITX motherboard without front audio panel, there will
be no capture source if the HDA codec does not support stereo mix
after the driver retask those input jacks for 5.1 outputs

Does this mean that those 3 jacks , 5 jacks and 6 jacks desktop need
to add the rear panel jack to use snd_jack_report ?

Re: ALSA and MediaController

[Mark Brown]

Raymond, it's fairly basic process for Linux lists to do a reply to
all.  Please pay attention to this.

On Sat, May 21, 2011 at 10:43:55AM +0800, Raymond Yau wrote:
> 2011/5/18 pl bossart <bossart.nospam@gmail.com>:
> > 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.

> How Media controller or PA handle hda jack retasking of those 3 jacks
> motherboard (channel mode or smart 5.1 switch) ?

> For those mini ITX motherboard without front audio panel, there will
> be no capture source if the HDA codec does not support stereo mix
> after the driver retask those input jacks for 5.1 outputs

This just sounds like a fairly basic reconfiguration of the CODEC, it's
no different to any other rerouting.

> Does this mean that those 3 jacks , 5 jacks and 6 jacks desktop need
> to add the rear panel jack to use snd_jack_report ?

It seems like a good idea to report any jacks we can do detection on....

Re: ALSA and MediaController

[Raymond Yau]

2011/5/21 Mark Brown <broonie@opensource.wolfsonmicro.com>:
>
>> How Media controller or PA handle hda jack retasking of those 3 jacks
>> motherboard (channel mode or smart 5.1 switch) ?
>
>> For those mini ITX motherboard without front audio panel, there will
>> be no capture source if the HDA codec does not support stereo mix
>> after the driver retask those input jacks for 5.1 outputs
>
> This just sounds like a fairly basic reconfiguration of the CODEC, it's
> no different to any other rerouting.
>
>> Does this mean that those 3 jacks , 5 jacks and 6 jacks desktop need
>> to add the rear panel jack to use snd_jack_report ?
>
> It seems like a good idea to report any jacks we can do detection on....
>

But snd_jack API seem does not has any definition for "Line In" - Blue jacks ?

The jack retasking is performed by snd_hda_sequence_write_cache(codec,
chmode[mode].sequence) in snd_hda_ch_mode_put() for some HDA codecs

Re: ALSA and MediaController

[Mark Brown]

On Mon, May 23, 2011 at 01:39:08PM +0800, Raymond Yau wrote:
> 2011/5/21 Mark Brown <broonie@opensource.wolfsonmicro.com>:

I see you've ignored my remarks about CCing people and managed to cut
that text without also deleting other unneeded context; please do CC
people, it is actually important if you want people to engage in
discussion.

> But snd_jack API seem does not has any definition for "Line In" - Blue jacks ?

I don't see any substantial issue with adding such a definition if
someone has use for it?

> The jack retasking is performed by snd_hda_sequence_write_cache(codec,
> chmode[mode].sequence) in snd_hda_ch_mode_put() for some HDA codecs

I'm not sure what the point you're trying to make here is - the
internals of individual drivers shouldn't be too relevant to external
interfaces?