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

ALSA 1.2.8 release
by Jaroslav Kysela 14 Jun '26

14 Jun '26

Hello all, new ALSA userspace packages were released. You may download them from the ALSA website http://www.alsa-project.org or directly: HTTP: https://www.alsa-project.org/files/pub FTP: ftp://ftp.alsa-project.org/pub Released packages: alsa-lib alsa-utils alsa-ucm-conf tinycompress Full list of changes: https://www.alsa-project.org/wiki/Changes_v1.2.7.2_v1.2.8 The fingerprint of the public signing key is: F04D F507 37AC 1A88 4C4B 3D71 8380 596D A6E5 9C91 Have fun, Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 14

(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

[REGRESSION] Audio popping on ThinkPad X1 Carbon Gen 12 (ALC287) after commit d2e01e0c5e94
by Jérémy Bethmont 14 Apr '26

14 Apr '26

Hi Takashi, Kailang, I am reporting an audio regression introduced in kernel 6.18.13 on the Lenovo ThinkPad X1 Carbon Gen 12 (Meteor Lake, Realtek ALC287 codec, SSID: 0x17aa231e). Since this update, the laptop emits a short, noticeable hardware pop/blip from the speakers exactly when an audio stream closes and the PCM state suspends. It happens consistently a few seconds after playback finishes (e.g., after a system notification or terminal bell). I have tracked the regression down to the following commit: d2e01e0c5e947da0b5005ca89efa82baeb232adc ("ALSA: hda/realtek - fixed speaker no sound") #regzbot introduced: d2e01e0c5e947da0b5005ca89efa82baeb232adc Root cause analysis: The commit modifies the `alc287_alc1318_playback_pcm_hook` function, adding raw COEF writes to disable/enable AMP silence detection on HDA_GEN_PCM_ACT_OPEN and HDA_GEN_PCM_ACT_CLOSE. Because `alc287_alc1318_playback_pcm_hook` is a shared hook used by multiple Lenovo ALC287/ALC1318 devices, these unconditional `WRITE_COEF` instructions are being sent to hardware that does not need the silence detection fix. On the X1 Carbon Gen 12, executing `alc_process_coef_fw(codec, en_coefs)` upon stream close triggers an immediate electrical pop. Monitoring with `pw-mon` confirms the hardware pop coincides perfectly with the monitor_FR / monitor_FL ports going idle/suspended. Proposed solution: Could we revert this commit, or alternatively, wrap these specific silence-detection COEF writes in a targeted `ALC287_FIXUP` quirk matched via SSID/DMI, rather than executing them globally in the shared playback hook? Thank you for your time and work on this. Best regards, Jeremy

3 8

[PATCH] ASoC: rt1320-sdw: remove brown out settings in blind_write
by jack.yu＠realtek.com 01 Apr '26

01 Apr '26

From: Jack Yu <jack.yu(a)realtek.com> Remove brown out settings as these settings are for customized cases, not for general cases. Signed-off-by: Jack Yu <jack.yu(a)realtek.com> --- sound/soc/codecs/rt1320-sdw.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/sound/soc/codecs/rt1320-sdw.c b/sound/soc/codecs/rt1320-sdw.c index 8bb7e8497c72..35797a13cc7e 100644 --- a/sound/soc/codecs/rt1320-sdw.c +++ b/sound/soc/codecs/rt1320-sdw.c @@ -169,12 +169,6 @@ static const struct reg_sequence rt1320_vc_blind_write[] = { { 0xd487, 0x3b }, { 0xd486, 0xc3 }, { 0xc598, 0x04 }, - { 0xdb03, 0xf0 }, - { 0xdb09, 0x00 }, - { 0xdb08, 0x7a }, - { 0xdb19, 0x02 }, - { 0xdb07, 0x5a }, - { 0xdb05, 0x45 }, { 0xd500, 0x00 }, { 0xd500, 0x17 }, { 0xd600, 0x01 }, -- 2.53.0

3 2

Add sofprobeclient binary
by GitHub pull_request - opened 31 Mar '26

31 Mar '26

alsa-project/tinycompress pull request #35 was opened from jsarha: I was hoping this SOF [1] debug tool could be accepted as part of tinycompress package. The current method of usage [2] is not very convenient and a single binary doing everything would simplify things nicely. And since this method of debugging uses alsa compressed support, I think the most natural place for the tool would be as part of tinycompress repository. Best regards, Jyri [1] https://github.com/thesofproject [2] https://thesofproject.github.io/latest/developer_guides/debugability/probes… Request URL : https://github.com/alsa-project/tinycompress/pull/35 Patch URL : https://github.com/alsa-project/tinycompress/pull/35.patch Repository URL: https://github.com/alsa-project/tinycompress

1 0

[PATCH] ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9
by Alexander Savenko 31 Mar '26

31 Mar '26

The Lenovo Yoga Pro 7 14IMH9 (DMI: 83E2) shares PCI SSID 17aa:3847 with the Legion 7 16ACHG6, but has a different codec subsystem ID (17aa:38cf). The existing SND_PCI_QUIRK for 17aa:3847 applies ALC287_FIXUP_LEGION_16ACHG6, which attempts to initialize an external I2C amplifier (CLSA0100) that is not present on the Yoga Pro 7 14IMH9. As a result, pin 0x17 (bass speakers) is connected to DAC 0x06 which has no volume control, making hardware volume adjustment completely non-functional. Audio is either silent or at maximum volume regardless of the slider position. Add a HDA_CODEC_QUIRK entry using the codec subsystem ID (17aa:38cf) to correctly identify the Yoga Pro 7 14IMH9 and apply ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN, which redirects pin 0x17 to DAC 0x02 and restores proper volume control. The existing Legion entry is preserved unchanged. This follows the same pattern used for 17aa:386e, where Legion Y9000X and Yoga Pro 7 14ARP8 share a PCI SSID but are distinguished via HDA_CODEC_QUIRK. Link: https://github.com/nomad4tech/lenovo-yoga-pro-7-linux Tested-by: Alexander Savenko <alex.sav4387(a)gmail.com> Signed-off-by: Alexander Savenko <alex.sav4387(a)gmail.com> --- 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 086c05053..8efb3e363 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -7622,6 +7622,10 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x3834, "Lenovo IdeaPad Slim 9i 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x383d, "Legion Y9000X 2019", ALC285_FIXUP_LEGION_Y9000X_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3843, "Lenovo Yoga 9i / Yoga Book 9i", ALC287_FIXUP_LENOVO_YOGA_BOOK_9I), + /* Yoga Pro 7 14IMH9 shares PCI SSID 17aa:3847 with Legion 7 16ACHG6; + * use codec SSID to distinguish them + */ + HDA_CODEC_QUIRK(0x17aa, 0x38cf, "Lenovo Yoga Pro 7 14IMH9", ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN), SND_PCI_QUIRK(0x17aa, 0x3847, "Legion 7 16ACHG6", ALC287_FIXUP_LEGION_16ACHG6), SND_PCI_QUIRK(0x17aa, 0x384a, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), -- 2.43.0

2 0

[PATCH] ASoC: Intel: ehl_rt5660: Use the correct rtd->dev device in hw_params
by Sachin Mokashi 31 Mar '26

31 Mar '26

In rt5660_hw_params(), the error path for snd_soc_dai_set_sysclk() correctly uses rtd->dev as the logging device, but the error path for snd_soc_dai_set_pll() uses codec_dai->dev instead. These two devices are distinct: - rtd->dev is the platform device of the PCM runtime (the Intel HDA/SSP controller, e.g. 0000:00:1f.3), which owns the machine driver callback. - codec_dai->dev is the I2C device of the rt5660 codec itself (i2c-10EC5660:00). Since hw_params is a machine driver operation and both calls are made within the same function from the machine driver's context, all error messages should be attributed to rtd->dev. Using codec_dai->dev for one of them would suggest the error originates inside the codec driver, which is misleading. Align the PLL error log with the sysclk one to use rtd->dev, matching the convention used by all other Intel board drivers in this directory. Signed-off-by: Sachin Mokashi <sachin.mokashi(a)intel.com> --- sound/soc/intel/boards/ehl_rt5660.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/ehl_rt5660.c b/sound/soc/intel/boards/ehl_rt5660.c index 5c7b218f22b7..c40cd9fb1a26 100644 --- a/sound/soc/intel/boards/ehl_rt5660.c +++ b/sound/soc/intel/boards/ehl_rt5660.c @@ -127,7 +127,7 @@ static int rt5660_hw_params(struct snd_pcm_substream *substream, params_rate(params) * 50, params_rate(params) * 512); if (ret < 0) - dev_err(codec_dai->dev, "can't set codec pll: %d\n", ret); + dev_err(rtd->dev, "can't set codec pll: %d\n", ret); return ret; } -- 2.34.1 Intel Deutschland GmbH Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany Tel: +49 89 991 430, www.intel.de Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell Chairperson of the Supervisory Board: Nicole Lau Registered Seat: Munich Commercial Register: Amtsgericht Muenchen HRB 186928

2 1

[PATCH 0/2] ASoC: amd: acp: update dmic_num logic for acp pdm dmic
by Vijendar Mukunda 30 Mar '26

30 Mar '26

This patch series updates the dmic_num logic for acp pdm dmic and renames the dmic component name in acp soundwire legacy machine driver. Vijendar Mukunda (2): ASoC: amd: acp: update dmic_num logic for acp pdm dmic ASoC: amd: acp-sdw-legacy: rename the dmic component name sound/soc/amd/acp/acp-sdw-legacy-mach.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.48.1

3 5

USB-Audio: Add Audient EVO4
by GitHub pull_request - edited 30 Mar '26

30 Mar '26

alsa-project/alsa-ucm-conf pull request #708 was edited from motolav: This is a 4in/4out device with 1 analog stereo out and 2 analog mono in. The hardware mixed loopback interface takes up the remaining 4 channels. Without this UCM the device is configured as 4.0 surround for in and out. I copied the way Windows configures the device except for the stereo mic mix as I couldn't get it to work somehow(might have been a wiremix issue). It seems like only the main output volume can be controlled with alsa, modifying anything else requires a driver or software to manually change hardware config Closes: #303 Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/708 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/708.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

USB-Audio: Add Audient EVO4
by GitHub pull_request - reopened 30 Mar '26

30 Mar '26

alsa-project/alsa-ucm-conf pull request #708 was reopened from motolav: This is a 4in/4out device with 1 analog stereo out and 2 analog mono in. The hardware mixed loopback interface takes up the remaining 4 channels. Without this UCM the device is configured as 4.0 surround for in and out. I copied the way Windows configures the device except for the stereo mic mix as I couldn't get it to work somehow(might have been a wiremix issue). Needs the PlaybackMixerElem and CaptureMixerElem implemented so software volumes are tied to hardware volumes Closes: #303 Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/708 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/708.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0