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

[Arnaud Pouliquen]

Hi,

On 11/09/2016 01:33 PM, Takashi Sakamoto wrote:
> Hi,
> 
> On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
>> 3) Patches proposed:
>> Based on these observations, here are some patches that i tested in my
>> environment. There are complementary,  and could answer to some
>> limitations mentioned above.
>>
>> 3-1) Alsa-utils patch
>>
>> - iecset: allow to select control with device and sub-device numbers
>>   This patch allows to access to 2 iec controls differentiated by
>>   device/sub-devices numbers
>> => For me, this patch is mandatory to be able to address the ASoC IEC
>>    controls, in case of no fix is implemented to allows index field
>>    update in ASoC.
>>
>> 3-2) Alsa driver patches
>>   - ASoC: core: allow PCM control binding to PCM device
>>   	Add relationship between DAIs PCM controls and PCM device.
>>
>>   - ALSA: control: increment index field for duplicated control.
>>    	Generic implementation of the patch proposed in HDA driver
>>         (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b43add)
>>
>>   - ASoC: sti: use bind_pcm_ctl
>>   	implementation of bind_pcm_ctl for sti driver.
> 
> In my view, this patchset includes two attempts:
> 1.to add a framework into ALSA SoC part to relate some control element 
> sets to PCM devices
> 2.to allow drivers in ALSA SoC part to add some control element sets 
> from the same codes according to entries of dtb
> 
> To achieve above 2nd attempt, it changes ALSA control core to accept 
> several control element sets with the same name by assigning proper 
> indexes to the sets.
> 
> Well, since your former messages, you continue using the word, 'general' 
> or 'generic'. If it were somewhat general, it should satisfy 
> requirements in whole this subsystem. Actually, there's none of such 
> requirements outside of ALSA SoC part. For the drivers outside of ALSA 
> SoC part, design of target sound card is fixed in advance, therefore 
> programmers can assign control element sets to PCM devices in usual 
> ways. At least, current infrastructure in ALSA control core can satisfy 
> the programmers.
> 
> Therefore, I think that your attempts includes over-generalization. In 
> theory, it can bring over-specification easily and it causes code 
> complication or unmaintained codes.

I based my RFC on the fact that i was facing same kind of problem than
HDA driver (last time i mention it). In this context, i don't think that
it was senseless to have a global approach.
If not the good approach, let's refocus on ASoC, that's fine by me.
> 
> 
> Focusing on ALSA SoC part, there's a requirement to register control 
> element sets from the same code, in fact. So I wonder why you don't 
> start your explanation in an aspect of it. In short, I can't understand 
> the reason that you adhere to such an inappropriate generalization for 
> this subsystem.
> 
> In this patchset, you adhere to usage of 'index' field. But there's 
> another way; assigning different identification information to the 
> control element sets. Let us to start discussion from this point? At 
> least, Iwai-san said, former driver for Intel High Definition Audio is 
> necessarily not a good example for a model to c
> onsider about this issue and the usage of 'index' is not 
> well-generalized[1].
> 
> Finally, it's better to clear main points of your issue, for practical 
> and meaningful discussion for better approaches, before starting this 
> discussion, I think. At least, there's over-generalization, 
> misunderstandings of design and interfaces, driver-specific historical 
> reasons and so on.
> 
> 
> [1] [alsa-devel] [RFC 0/4] ALSA controls management using 
> index/device/sub-devices fields
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.html
> 
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.

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

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.
       Furthermore, this "virtual" value has to be aligned with the one
       defined in alsa-lib conf file(s).
     - iecset uses only index to differentiate IEC controls. But in
       ASoC implementation this is not possible as index is forced to 0.

Regards
Arnaud