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'.
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.
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.
- 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.
Yes, enough later, we need to discuss about user space.
However, your issue includes a batch of issues on both of kernel land
and user land. Intractableness, toughness, hardness, something like that
for each of them is not so light and small. I think it better to solve
these child issues step by steap. In this context, I said 'another'.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
