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

[Arnaud Pouliquen]

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

I will send a V2 that integrates SNDRV_CTL_INDEX_AUTO (and
SNDRV_CTL_DEVICE_AUTO for the ASoC PCM link)

Thanks & Regards
Arnaud