Hi Pierre,
On 5/9/2024 6:11 AM, Pierre-Louis Bossart wrote:
It is expected for the USB offloading driver to add the kcontrol to the
sound card associated with the USB audio device. An example output
would
look like:
tinymix -D 1 get 'USB Offload Playback Capable Card'
0 (range -1->32)
You already gave the following examples in patch 29:
"
USB offloading idle:
tinymix -D 0 get 'USB Offload Playback Route Status'
-->-1, -1 (range -1->32)
USB offloading active(USB card#1 pcm#0):
tinymix -D 0 get 'USB Offload Playback Route Status'
-->1, 0 (range -1->32)
"
Can you clarify how many controls there would be in the end?
For USB offload situations, there will be a set of controls for
playback status and playback select. The offload jack will also be
there to tell us if there is an offload path available for the
platform ASoC sound card.
Also isn't tinymix -D N going to give you the controls for card N?
Yes, since the offload portion is handled as a DPCM DAI link to the
platform ASoC card, it will be included as a kcontrol for that.
Thanks
Wesley Cheng
Sorry for responding again. I read your email again, and wanted to also
add that aside from the above, which are all within the ASoC layer, as
we discussed previously, we should have a kcontrol in the USB SND card
to determine if there is an ASoC platform card capable of offloading.
This is also available from the SND card created by the USB audio device.
That makes sense: if the application wanted to use a given endpoint, it
could check if there is a 'better' path exposed by another card. It'd be
a lot easier than reading controls from random cards.
Was this part of this patchset or more of an idea for a future addition?
Its part of this patchset. Please refer to patch#34. The
mixer_usb_offload is initialized by the offload entity residing in USB
SND (qc_usb_audio_offload), and will add it to the sound card associated
with the USB device.
Thanks
Wesley Cheng
