[alsa-devel] asihpi: Control naming

[Takashi Iwai]

At Fri, 01 Oct 2010 09:23:52 +1300,
Eliot Blennerhassett wrote:
> 
> Thanks Takashi,
> 
> On 30/09/10 18:46, Takashi Iwai wrote:
> > At Thu, 30 Sep 2010 16:44:14 +1300,
> > Eliot Blennerhassett wrote:
> >>
> >> Hi all,
> >>
> >> I'm struggling with getting the correct names for controls, so that they
> >> show up correctly in the Playback or Capture modes of alsamixer
> >>
> >> E.g. "PCM 3 Capture Meter" appears in the playback controls?
> >>
> >> How is capture vs playback display determined?
> >> or to put it another way: What are the rules for creating control names.
> > 
> > The rule is simple.  The control name consists of three parts,
> > base-name, direction, and suffix.  The direction is either "Playback"
> > or "Capture", and the suffix is either "Volume" or "Switch".
> > Then the direction and the capture are omitted, and grouped together
> > with other controls with the same base name.
> > (There are a few exceptional cases, but in general the rule above is
> >  applied.)
> > 
> > "PCM 3 Capture Meter" is regarded as a playback control since it has
> > an invalid (unknown) suffix.  If it's "PCM 3 Meter Capture Volume",
> 
> But it is not a volume, it is a level meter?!
> We also have controls for tuners, microphones, equalizers, sampleclocks
> etc.  Surely these can't be all "Volume" or "Switch"
> I'm not sure why the suffix has any bearing on the direction?

Actually, this control is handled as a "neutral" control without
the directional attribute.  alsamixer or else may show it in the
playback but also may show in capture, too.

Maybe the mixer element parser can be improved to look for the
direction word to determine the additional direction attribute.
If one word of either "Playback" or "Capture" is found, we can
assume its direction as such.


> > in mixer, it'll become "PCM 3 Meter".  Also, you can (better to) use
> > an index for each control, so it can be expressed as "PCM Meter" with
> > index 3, too.
> 
> We used to have it this way.
> It makes sense for the controls attached to the single node e.g. player
> or lineout.
> However, it is confusing for identifying the volumes between play1 and
> lineout0?
> 
> Without using indices I have (consistent)
> 
> PCM 0 Playback Volume
> PCM 1 Playback Volume
> PCM 0 to Lineout 0 Playback Volume
> PCM 0 to Lineout 1 Playback Volume
> PCM 1 to Lineout 0 Playback Volume
> PCM 1 to Lineout 1 Playback Volume
> Lineout 0 Playback Volume
> Lineout 1 Playback Volume
> 
> with indices (maybe)
> PCM Playback Volume, 0
> PCM Playback Volume, 1
> PCM 0 to Lineout 0 Playback Volume
> PCM 0 to Lineout 1 Playback Volume
> PCM 1 to Lineout 0 Playback Volume
> PCM 1 to Lineout 1 Playback Volume
> Lineout Playback Volume, 0
> Lineout Playback Volume, 1
> 
> Now, if I could have 2 indices, maybe ...
> PCM to Lineout Playback Volume, 1, 0

So, you have matrix volumes.  We had discussions how to implement
the matrix volumes, and there is actually an infrastructure to
handle multi-dimension volume arrays.  But, no driver is using the
feature, IIRC...

> Also, on the input multiplexer (route?), the options are
> Linein 0
> Linein 1
> 
> rather than
> Linein, 0
> Linein, 1
> 
> 
> I.e. the names match, rather than using indices in one place, and
> distinct names in another

One (known) remaining problem is the matching between an enum item
string to a control (or mixer) with an index number.  For example,
some HD-audio codecs have multiple mics, and a similar problem appears
there.


Takashi