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