- Alsa-devel - mailman.alsa-project.org

ALSA PCM playing stops randomly, write buffer fills up
by GitHub issues - edited 14 May '26

14 May '26

alsa-project/alsa-lib issue #506 was edited from brucemack: Hi: I have simple ASLA application that exhibits a strange behavior. I would welcome any advice for improved debug techniques. My program is non-blocking with a single playback handle. My program is a loop that plays a tone that lasts for 2 seconds, with a 1 second gap. While the tone is active my program writes a 20ms block of audio (960 PCM samples x 2 channels at 48k) every 20ms. My buffer time is set to 320ms (plenty of space). My start threshold is set to 1200 frames. The audio hardware is a USB-connected device using a CM108B chip. My program runs very nicely with good audio quality for several minutes. The delay/available pointers move around exactly the way I'd expect and the delay never goes above 2000 frames when the tone is playing. Production and consumption of audio are perfectly matched in a smooth stream. The state also looks good - it moves from XRUN to prepared to running and back to XRUN as the tone starts and stops. After several minutes, the delay suddenly start to rise (and the available space falls) to the point where snd_pcm_writei() won't accept any more data. It gets stuck like this forever. Strangely, when I kill the program and restart it everything is fine until this repeats several minutes later. From my diagnostic prints (see below) it seems like the play buffer just suddenly stops getting consumed, even though the state is still running (3). I would be grateful if someone could suggest an idea for diagnosing this problem. arduino@Q1:~/amp-server/build$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version k6.16.7-g0dd6551ae96b. I: 05-14 00:52:00.780 Turning off tone I: 05-14 00:52:00.800 Playback state change (2801) 3 -> 4 [1536, 14400] I: 05-14 00:52:00.820 Playback state change (2802) 4 -> 2 [0, 15360] I: 05-14 00:52:00.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:01.780 Turning on tone I: 05-14 00:52:01.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:01.820 Playback state change (2852) 2 -> 3 [1536, 14400] I: 05-14 00:52:01.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:03.780 Turning off tone I: 05-14 00:52:03.800 Playback state change (2951) 3 -> 4 [1536, 14400] I: 05-14 00:52:03.820 Playback state change (2952) 4 -> 2 [0, 15360] I: 05-14 00:52:03.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:04.780 Turning on tone I: 05-14 00:52:04.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:04.820 Playback state change (3002) 2 -> 3 [1536, 14400] I: 05-14 00:52:04.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:06.780 Turning off tone I: 05-14 00:52:06.800 Playback state change (3101) 3 -> 4 [1536, 14400] I: 05-14 00:52:06.820 Playback state change (3102) 4 -> 2 [0, 15360] I: 05-14 00:52:06.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:07.780 Turning on tone I: 05-14 00:52:07.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:07.820 Playback state change (3152) 2 -> 3 [1536, 14400] I: 05-14 00:52:07.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:09.780 Turning off tone I: 05-14 00:52:09.800 Playback state change (3251) 3 -> 4 [1536, 14400] I: 05-14 00:52:09.820 Playback state change (3252) 4 -> 2 [0, 15360] I: 05-14 00:52:09.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:10.780 Turning on tone I: 05-14 00:52:10.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:10.820 Playback state change (3302) 2 -> 3 [1920, 13440] **PROBLEM STARTS HERE** I: 05-14 00:52:10.820 Delay/avail 1920 / 13440 frames I: 05-14 00:52:10.840 Delay/avail 2880 / 12480 frames I: 05-14 00:52:10.860 Delay/avail 3840 / 11520 frames I: 05-14 00:52:10.880 Delay/avail 4800 / 10560 frames I: 05-14 00:52:10.900 Delay/avail 5760 / 9600 frames I: 05-14 00:52:10.920 Delay/avail 6720 / 8640 frames I: 05-14 00:52:10.940 Delay/avail 7680 / 7680 frames I: 05-14 00:52:10.960 Delay/avail 8640 / 6720 frames I: 05-14 00:52:10.980 Delay/avail 9600 / 5760 frames I: 05-14 00:52:10.000 Delay/avail 10560 / 4800 frames E: 05-14 00:52:10.000 Delay is growing I: 05-14 00:52:11.220 Delay/avail 11520 / 3840 frames E: 05-14 00:52:11.220 Delay is growing I: 05-14 00:52:11.440 Delay/avail 12480 / 2880 frames E: 05-14 00:52:11.440 Delay is growing I: 05-14 00:52:11.660 Delay/avail 13440 / 1920 frames E: 05-14 00:52:11.660 Delay is growing I: 05-14 00:52:11.880 Delay/avail 14400 / 960 frames E: 05-14 00:52:11.880 Delay is growing I: 05-14 00:52:12.100 Delay/avail 15360 / 0 frames E: 05-14 00:52:12.100 Delay is growing E: 05-14 00:52:12.300 USB BUFFER FULL, state 3 15360 0 I: 05-14 00:52:12.780 Turning off tone I: 05-14 00:52:13.781 Turning on tone E: 05-14 00:52:14.300 USB BUFFER FULL, state 3 15360 0 I: 05-14 00:52:15.780 Turning off tone I: 05-14 00:52:16.780 Turning on tone E: 05-14 00:52:16.781 USB BUFFER FULL, state 3 15360 0 Issue URL : https://github.com/alsa-project/alsa-lib/issues/506 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

ALSA PCM playing stops randomly, write buffer fills up
by GitHub issues - opened 14 May '26

14 May '26

alsa-project/alsa-lib issue #506 was opened from brucemack: Hi: I have simple ASLA application that exhibits a strange behavior. I would welcome any advice for improved debug techniques. My program is non-blocking with a single playback handle. My program is a loop that plays a tone that lasts for 2 seconds, with a 1 second gap. While the tone is active my program writes a 20ms block of audio (960 PCM samples x 2 channels at 48k) every 20ms. My buffer time is set to 320ms (plenty of space). My start threshold is set to 1200 frames. The audio hardware is a USB-connected device using a CM108B chip. My program runs very nicely with good audio quality for several minutes. The delay/available pointers move around exactly the way I'd expect and the delay never goes above 2000 frames when the tone is playing. Production and consumption of audio are perfectly matched in a smooth stream. The state also looks good - it moves from XRUN to prepared to running and back to XRUN as the tone starts and stops. After several minutes, the delay suddenly start to rise (and the available space falls) to the point where snd_pcm_writei() won't accept any more data. It gets stuck like this forever. Strangely, when I kill the program and restart it everything is fine until this repeats several minutes later. From my diagnostic prints (see below) it seems like the play buffer just suddenly stops getting consumed, even though the state is still running (3). I would be grateful if someone could suggest an idea for diagnosing this problem. I: 05-14 00:52:00.780 Turning off tone I: 05-14 00:52:00.800 Playback state change (2801) 3 -> 4 [1536, 14400] I: 05-14 00:52:00.820 Playback state change (2802) 4 -> 2 [0, 15360] I: 05-14 00:52:00.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:01.780 Turning on tone I: 05-14 00:52:01.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:01.820 Playback state change (2852) 2 -> 3 [1536, 14400] I: 05-14 00:52:01.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:03.780 Turning off tone I: 05-14 00:52:03.800 Playback state change (2951) 3 -> 4 [1536, 14400] I: 05-14 00:52:03.820 Playback state change (2952) 4 -> 2 [0, 15360] I: 05-14 00:52:03.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:04.780 Turning on tone I: 05-14 00:52:04.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:04.820 Playback state change (3002) 2 -> 3 [1536, 14400] I: 05-14 00:52:04.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:06.780 Turning off tone I: 05-14 00:52:06.800 Playback state change (3101) 3 -> 4 [1536, 14400] I: 05-14 00:52:06.820 Playback state change (3102) 4 -> 2 [0, 15360] I: 05-14 00:52:06.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:07.780 Turning on tone I: 05-14 00:52:07.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:07.820 Playback state change (3152) 2 -> 3 [1536, 14400] I: 05-14 00:52:07.820 Delay/avail 1536 / 14400 frames I: 05-14 00:52:09.780 Turning off tone I: 05-14 00:52:09.800 Playback state change (3251) 3 -> 4 [1536, 14400] I: 05-14 00:52:09.820 Playback state change (3252) 4 -> 2 [0, 15360] I: 05-14 00:52:09.820 Delay/avail 0 / 15360 frames I: 05-14 00:52:10.780 Turning on tone I: 05-14 00:52:10.800 Delay/avail 960 / 14400 frames I: 05-14 00:52:10.820 Playback state change (3302) 2 -> 3 [1920, 13440] **PROBLEM STARTS HERE** I: 05-14 00:52:10.820 Delay/avail 1920 / 13440 frames I: 05-14 00:52:10.840 Delay/avail 2880 / 12480 frames I: 05-14 00:52:10.860 Delay/avail 3840 / 11520 frames I: 05-14 00:52:10.880 Delay/avail 4800 / 10560 frames I: 05-14 00:52:10.900 Delay/avail 5760 / 9600 frames I: 05-14 00:52:10.920 Delay/avail 6720 / 8640 frames I: 05-14 00:52:10.940 Delay/avail 7680 / 7680 frames I: 05-14 00:52:10.960 Delay/avail 8640 / 6720 frames I: 05-14 00:52:10.980 Delay/avail 9600 / 5760 frames I: 05-14 00:52:10.000 Delay/avail 10560 / 4800 frames E: 05-14 00:52:10.000 Delay is growing I: 05-14 00:52:11.220 Delay/avail 11520 / 3840 frames E: 05-14 00:52:11.220 Delay is growing I: 05-14 00:52:11.440 Delay/avail 12480 / 2880 frames E: 05-14 00:52:11.440 Delay is growing I: 05-14 00:52:11.660 Delay/avail 13440 / 1920 frames E: 05-14 00:52:11.660 Delay is growing I: 05-14 00:52:11.880 Delay/avail 14400 / 960 frames E: 05-14 00:52:11.880 Delay is growing I: 05-14 00:52:12.100 Delay/avail 15360 / 0 frames E: 05-14 00:52:12.100 Delay is growing E: 05-14 00:52:12.300 USB BUFFER FULL, state 3 15360 0 I: 05-14 00:52:12.780 Turning off tone I: 05-14 00:52:13.781 Turning on tone E: 05-14 00:52:14.300 USB BUFFER FULL, state 3 15360 0 I: 05-14 00:52:15.780 Turning off tone I: 05-14 00:52:16.780 Turning on tone E: 05-14 00:52:16.781 USB BUFFER FULL, state 3 15360 0 Issue URL : https://github.com/alsa-project/alsa-lib/issues/506 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ALSA: hda/realtek: Add quirk for Samsung Galaxy Book5 360 headphone
by Markus Kramer 14 May '26

14 May '26

The Samsung Galaxy Book5 360 (NP750QHA, PCI subsystem ID 0x144d:0xc902) has severe audio distortion on the 3.5mm headphone jack. Applying ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET corrects the output path configuration, consistent with fixes already applied to other Samsung Galaxy Book models using the same ALC256 codec. Cc: stable(a)vger.kernel.org Link: https://github.com/thesofproject/linux/issues/5648 Signed-off-by: Markus Kramer <linux(a)markus-kramer.de> --- sound/hda/codecs/realtek/alc269.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 55bb98e2e..4c610842c 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -7504,6 +7504,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS), SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS), SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS), + SND_PCI_QUIRK(0x144d, 0xc902, "Samsung Galaxy Book5 360 (NP750QHA)", ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET), SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS), SND_PCI_QUIRK(0x144d, 0xc1cb, "Samsung Galaxy Book3 Pro 360 (NP965QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS), SND_PCI_QUIRK(0x144d, 0xc1cc, "Samsung Galaxy Book3 Ultra (NT960XFH)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS), -- 2.51.2

1 0

[BUG] ASoC: amd: yc: HP Notebook 255R G10 (board 8D22) missing from quirk table
by Alen Tišljar 13 May '26

13 May '26

Hello, The internal microphone on the HP Notebook 255R G10 does not work on Linux because the board is missing from the ACP6x DMI quirk table in sound/soc/amd/yc/acp6x-mach.c. Hardware: Laptop: HP Notebook 255R G10 Board name: 8D22 (HP) Audio coprocessor: AMD ACP/ACP3X/ACP6x Analog codec: Realtek ALC236 (working fine for speakers/headphones) Symptoms: Internal microphone is not captured. No acp6x DMIC device appears in arecord -l — only the ALC236 analog inputs are listed. In dmesg, the ACP6x PCI device is enabled. Tested on: Ubuntu 24.04 LTS (board 8D22 is not present in the mainline acp6x-mach.c as of today) Relevant dmesg output: snd_pci_acp6x 0000:03:00.5: enabling device (0000 -> 0002) no further ACP6x/DMIC messages follow arecord -l: **** List of CAPTURE Hardware Devices **** card 1: Generic_1 [HD-Audio Generic], device 0: ALC236 Analog [ALC236 Analog] card 1: Generic_1 [HD-Audio Generic], device 2: ALC236 Alt Analog [ALC236 Alt Analog] Suggested fix: Add the following entry to yc_acp_quirk_table[] in sound/soc/amd/yc/acp6x-mach.c, analogous to commit 0c6498a59fbb ("ASoC: amd: yc: Add HP 255 G10 into quirk table") which handled the closely related HP 255 G10 (board 8B2F): { .driver_data = &acp6x_card, .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "HP"), DMI_MATCH(DMI_BOARD_NAME, "8D22"), } }, I'm happy to test any proposed patch on this hardware. I'm not currently set up to submit a formal patch via git send-email, but if no one is able to pick this up, I'm willing to submit one myself. Thank you, Alen Tišljar

2 3

snd-firewire-ctl-services: Digidesign Digi-002R - missing control for 'Optical mode'
by simon＠mungewell.org 13 May '26

13 May '26

I have noticed that 'snd-firewire-ctl-services' does not provide a control for switching the mode of the Optical connections, which can be either ADAT or S/PDIF. The Windows/Mac drivers let the user select the mode. It is mentioned in the kernel source, but seemingly not exposed to the user: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sou… Note, when 'Optical S/PDIF' is selected, the 'RCA S/PDIF' connectors are disabled. I have the 002-Rack interface, and can assist with testing, Simon.

2 5

equest to upstream: ALC287_FIXUP_TXNW2781_I2C quirk for ASUS Strix Gxx5 family (CachyOS commit 20313d76)
by Rob Blake 13 May '26

13 May '26

Hi all, I'm writing to ask whether the small fixup-table change below can be picked up for mainline. It's already in CachyOS's downstream tree since 2026-03-06 and is reported to restore speaker audio on an entire family of recent ASUS ROG Strix laptops, including mine. The relevant commit is by Eric Naim <dnaim(a)cachyos.org>: CachyOS commit 20313d767be2e5abdb88295b7c724634e1937a4f "ALSA: hda/realtek: Use ALC287_FIXUP_TXNW2781_I2C for ASUS Strix Gxx5" https://github.com/CachyOS/linux/commit/20313d767be2e5abdb88295b7c724634e19… The change is a six-line edit to sound/hda/codecs/realtek/alc269.c: the affected SSIDs are currently mapped to ALC287_FIXUP_TAS2781_I2C but actually need ALC287_FIXUP_TXNW2781_I2C. The wrong quirk leaves the I²C interrupt config inconsistent with the ACPI TXNW2781 entry, so serial-multi-instantiate fails to resolve IRQ index 0 for each of the three amp channels, and only the first channel binds. SSIDs affected (per Eric's patch): 0x1043 0x3ee0 ASUS Strix G815_JHR_JMR_JPR 0x1043 0x3ef0 ASUS Strix G635LR_LW_LX 0x1043 0x3f00 ASUS Strix G815LH_LM_LP 0x1043 0x3f10 ASUS Strix G835LR_LW_LX 0x1043 0x3f20 ASUS Strix G615LR_LW <-- my machine 0x1043 0x3f30 ASUS Strix G815LR_LW On my G615LW (SSID 1043:3f20) running kernel 6.19.14-101.fc44, the broken state matches Eric's commit log exactly: Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found Serial bus multi instantiate pseudo device driver TXNW2781:00: error -ENXIO: IRQ index 0 not found Serial bus multi instantiate pseudo device driver TXNW2781:00: Instantiated 3 I2C devices. with .0 binding to tas2781-hda and .1/.2 staying at driver=NONE. Speakers are silent. Headphones work (they're on a separate codec pin and don't involve TAS2781). I've ruled out asusd as the cause — I rebooted with asusd masked and the failure is identical, so this is purely codec-quirk-table business. Original upstream report: https://lore.kernel.org/CACB9z7kjs8rhLstEc8fV29BCTb5dd881JwGozoKdO5cwCb=YwQ… CachyOS issue with discussion: https://github.com/CachyOS/linux-cachyos/issues/752 I'm not a kernel developer and don't feel qualified to submit Eric's patch on his behalf. Could one of you (or Eric, if you're on this list) take a look and consider sending it for inclusion? It's a self-contained six-line change that fixes audio for a sizeable family of shipping laptops, and the patch is already authored and signed-off. Happy to test patches against my G615LW. Thanks, Rob -- Rob Blake Director Losource Ltd Tel: +44(0)7951 081480 Privacy Notice: This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Losource Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

2 1

Add support for ASUS Pro ET900N G3 front panel audio
by GitHub pull_request - edited 13 May '26

13 May '26

alsa-project/alsa-ucm-conf pull request #757 was edited from Kenny4-Lin: This PR adds UCM configuration support for ASUS Pro ET900N G3 - Station GB300 : - Front panel line out - Front panel mic in - Rear line in Tested on local DGX system, all inputs/outputs working correctly. Signed-off-by: Kenny4 <Kenny4_Lin(a)asus.com> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/757 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/757.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Asunto: SAVITECH JM45 (262a:0001) needs QUIRK_FLAG_DSD_RAW for native DSD
by Alejandro Barros Argibay 13 May '26

13 May '26

Hi, I have a SAVITECH JM45 USB DAC that supports native DSD playback but is not in the quirk_flags_table. Without a quirk, the DSD altset is exposed as SPECIAL and userspace falls back to DoP or PCM conversion. USB descriptor: Bus 003 Device 009: ID 262a:0001 SAVITECH Corp. JM45 Relevant part of /proc/asound/cardN/stream0 (without quirk): Interface 2 Altset 4 Format: SPECIAL Channels: 2 Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000 Bits: 32 DSD raw: DOP=0, bitrev=0 After loading with: modprobe snd_usb_audio quirk_flags=262a0001:0x8000 The altset is correctly exposed as DSD_U32_BE and MPD 0.24 plays DSF files natively at DSD64/128/256 (verified visually: the DAC's status LED switches from green to blue indicating raw DSD reception, and /proc/asound/cardN/pcm0p/sub0/hw_params shows format: DSD_U32_BE). Could QUIRK_FLAG_DSD_RAW be added for 262a:0001? Kernel: linux Samsung 7.0.5-2-cachyos (CachyOS rolling) Tested with: mpd 0.24.10, alsa-lib 1.2.x Thanks, Alejandro

1 0

[PATCH AUTOSEL 7.0-5.10] ALSA: sparc/dbri: add missing fallthrough
by Sasha Levin 12 May '26

12 May '26

From: Rosen Penev <rosenp(a)gmail.com> [ Upstream commit 2bcbb163162789d3488562073dbb99d9bd71a762 ] Fixes compiler error with probably newer compilers: sound/sparc/dbri.c:595:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] 595 | case 1: | ^ sound/sparc/dbri.c:595:2: note: insert 'break;' to avoid fall-through 595 | case 1: | ^ | break; Signed-off-by: Rosen Penev <rosenp(a)gmail.com> Link: https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Phase 1: Commit Message Forensics Step 1.1 Record: Subsystem `ALSA: sparc/dbri`; action verb `add`; intent is to add a missing `fallthrough` annotation in `reverse_bytes()`. Step 1.2 Record: Tags present: `Signed-off-by: Rosen Penev <rosenp(a)gmail.com>`, `Link: https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com`, `Signed-off-by: Takashi Iwai <tiwai(a)suse.de>`. No `Fixes:`, `Reported- by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`. Step 1.3 Record: The commit body reports a concrete compiler error: `-Werror,-Wimplicit-fallthrough` in `sound/sparc/dbri.c` at the fallthrough from `case 2` to `case 1`. Symptom is a build failure for this driver/config with a compiler that diagnoses this unannotated fallthrough as an error. No kernel version is named. Root cause is an intentional fallthrough lacking the kernel `fallthrough;` marker. Step 1.4 Record: This is not a hidden runtime bug fix; it is an explicit build fix. Build fixes are stable-acceptable when they repair compilation of existing code. ## Phase 2: Diff Analysis Step 2.1 Record: One file changed: `sound/sparc/dbri.c`, `+1/-0`. One function modified: `reverse_bytes()`. Scope is a single-file, one-line surgical build fix. Step 2.2 Record: Before, `case 2` performed the final bit swap and implicitly fell into `case 1`/`case 0`, which then `break`s. After, the same fallthrough is explicitly annotated with `fallthrough;`. Runtime control flow is unchanged. Step 2.3 Record: Bug category is build fix / compiler diagnostic fix. Specific mechanism: the kernel already annotates earlier intentional fallthroughs in the same switch, but the `case 2` to `case 1` fallthrough lacked the annotation, triggering `-Wimplicit-fallthrough` as an error. Step 2.4 Record: Fix quality is high: it is one line, uses the existing kernel `fallthrough` pseudo-keyword, matches nearby code style in current branches, and does not change APIs or runtime behavior. Regression risk is very low. ## Phase 3: Git History Investigation Step 3.1 Record: `git blame` on `2bcbb16316278^` attributes this code to `c3c9a75ede23f`, but the repository is shallow/grafted there, so that is not a reliable true introduction point. I verified the same missing annotation exists in local stable-related branches `pending-5.4`, `pending-5.10`, `pending-5.15`, `pending-6.1`, `pending-6.6`, `pending-6.12`, `pending-6.19`, and `pending-7.0`. Step 3.2 Record: No `Fixes:` tag is present, so there is no introducing commit to follow from the message. Step 3.3 Record: Recent `sound/sparc/dbri.c` history on `linux- next/master` shows this commit, then `ALSA: sparc/dbri: Use guard() for spin locks`, then the shallow boundary. The guard refactor is not a semantic prerequisite for adding this annotation, although older stable branches may have slightly different context. Step 3.4 Record: Author Rosen Penev has this recent `sound/sparc` commit in the checked history. The commit was applied by Takashi Iwai, and `MAINTAINERS` lists Takashi Iwai and Jaroslav Kysela as SOUND maintainers. Step 3.5 Record: No dependent `reverse_bytes` commits were found by subject search. The change can be applied standalone as an annotation. For `pending-5.4`, context differs because earlier fallthroughs are comments rather than `fallthrough;`, so that tree may need a trivial backport adjustment. ## Phase 4: Mailing List And External Research Step 4.1 Record: `b4 dig -c 2bcbb16316278` found the original submission at the provided lore/patch URL. `b4 dig -a` found only v1; no later revision. The saved mbox contains Takashi Iwai’s reply: “Applied now. Thanks.” No NAKs or concerns were present in the fetched thread. Step 4.2 Record: `b4 dig -w` shows recipients: Rosen Penev, `linux- sound(a)vger.kernel.org`, Jaroslav Kysela, Takashi Iwai, and `linux- kernel(a)vger.kernel.org`. Step 4.3 Record: No separate bug report or `Reported-by` tag. The reported failure is the compiler diagnostic included in the patch email and commit message. Step 4.4 Record: `b4 dig -a` shows this is a single-patch series, not part of a multi-patch dependency chain. Step 4.5 Record: WebFetch to lore/stable search was blocked by Anubis. Local stable branch log searches did not find this exact fix or a related `unannotated fall-through` fix already present in the checked stable branches. ## Phase 5: Code Semantic Analysis Step 5.1 Record: Modified function: `reverse_bytes()`. Step 5.2 Record: Callers found in `sound/sparc/dbri.c`: `xmit_fixed()` calls `reverse_bytes()` for MSB fixed-pipe transmit data; `dbri_process_one_interrupt()` calls it for fixed-data receive interrupts. Step 5.3 Record: `reverse_bytes()` only performs bit manipulation and may print an error for unsupported lengths; it does not allocate memory, take locks, or call into external subsystems. Step 5.4 Record: Runtime paths are reachable through DBRI/CS4215 initialization/control and interrupt handling on supported SPARC SBus DBRI hardware. For this patch, runtime reachability is not the main issue because the fix targets compilation and preserves runtime flow. Step 5.5 Record: Nearby switch cases already had intentional fallthrough annotations; this patch fills the only missing annotation in that chain. ## Phase 6: Stable Tree Analysis Step 6.1 Record: The missing annotation exists in checked stable-related branches from `pending-5.4` through `pending-7.0`. Therefore the affected source is present in active stable-era trees available locally. Step 6.2 Record: Expected backport difficulty is clean or trivial for most branches. `pending-5.4` has older comment-style fallthrough context before `case 2`, so it may require a small context adjustment, but the same one-line semantic change applies. Step 6.3 Record: No related fix with this subject or `unannotated fall- through` in `sound/sparc/dbri.c` was found in the checked stable-related branches. ## Phase 7: Subsystem And Maintainer Context Step 7.1 Record: Subsystem is ALSA SPARC sound driver, specifically Sun DBRI. Criticality is peripheral/platform-specific, not core kernel-wide. Step 7.2 Record: Recent `sound/sparc` history is sparse and mostly maintenance/refactoring/build-style changes, indicating a mature low- churn driver area. ## Phase 8: Impact And Risk Assessment Step 8.1 Record: Affected users are config/platform-specific: SPARC/SBus builds with `SND_SUN_DBRI`. Step 8.2 Record: Trigger is building this driver with a compiler/configuration that treats the unannotated fallthrough warning as an error. I did not independently reproduce the compiler failure locally. Step 8.3 Record: Failure mode is build failure, not runtime crash or data corruption. Severity is high for affected builders because the kernel/module cannot be built successfully under that toolchain/config. Step 8.4 Record: Benefit is meaningful for affected stable users because it restores buildability of an existing driver. Risk is very low: one annotation line, no feature, no API change, no runtime logic change. Risk-benefit ratio favors backporting. ## Phase 9: Final Synthesis Step 9.1 Record: Evidence for backporting: concrete compiler error, existing driver code in stable branches, one-line obviously-correct fix, maintainer-applied patch, no runtime behavior change, and build fixes are valid stable material. Evidence against: platform-specific impact and no independent local build reproduction. Unresolved: exact true historical introduction predates the shallow boundary; lore stable search via WebFetch was blocked. Step 9.2 Record: Stable rules checklist: 1. Obviously correct and tested: yes for correctness by inspection; maintainer applied it. No local build test performed. 2. Fixes a real bug: yes, reported compiler error in existing code. 3. Important issue: yes for affected stable builds, because it can stop compilation. 4. Small and contained: yes, one line in one function. 5. No new features/APIs: yes. 6. Can apply to stable trees: yes with at most trivial context adjustment, especially for older comment-style fallthrough branches. Step 9.3 Record: Exception category applies: build fix. Step 9.4 Record: Decision is to backport. This is exactly the kind of low-risk build fix stable trees should carry. ## Verification - [Phase 1] Parsed `git show --format=fuller --stat --patch 2bcbb16316278`: confirmed subject, tags, compiler-error body, and one- line patch. - [Phase 2] Read `sound/sparc/dbri.c`: confirmed `reverse_bytes()` has annotated fallthroughs except the candidate-added `case 2` annotation. - [Phase 3] Ran `git blame 2bcbb16316278^ -L 578,598 -- sound/sparc/dbri.c`: confirmed changed area, with shallow/grafted limitation. - [Phase 3] Ran branch snippet checks on `pending-5.4` through `pending-7.0`: confirmed the missing annotation exists in all checked stable-related branches. - [Phase 3] Ran recent file history and author history checks: found only related maintenance/refactor commits, no dependency series. - [Phase 4] Ran `b4 dig -c`, `-a`, `-w`, and saved the mbox: confirmed single v1 patch, proper ALSA recipients, and maintainer “Applied now” reply. - [Phase 5] Searched `reverse_bytes(` call sites: confirmed callers are `xmit_fixed()` and `dbri_process_one_interrupt()`. - [Phase 6] Searched stable branch logs: no existing backport or duplicate fix found locally. - [Phase 7] Checked `MAINTAINERS`: confirmed SOUND maintainers include Jaroslav Kysela and Takashi Iwai. - [Phase 8] Checked `include/linux/compiler_attributes.h`: confirmed `fallthrough` is the intended kernel pseudo-keyword and is available in checked stable branches. - UNVERIFIED: I did not reproduce the compiler error with a local SPARC/SBus DBRI build. - UNVERIFIED: The exact original introduction before the repository’s shallow/grafted boundary could not be determined. - UNVERIFIED: WebFetch could not read lore/stable search results because Anubis blocked the page. **YES** sound/sparc/dbri.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/sparc/dbri.c b/sound/sparc/dbri.c index 75f82a92ff44f..2f5f62079fa4a 100644 --- a/sound/sparc/dbri.c +++ b/sound/sparc/dbri.c @@ -592,6 +592,7 @@ static __u32 reverse_bytes(__u32 b, int len) fallthrough; case 2: b = ((b & 0xaaaaaaaa) >> 1) | ((b & 0x55555555) << 1); + fallthrough; case 1: case 0: break; -- 2.53.0

1 7

[PATCH] ALSA: M-Audio C600 disable Output Gain Knob
by Simon Wood 11 May '26

11 May '26

The C400/C600 interfaces have a large output gain knob which attenuates the outputs as stereo pairs (1/2, 3/4 and 5/6). The Windows driver/app provides a control to disable this knob/behaviour on any/all outputs, forcing maximum gain on each. The 'disable behaviour' is desirable if any outputs are being used for aux/effects sends, or if interface is being used as a live/matrix mixer. This patch adds a control to select which output pairs are affected by the Output Gain Knob. Default behaviour is to select all outputs. Tested on the C600, likely also works for the C400. Signed-off-by: Simon Wood <simon(a)mungewell.org> --- sound/usb/mixer_quirks.c | 46 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c index 11e205da7964..16d8eb111d01 100644 --- a/sound/usb/mixer_quirks.c +++ b/sound/usb/mixer_quirks.c @@ -1282,7 +1282,7 @@ static int snd_ftu_eff_switch_init(struct usb_mixer_interface *mixer, err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC_GET_CUR, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, - pval & 0xff00, + (pval & 0xff00) | ((pval & 0xff0000) >> 16), snd_usb_ctrl_intf(mixer->hostif) | ((pval & 0xff) << 8), value, 2); if (err < 0) @@ -1315,7 +1315,7 @@ static int snd_ftu_eff_switch_update(struct usb_mixer_elem_list *list) usb_sndctrlpipe(chip->dev, 0), UAC_SET_CUR, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_OUT, - pval & 0xff00, + (pval & 0xff00) | ((pval & 0xff0000) >> 16), snd_usb_ctrl_intf(list->mixer->hostif) | ((pval & 0xff) << 8), value, 2); } @@ -1728,6 +1728,44 @@ static int snd_c400_create_effect_ret_vol_ctls(struct usb_mixer_interface *mixer return 0; } +/* output gain knob selectively adjusts outputs as stereo pairs */ +/* reuses functions from FTU effect switch */ +static int snd_c400_knob_switch_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + static const char *const texts[8] = { + "None", "1/2", "3/4", "1/2 3/4", + "5/6", "1/2 5/6", "3/4 5/6", "1/2 3/4 5/6" + }; + + return snd_ctl_enum_info(uinfo, 1, ARRAY_SIZE(texts), texts); +} + +static int snd_c400_create_knob_switch(struct usb_mixer_interface *mixer, + int validx, int bUnitID) +{ + static struct snd_kcontrol_new template = { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "Output Gain Knob", + .index = 0, + .access = SNDRV_CTL_ELEM_ACCESS_READWRITE, + .info = snd_c400_knob_switch_info, + .get = snd_ftu_eff_switch_get, + .put = snd_ftu_eff_switch_put + }; + struct usb_mixer_elem_list *list; + int err; + + err = add_single_ctl_with_resume(mixer, bUnitID, + snd_ftu_eff_switch_update, + &template, &list); + if (err < 0) + return err; + list->kctl->private_value = (validx << 8) | bUnitID; + snd_ftu_eff_switch_init(mixer, list->kctl); + return 0; +} + static int snd_c400_create_mixer(struct usb_mixer_interface *mixer) { int err; @@ -1760,6 +1798,10 @@ static int snd_c400_create_mixer(struct usb_mixer_interface *mixer) if (err < 0) return err; + err = snd_c400_create_knob_switch(mixer, 0x0900, 0x20); + if (err < 0) + return err; + return 0; } -- 2.43.0

1 0