Currently, a mixer is disabled when its GET_CUR is sticky, causing
userspace to fall back to soft mixers, unless
QUIRK_FLAG_MIXER_GET_CUR_BROKEN is set. This leads to issues on some
wireless headphones with broken GET_CUR but effective SET_CUR, which use
poorly-performed lossy codecs and are prone to audible distortion at low
volume. They have to set the quirk flag to reeanble the mixer.

Considering that users can always opt into soft mixers if they need it,
i.e., when SET_CUR is stubbed, demote the severity of sticky GET_CUR by
marking GET_CUR as broken and only provide mixer values from the cache.
The mixer itself is still registered.

The default behavior of sticky check now becomes what
QUIRK_FLAG_MIXER_GET_CUR_BROKEN originally does, so the quirk flag is no
longer needed.

On some devices, whether their GET_CUR being sticky depends on whether
hotpluggable components are present. When the hotpluggable components
are missing on probe, their GET_CUR behavior is classified as broken.
Therefore, reverse QUIRK_FLAG_MIXER_GET_CUR_BROKEN as
QUIRK_FLAG_MIXER_GET_CUR_OK, so that it can be set to prevent the
heuristics from gating GET_CUR.

Note that even if the quirk flag is set, init_cur_mix_raw() should still
initialize the mixer value to cval->min, otherwise restoring the bogus
saved value on the first channel could lead to unbalanced channels.

The first user of QUIRK_FLAG_MIXER_GET_CUR_OK is Logitech PRO X
Wireless, whose Playback mixer's GET_CUR somehow becomes broken when the
microphone is detached, so set QUIRK_FLAG_MIXER_GET_CUR_OK to prevent
the mixer behavior from depending on whether the microphone is attached.
The device also needs QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE as the minimum
mixer value doesn't work properly.

Reported-by: Alexander Niemeyer <adventureFAN@gmx.de>
Closes: https://msgid.link/6262cbbd-d1f2-4c9d-a1c7-9c5d12636f4b@gmx.de
Closes: https://msgid.link/7984832b-86f6-4934-bfc0-1ed70218973a@gmx.de
Signed-off-by: Rong Zhang <i@rong.moe>
---
Rong Zhang (4):
      ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_ALWAYS_SET_RATE
      ALSA: usb-audio: Demote the severity of sticky GET_CUR
      ALSA: usb-audio: Reverse MIXER_GET_CUR_BROKEN as MIXER_GET_CUR_OK
      ALSA: usb-audio: Add quirk flags for Logitech PRO X Wireless

 Documentation/sound/alsa-configuration.rst | 25 ++++-----
 sound/usb/mixer.c                          | 82 ++++++++++--------------------
 sound/usb/quirks.c                         | 19 +++----
 sound/usb/usbaudio.h                       | 24 ++++-----
 4 files changed, 56 insertions(+), 94 deletions(-)
---
base-commit: 26260251022fbc2f248a3d747a9b2b961b18d2d8
change-id: bfb273cc-uac-demote-sticky-check-f92d4aaca7e6

Thanks,
Rong

On Sat, 22 Aug 2026 20:52:27 +0200,
Rong Zhang wrote:
> 
> Currently, a mixer is disabled when its GET_CUR is sticky, causing
> userspace to fall back to soft mixers, unless
> QUIRK_FLAG_MIXER_GET_CUR_BROKEN is set. This leads to issues on some
> wireless headphones with broken GET_CUR but effective SET_CUR, which use
> poorly-performed lossy codecs and are prone to audible distortion at low
> volume. They have to set the quirk flag to reeanble the mixer.
> 
> Considering that users can always opt into soft mixers if they need it,
> i.e., when SET_CUR is stubbed, demote the severity of sticky GET_CUR by
> marking GET_CUR as broken and only provide mixer values from the cache.
> The mixer itself is still registered.
> 
> The default behavior of sticky check now becomes what
> QUIRK_FLAG_MIXER_GET_CUR_BROKEN originally does, so the quirk flag is no
> longer needed.
> 
> On some devices, whether their GET_CUR being sticky depends on whether
> hotpluggable components are present. When the hotpluggable components
> are missing on probe, their GET_CUR behavior is classified as broken.
> Therefore, reverse QUIRK_FLAG_MIXER_GET_CUR_BROKEN as
> QUIRK_FLAG_MIXER_GET_CUR_OK, so that it can be set to prevent the
> heuristics from gating GET_CUR.
> 
> Note that even if the quirk flag is set, init_cur_mix_raw() should still
> initialize the mixer value to cval->min, otherwise restoring the bogus
> saved value on the first channel could lead to unbalanced channels.
> 
> The first user of QUIRK_FLAG_MIXER_GET_CUR_OK is Logitech PRO X
> Wireless, whose Playback mixer's GET_CUR somehow becomes broken when the
> microphone is detached, so set QUIRK_FLAG_MIXER_GET_CUR_OK to prevent
> the mixer behavior from depending on whether the microphone is attached.
> The device also needs QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE as the minimum
> mixer value doesn't work properly.
> 
> Reported-by: Alexander Niemeyer <adventureFAN@gmx.de>
> Closes: https://msgid.link/6262cbbd-d1f2-4c9d-a1c7-9c5d12636f4b@gmx.de
> Closes: https://msgid.link/7984832b-86f6-4934-bfc0-1ed70218973a@gmx.de
> Signed-off-by: Rong Zhang <i@rong.moe>

Applied all four patches now.  Thanks.


Takashi

Hi there,

I am continuing to have a bug across the latest 7.2 kernels, as well as 
6.18 and 6.12 LTS branches concerning hardware volume control on my 
Audient EVO4, that I think is related to this issue - would appreciate 
some guidance if not.

Specifically, when changing volume via the knob on the front of the 
device, everything works perfectly, but when modifying volume through 
pwvucontrol or wpctl the volume drastically lowers. As far as I can 
understand, pipewire is resorting to a software mixer for the device for 
some reason, whilst also actively modifying the hardware volume at the 
same time - is this what should occur with "sticky mixers"?

prior to kernels 7.2 (tested 7.1.13) the volume control works perfectly 
via wpctl.

I attempted to add a quirk flag to snd_usb_audio to work around the 
issue without success:

```

sudo modprobe snd_usb_audio quirk_flags=2708:0006:mixer_get_cur_broken

```


I also tried applying these patches to add extra mixer controls to my 
EVO4: https://lore.kernel.org/lkml/20260919151840.24371-1-arc@gmx.li/

This worked fine after I modified the UCM conf for the device to follow 
the new (correct) naming scheme for the master volume, but the volume 
problem was still occuring.


is this problem I'm having related to these sticky mixers?


I originally reported this to wireplumber thinking it was an issue 
there, more information is provided at the link below:

https://gitlab.freedesktop.org/pipewire/wireplumber/-/work_items/1022


As I've never reported anything upstream to the kernel before, I'd 
appreciate extra guidance where necessary. Would love to get this solved 
as its making all volume control on my system unusable, and the change 
which has caused it has also been pushed to LTS kernels, leaving me with 
no working kernel besides reverting to the now EOL 7.1 series.


Faaris

Hi Faaris,

On Fri, 2026-09-25 at 19:33 +0100, Faaris Ansari wrote:
> Hi there,
> 
> I am continuing to have a bug across the latest 7.2 kernels, as well as 
> 6.18 and 6.12 LTS branches concerning hardware volume control on my 
> Audient EVO4, that I think is related to this issue - would appreciate 
> some guidance if not.
> 
> Specifically, when changing volume via the knob on the front of the 
> device, everything works perfectly, but when modifying volume through 
> pwvucontrol or wpctl the volume drastically lowers. As far as I can 
> understand, pipewire is resorting to a software mixer for the device for 
> some reason, whilst also actively modifying the hardware volume at the 
> same time - is this what should occur with "sticky mixers"?
> 
> prior to kernels 7.2 (tested 7.1.13) the volume control works perfectly 
> via wpctl.
> 
> I attempted to add a quirk flag to snd_usb_audio to work around the 
> issue without success:
> 
> ```
> 
> sudo modprobe snd_usb_audio quirk_flags=2708:0006:mixer_get_cur_broken
> 
> ```

Nah. This is not the proper way to specify module parameters. It silently
succeeds when the module is already loaded, without actually modifying
the parameter. It only works when the module has not been loaded.

It's more preferred to write the option to /etc/modprobe.d/, unload the
module, and probe the driver again. After that, check
/sys/module/snd_usb_audio/parameters/quirk_flags to see if it's applied.

Note that while you can modify the parameter through sysfs, I don't
recommend you to do so, as it can't handle line feed properly.

> 
> 
> I also tried applying these patches to add extra mixer controls to my 
> EVO4: https://lore.kernel.org/lkml/20260919151840.24371-1-arc@gmx.li/
> 
> This worked fine after I modified the UCM conf for the device to follow 
> the new (correct) naming scheme for the master volume, but the volume 
> problem was still occuring.
> 
> 
> is this problem I'm having related to these sticky mixers?
> 
> 
> I originally reported this to wireplumber thinking it was an issue 
> there, more information is provided at the link below:
> 
> https://gitlab.freedesktop.org/pipewire/wireplumber/-/work_items/1022
> 
> 
> As I've never reported anything upstream to the kernel before, I'd 
> appreciate extra guidance where necessary. Would love to get this solved 
> as its making all volume control on my system unusable, and the change 
> which has caused it has also been pushed to LTS kernels, 
> 

No, v7.2 is a *stable* version instead of an *LTS* version.

> leaving me with 
> no working kernel besides reverting to the now EOL 7.1 series.

Please test v7.3-rc.

Thanks,
Rong

> 
> 
> Faaris