Hi Pierre, On 6/21/2024 1:27 AM, Pierre-Louis Bossart wrote: > > >> I'll spend some time to evaluate your suggestion about moving the logic >> to control the offloading from USB SND versus ASoC, since there are >> valid points. However, before I do that, I just want to make sure folks >> are also inline with that thinking. I've had to put a lot of effort >> moving things around such as the previous example, and now you've >> suggested to move it back to the vendor specific drivers. >> >> @Pierre, since you've helped with providing a lot of valuable input in >> the previous revisions on the kcontrol uses, what do you think about the >> proposal from Amadeusz? Basically shifting the offload device selection >> into USB SND from the ASoC USB BE driver, and having this per USB SND >> device. >> >> [1] >> https://lore.kernel.org/linux-usb/20231017200109.11407-30-quic_wcheng@xxxxxxxxxxx/ > This thread is very hard to follow, I am not sure I fully understood the > initial proposal, and I am not sure I follow Amadeusz' either. > > 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. > > 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 .... 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. 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) Thanks Wesley Cheng
