On 8/29/24 21:40, Wesley Cheng wrote:
The USB SND path may need to know how the USB offload path is routed, so that applications can open the proper sound card and PCM device. The implementation for the QC ASoC design has a "USB Mixer" kcontrol for each possible FE (Q6ASM) DAI, which can be utilized to know which front end link is enabled.
When an application/userspace queries for the mapped offload devices, the logic will lookup the USB mixer status though the following path:
MultiMedia* <-> MM_DL* <-> USB Mixer*
The "USB Mixer" is a DAPM widget, and the q6routing entity will set the DAPM connect status accordingly if the USB mixer is enabled. If enabled, the Q6USB backend link can fetch the PCM device number from the FE DAI link (Multimedia*). With respects to the card number, that is straightforward, as the ASoC components have direct references to the ASoC platform sound card.
An example output can be shown below:
Number of controls: 9 name value Capture Channel Map 0, 0 (range 0->36) Playback Channel Map 0, 0 (range 0->36) Headset Capture Switch On Headset Capture Volume 1 (range 0->4) Sidetone Playback Switch On Sidetone Playback Volume 4096 (range 0->8192) Headset Playback Switch On Headset Playback Volume 20, 20 (range 0->24) USB Offload Playback Route PCM#0 0, 1 (range -1->255)
The "USB Offload Playback Route PCM#*" kcontrol will signify the corresponding card and pcm device it is offload to. (card#0 pcm - device#1) If the USB SND device supports multiple audio interfaces, then it will contain several PCM streams, hence in those situations, it is expected that there will be multiple playback route kcontrols created.
Signed-off-by: Wesley Cheng quic_wcheng@quicinc.com
sound/soc/qcom/qdsp6/q6usb.c | 104 +++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+)
diff --git a/sound/soc/qcom/qdsp6/q6usb.c b/sound/soc/qcom/qdsp6/q6usb.c index 10337d70eb27..c2fc0dedf430 100644 --- a/sound/soc/qcom/qdsp6/q6usb.c +++ b/sound/soc/qcom/qdsp6/q6usb.c @@ -132,6 +132,109 @@ static int q6usb_audio_ports_of_xlate_dai_name(struct snd_soc_component *compone return ret; }
+static int q6usb_get_pcm_id_from_widget(struct snd_soc_dapm_widget *w) +{
- struct snd_soc_pcm_runtime *rtd;
- struct snd_soc_dai *dai;
- for_each_card_rtds(w->dapm->card, rtd) {
dai = snd_soc_rtd_to_cpu(rtd, 0);/** Only look for playback widget. RTD number carries the assigned* PCM index.*/if (dai->stream[0].widget == w)return rtd->num;- }
- return -1;
+}
+static int q6usb_usb_mixer_enabled(struct snd_soc_dapm_widget *w) +{
- struct snd_soc_dapm_path *p;
- /* Checks to ensure USB path is enabled/connected */
- snd_soc_dapm_widget_for_each_sink_path(w, p)
if (!strcmp(p->sink->name, "USB Mixer") && p->connect)return 1;- return 0;
+}
+static int q6usb_get_pcm_id(struct snd_soc_component *component) +{
- struct snd_soc_dapm_widget *w;
- struct snd_soc_dapm_path *p;
- int pidx;
- /*
* Traverse widgets to find corresponding FE widget. The DAI links are* built like the following:* MultiMedia* <-> MM_DL* <-> USB Mixer**/- for_each_card_widgets(component->card, w) {
if (!strncmp(w->name, "MultiMedia", 10)) {/** Look up all paths associated with the FE widget to see if* the USB BE is enabled. The sink widget is responsible to* link with the USB mixers.*/snd_soc_dapm_widget_for_each_sink_path(w, p) {if (q6usb_usb_mixer_enabled(p->sink)) {pidx = q6usb_get_pcm_id_from_widget(w);return pidx;}}
Humm, there should be a note that the design assumes that the USB offload path exposes a single PCM per endpoints - same as the non-offloaded path. If the ASoC card has multiple PCMs for each endpoint, possibly with different processing on each PCM, then the mapping would fail.
The other question is whether you need to walk in the DAPM graph, in theory DPCM has helpers to find which FEs are connected to which BE.