Hi Amadeusz,
On 6/18/2024 4:42 AM, Amadeusz Sławiński wrote:
On 6/17/2024 7:02 PM, Wesley Cheng wrote:
Hi Amadeusz,
On 6/13/2024 12:46 AM, Amadeusz Sławiński wrote:
On 6/12/2024 9:28 PM, Wesley Cheng wrote:
Hi Amadeusz,
On 6/12/2024 7:47 AM, Amadeusz Sławiński wrote:
On 6/11/2024 1:58 AM, Wesley Cheng wrote:
(...)
+In the case where the USB offload driver is unbounded, while USB
SND is
unbounded -> unbound
(...)
+SOC USB and USB Sound Kcontrols
+===============================
+Details
+-------
+SOC USB and USB sound expose a set of SND kcontrols for
applications to select
+and fetch the current offloading status for the ASoC platform
sound card. Kcontrols
+are split between two layers:
+
+ - USB sound - Notifies the sound card number for the ASoC
platform sound
+ card that it is registered to for supporting audio offload.
+
+ - SOC USB - Maintains the current status of the offload path,
and device
+ (USB sound card and PCM device) information. This would be
the main
+ card that applications can read to determine offloading
capabilities.
+
+Implementation
+--------------
+
+**Example:**
+
+ **Sound Cards**:
+
+ ::
+
+ 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
+ SM8250-MTP-WCD9380-WSA8810-VA-DMIC
+ 1 [C320M ]: USB-Audio - Plantronics C320-M
+ Plantronics Plantronics C320-M at
usb-xhci-hcd.1.auto-1, full speed
+
+
+ **Platform Sound Card** - card#0:
+
+ ::
+
+ USB Offload Playback Route Card Select 1 (range -1->32)
+ USB Offload Playback Route PCM Select 0 (range -1->255)
+ USB Offload Playback Route Card Status -1 (range -1->32)
+ USB Offload Playback Route PCM Status -1 (range -1->255)
+
+
+ **USB Sound Card** - card#1:
+
+ ::
+
+ USB Offload Playback Capable Card 0 (range -1->32)
+
+
+The platform sound card(card#0) kcontrols are created as part of
adding the SOC
+USB device using **snd_soc_usb_add_port()**. The following
kcontrols are defined
+as:
+
+ - ``USB Offload Playback Route Card Status`` **(R)**: USB sound
card device index
+ that defines which USB SND resources are currently offloaded.
If -1 is seen, it
+ signifies that offload is not active.
+ - ``USB Offload Playback Route PCM Status`` **(R)**: USB PCM
device index
+ that defines which USB SND resources are currently offloaded.
If -1 is seen, it
+ signifies that offload is not active.
+ - ``USB Offload Playback Route Card Select`` **(R/W)**: USB
sound card index which
+ selects the USB device to initiate offloading on. If no
value is written to the
+ kcontrol, then the last USB device discovered card index will
be chosen.
I see only one kcontrol, what if hardware is capable of offloading
on more cards, is it possible to do offloading on more than one
device?
+ - ``USB Offload Playback Route PCM Select`` **(R/W)**: USB PCM
index which selects
+ the USB device to initiate offloading on. If no value is
written to the
+ kcontrol, then the last USB device discovered PCM zero index
will be chosen.
+
+The USB sound card(card#1) kcontrols are created as USB audio
devices are plugged
+into the physical USB port and enumerated. The kcontrols are
defined as:
+
+ - ``USB Offload Playback Capable Card`` **(R)**: Provides the
sound card
+ number/index that supports USB offloading. Further/follow up
queries about
+ the current offload state can be handled by reading the
offload status
+ kcontrol exposed by the platform card.
+
Why do we need to some magic between cards? I feel like whole
kcontrol thing is overengineered a bit - I'm not sure I understand
the need to do linking between cards. It would feel a lot simpler
if USB card exposed one "USB Offload" kcontrol on USB card if USB
controller supports offloading and allowed to set it to true/false
to allow user to choose if they want to do offloading on device.
(...)
Based on feedback from Pierre, what I understood is that for some
applications, there won't be an order on which sound card is
queried/opened first.
Yes if you have multiple cards, they are probed in random order.
So the end use case example given was if an application opened the
USB sound card first, it can see if there is an offload path
available. If there is then it can enable the offload path on the
corresponding card if desired.
This still doesn't explain why you need to link cards using controls.
What would not work with simple "Enable Offload" with true/false
values on USB card that works while you do have above routing controls?
Sorry for the late response.
I think either way, even with the "Enable Offload" kcontrol in USB
SND, we'd need a way to link these cards, because if you have multiple
USB audio devices connected, and say... your offload mechanism only
supports one stream. Then I assume we'd still need to way to
determine if that stream can be enabled for that USB SND device or not.
Since the USB SND isn't really the entity maintaining the offload
path, I went with the decision to add that route selection to the ASoC
platform card. It would have access to all the parameters supported by
the audio DSP.
Problem with card selection is that it will most likely work in pretty
random way during reboots and similar scenarios.
Taking from your example:
USB Offload Playback Route Card Select 1 (range -1->32)
USB Offload Playback Route PCM Select 0 (range -1->255)
USB Offload Playback Route Card Status -1 (range -1->32)
USB Offload Playback Route PCM Status -1 (range -1->255)
This tells that hw:1,0 will be offloaded USB card. What happens if after
reboot the USB card and offload card change places, the control will be
pointing at its owner... Another scenario to consider is that user
attaches two USB cards and only first one does offload. Now what happens
when they enumerate in different order after reboot (swapping places)?
Taking into the account that most systems restore previous values of
controls in some way - this will point at wrong card.
That sounds like a problem that would exist with current USB SND
implementation too? Removing the offloading perspective, how does the
system ensure that the previous setting stays persistent? For example,
as you mentioned, depending on which USB device enumerates first, the
sound card may be different so cards will be switched.
I think I mentioned this previously in another discussion, but I think
the idea was that with the
USB Offload Playback Capable Card
kcontrol, would allow the system to at least know there is an offload
capable path pointing to the ASoC platform card, and fetch more detailed
information about which device is selected for offloading, etc...
In my opinion Offload capability should be the capability of the
endpoint - in this case USB card (even if in the background it needs to
talk to some other device) and it should be exposed as such. Currently
you are mixing capabilities of your audio card with capabilities of USB
card.
And adding more controls will not make it easy to use from end user
perspective. Most users will most likely want for the devices to perform
offload automatically if possible to save power and just have control to
disable it in case they want to test if it works better without it in
case of some problems.
I agree with you that we need to keep the controls at a minimum, but I
think what I have in place is fairly reasonable. If we switch to having
the USB SND controlling things, we'd save maybe one control? I think
keeping the offload status controls are still fairly valuable in both
scenarios, as userspace may need to verify which USB SND card is being
offloaded.
Additional question what happens if you want to offload two usb cards,
currently the above set of controls allows you to only point at one
card, will you be adding additional set of above controls dynamically
for each USB card attached?
It would depend on the number of offload streams that folks may be
supporting on their platform. In our case we only have one available
stream, so applications would need to switch between the two devices
using the card/pcm selector.
In this case, there will be only one set of controls to select the
card/pcm device. As of now (I think I'll change to to add another
separate set of controls per stream) if you did support multiple
streams, then the current card/PCM device selector would take in
multiple arugments. (ie for two streams the kcontrol can take in two values)
Thanks
Wesley Cheng
