On 12/5/2024 4:53 PM, Wesley Cheng wrote: > On 12/4/2024 2:49 PM, Pierre-Louis Bossart wrote: >>> >>>>> UAOL is one of our priorities right now and some (e.g.: me) prefer to not pollute their mind with another approaches until what they have in mind is crystalized. In short, I'd vote for a approach where USB device has a ASoC representative in sound/soc/codecs/ just like it is the case for HDAudio. Either that or at least a ASoC-component representative, a dependency for UAOL-capable card to enumerate. >>>> The main difference is that we don’t want the USB audio *control* part to be seen in two places. The only requirement is to stream data with an alternate optimized path, but all the volume control and whatnot is supposed to be done using the regular usb-audio card. It would be complete chaos for userspace if the same volume can be represented differently. >>>> The comparison with HDaudio is not quite right either. In the case of HDaudio, it’s an all-or-nothing solution. The external device is controlled by one entity, either legacy or ASoC based. That choice is made at driver probe time. In the case of USB, the application needs to have the choice of using either the legacy path, or the optimized path that goes through a DSP. I think the last thing you want given this context is to make the USB audio device an ASoC codec. >>>> I find it rather interesting that this architectural feedback comes at the v30, it’s unfair to Wesley really... >>> Hi Pierre, >>> >>> Obviously I'm late. After scanning the history of this one, indeed it's been a while since v1 has been sent. And thus I posted no NACKs. At the same time if I am to choose between: provide feedback vs provide no-feedback, I'd rather choose the former even if I'm to be ignored/overridden by a subsystem maintainer. >>> >>> The subsystem maintainers also hold the last word, and I have no problem with them merging the patches if they believe its existing shape is good-enough. For example, my team could follow up this implementation next year with a patchset expanding/updating the functionality. I see this as a viable option. >> That’s what we had in mind before I left Intel. The interfaces seen by userspace are PCM devices and kcontrols, it doesn’t matter too much if there is one card, two cards, and if the implementation relies on an ASoC codec, a library or something else. >> The bulk of the work is to enable the USB offload from top to bottom, by changing PipeWire/CRAS/HAL to select the new optimized path when available and deal with plug/unplug events. >> Improvements at the kernel level can be done later if required. It’s hard to argue that the proposal in this series is fundamentally broken, but as usual it’s likely that some requirements are missing or not known yet. The same thing happened with compressed offload, none one thought about gapless playback until Android made it a requirement. Maybe what we’d need is a ‘protocol version’ for USB offload so that changes can be tracked and handled? > > Thanks for chiming in, Pierre. So for now, with the next revision I have prepared, I'm currently adding: > > 1. Some improvements to xHCI sideband to account for core sequences that need to be notified to the offload driver, ie transfer ring free > > 2. Moved the USB SND offload mixer driver into the QC vendor module for now, as instructed by Takashi: > > https://lore.kernel.org/linux-usb/87cyiiaxpc.wl-tiwai@xxxxxxx/ > > 3. Added separate kcontrols for fetching mapped PCM device and card indexes (versus one that returns a card and PCM device pair [array]) > > 4. Removed some jack controls (enable/disable) from soc-usb > > 5. Updated documentation for #3 > > > Those are the major changes that will come in the next revision. I'm just trying to figure out who/where the "protocol version" should be checked if we decided to add it. (or if we need to check for it anywhere...) From the userspace perspective, it should be agnostic to how we've implemented offloading from the kernel, and I don't see any major shifts in how userspace implements things even if we make improvements from kernel. Hi Takashi, Could you possibly help share some direction on what you think of the current design, and if you think its detrimental that we make modifications mentioned by Cezary? I have the next revision ready for review, but I wanted to get a better sense on the likeliness of this landing upstream w/o the major modifications. Thanks Wesley Cheng > > Thanks > > Wesley Cheng >
