On 11/08/2016 03:30 PM, Takashi Iwai wrote:
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.
Thanks for the clarification. In this case, "[RFC 4/4 ] iecset: allow to select control with device and sub-device numbers" seems coherent, to allow access to this PCM controls with device/subdevice values... I will propose it in a separate patch-set to not mix kernel and application patch...
As 'IEC958 Playback Default' is specific, i will also try to rework and propose a new version of [PATCH v4 3/6] ALSA: pcm: add IEC958 channel status control helper (http://www.spinics.net/lists/alsa-devel/msg47615.html)
- 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.
- 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=ea9b4...
=> 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.
I will send a V2 that integrates SNDRV_CTL_INDEX_AUTO (and SNDRV_CTL_DEVICE_AUTO for the ASoC PCM link)
Thanks & Regards Arnaud