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
