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

Cezary Rojewski
2024-12-04T22:11:39Z

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