> 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. 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. 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. At any rate, I would put all the controls under the USB generic card, because it's always present no matter what the controller or DSP configurations are.
