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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
