Re: [PATCH 3/3] ALSA: usb-audio: Do not expose sticky mixers

[Takashi Iwai <tiwai@suse.de>]

On Wed, 05 Aug 2026 16:32:00 +0200,
Rong Zhang wrote:
> 
> Hi Michal,
> 
> Thanks for the report.
> 
> On Tue, 2026-08-04 at 23:55 +0200, Michal Pecio wrote:
> > On Sat, 11 Apr 2026 01:49:04 +0800, Rong Zhang wrote:
> > > Some devices' mixers are sticky, which accept SET_CUR but do absolutely
> > > nothing. Registering these mixers confuses userspace and results in
> > > ineffective volume control.
> > > 
> > > Check if a mixer is sticky by setting the volume to the maximum or
> > > minimum value and checking for effectiveness afterward. Prevent the
> > > mixer from being registered if it turns out to be sticky.
> > > 
> > > Quirky device sample:
> > > 
> > >   usb 7-1: New USB device found, idVendor=0e0b, idProduct=fa01, bcdDevice= 1.00
> > >   usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > >   usb 7-1: Product: Feaulle Rainbow
> > >   usb 7-1: Manufacturer: Generic
> > >   usb 7-1: SerialNumber: 20210726905926
> > >   (Mic Capture Volume)
> > > 
> > > Signed-off-by: Rong Zhang <i@rong.moe>
> > 
> > This appears to break (yet another) device, as reported below.
> > Not 100% sure because both affected users ran away to -lts and
> > appear to be of the "won't compile kernel patches" variety.
> > 
> > https://bbs.archlinux.org/viewtopic.php?id=314220
> 
> Let me quote some words below:
> 
> > After updating, my headset output was halved (or so) despite the same mixer levels and sounds weird/bassy/distorted during fading audio. Previously my volume was set to 25%, but now i need 40-50% for the same volume, and the quality seems worse.
> > 
> 
> The new 100% still maps to the original 100% as the sticky check sets the
> mixer value to max before bailing out. IOW, it won't result in always-
> halved physical volume.
> 
> If the dB reporting is correct, both a hardware mixer and a soft mixer
> should map to similar physical volume on the same device. That is, volume
> other than 100% behaving differently usually implies broken dB reporting.
> So the difference in volume mapping isn't really an issue caused by soft
> mixer. Instead, it exposes yet another device quirk.
> 
> Distortion at low volume is a side effect of soft mixers on some devices.
> Usually it's hardly audible. I guess the SteelSeries Arctis Nova 5 uses a
> poorly-performed lossy 2.4GHz codec, making the distortion worse.
> 
> > 
> > [...]
> > 
> > Broken kernel output:
> > 
> > Jul 09 17:06:05 <HOSTNAME> kernel: usb 3-1: Product: SteelSeries Arctis Nova 5
> > Jul 09 17:06:05 <HOSTNAME> kernel: usb 3-1: Manufacturer: SteelSeries
> > Jul 09 17:06:05 <HOSTNAME> kernel: hid-generic 0003:1038:2232.0008: hiddev99,hidraw7: USB HID v1.11 Device [SteelSeries SteelSeries Arctis Nova 5] on usb-0000:13:00.3-1/input3
> > Jul 09 17:06:05 <HOSTNAME> kernel: input: SteelSeries SteelSeries Arctis Nova 5 as /devices/pci0000:00/0000:00:08.1/0000:13:00.3/usb3/3-1/3-1:1.4/0003:1038:2232.0009/input/input12
> > Jul 09 17:06:06 <HOSTNAME> kernel: hid-generic 0003:1038:2232.0009: input,hidraw8: USB HID v1.11 Device [SteelSeries SteelSeries Arctis Nova 5] on usb-0000:13:00.3-1/input4
> > Jul 09 17:06:06 <HOSTNAME> kernel: hid-generic 0003:1038:2232.000A: hiddev100,hidraw9: USB HID v1.11 Device [SteelSeries SteelSeries Arctis Nova 5] on usb-0000:13:00.3-1/input5
> > Jul 09 17:06:07 <HOSTNAME> kernel: usb 3-1: 9:0: sticky mixer values (-19712/0/256 => 0), disabling
> > Jul 09 17:06:07 <HOSTNAME> kernel: usb 3-1: 10:0: sticky mixer values (-21248/0/256 => 0), disabling
> 
> With the kmsg dump, as well as the user confirming that the UAC mixer
> responds to SET_CUR, I can confirm the device has broken GET_CUR mixers
> instead of sticky ones.
> 
> I will submit a patch to add QUIRK_FLAG_MIXER_GET_CUR_BROKEN for the
> device, so that the UAC mixer can be reenabled.
> 
> > 
> > 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.
> 
> In contrast, exposing a broken GET_CUR mixer is more like an optimization
> for slightly better volume control quality (if the mixer is otherwise
> implemented properly) compared to a soft mixer.
> 
> Other than the unfortunate combination with lossy codecs, usually the
> distortion caused by a soft mixer is only audible on a device with high
> gain, but such a device should also come with a gain control knob anyway
> -- the user really should use the knob to tune the volume.
> 
> Thanks,
> Rong

Well, this is getting more troublesome than expected, as it seems;
there have been a few more bug reports, too (I forgot places), and I'm
afraid that the tendency will remain.

My impression is that Windows drivers don't care about the GET_CUR, so
often the device firmware doesn't treat it at all.  If that's the
case, it'd be also fine just to take the given mixer value as-is.
OTOH, if we want to be more strict, keeping the high default is also
logical -- which is our current behavior.  That is, there is no
perfect answer to this, and it purely depends on our decision.

At least, for 7.3 kernel, I'll keep the current code and take
BROKEN_GET_CUR quirks for the reported devices.  But if the reports
keeping flooding, we'd have to reconsider.  Let's see.


thanks,

Takashi