On 8/8/24 14:11, Amadeusz Sławiński wrote:
On 8/8/2024 3:19 AM, Wesley Cheng wrote:
Hi Amadeusz,
On 8/6/2024 7:51 AM, Amadeusz Sławiński wrote:
On 8/1/2024 3:17 AM, Wesley Cheng wrote:From past discussions, I think so far everyone is on board with the
With USB audio offloading, an audio session is started from the ASoC
platform sound card and PCM devices. Likewise, the USB SND path is
still
readily available for use, in case the non-offload path is desired. In
order to prevent the two entities from attempting to use the USB bus,
introduce a flag that determines when either paths are in use.
How can this happen? Can you provide some example with list of
devices and which one should block the other? If I recall correctly
devices are already exclusive unless you support substreams which
ASoC does not at the moment.
idea of having both the USB sound card and PCM devices exist in
conjunction w/ the USB offload path, which is going to be done over
the ASoC platform card. So for example,
Sorry, I must have missed that and examples in documentation could
probably be a bit better, it is bit late at patchset 24 that I
understood about this now. And is part of a reason why I was confused
about kcontrol implementation.
/ # cat /proc/asound/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.2, full speed
This device currently has the following sound cards within the system:
- card#0 - ASoC platform card: handles USB offload, speaker, etc...
- card#1 - USB SND card: card created for interacting with the
connected USB device.
So now, with USB offloading in the picture, there are basically two
paths that can start attempting to utilize the same USB device
endpoints. Let's keep it simple and assume the device only has one
playback substream (which means only one PCM device)
/proc/asound/card1 # cat stream0
Plantronics Plantronics C320-M at usb-xhci-hcd.1.auto-1.2, full
speed : USB Audio
Playback:
Status: Stop
Interface 2
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ADAPTIVE)
Rates: 8000, 16000, 24000, 32000, 44100, 48000
Bits: 16
Channel map: FL FR
So the patch here will prevent transfers from happening from both the
offload path and directly over the USB SND PCM device, which
correlates to the following paths:
- offload: card#0 pcm#0
- USB SND: card#1 pcm#0
Well, it's one way to do that.
Personally I would just reuse USB FEs and when opening one check if it
can be offloaded:
* check if someone disabled Offload on FE
* check if it is connected to HW that can do Offload at all
* check if Offload streams are available on backing HW
* check if audio formats are supported by above HW
* do any other checks that may be needed
and then just redirect FE setup to relevant driver doing offload if
able, otherwise just go standard path.
How would userspace know which 'USB FE' to use?
The discovery and mapping between cards and devices is the main problem.
It's much simpler to start from a generic "USB-Audio" card, and check if
the functionality exposed by one PCM device is offloaded to another
ASoC-based card. Then all the interaction can start with this offloaded
device without any guesswork on the mapping between cards/devices.
The point is that the USB-Audio card will always be there, whereas those
ASoC cards will have different names and implementation restrictions. In
the example we have here, if you want to capture audio you *have* to use
the USB-Audio card.
In other words, it's just an endianness type of debate with no clear
difference between solutions and a matter of personal preference. The
reality is that there's a clear asymmetrical pattern. The USB-Audio card
is always present and usable, the ASoC offloaded cards are only present
in specific implementations and only usable if conditions are met.