Re: [PATCH 3/3] ALSA: usb-audio: Do not expose sticky mixers
Rong Zhang <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.sound |
|---|---|
| Message-ID | <[email protected]> |
Hi Michal, On Sat, 2026-08-08 at 22:10 +0200, Michal Pecio wrote: > On Wed, 05 Aug 2026 22:32:00 +0800, Rong Zhang wrote: > > On Tue, 2026-08-04 at 23:55 +0200, Michal Pecio wrote: > > > My $.02 - was there no way to deal with this in userspace, > > > or to make it opt-in rather than opt-out? > > > > While userspace can ignore hardware mixers via some configurations, > > the current opt-out model is really about: > > > > When we can't distinguish between both, will the extra advantages > > of exposing a broken GET_CUR mixer outweigh the disadvantages of > > exposing a sticky one? > > > > My answer is no. > > > > A sticky hardware mixer breaks volume control completely. If a user > > doesn't know how to tell the audio stack to ignore it, it will be a > > terrible out-of-box experience. > > Being able to work around it by using a different mixer control doesn't > sound like "completely broken" to me. It seems the whole issue is that > some mixer controls have no effect and you believe you can detect them > by changing the control a few times and seeing if the vaule read back > from HW changes accordingly. Of course, this also falsely catches mixer > controls which are write-only. > > I'm not familiar with UAC and ALSA mixer APIs so I don't know, but as > the whole issue boils down to incluencing userspace mixer selection, > is there really no way to perform the same heuristic in userspace, > snd-usb-audio always caches mixer value and tries to provide the cached value whenever possible. As a side effect, userspace can't detect sticky mixers using standard mixer control interfaces. Thanks, Rong > move > the quirk list there as well and let users override it with a click? > > Regards, > Michal