Re: [PATCH] ALSA: usb-audio: Check sticky mixers precisely
From: Alexander Niemeyer
Date: Wed Aug 19 2026 - 14:37:53 EST
Hi Rong,
thanks. I have now completed the three tests you asked for.
1. Your sticky-check patch with the detachable Mic boom attached
I tested the same minimal 7.1.8 backport of your ~16-value / 10 ms
sticky-check logic again, this time with the detachable microphone boom
physically attached.
The external snd-usb-audio module was rebuilt and loaded successfully
(the module taint was "O"), and the old 100 ms diagnostic changes were
removed before this test.
The result is still a failure:
sticky mixer values (-16384/0/256 => -3840), disabling
The PCM control exposes only:
Capabilities: pswitch pswitch-joined
and no Playback Volume control.
I repeated this once more with another dongle replug, without changing
the module or touching the volume wheel, and got the same result again.
So:
your sticky-check patch + Mic boom attached
-> still classified as sticky
-> reproduced twice
2. Is Playback SET_CUR really broken after Mic SET_RES with the boom detached?
For this test I detached the microphone boom.
I used a test version of snd-usb-audio which:
- performed the Mic UAC1 resolution probe,
- kept the Playback Volume control exposed,
- clamped the known-broken advertised -64 dB minimum to -63 dB,
- and bypassed the normal ALSA mixer cache so that mixer reads fetch
GET_CUR from the device.
The initial Playback value was:
43 = -20 dB
I played a 3-second 1 kHz test tone and listened to its level.
Then I requested:
23 = -40 dB
The immediate output from the cset operation still showed:
values=43
I waited two seconds and issued a fresh cget. It then returned:
values=23
I played the exact same test tone again, and the second tone was clearly
quieter.
So Playback SET_CUR is physically effective.
At least in this test, the effect after Mic SET_RES with the boom
detached is not that Playback SET_CUR stops working. Instead, GET_CUR
can remain stale for some time after SET_CUR and later reflect the
actual value.
In short:
before: 43 (-20 dB)
SET_CUR requested: 23 (-40 dB)
immediate result: 43
GET_CUR after 2 s: 23
physical volume: clearly quieter
3. QUIRK_FLAG_MIXER_GET_CUR_BROKEN and mixer change notifications
Linux 7.1.8 does not contain QUIRK_FLAG_MIXER_GET_CUR_BROKEN yet, so for
this test I made a minimal backport of the flag behavior to the otherwise
stock 7.1.8 mixer code, without your new sticky-check patch.
I loaded snd-usb-audio with:
quirk_flags=046d:0aba:mixer_get_cur_broken
The kernel detected the constant GET_CUR condition and kept the Playback
Volume control exposed:
sticky mixer values (-16384/0/256 => -3840), disabling
PROXTESTC: treating constant GET_CUR as broken
For this test the microphone boom was attached.
Before turning the physical headset wheel:
ALSA cget: 56
wpctl: Volume 0.72
I then deliberately turned the physical volume wheel further down.
Afterwards:
ALSA cget: 47
wpctl: Volume 0.52
KDE's volume OSD also reacted normally while I turned the wheel.
So, on this device, using MIXER_GET_CUR_BROKEN did not break propagation
of physical mixer changes through the audio stack:
physical wheel
-> ALSA value changed
-> PipeWire value changed
-> KDE OSD reacted normally
Therefore the current picture seems to be:
- Your revised sticky check still rejects the Playback Volume control,
both with the detachable Mic boom attached and detached.
- With the Mic boom detached, Mic SET_RES can make Playback GET_CUR stay
stale after a Playback SET_CUR, but Playback SET_CUR itself is still
physically effective.
- At least on this Logitech device, treating GET_CUR as broken did not
prevent physical wheel changes from reaching ALSA/PipeWire/KDE.
Let me know what you would like me to test next. I have kept the Fedora
test environment and module-signing setup intact.
Thanks,
Alexander
Am 19.08.2026 um 18:39 schrieb Rong Zhang:
Hi Alexander,
On Tue, 2026-08-18 at 17:24 +0200, Alexander Niemeyer wrote:
Hi Rong,Could you test my patch with Mic attached?
one important follow-up to my previous message:
I realized that the detachable microphone boom was not physically connected
to the headset during the direct libusb tests I reported earlier.
I therefore repeated the relevant tests with the boom microphone attached,
and the result changes in an important way.
With the boom microphone attached, on a fresh device:
Mic GET_RES = 256
no SET_RES
Playback:
GET_CUR = -3840 (-15 dB)
SET_CUR = -2048 (-8 dB)
GET_CUR changes to -2048 after 65.3 ms
Result: PASS
After another power cycle, with the boom still attached:
Mic GET_RES before = 256
Mic SET_RES(128) = success
Mic GET_RES after = 256
Playback:
GET_CUR = -3840 (-15 dB)
SET_CUR = -2048 (-8 dB)
GET_CUR changes to -2048 after 66.3 ms
Result: PASS
I also repeated the complete Mic SET_RES sequence:
SET_RES 128
SET_RES 64
SET_RES 32
SET_RES 16
SET_RES 8
SET_RES 4
SET_RES 2
SET_RES 1
All requests return success, GET_RES remains 256, and Playback
SET_CUR(-8 dB)
still works afterwards, with GET_CUR changing after 76.0 ms.
However, with the boom microphone attached, the stock Fedora 7.1.8
snd-usb-audio driver still reproduces the original failure:
sticky mixer values (-16384/0/256 => -3840), disabling
and no PCM Playback Volume control is exposed.
So I need to correct the conclusion from my previous message:Thanks for your tests.
The Mic SET_RES behavior is real, but it depends on whether the detachable
microphone boom is physically connected.
With the boom disconnected:
a single Mic SET_RES(128) is sufficient to make subsequent Playback
SET_CUR ineffective for more than 1200 ms.
With the boom connected:
both a single Mic SET_RES(128) and the full SET_RES sequence leave
Playback SET_CUR working normally.
Let me conclude:
- Mic detached: SET_RES on Mic breaks Playback
- Mic attached: SET_RES on Mic breaks nothing
Still, I doubt if Playback SET_CUR is really broken in the first case.
There is a chance that Playback SET_CUR is effective while GET_CUR
becomes broken.
Could you test:
- Leave the Mic detached
- SET_RES on Mic
- GET_CUR on Playback
- Play some audio, listen to it
- SET_CUR on Playback
- GET_CUR on Playback
- Play some audio again, listen to it, and tell if the physical volume
has changed
The procedure can be achieved by hacking into the snd-usb-audio driver
and nullifying its cache mechanism, so that you can fetch GET_CUR values
from standard ALSA mixer interface.
If you can notice physical volume changes, it implies SET_RES on Mic
break Playback GET_CUR without breaking SET_CUR. Otherwise, it break
Playback SET_CUR.
If it only breaks GET_CUR, it implies the methodology of sticky check is
problematic. In this case I would probably consider demoting the sticky
check's severity.
I am also thinking about how we should demote the severity. Could you
also test if applying QUIRK_FLAG_MIXER_GET_CUR_BROKEN (without this
patch) breaks mixer change notifications? I.e., tune the volume with the
buttons/knobs on the device and see if the audio stack reflects the
change. I guess it will break the notifications, but I would still like
to wait for your confirmation.
Thanks,
Rong
Therefore Mic SET_RES alone does not explain the complete snd-usb-audio
failure in all device configurations. There must be another difference in
the full snd-usb-audio initialization path when the boom is attached.
The separate Playback -64 dB minimum issue I reported remains unchanged:
-64 dB is ineffective, -63 dB works, and attempting -64 dB does not prevent
subsequent valid Playback SET_CUR requests from working.
Sorry for not noticing the detachable-microphone state earlier. I wanted to
send this correction as soon as I confirmed it.
I still have the usbmon/pcapng captures and can run further targeted tests
if useful.
Thanks,
Alexander
Am 18.08.2026 um 16:41 schrieb Alexander Niemeyer:
Hi Rong,
I think we found the reason for the different behavior.
I reproduced the snd-usb-audio initialization sequence step by step
with direct libusb UAC1 control transfers and isolated the problem to
SET_RES on the *Mic Capture Volume control (Feature Unit 3)*.
A fresh-device control test looks like this:
Mic GET_RES = 256
no SET_RES
Playback:
GET_CUR = -3840 (-15 dB)
SET_CUR = -2048 (-8 dB)
GET_CUR changes to -2048 after 68.0 ms
Result: PASS
After another power cycle, I repeated the same test but issued just
*one* SET_RES request to the Mic Feature Unit first:
Mic GET_RES before = 256
Mic SET_RES(128) = success
Mic GET_RES after = 256
Playback:
GET_CUR = -3840 (-15 dB)
SET_CUR = -2048 (-8 dB)
GET_CUR remains -3840 for more than 1200 ms
Result: FAIL
So a single successful |SET_RES(128)| on Feature Unit 3 is sufficient
to make subsequent |SET_CUR| requests to the Playback Volume control
on Feature Unit 2 ineffective.
I also tested the complete Mic SET_RES sequence used by snd-usb-audio:
SET_RES 128
SET_RES 64
SET_RES 32
SET_RES 16
SET_RES 8
SET_RES 4
SET_RES 2
SET_RES 1
All requests return success, while GET_RES remains 256. After that
sequence, Playback SET_CUR also remains ineffective for more than 1200
ms.
Interestingly, the Mic control itself still works after this. In an
ALSA-like Mic probe I could successfully change Mic Volume from 0 dB
to -64 dB and then +1 dB, with GET_CUR reflecting those changes
essentially immediately (~0.3 ms). Playback remained broken afterwards.
I also checked whether SET_RES on the Playback Feature Unit itself
causes the problem. It does not:
Playback GET_RES = 256
SET_RES 128 -> 64 -> 32 -> 16 -> 8 -> 4 -> 2 -> 1
GET_RES still = 256
Playback SET_CUR(-8 dB)
GET_CUR changes successfully after 87.7 ms
So the problematic operation appears specifically to be *SET_RES on
the Mic Feature Unit affecting the Playback Feature Unit*.
I also clarified the separate advertised-minimum issue:
Playback SET_CUR(-64 dB):
no change after >1200 ms
followed by SET_CUR(-8 dB):
works normally after 54.9 ms
Playback SET_CUR(-63 dB):
works after 75.8 ms
followed by SET_CUR(-8 dB):
works after 43.6 ms
Therefore the broken -64 dB endpoint does not leave the device in the
broken state; it is a separate issue. -63 dB works normally.
I also captured usbmon/pcapng traces for both a working direct-libusb
SET_CUR sequence and the failing snd-usb-audio initialization, so I
can send those as well if they are useful.
This also seems to explain why the sticky-check changes did not help:
by the time snd-usb-audio reaches the Playback Volume sticky check,
the earlier Mic SET_RES sanity test has already put the device into
the state where Playback SET_CUR no longer takes effect.
Let me know if you would like me to test a patch or capture any
additional traces.
Thanks,
Alexander
Am 16.08.2026 um 17:08 schrieb Rong Zhang:
Hi Alexander,
On Sun, 2026-08-16 at 16:09 +0200, Alexander Niemeyer wrote:
Hi Rong,Thanks for the information.
Sure. The libusb tests were direct USB Audio Class 1 control transfers
to the headset using libusb/PyUSB, not ALSA mixer operations.
I accessed Feature Unit 2 on AudioControl interface 0, master
channel 0,
with the UAC1 Volume control selector:
wValue = 0x0200 /* Volume control, master channel */
wIndex = 0x0200 /* Feature Unit 2, interface 0 */
I used the standard class-specific requests directly, including
GET_CUR,
GET_MIN, GET_MAX, GET_RES and SET_CUR, with signed 16-bit little-endian
volume values in 1/256 dB units.
The device reported:
GET_CUR: 0 ( 0 dB in that test)
GET_MIN: -16384 (-64 dB)
GET_MAX: 0 ( 0 dB)
GET_RES: 256 ( 1 dB)
For the timing tests I issued SET_CUR for a target value and then
repeatedly queried GET_CUR until the value changed or the timeout
expired.
Valid values became visible after roughly:
-1 dB ~81 ms
-2 dB ~52 ms
-4 dB ~47 ms
-8 dB ~47 ms
-16 dB ~52 ms
-32 dB ~47 ms
The advertised -64 dB minimum behaved differently: SET_CUR returned
successfully, but GET_CUR did not change even after 1000 ms.
To access the AudioControl interface with libusb, I unbound the
AudioControl interface from snd-usb-audio for the duration of the test.
I did not intentionally open a playback stream during those libusb
tests. Because the AudioControl interface had been unbound from
snd-usb-audio, I also do not believe there was an active ALSA playback
stream at that point.
Unfortunately, I still don't exactly see why the device behaved
differently when GET_CUR/SET_CUR requests were sent from snd-usb-audio
compared to your libusb tests.
snd-usb-audio also tries SET_RES to test the sanity of GET_RES. Could
you
test if it breaks your device's GET_CUR?
Maybe comparing them with usbmon can show some clues. You can use
Wireshark to sniff /dev/usbmon*.
Hint: a Thunderbolt port usually corresponds to a dedicated USB root
hub.
If you have one, plug the device to it to get pure usbmon trace results
with no noisy URBs from other devices.
Thanks,
Rong
If the open-stream state is important, I can repeat the experiment
specifically controlling for playback-stream-open versus
playback-stream-closed.
Thanks,
Alexander
Am 16.08.2026 um 15:50 schrieb Rong Zhang:
Hi Alexander,
On Sun, 2026-08-16 at 07:14 +0200, Alexander Niemeyer wrote:
Hi Rong,Really interesting. Maybe the mixer changes its value only when
I tested the sticky-check part of your patch on the Logitech PRO X
Wireless (046d:0aba) on Fedora 44, kernel 7.1.8-200.fc44.x86_64.
Since your patch is based on a newer tree, I used a minimal
backport of
the new ~16-value / 10 ms sticky-check logic to the 7.1.8 code. The
GET_CUR-broken handling from the newer tree was not included; GET_CUR
itself succeeds on this device.
Unfortunately, the playback control is still classified as sticky:
2:0: sticky mixer values (-16384/0/256 => -3840), disabling
I then instrumented the check and tried an additional diagnostic:
after
every successful SET_CUR, wait 100 ms and perform another GET_CUR
before
issuing the next SET_CUR.
For the playback volume, the saved value was -3840 and GET_CUR
remained
at -3840 for every tested value, even after 100 ms, for example:
test=-15104 immediate=-3840 after100ms=-3840
test=-13824 immediate=-3840 after100ms=-3840
test=-3584 immediate=-3840 after100ms=-3840
test=-2304 immediate=-3840 after100ms=-3840
test=-1024 immediate=-3840 after100ms=-3840
test=0 immediate=-3840 after100ms=-3840
So in this case the issue does not appear to be simply that the
accumulated 10 ms sleeps are too short. During the probe-time sticky
check, SET_CUR succeeds but GET_CUR for the playback control remains
unchanged even when each SET_CUR is given 100 ms before the next one.
This differs from my previous direct libusb tests with the
AudioControl
interface unbound, where valid SET_CUR values became visible through
GET_CUR after roughly 47–81 ms.
there is
an opened playback stream.
Could you clarify your "libusb tests"?
Thanks,
Rong
The first debug line I saw with |saved=0| was from the Mic Capture
Volume control; that control changed immediately and returned as
non-sticky. The sequence above with |saved=-3840| is the
problematic PCM
Playback Volume control.
I'd be happy to test another version or run additional diagnostics if
useful.
Best regards,
Alexander
Am 15.08.2026 um 23:47 schrieb Rong Zhang:
Some mixers are asynchronous, and some have broken min/max. They are
mistakenly considered sticky due to how the check is implemented.
Check sticky mixers more precisely by checking approximately 16
values
and adding a msleep(10) between each check, so that asynchronous
mixers
have enough time to change the value and mixers with broken
min/max are
checked properly. Additionally, mark GET_CUR as broken when
get_cur_mix_raw() fails, instead of returning successfully.
Reported-by: Alexander Niemeyer<adventureFAN@xxxxxx>
Closes:https://lore.kernel.org/r/6262cbbd-d1f2-4c9d-a1c7-9c5d12636f4b@xxxxxx
Signed-off-by: Rong Zhang<i@xxxxxxxx>
---
sound/usb/mixer.c | 51
++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 703c118f9d4e..3d0f97730a06 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1256,22 +1256,59 @@ static void init_cur_mix_raw(struct
usb_mixer_elem_info *cval, int ch, int idx)
static int check_sticky_volume_control(struct
usb_mixer_elem_info *cval,
int channel, int saved)
{
- int sticky_test_values[] = { cval->min, cval->max };
- int test, check, i;
+ int test, check, res;
+
+ /*
+ * Check approximately 16 values (15 intervals).
+ * If the resolution is not fine enough, check fewer values.
+ */
+ res = DIV_ROUND_UP(cval->max - cval->min, 15);
+ res = res ? roundup(res, cval->res) : cval->res;
+
+ /*
+ * If (cval->max - cval->min) is not a multiple of
cval->res, we still
+ * want to test cval->max anyway.
+ */
+ for (test = cval->min; test < cval->max + res; test += res) {
+ if (test > cval->max)
+ test = cval->max;
- for (i = 0; i < ARRAY_SIZE(sticky_test_values); i++) {
- test = sticky_test_values[i];
if (test == saved)
continue;
/* Assume non-sticky on failure. */
- if (snd_usb_set_cur_mix_value(cval, channel, 0, test) ||
- get_cur_mix_raw(cval, channel, &check) ||
- check != saved) /* SET_CUR effective, non-sticky. */
+ if (snd_usb_set_cur_mix_value(cval, channel, 0, test))
+ return 0;
+
+ if (get_cur_mix_raw(cval, channel, &check))
+ goto get_cur_broken;
+ if (check != saved) /* SET_CUR effective, non-sticky. */
return 0;
+
+ /*
+ * Leave some time for asynchronous mixers to change the
value.
+ *
+ * Note that there is no need to wait between SET_CUR and
+ * GET_CUR, as we don't care whether the GET_CUR value
matches
+ * the SET_CUR one. IOW, what we expect is just a
GET_CUR value
+ * differing from the saved one.
+ *
+ * Mixers of most devices are synchronous. The should have
+ * returned early without extra sleep. Asynchronous
mixers will
+ * return once the accumulated time is enough for them
to change
+ * the value.
+ */
+ msleep(10);
}
+ /* Check again after the last msleep(). */
+ if (get_cur_mix_raw(cval, channel, &check))
+ goto get_cur_broken;
+ if (check != saved)
+ return 0;
+
if (cval->head.mixer->chip->quirk_flags &
QUIRK_FLAG_MIXER_GET_CUR_BROKEN) {
+get_cur_broken:
usb_audio_info(cval->head.mixer->chip,
"%d:%d: broken mixer GET_CUR (%d/%d/%d =>
%d)\n",
cval->head.id,
mixer_ctrl_intf(cval->head.mixer),
---
base-commit: 3eb40771c00a8488fa6ed2cc1fe203477908bf38
change-id: 74676fce-uac-precise-sticky-check-94474a22b57d
Thanks,
Rong