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

[Takashi Sakamoto]

On Nov 6 2016 22:43, Arnaud Pouliquen wrote:
>> 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.

I don't think so. But in your case, 'snd-soc-simple-card' is used to 
maintain own sound card instance, and this module has no handlers for 
the callback. So we don't utilize the callback for this aim unless 
integrating the module.

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

If you focused on ALSA SoC part only, I'd not continue this discussion 
more. I'm not a developer for the part, and join in this discussion just 
for ALSA control interface.

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

I prefer discuss after deciding your approach on kernel side. But in 
previous message I misunderstood that S/PDIF interface of your STI SoC 
in system side can handle IEC 60958 sub-frame. Actually, it seems not to 
be. In this case, usage of pcm hook for 'ctl_elems' type might be 
appropriate. I'm sorry to have confused you.


Regards

Takashi Sakamoto