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

[Arnaud Pouliquen]

hello Takashi,

On 11/12/2016 05:23 AM, Takashi Sakamoto wrote:
>> So I propose to continue discussion on a simple and concrete use case:
>> The 'IEC958 Playback Default' control.
>>
>> In my ASoC driver i have one HDMI and one SPDIF outputs.
>> so I have 2'IEC958 Playback Default' PCM controls.
>> => Each control can be set independently.
> 
> Yes. It's a demand in your issue.
> (here, I ignore a process to generalize the issue for wider range in 
> this subsystem because it's another issue.)
> 
>> Regarding control identification field (struct snd_ctl_elem_i):
>>  .numid;  => set by ALSA framework
>>  .iface;  => must be SNDRV_CTL_ELEM_IFACE_PCM
>>  .device; => must be linked to PCM device , but not possible for
>>              ASoC DAI...
>>  .subdevice => not used in ASoC implementation
>>  .name      => 'IEC958 Playback Default'
>>  .index     => not used in ASoC, forced to 0 by snd_soc_cnew
>>
>> Other solution: use control "prefix"? not possible as control has a
>> pre-defined name.
>>
>> => Only solution to differentiate the control: "device" field.
>>    (that seems coherent as it a PCM device).
> 
> This is one of solutions we can perform for this issue. As a feasibility 
> study, in the end of this message, I wrote a small program with a 
> feature of 'user-defined control element set' in ALSA control core.
> 
> I think usage of 'device' field is better than usage of prefix for 
> 'name' field. It clearly represents the relationship between control 
> element set and PCM devices. And it's just suitable for this issue.
> 
This is also my view.
Now base on your mail, that point possibility to extend name
(http://www.spinics.net/lists/alsa-devel/msg56713.html):
> I note that we can give unique names to control element set for IEC
> 60958. According to this document, Between "IEC958" and the rest, we can
> put arbitrary string.
>
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/designs/control-names.rst

I missed this, Seems that name is also another solution for IEC controls.
Gstreamer and pulseaudio use PCM name to set the AES value (e.g.
'B2120.pcm.hdmi.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2' so simple
to adapt alsa conf file with good name.
iecset could be adapted in a quite simple way using device name or an
new option ( e.g. "-e name control name extension IEC958 <name> Playback
Default")

But, perhaps better to use device... as it match with expected PCM
control rule and as it could be applied for controls
based on standard syntax: [LOCATION] SOURCE [CHANNEL] [DIRECTION] FUNCTION

>> Issues:
>>      - use "device" in ASOC DAI driver means that driver needs to
>>        define a "virtual" PCM device value, not the PCM device.
>> 	=> this break the rule that mention that PCM control should be
>>         linked to a PCM device.
> 
> Please show me where related codes and structures are. At least, I 
> cannot understand what you said because it's really abstracted.
As example, here is my current implementation (correspond to the piece
of code i would like to rework):
http://www.lingrok.org/xref/linux-linus/sound/soc/sti/sti_uniperif.c#232
- "device" field is set to the instance ID of the DAI uniperiph player.
- "index" filed is also set but overwritten by ASoC core.
In this implementation what i name "virtual device is the "device" value
uni->id
HDMI: uni->id = 0 ( PCM device associated is hw:0,0)
SPDIF: uni->id = 3 ( PCM device associated is hw:0,2)

If i don't set the device value then i can not create both controls.
A better way should be to set device to PCM device.
This was the topic of [RFC 1/4] ASoC: core: allow PCM control binding to
PCM device (http://www.spinics.net/lists/alsa-devel/msg56482.html).

> 
>>        Furthermore, this "virtual" value has to be aligned with the one
>>        defined in alsa-lib conf file(s).
> 
> Ditto.
I have not upstreamed my card conf file but an example is available at
end of my mail.
Value of the device field must be aligned with ASoC driver device values:
HDMI: STI-B2120.pcm.hdmi.0.hooks.0.device=0
SPDIF: STI-B2120.pcm.iec958.0.hooks.0.device=3

If these controls were associated to the PCM device, I should not have
to fix the value but I should be able to retrieve it.

> 
>>      - iecset uses only index to differentiate IEC controls. But in
>>        ASoC implementation this is not possible as index is forced to 0.
> 
> _Apparently_, mixer APIs in alsa-lib is not well-designed to represent 
> capacity of ALSA control core. It's not better to judge somwthing 
> according to its design.
Not sure to follow you... I can not see any issue in alsa-lib. Just a
limitation of using iecset with ASoC implementation.
> 
> Although we need to improve iecset tool, this is another issue.
> 
>From my point of view, iecset is part of the topic even if i agree that
details on potential update could/should be discuss in a separate thread.
In case, PCM control device value is not aligned with PCM device, a
workaround exists, even if it does not respect the alignment between PCM
control and PCM device...
For iecset, i have no solution except patch it, if we consider that
index field incrementation is not the good solution for PCM controls.
So for me it is important to keep it in mind in discussions.

-------------

<confdir:pcm/iec958.conf>
<confdir:pcm/hdmi.conf>

STI-B2120.pcm.iec958.common {
	@args [ CARD DEVICE CTLINDEX AES0 AES1 AES2 AES3 ]
	@args.CARD {
		type string
	}
	@args.DEVICE {
		type integer
	}
	@args.CTLINDEX {
		type integer
	}
	@args.AES0 {
		type integer
		# consumer, not-copyright, emphasis-none, mode=0
		default 0x00
	}
	@args.AES1 {
		type integer
		# original, PCM coder
		default 0x00
	}
	@args.AES2 {
		type integer
		# source and channel
		default 0x00
	}
	@args.AES3 {
		type integer
		# fs=48000Hz, clock accuracy=1000ppm
		default 0x00
	}
	type hooks
	slave.pcm {
		type hw
		card $CARD
		device $DEVICE
	}
	hooks.0 {
		type ctl_elems
		hook_args [
		{
			interface PCM
			name "IEC958 Playback Default"
			device 3
			lock true
			preserve true
			value [ $AES0 $AES1 $AES2 $AES3 ]
		}
		]
	}
	hint.device $DEVICE
}

STI-B2120.pcm.iec958.0 {
	@args [ CARD AES0 AES1 AES2 AES3 ]
	@args.CARD { type string }
	@args.AES0 { type integer }
	@args.AES1 { type integer }
	@args.AES2 { type integer }
	@args.AES3 { type integer }
	@func refer
	name {
		@func concat
		strings [
			"cards.STI-B2120.pcm.iec958.common:"
			"CARD=" $CARD ","
			"DEVICE=2,"
			"CTLINDEX=0,"
			"AES0=" $AES0 ","
			"AES1=" $AES1 ","
			"AES2=" $AES2 ","
			"AES3=" $AES3
		]
	}
}

STI-B2120.pcm.hdmi.common {
	@args [ CARD DEVICE CTLINDEX AES0 AES1 AES2 AES3 ]
	@args.CARD {
		type string
		default 0
	}
	@args.DEVICE {
		type integer
		default 0
	}
	@args.CTLINDEX {
		type integer
	}
	@args.AES0 {
		type integer
		# consumer, not-copyright, emphasis-none, mode=0
		default 0x00
	}
	@args.AES1 {
		type integer
		# original, PCM coder
		default 0x00
	}
	@args.AES2 {
		type integer
		# source and channel
		default 0x00
	}
	@args.AES3 {
		type integer
		# fs=48000Hz, clock accuracy=1000ppm
		default 0x00I missed this, Seems that name is also another solution
for IEC controls.

	}
	type hooks
	slave.pcm {
		type hw
		card $CARD
		device $DEVICE
	}
	hooks.0 {
		type ctl_elems
		hook_args [
			{
				interface PCM
				name "IEC958 Playback Default"
				device 0
				lock true
				preserve true
				value [ $AES0 $AES1 $AES2 $AES3 ]
			}
		]
	}
	hint.device $DEVICE
}
STI-B2120.pcm.hdmi.0 {
	@args [ CARD AES0 AES1 AES2 AES3 ]
	@args.CARD { type string }
	@args.AES0 { type integer }
	@args.AES1 { type integer }
	@args.AES2 { type integer }
	@args.AES3 { type integer }
	@func refer
	name {
		@func concat
		strings [
			"cards.STI-B2120.pcm.hdmi.common:"
			"CARD=" $CARD ","
			"DEVICE=0,"
			"CTLINDEX=0,"
			"AES0=" $AES0 ","
			"AES1=" $AES1 ","
			"AES2=" $AES2 ","
			"AES3=" $AES3
		]
	}
}

Thanks and Regards
Arnaud