On 7/4/2024 12:05 AM, Wesley Cheng wrote:
On 7/3/2024 2:50 AM, Pierre-Louis Bossart wrote:
There are really multiple layers to deal with
a) is the controller able to support the offload path? IIRC this is
embedded in an obscure XHCI property, it would make sense to
expose it
as a control, or component string, of the USB card.
If a component string/tag is desired, I already have some way of
doing that. I can add it to the USB card.
b) is there a companion card capable of dealing with the offload
path?
Since the presence of this card may depend on driver probe, there
should
be a control on the USB card. userspace could detect changes to this
control and detect if that path is or is no longer enabled.
So currently, the "USB Offload Playback Capable Card" kcontrol (on
the USB card) will determine if there is an offload path. However,
this differs than what Amadeusz is suggesting, in that he wants a
single kcontrol created for EACH USB card identified (per USB audio
device), and a simple enable/disable control to determine if the
offload path is enabled for that card/pcm stream.
It would be a simpler approach for the userspace, and if the card
that handles the offload card isn't present, then these
enable/disable control will be set to "disabled," and even if users
attempt to set the control, it won't go through.
Not following. Are you suggesting userspace would modify the
enable/disable status?
Yes, this is the suggestion. One writeable kcontrol on the USB SND
audio device that will control if that USB audio device is going to
be offloaded. If the kcontrol reads back "enabled" (or 1) then
userspace knows that the offload path is active. Else, if it reads
"disabled" (or 0) after the attempt to set the kcontrol, then the
offload path was unsuccessfully enabled, ie maybe due to no available
offload streams.
It's a bit over-engineered IMHO.
My alternate suggestion is a read-only control reporting that offload is
possible. Then userspace attempts to open a PCM device on the ASoC card,
any failures due to resources would be handled at that point.
I would just have a read-only control that reports what the hardware
can
do and which other card can deal with offload. It's up to userspace to
select the offloaded PCM device or not.
That is what I have implemented in the previous patch series. One
USB SND kcontrol within each USB audio device, which points to the
ASoC platform card that supports offloading:
"USB Offload Playback Capable Card" --> returns the card index to the
ASoC platform card
>From there the offloading control is all within the ASoC platform
card. This is opposite to what Amaduesz suggested in that, the
offload control of which USB device to offload should be within USB
SND (not ASoC)
It's very hard to follow, I don't understand what userspace needs to
'control' - in the modify sense. What userspace needs is a place to read
from, and then select the PCM device and follow usual ALSA configuration
with hw_params.
From what I've seen I assumed that goal is to allow Offloading of
specific stream from USB card. Otherwise I would say controls are not
needed at all, as more user friendly solution is Offloading streams in
order they are used as long as resources are available.
That's not great in terms of audio routing, you'd really want more rules
or controlled behavior where the order in which devices are used does
not matter.
So to clarify, when I mention to 'control' this is in case userspace does want to modify which USB device is offloaded. By default, the current behavior is that the latest USB headset is going to be enabled for offloading. IF say...userspace has some mechanism to switch which USB device is offloaded, they can do so using:
USB Offload Playback Route Card Select
USB Offload Playback Route PCM Select
The above controls are read/write. read will fetch the current USB card and pcm indexes being enabled for offload. write will set the USB card and pcm index to enable offload on. Both reside on the ASoC card that is associated w/ the USB BE DAI link.
c) which PCM device is actually offloaded? This could be plural
for some
implementations. The mapping between PCM devices exposed by the USB
card, and those exposed by the companion card, should be known to
userspace. I am not sure how this would be done though, a variable
number of controls is a sure way to confuse userspace.
Expanding on Amadeusz's suggestion, my idea is to have an
enable/disable kcontrol per USB stream. For example, one USB card
could have multiple PCM devices (USB streams). So we would have
something like:
PCM Offload Playback Enable Stream#0 enable/disable
PCM Offload Playback Enable Stream#1 enable/disable
....
are those read-only or not?
No, writable and readable.
The writable part introduces a complicated error handling, e.g. what
happens if you have an offloaded stream and then this control is changed
with amixer while streaming?
-EBUSY? and keep old value
That would require a stop, fw_free, close, reopening of the
non-offloaded device and restart. Best to avoid interrupting streams, if
there are no resources that should be detected with an early fail during
open/hw_params. Once the stream is flowing, it should not be interrupted
- unless the USB device is removed of course.
I agree. We don't want to interrupt streams if some reason someone tries to switch the offload path. If there is already an active offload stream, then any attempt to switch/control which USB card/pcm stream is offload is going to be ignored.
So we'd know which USB card and PCM device is selected for USB
SND. However, I see what you're getting at in case there are
multiple supported streams, because userspace needs to know which
ASoC card/pcm combination corresponds to which USB device/combination.
I don't understand how this would help map the two parts? There's
got to
be an additional mapping...
It won't help with the mapping. That is something which we'd need to
add, suggestion below.
What do you think about having a USB card kcontrol to display the
mapped ASoC card and PCM indexes?
PCM Offload Playback Enable Stream Mapping#0 0, 1 (ASoC card#0,
PCM device#1)
To summarize, if we did this, I'd plan to remove all the kcontrols
in ASoC card, and have the following in the USB card for an USB
audio device that supports one USB stream:
PCM Offload Playback Enable Stream#0 enable/disable
PCM Offload Playback Enable Stream Mapping#0 0, 1 (ASoC card#0,
PCM device#1)
... which is suggested here.
Assuming these are read-only controls, we would need to know which PCM
device on the USB card can be optimized with the use of which PCM
device
on the ASoC card. That means a set of three values. You would also want
a number of streams to make the guesswork on controls less painful.
OK, so now to just figuring out something that both you and Amadeusz
can agree on before I put time implementing it. So I've implemented
the "enable/disable" path that Amadeusz suggested, which is
highlighted in my previous response, for evaluation purposes. The
overall question is which layer should control the devices that will
be offloaded. In my submissions up until now, the control was given
to the ASoC platform card to determine which USB device to offload.
Amadeusz mentioned that it might be beneficial to move the control to
the USB SND devices, because what if the offloading is NOT backed by
ASoC. (highlighted in [1]) However, IMO the current implementation
assumes there is ASoC involved, which should mean that there is some
platform "card" that is backing the offload path. Please let me know
if my understanding is incorrect, @Amadeusz.
I still fundamentally don't get why userspace would try and modify any
controls, this makes the flows more complicated IMHO since you also have
the PCM open/hw_params stages.
I really think it'd be more than enough if the USB card exposed
read-only values showing that offload is possible and which card/device
to map to. Then userspace uses the ASoC PCM device and errors are
handled at that level.
Just so I understand...is it really desired that userspace doesn't have the flexibility to choose which USB device is offloaded? I know it complicates what needs to be done, but it could be just an additional feature that can be added later on. Again, by default, we select the last USB headset plugged in to be enabled for offload by default.
If it chooses endpoint by itself perhaps you can send patch set without
controls first? This has added benefit of less patches in series, making
it easier to review and it won't block whole patch set by discussion on
controls feature. Controls can be added in followup series.
I tend to agree, less values to change, less chance something breaks.
However I think that there should be some way to disable Offload in case
something doesn't work properly. (It doesn't have to be control, one can
go with module parameter or sysfs toggle or something.)
Agree with this, a 'static' configuration to disable offload would be
just fine. Module parameter is fine.
A control to read if offload is possible and what the mapping is would
be good. From there on, userspace may open the offloaded PCM and deal
with all events (hw_params not supported, xruns, removal, etc).
I can look into adding this mapping part to the USB SND card, so we know which ASoC card/pcm devices are associated to the USB SND device for offloading. Thank you for the discussions and input!
Thanks
Wesley Cheng
