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

[Rong Zhang]

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@xxxxxxxx>
> 
> 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

> 
> Regards,
> Michal