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

[Arnaud Pouliquen]

On 11/16/2016 10:34 AM, Takashi Sakamoto wrote:
> On Nov 14 2016 22:58, Arnaud Pouliquen wrote:
>>>> 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).
> 
> In below call graph, each module cannot directly indicate the 'device' 
> number because 'struct snd_soc_card.num_rtd' is incremented by ALSA SoC 
> core and the number is used as an argument for 'snd_pcm_new_internal()' 
> or 'snd_pcm_new()'.
> 
> (sound/soc/soc-core.c)
> snd_soc_register_card()
> ->snd_soc_instantiate_card()
>    ->soc_bind_dai_link() (each on card->num_links/dai_link_list)
>      ->soc_new_pcm_runtime()
>      ->soc_add_pcm_runtime()
>        list_add_tail(&card->rtd_list)
>        rtd->num = card->num_rtd
>        card->num_rtd++
>    ->soc_probe_link_dais() (each on card->rtd_list)
>      (sound/soc/soc-pcm.c)
>      ->soc_new_pcm(rtd, num = rtd->num)
>        ->snd_pcm_new_internal(num)
>        ->snd_pcm_new(num)
>        struct snd_soc_pcm_runtime.pcm = pcm
>    ->snd_card_regiser()
> 
> Thus, modules are forced to 'guess' the card structure in a point of PCM
> character devices. I think you expressed this as 'virtual'.
Yes. Or fix an arbitrary PCM device value if not possible to guess.
> 
> Well, as a glance of ALSA SoC core, we have a call of 'struct 
> snd_soc_card.late_probe()' just before 'snd_card_register()'. We can 
> probably add ad-hoc control element sets for each PCM character devices.
> 
> snd_soc_register_card()
> ->snd_soc_instantiate_card()
>    ->soc_bind_dai_link()
>    ->soc_probe_link_dais()
>    ->snd_soc_add_card_controls()
>    ->struct snd_soc_card.late_probe()
>    ->snd_card_register()
> 
> But it seems to be a bit cumbersome. I think it better to add a smart 
> framework for the PCM-related controls. In this point, I agree with your 
> direction.

Another point is that, at least in theory, a DAI driver can add a
control after card creation. In this case PCM control should also be
associated to PCM device. Late probe could not handle it.

If we are aligned on direction, what is your suggestion to continue
discussion?
Do you want to continue discussion based on [RFC 1/4] ASoC: core: allow
PCM control binding to PCM device?
Other?

> 
>>>>        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.
> 
> As long as I know, 'pcm/iec958.conf' and 'pcm/hdmi.conf' use different 
> strategy to handle PCM-related control element set for IEC958 type. Your 
> configuration does not work well for pcm.iec958 plugin.
> 

Please could you detail?
HDMI supports more configurations than SPDIF (e.g HBRA). Furthermore
application can retrieve HDMI sinks capability with EDID. So full agree
that strategy can be different. That's why Two IEC controls are needed.
But focusing on 'pcm/iec958.conf' and 'pcm/hdmi.conf', they are almost
identical...

Thanks and Regards

Arnaud