Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

[Cezary Rojewski]

On 2024-12-04 8:47 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.

Kind regards,
Czarek