[alsa-devel] [RFC 0/4] ALSA controls management using index/device/sub-devices fields

[Takashi Iwai]

On Tue, 08 Nov 2016 15:16:29 +0100,
Arnaud Pouliquen wrote:
> 
> Hello Clemens,
> 
> On 11/08/2016 10:52 AM, Clemens Ladisch wrote:
> > Arnaud Pouliquen wrote:
> >> 1-1) How to Instantiate generic ALSA control
> >>
> >> The  point is the handling of multi instance of generic ALSA controls.
> >> In this case "prefix" can not be used. Controls have to be identified
> >> by a combination of device/sub-device/index
> > 
> > Controls are identified either
> > - by their numid, or
> > - by the combination of iface/device/subdevice/name/index.
> > 
> > The device/subdevice fields are used to link controls with PCM devices;
> > this is needed for per-stream volume controls or for the S/PDIF "Mask"
> > controls, which set properties of some PCM stream.
> Seems that today device/subdevice are also used to differentiate PCM
> control, using a "virtual" device/subdevice that is not linked to a
> "real PCM device. This is what i understand when i parse HDA-Intel.conf
> for instance HDA-Intel.pcm.hdmi.1: "DEVICE=7,"

The HD-audio shouldn't be taken as the good reference.  It has its own
mapping there just to keep the backward compatibility with the old
implementation that was basically broken.


> > 
> >>     Should we always apply this rules?
> >>       - MIXER control type: as it is not linked to PCM device but card,
> >> 	"index" is used to instantiate control.
> > 
> > "index" is _always_ used.
> > 
> >>       - PCM control type: as it is linked to PCM device,
> >>         "device/subdevice" is used to instantiate control.
> >>     Or could we consider that a control can be instantiated using
> >>       device/subdevice fields  and/or index fields?
> > 
> > The amixer tool does not allow controls with the same iface/name/index
> > values, regardless of the (sub)device values.  This appears to be a bug
> > in amixer (because the behaviour is different from the kernel's), but
> > the (sub)device fields were never intended to be used by MIXER controls,
> In fact only amixer simple controls are not handled using (sub)device
> fields. if simple control is only MIXER controls, it is not a bug as it
> respect rules.
> 
> > and PCM controls typically are inactive when their stream is closed.
> if we consider that 'IEC958 Playback Default' is a PCM control. This is
> not compatible with iecset application that sets the control without
> opening the PCM device.

Yes, it's a slight inconsistency.  But it's specific to "Default"
stuff.  All other controls are usually tied with PCM open/close.

> > 
> >>    - Concerning IEC controls, should we consider them as PCM or MIXER
> >>      type controls? In current implementations both are used...
> > 
> > MIXER controls are shown in alsamixer.  PCM controls are hidden, and
> > accessed by software.
> > 
> > Something like "IEC958 Playback Switch" should be MIXER, and "IEC958
> > Playback Con Mask", PCM.
> > 
> >> 2) From driver point of view
> >>
> >> 2-1) None SOC drivers:
> >> Today solution seems to base indexation on both "index" and "device"
> >> number. Device indexation seems not linked to PCM device number
> >> Example in  ea9b43addc4d ("ALSA: hda - Fix broken workaround for HDMI/SPDIF conflicts").
> >> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b43add
> >>
> >> => The drawback is that each driver has to implement it. Could be nice
> >>    to have in generic code....
> > 
> > In the good old times, the ALSA framework assumed that a driver knows
> > all its controls, and handles conflicts by assignind index values.
> > 
> > It would be useful to let snd_ctl_add() assign a new index automatically,
> > but only if explicitly requested (e.g., something like
> > "#define SNDRV_CTL_INDEX_AUTO -1").
> you right, seems more reasonable, I will update this for a V2, if
> everyone is ok for this solution...

Right, this behavior must be optional.  For the normal drivers, the
duplicated controls *are* errors, and we catch it instead.  For
drivers that are aware of confliction and want the automatic
workaround (e.g. HD-audio driver does it already), this kind of code
would be useful to be in the common place.


thanks,

Takashi