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

[PATCH] ALSA: hda/realtek: Add codec SSID quirk for Lenovo Yoga Pro 9 16IMH9
by Rámon van Raaij 01 May '26

01 May '26

The Yoga Pro 9 16IMH9 (codec SSID 17aa:38d6) shares PCI audio device subsystem ID 17aa:3811 with the Legion S7 15IMH05. The existing SND_PCI_QUIRK entry for the Legion routes both machines to ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS, which does not bind the TAS2781 smart amplifiers, resulting in near-silent built-in speakers. Add an HDA_CODEC_QUIRK entry immediately before the conflicting PCI quirk that matches the Yoga Pro 9's unique codec SSID and routes it to ALC287_FIXUP_TAS2781_I2C. Codec quirks are evaluated after PCI quirks and take precedence, leaving the Legion S7 15IMH05 entry unaffected. This follows the same pattern used to disambiguate PCI SSID 17aa:3847 (shared between Yoga Pro 7 14IMH9 and Legion 7 16ACHG6), where a HDA_CODEC_QUIRK for codec SSID 17aa:38cf resolves the conflict. Signed-off-by: Rámon van Raaij <ramon(a)vanraaij.eu> --- sound/hda/codecs/realtek/alc269.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index ae74e1b69..648051366 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -7605,6 +7605,10 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), HDA_CODEC_QUIRK(0x17aa, 0x3802, "DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga Pro 9 14IRP8", ALC287_FIXUP_TAS2781_I2C), + /* Yoga Pro 9 16IMH9 shares PCI SSID 17aa:3811 with Legion S7 15IMH05; + * use codec SSID to distinguish them + */ + HDA_CODEC_QUIRK(0x17aa, 0x38d6, "Lenovo Yoga Pro 9 16IMH9", ALC287_FIXUP_TAS2781_I2C), SND_PCI_QUIRK(0x17aa, 0x3811, "Legion S7 15IMH05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940 / Yoga Duet 7", ALC298_FIXUP_LENOVO_C940_DUET7), -- 2.54.0

1 0

AACI driver bug
by Саня Пронський 30 Apr '26

30 Apr '26

Hello, I've noticed a potential race condition in the AACI driver (sound/arm/aaci.c). The current implementation of aaci_fifo_irq() accesses the substream pointer outside the spinlock-protected area, which could lead to a NULL pointer dereference or use-after-free if the substream is released in a parallel thread. This patch ensures the substream pointer is safely captured under the lock before use. Best regards, Alexander Pronskiy

1 0

snd_mixer_selem_ask_playback_vol_dB calculates wrong volume with SND_CTL_TLVT_DB_MINMAX_MUTE
by GitHub issues - edited 30 Apr '26

30 Apr '26

alsa-project/alsa-lib issue #504 was edited from pv: snd_mixer_selem_ask_playback_dB_vol() and snd_mixer_selem_ask_playback_vol_dB() are inconsistent between each other when SND_CTL_TLVT_DB_MINMAX_MUTE is enabled. Similarly for `snd_mixer_selem_get_playback_dB` after setting volume dB_vol returned. Version: alsa-lib-1.2.15.3-3.fc44.x86_64 In Pipewire, we have ``` if ((r = snd_mixer_selem_ask_playback_dB_vol(me, value_dB, rounding, &val)) < 0) return r; if ((r = snd_mixer_selem_ask_playback_vol_dB(me, val, &dB)) < 0) return r; ``` In the problem case `value_dB = -3259` and `rounding = +1` but I'm seeing ``` (gdb) p val $55 = 1 (gdb) p dB $56 = -9999999 ``` The `val = 1` is correct (the device is muted only at HW volume 0), but dB from snd_mixer_selem_ask_playback_vol_dB is wrong, the device is not muted at volume 1. (The inconsistency results to Pipewire volume control being broken at low volume.) The device in question is "1532:055e Razer USA, Ltd Razer Nommo V2 X" -- it is muted at lowest ALSA hw volume 0, and anything > 0 is not muted (so it needs the mixer_playback_min_mute quirk). In snd_tlv_convert_to_dB: ``` snd_tlv_convert_to_dB (tlv=0x7b460cd21610, rangemin=0, rangemax=7248, volume=1, db_gain=0x7b260b455e40) at control/tlv.c:212 254 if (*db_gain < mindb) (gdb) p type $80 = 5 (gdb) p mindb $72 = -2837 (gdb) p maxdb $73 = -6 ``` The `*db_gain = (maxdb - mindb) * (volume - rangemin) / (rangemax - rangemin) + mindb` results to `*db_gain == mindb` and the function returns with SND_CTL_TLV_DB_GAIN_MUTE which is wrong. Reverting https://github.com/alsa-project/alsa-lib/commit/41039b49ad3e20506134864028c… appears to fix it for me (get `dB == -2837`). Alternatively one could change snd_tlv_convert_from_dB to match so the rounding is right. I don't understand the new logic, doesn't SND_CTL_TLVT_DB_MINMAX_MUTE mean that the lowest hardware volume value is muted? (Also, the ALSA 1/100 dB values round to zero earlier than the USB 1/256 dB ones.) Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5235 (I also have access to similar device locally) Issue URL : https://github.com/alsa-project/alsa-lib/issues/504 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

snd_mixer_selem_ask_playback_vol_dB calculates wrong volume with SND_CTL_TLVT_DB_MINMAX_MUTE
by GitHub issues - edited 30 Apr '26

30 Apr '26

alsa-project/alsa-lib issue #504 was edited from pv: snd_mixer_selem_ask_playback_dB_vol() and snd_mixer_selem_ask_playback_vol_dB() are inconsistent between each other when SND_CTL_TLVT_DB_MINMAX_MUTE is enabled. Similarly for `snd_mixer_selem_get_playback_dB` after setting volume dB_vol returned. Version: alsa-lib-1.2.15.3-3.fc44.x86_64 In Pipewire, we have ``` if ((r = snd_mixer_selem_ask_playback_dB_vol(me, value_dB, rounding, &val)) < 0) return r; if ((r = snd_mixer_selem_ask_playback_vol_dB(me, val, &dB)) < 0) return r; ``` In the problem case `value_dB = -3259` and `rounding = +1` but I'm seeing ``` (gdb) p val $55 = 1 (gdb) p dB $56 = -9999999 ``` The `val = 1` is correct (the device is muted only at HW volume 0), but dB from snd_mixer_selem_ask_playback_vol_dB is wrong. (Results to Pipewire volume control being broken at low volume.) The device in question is "1532:055e Razer USA, Ltd Razer Nommo V2 X" -- it is muted at lowest ALSA hw volume 0, and anything > 0 is not muted (so it needs the mixer_playback_min_mute quirk). In snd_tlv_convert_to_dB: ``` snd_tlv_convert_to_dB (tlv=0x7b460cd21610, rangemin=0, rangemax=7248, volume=1, db_gain=0x7b260b455e40) at control/tlv.c:212 254 if (*db_gain < mindb) (gdb) p type $80 = 5 (gdb) p mindb $72 = -2837 (gdb) p maxdb $73 = -6 ``` The `*db_gain = (maxdb - mindb) * (volume - rangemin) / (rangemax - rangemin) + mindb` results to `*db_gain == mindb` and the function returns with SND_CTL_TLV_DB_GAIN_MUTE which is wrong. Reverting https://github.com/alsa-project/alsa-lib/commit/41039b49ad3e20506134864028c… appears to fix it for me (get `dB == -2837`). Alternatively one could change snd_tlv_convert_from_dB to match so the rounding is right. I don't understand the new logic, doesn't SND_CTL_TLVT_DB_MINMAX_MUTE mean that the lowest hardware volume value is muted? (Also, the ALSA 1/100 dB values round to zero earlier than the USB 1/256 dB ones.) Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5235 (I also have access to similar device locally) Issue URL : https://github.com/alsa-project/alsa-lib/issues/504 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

snd_mixer_selem_ask_playback_vol_dB calculates wrong volume with SND_CTL_TLVT_DB_MINMAX_MUTE
by GitHub issues - opened 30 Apr '26

30 Apr '26

alsa-project/alsa-lib issue #504 was opened from pv: snd_mixer_selem_ask_playback_dB_vol() and snd_mixer_selem_ask_playback_vol_dB() are inconsistent between each other when SND_CTL_TLVT_DB_MINMAX_MUTE is enabled. Similarly for `snd_mixer_selem_get_playback_dB` after setting volume dB_vol returned. Version: alsa-lib-1.2.15.3-3.fc44.x86_64 In Pipewire, we have ``` if ((r = snd_mixer_selem_ask_playback_dB_vol(me, value_dB, rounding, &val)) < 0) return r; if ((r = snd_mixer_selem_ask_playback_vol_dB(me, val, &dB)) < 0) return r; ``` In the problem case `value_dB = -3259` and `rounding = +1` but I'm seeing ``` (gdb) p val $55 = 1 (gdb) p dB $56 = -9999999 ``` The `val = 1` is correct (the device is muted only at HW volume 0), but dB from snd_mixer_selem_ask_playback_vol_dB is wrong. (Results to Pipewire volume control being broken at low volume.) The device in question is "1532:055e Razer USA, Ltd Razer Nommo V2 X" -- it is muted at lowest ALSA hw volume 0, and anything > 0 is not muted (so it needs the mixer_playback_min_mute quirk). In snd_tlv_convert_to_dB: ``` snd_tlv_convert_to_dB (tlv=0x7b460cd21610, rangemin=0, rangemax=7248, volume=1, db_gain=0x7b260b455e40) at control/tlv.c:212 254 if (*db_gain < mindb) (gdb) p type $80 = 5 (gdb) p mindb $72 = -2837 (gdb) p maxdb $73 = -6 ``` The `*db_gain = (maxdb - mindb) * (volume - rangemin) / (rangemax - rangemin) + mindb` results to `*db_gain == mindb` and the function returns with SND_CTL_TLV_DB_GAIN_MUTE which is wrong. Reverging https://github.com/alsa-project/alsa-lib/commit/41039b49ad3e20506134864028c… appears to fix it for me (get `dB == -2837`). I don't understand the new logic, doesn't SND_CTL_TLVT_DB_MINMAX_MUTE mean that the lowest hardware volume value is muted? (Also, the ALSA 1/100 dB values round to zero earlier than the USB 1/256 dB ones.) Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5235 (I also have access to similar device locally) Issue URL : https://github.com/alsa-project/alsa-lib/issues/504 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

(re)use and (re)definition of snd_pcm_hw_params->fifo_size for 'jumpy DMA'
by Péter Ujfalusi 30 Apr '26

30 Apr '26

Hi, for years the discussion around jumpy, bursty DMA have been popping up and we always concluded that we are missing a good definition and agreed way between kernel and user space to handle this. In ALSA it is expected that the DMA (hw_ptr) moves in steady small steps. There is a BATCH mode which tells that the DMA cannot report sub period size position, progression. The DMA bursting fits neither of this, it moves in bigger jumps (bursts) and it can as well can report position in byte level. Typically these systems have DSP which can consumes data in various chunks, making the hw_ptr to jump. Over time the hw_ptr do move at the sampling rate, but when zooming in we can see: initial jump of X frames, hw_ptr stays static for about ~X frame worth of time then the hw_ptr jumps again ahead of X frames, and again, hw_ptr stops, ... This can be a problem for user space which wants to write samples as close to hw_ptr as possible since if it is not aware of the bursty-DMA than it is possible that a burst will jump over the sw_ptr, causing xrun. I was looking at what, how and where we should add this information in kernel and to take it in use by user space when I stumbled across the 'fifo_size' of hw_params struct. It is only set by a few drivers: sound/arm/aaci.c sound/arm/pxa2xx-pcm-lib.c sound/soc/renesas/dma-sh7760.c sound/soc/starfive/jh7110_tdm.c sound/soc/tegra/tegra_pcm.c sound/soc/xtensa/xtfpga-i2s.c sound/usb/misc/ua101.c sound/x86/intel_hdmi_audio.c It's definition is awkwardly a bit different in kernel and alsa-lib: in kernel it can be in bytes or frames, but in user space it is always in frames (snd_pcm_hw_params_get_fifo_size). So far I could not find evidence that this is in active use by user space. Not used in alsa-utils, pipewire, pulseaudio at least and web search came back empty handed as well. My proposal thus is to re-use, re-define extend the fifo_size as and indication that the hw_ptr _can_ jump at least fifo_size number of frames so applications must take this into account when doing direct update in ALSA buffer for low latency. Or should we add a new member (carved out from the reserved section of hw_params struct) specifically for this purpose, like dma_burst_size, which likely going to be equal to fifo_size if both is filled by the driver. Or a new flag (SNDRV_PCM_INFO_) that PCM devices can use to indicate that the DMA is bursting and in that case the fifo_size holds the number of frames that it is expected to jump. But we are slowly running out of bits and I'm not sure if it is a good idea to dual use in kernel internal bits for user ABI (SNDRV_PCM_INFO_DRAIN_TRIGGER, SNDRV_PCM_INFO_FIFO_IN_FRAMES) https://github.com/thesofproject/linux/issues/5313 https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4489 -- Péter

4 31

Sound over Display support for Microsoft Windows Dev Kit 2023 (Blackrock)
by GitHub pull_request - edited 30 Apr '26

30 Apr '26

alsa-project/alsa-ucm-conf pull request #756 was edited from jglathe: Introduce a device profile for the Microsoft Windows Dev Kit 2023. It has a miniDP out and 2 Type-C connectors capable of DP Altmode, and no other (easily) accessible othe audion input/outputs. To use it you also need the corresponding topology, will be a [PR in audioreach-topology](https://github.com/jglathe/audioreach-topology/tree/jg…. I also tried to integrate it with the existing Lenovo Thinkpad X13s profile to get automatic detection (works here). Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/756 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/756.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Jg/blackrock audio
by GitHub pull_request - opened 30 Apr '26

30 Apr '26

alsa-project/alsa-ucm-conf pull request #756 was opened from jglathe: Introduce a device profile for the Microsoft Windows Dev Kit 2023. It has a miniDP out and 2 Type-C connectors capable of DP Altmode, and no other (easily) accessible othe audion input/outputs. To use it you also need the corresponding topology, will be a [PR in audioreach-topology](https://github.com/jglathe/audioreach-topology/tree/jg…. I also tried to integrate it with the existing Lenovo Thinkpad X13s profile to get automatic detection (works here). Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/756 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/756.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v4 1/2] ALSA: control: tidy up whitespaces
by Maciej Strozek 30 Apr '26

30 Apr '26

Clean up trailing whitespace in preparation for the card components changes. Signed-off-by: Maciej Strozek <mstrozek(a)opensource.cirrus.com> --- sound/core/control_compat.c | 2 +- sound/core/init.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/core/control_compat.c b/sound/core/control_compat.c index 16bc80555f265..4ad571087ff59 100644 --- a/sound/core/control_compat.c +++ b/sound/core/control_compat.c @@ -417,7 +417,7 @@ static int snd_ctl_elem_add_compat(struct snd_ctl_file *file, break; } return snd_ctl_elem_add(file, data, replace); -} +} enum { SNDRV_CTL_IOCTL_ELEM_LIST32 = _IOWR('U', 0x10, struct snd_ctl_elem_list32), diff --git a/sound/core/init.c b/sound/core/init.c index 0c316189e9476..593c05895e118 100644 --- a/sound/core/init.c +++ b/sound/core/init.c @@ -722,7 +722,7 @@ static void snd_card_set_id_no_lock(struct snd_card *card, const char *src, int len, loops; bool is_default = false; char *id; - + copy_valid_id_string(card, src, nid); id = card->id; @@ -1031,7 +1031,7 @@ int __init snd_card_info_init(void) * * Return: Zero otherwise a negative error code. */ - + int snd_component_add(struct snd_card *card, const char *component) { char *ptr; -- 2.47.3

1 0

ASoC: Intel: sof_es8336: add DMI quirk for Huawei MateBook D15 NBLB-WAX9N-PCB-B2
by Aser Martinez 29 Apr '26

29 Apr '26

Hi, The Huawei MateBook D15 variant with board name NBLB-WAX9N-PCB-B2 is missing a DMI quirk entry in sof_es8336.c. The related BOHB-WAX9-PCB-B2 board was fixed previously, but this variant was not included. Hardware: Huawei MateBook D15 DMI_SYS_VENDOR: HUAWEI DMI_BOARD_NAME: NBLB-WAX9N-PCB-B2 Kernel: 7.0.1 (CachyOS) Codec: ES8336 via SOF (sof-cml-es8336-dmic2ch-ssp0) Problem: Headphone jack produces no audio. With quirk=0xb0 manually set via modprobe.d, headphones partially work but jack detection is unreliable. The fix should be adding this DMI entry to sof_es8336.c: { .callback = sof_es8336_quirk_cb, .matches = { DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"), DMI_MATCH(DMI_BOARD_NAME, "NBLB-WAX9N-PCB-B2"), }, .driver_data = (void *)(SOF_ES8336_HEADPHONE_GPIO), }, alsa-info output attached. Thanks, Aser

1 0