wireguard-linux/sound/usb, branch stable

ALSA: usb-audio: Add delay quirk for SPACETOUCH USB Audio

2026-08-17T11:52:26Z

Audio control requests that set sampling frequency sometimes fail on this card. Adding delay between control messages eliminates that problem. usb 1-1: New USB device found, idVendor=0666, idProduct=0880 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB Audio usb 1-1: Manufacturer: SPACETOUCH usb 1-1: SerialNumber: 000000000 Signed-off-by: Lianqin Hu Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/TYUPR06MB6217D93F595D9995413C9721D2A72@TYUPR06MB6217.apcprd06.prod.outlook.com

Merge branch 'for-next' into for-linus

2026-08-17T07:53:02Z

ALSA: usb-audio: Rename the Audient iD14 monitor mix volume control

2026-08-14T05:57:16Z

On the Audient iD14 (2708:0008), feature unit 12 is traced through to the Speaker output terminal and is therefore exported as "Speaker Playback Volume". The name fits it badly. It advertises Volume on only four of its six logical channels, which the driver records as cmask=0xf, channels=4 on a 6-channel playback stream, and it sits on the monitor mixer branch rather than in the direct playback path: INPUT_TERMINAL 2 (USB streaming, 6ch) -> EXTENSION_UNIT 51 -> FEATURE_UNIT 10 (no controls) -> OUTPUT_TERMINAL 20 (Speaker) while FU 12 hangs off MIXER_UNIT 60 and feeds back into EXTENSION_UNIT 51. Userspace adopts the control as the stream's hardware playback volume, so any setting below 0 dB attenuates part of the stream and not the rest. Measured over the device's own digital loopback, with one -12 dBFS tone per channel played straight to hw:, PCM channel 0 is unaffected while channel 1 tracks the control: at 107/127 (-20 dB) the two read -15.89 and -35.89 dBFS, a 20.00 dB imbalance, and at 127/127 both read -15.89 dBFS. Give the unit a non-standard name so that it is no longer taken for the stream's master volume. Dropping the control instead also fixes the imbalance, but FU 12 keeps its value across a module reload, so dropping it strands a device that is already attenuated with nothing able to reset it. Renaming leaves the monitor gain reachable and that recovery path intact. The mapped name ends in "Playback" because a name from the map suppresses the automatic " Playback" but still gets " Volume" appended; the control comes out as "Monitor Mix Playback Volume". Tested on the ACP path with PipeWire, which is where the problem reproduces: the control now stays at 127 at every volume setting and the imbalance is 0.00 dB, and setting it by hand to 107 and back to 127 gives 20.00 dB and 0.00 dB as before. Link: https://lore.kernel.org/linux-sound/0102019fed22f9d3-fa294ec5-02f1-4fd3-b3fa-76efc14331cc-000000@eu-west-1.amazonses.com/T/#u Signed-off-by: Neil Andrews Link: https://patch.msgid.link/0102019ffcdbb1e6-9b59d3cc-ef05-4df1-8f9f-fb2f425bcda2-000000@eu-west-1.amazonses.com Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix sample rates for PreSonus AudioBox USB

2026-08-12T05:27:57Z

The fixed audio formats for the PreSonus AudioBox USB specify a discrete rate mask but leave nr_rates at zero and rate_table unset. find_format() therefore rejects every requested rate, preventing the playback and capture streams from being opened. Add the advertised 44100 and 48000 Hz rates to both streams and report their 24 significant bits. Fixes: 34fe4a9df247 ("ALSA: usb-audio: Add quirk for PreSonus AudioBox USB") Cc: stable@vger.kernel.org Signed-off-by: Trevor Vorhees Link: https://patch.msgid.link/20260811-audiobox-usb-fix-v1-1-13c8b7f071ea@proton.me Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix popping noise on Valeton GP-200

2026-08-11T06:12:49Z

The Valeton GP-200 guitar multi-effects processor exhibits a continuous popping noise (~6Hz) during playback and recording. Force implicit feedback to resolve the issue. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221662 Signed-off-by: Zhang Heng Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260811024902.134457-4-zhangheng@kylinos.cn

ALSA: usx2y: Stop clearing urb->hcpriv before submission

2026-08-10T11:38:32Z

This is managed by USB core and drivers aren't expected to touch it. It should only be not NULL on a submitted URB, in which case clearing defeats the "submitted while active" sanity check in usb_submit_urb() and may crash the HCD handling the URB and panic the kernel. Signed-off-by: Michal Pecio Link: https://patch.msgid.link/20260810075728.483c827e.michal.pecio@gmail.com Signed-off-by: Takashi Iwai

ALSA: scarlett2: Use a private URB for the notification endpoint

2026-08-10T11:36:20Z

scarlett2_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the "already in use" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmd_done is left zeroed because it is initialised past that check and nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1 and wait_for_completion_timeout() would crash adding to the zeroed wait.head. Use a separate URB in scarlett2_data, as done for FCP, and initialise cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB in snd_usb_mixer_free() and resubmitting it in snd_usb_mixer_activate(), so scarlett2 must now do both: add scarlett2_cleanup_urb(), called from private_free and private_suspend, and a private_resume callback to re-establish the URB after resume. scarlett2_init_notify() is reached from there, and the URB kill path in scarlett2_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Also free the URB if the transfer buffer allocation fails, and both if usb_submit_urb() fails. Move scarlett2_init_notify() up next to scarlett2_cleanup_urb() so scarlett2_init_private() can reference it without a forward declaration. Fixes: 1b65088958ca ("ALSA: scarlett2: Implement handling of the ACK notification") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/ffb8ba37d5d605dfdfd8576949d67098651f9349.1786290885.git.g@b4.vu

ALSA: FCP: Use a private URB for the notification endpoint

2026-08-10T11:36:20Z

fcp_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the optional UAC2 status interrupt endpoint and mixer.c kills, resubmits and frees. On a device with that endpoint, fcp_init_notify()'s "already set up" early return fires on the status URB and returns success without doing anything. No FCP notification URB is submitted, and cmd_done is left zeroed because it is initialised past that early return and nowhere else. fcp_init() then issues init1_opcode and wait_for_completion_timeout() would crash adding to the zeroed wait.head. fcp_cleanup_urb() would also kill and free mixer.c's status URB. Use a separate URB in fcp_data, and initialise cmd_done in fcp_init_private() where fcp_data is allocated. fcp_init_notify() is reached again after suspend via fcp_reinit(), and the URB kill path in fcp_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Fixes: 46757a3e7d50 ("ALSA: FCP: Add Focusrite Control Protocol driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Geoffrey D. Bennett Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/2cad281e6434024ca48a9ecc94fa19d6777e9be7.1786290885.git.g@b4.vu

ALSA: usb-audio: add QUIRK_FLAG_ALWAYS_SET_RATE for Mackie DLZ Creator XS

2026-08-09T10:29:33Z

set_sample_rate_v2v3() returns early when the clock already reports the requested rate: prev_rate = get_sample_rate_v2v3(chip, fmt->iface, fmt->altsetting, clock); if (prev_rate == rate) goto validation; A device advertising exactly one sample rate always takes this branch, so it never receives a SET_CUR for CS_SAM_FREQ_CONTROL at all. The Mackie DLZ Creator XS (0a73:003a, 14 in / 4 out, 48 kHz only) requires that write. Without it the device drops off the USB bus roughly 0.2-1.8 s into any stream, clearing its port CONNECTION bit; captured audio is byte-correct until the instant it vanishes. USBPcap traces of a cold-booted device on Windows show SET_CUR 48000 issued unconditionally on every stream start, followed by clean streaming. The device is otherwise driven with plain class-compliant UAC2 - it also works on iOS, which cannot load a vendor driver - so no vendor-specific initialization is involved. The device is self-powered, so the resulting state survives a USB replug: initializing it on any host that issues the write leaves it working on Linux until it is power-cycled, which made the failure look intermittent. Add a quirk flag rather than dropping the early exit, since the opposite requirement also exists in-tree: QUIRK_FLAG_FIXED_RATE suppresses rate setting for single-rate devices (JBL Quantum610/810). The two behaviors are device-dependent and cannot both be the default. A/B on identically cold-booted hardware, same kernel, same port, repeated twice: without the flag device dropped after 5-6 s, then again after 3-4 s with the flag 20 s playback followed by 20 s of 14-channel capture, 960000 frames, zero re-enumerations This change was developed with an AI coding assistant. The assistant did the trace analysis that located the bug and wrote the patch and this changelog; the hardware testing, the cold-boot cycles and the decision to submit were the author's. Several earlier hypotheses it proposed - URB queue depth, isochronous packet under-allocation, endpoint start ordering - were disproven by measurement before this one. The bug was located with usbmon on Linux and USBPcap on Windows, by diffing an enumeration capture of a cold-booted device on each host. Verified on physical hardware by the A/B above. Assisted-by: Claude-Code:claude-opus-5 Signed-off-by: JJ Macalinao Link: https://patch.msgid.link/20260808172726.1107550-1-jj@macalinao.org Signed-off-by: Takashi Iwai

ALSA: usb-audio: Fix mixer regression on SteelSeries Arctis Nova 5

2026-08-08T15:51:59Z

The recent "sticky mixer" sanity check in USB-audio driver caused a regression on SteelSeries Arctis Nova 5 (1038:2232); because the firmware doesn't handle GET_CUR requests, some mixers are effectively disabled, leading to the too low / soft volumes: usb 5-1.1: 9:0: sticky mixer values (-19712/0/256 => 0), disabling usb 5-1.1: 10:0: sticky mixer values (-21248/0/256 => 0), disabling Restore the functionality by ignoring GET_CUR errors intentionally with MIXER_GET_CUR_BROKEN quirk. Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers") Reported-by: Gert Burger Closes: https://lore.kernel.org/CAEQ1D3kdA3mkQx7ei9Kq0gwky0qroJqCLKrkvgfkqgTbeu086A@mail.gmail.com Link: https://bbs.archlinux.org/viewtopic.php?id=314220 Link: https://patch.msgid.link/20260808152258.1948767-1-tiwai@suse.de Signed-off-by: Takashi Iwai