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

Intel/sof-hda-dsp/Hdmi.conf: HDMI devices always registered with high priority regardless of availability, causing Speaker to be ignored as fallback sink
by GitHub issues - opened 01 Mar '26

01 Mar '26

alsa-project/alsa-ucm-conf issue #711 was opened from abelic: ## Description In `ucm2/Intel/sof-hda-dsp/Hdmi.conf`, all three HDMI ports are registered unconditionally using `Condition { Type AlwaysTrue }` with priorities 500, 600 and 700. The laptop Speaker has priority 100 (from `HDA/HiFi-analog.conf`). This causes PipeWire/WirePlumber to always select HDMI1 as the fallback sink when the default sink becomes unavailable (e.g. Bluetooth speaker suspends), even when no monitor is connected. Audio is silently routed to HDMI1 (RUNNING state with no output) instead of the laptop Speaker. ## Hardware - Laptop: Huawei RLEFG-XX M1010 - Audio: Intel Raptor Lake-P/U/H cAVS (sof-hda-dsp) - OS: Fedora 43 - PipeWire: 1.4.10 - WirePlumber: 0.5.13 ## Steps to reproduce 1. Connect a Bluetooth audio device 2. Play audio — it routes correctly to Bluetooth 3. Disconnect or suspend the Bluetooth device 4. Audio is routed to HDMI1 sink instead of the laptop Speaker ## Observed behavior `pactl list short sinks` shows HDMI1 as RUNNING while Speaker is SUSPENDED. WirePlumber selects HDMI1 as fallback because its priority (500) is higher than Speaker (100), even though no monitor is connected and HDMI ports are reported as "not available". ## Expected behavior When HDMI ports are not available (no monitor connected), the Speaker should be selected as the fallback sink. ## Relevant config `ucm2/Intel/sof-hda-dsp/Hdmi.conf`: ``` If.hdmi1 { Condition { Type AlwaysTrue } # <-- no availability check True.Macro.hdmi1.HDMI { Number 1 Device 3 Priority 500 # higher than Speaker (100) } } If.hdmi2 { Condition { Type AlwaysTrue } True.Macro.hdmi1.HDMI { Number 2 Device 4 Priority 600 } } If.hdmi3 { Condition { Type AlwaysTrue } True.Macro.hdmi1.HDMI { Number 3 Device 5 Priority 700 } } ``` `ucm2/HDA/HiFi-analog.conf` (relevant excerpt): ``` Value { PlaybackPriority 100 # Speaker priority — lower than all HDMI ports ... } ``` ## Suggested fix Add availability detection for HDMI ports before assigning high priority, or lower HDMI priority when the port is not available, similar to how Headphones use `JackControl` for availability detection. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/711 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

~/.config
by GitHub issues - edited 01 Mar '26

01 Mar '26

alsa-project/alsa-ucm-conf issue #710 was edited from beatboxa: Alsa has a long history, and I think as a result, there may be some approaches that may predate some of today's standards. For example, I don't believe there are any configs stored in ~/.config/ like most other modern applications use. Even alsa's overall standard user config is ~/.asoundrc This may make sense as alsa is a lower-level hardware driver; however with ucm it approaches the user space and has some overlap with systems like pipewire or pulseaudio. Therefore, I'd like to recommend considering allowing ucm channel mappings to be stored in ~/.config/, which would override systemwide ucm mappings. Perhaps it could be hierarchical, where the system looks for configs in: - first looks at system directories (eg. /usr/share/alsa or /etc/alsa) - then ~/.asoundrc (for legacy compatibility) - then ~/.config/alsa Such that ~/.config/alsa is the override for the others. Particularly for ucm2 (eg. ~/.config/alsa/ucm2/), since this is designed for the user/application layer. In other words, I'd like to be able to define ucm2 channel mappings in ~/.config/alsa/ucm2 , which would override those in /usr/share/alsa/ucm2 (in my distro). One major benefit would be in surviving system or alsa package upgrades. One challenge might be in order of operations, as downstream systems like pipewire/wireplumber or pulseaudio or jack often rely on alsa; however I believe these would still end up picking up user configs. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/710 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

~/.config
by GitHub issues - opened 01 Mar '26

01 Mar '26

alsa-project/alsa-ucm-conf issue #710 was opened from beatboxa: Alsa has a long history, and I think as a result, there may be some approaches that may predate some of today's standards. For example, I don't believe there are any configs stored in ~/.config/ like most other modern applications use. Even alsa's overall standard user config is ~/.asoundrc This may make sense as alsa is a lower-level hardware driver; however with ucm it approaches the user space and has some overlap with systems like pipewire or pulseaudio. Therefore, I'd like to recommend considering allowing ucm channel mappings to be stored in ~/.config/, which would override systemwide ucm mappings. Perhaps it could be hierarchical, where the system looks for configs in: - first looks at system directories (eg. /usr/share/alsa or /etc/alsa) - then ~/.asoundrc (for legacy compatibility) - then ~/.config/alsa Such that ~/.config/alsa is the override for the others. Particularly for ucm2 (eg. ~/.config/alsa/ucm2/), since this is designed for the user/application layer. One major benefit would be in surviving system or alsa package upgrades. One challenge might be in order of operations, as downstream systems like pipewire/wireplumber or pulseaudio or jack often rely on alsa; however I believe these would still end up picking up user configs. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/710 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[GIT PULL] ASoC fixes for v7.0-rc1
by Mark Brown 26 Feb '26

26 Feb '26

The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v7.0-rc1 for you to fetch changes up to 32fc4168fa56f6301d858c778a3d712774e9657e: ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table (2026-02-23 14:52:11 +0000) ---------------------------------------------------------------- ASoC: Fixes for v7.0 One quirk and a fix for handling of exotic peripherals on cs42l43. ---------------------------------------------------------------- Azamat Almazbek uulu (1): ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table Charles Keepax (1): ASoC: cs42l43: Report insert for exotic peripherals sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ sound/soc/codecs/cs42l43-jack.c | 1 + 2 files changed, 8 insertions(+)

2 1

Re: [PATCH] ALSA: hda/ca0132: Set HP/Speaker auto-detect default from headphone pin verb
by Takashi Iwai 26 Feb '26

26 Feb '26

On Wed, 25 Feb 2026 18:36:45 +0100, Matt DeVillier wrote: > > From 79d54b6b2b2410ac3c169329b93607042b137693 Mon Sep 17 00:00:00 2001 > From: Matt DeVillier <matt.devillier(a)gmail.com> > Date: Wed, 25 Feb 2026 11:25:18 -0600 > Subject: [PATCH] ALSA: hda/ca0132: Set HP/Speaker auto-detect default from > headphone pin verb > > HP/Speaker auto-detect (VNID_HP_ASEL) has been off by default for every > CA0132 device since the driver was added in 2012. vnode_lswitch is > always initialized to 0 in ca0132_init_chip(), and no quirk or other > code path enables it. As a result, headphone jack detection works only > after the user manually turns on "HP/Speaker Auto Detect" in alsamixer, > which is not obvious on laptops with combo jacks (e.g. Google Link, > Alienware). > > Change the default to follow the headphone pin config: if the pin verb > has presence detect enabled (no AC_DEFCFG_MISC_NO_PRESENCE) and the > codec supports it (AC_PINCAP_PRES_DETECT), enable HP_ASEL by default. > This lets firmware (coreboot, UEFI, etc.) express whether the headphone > jack supports insertion detection. Devices with combo jacks can default > to auto-detect; devices with fixed/no jack leave it off. > > Signed-off-by: Matt DeVillier <matt.devillier(a)gmail.com> The code change looks OK, but the patch seems malformed by your mailer, and can't be applied cleanly. Also, the mailing list for the kernel patch submission is linux-sound(a)vger.kernel.org, not alsa-devel ML. Please fix your mail setup and resubmit to the right address. thanks, Takashi > --- > sound/hda/codecs/ca0132.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/sound/hda/codecs/ca0132.c b/sound/hda/codecs/ca0132.c > index dd054aedd501..ca6cb57347ea 100644 > --- a/sound/hda/codecs/ca0132.c > +++ b/sound/hda/codecs/ca0132.c > @@ -9816,6 +9816,15 @@ static void ca0132_config(struct hda_codec *codec) > spec->dig_in = 0x09; > break; > } > + > + /* Default HP/Speaker auto-detect from headphone pin verb: enable if the > + * pin config indicates presence detect (not AC_DEFCFG_MISC_NO_PRESENCE). > + */ > + if (spec->unsol_tag_hp && > + (snd_hda_query_pin_caps(codec, spec->unsol_tag_hp) & > AC_PINCAP_PRES_DETECT) && > + !(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, spec->unsol_tag_hp)) & > + AC_DEFCFG_MISC_NO_PRESENCE)) > + spec->vnode_lswitch[VNID_HP_ASEL - VNODE_START_NID] = 1; > } > > static int ca0132_prepare_verbs(struct hda_codec *codec) > -- > 2.51.0

1 0

Why does MMAP access ignore start_threshold?
by Mark Hills 25 Feb '26

25 Feb '26

It seems that start_threshold (swparams) is not honoured if MMAP access is used. Whereas I expect that once a total of enough bytes have been committed the device automatically starts the consuming of the buffer, as it does with snd_pcm_writei(). Is this a bug, or intentional design? It does not seem to be the subject of any documentation -- yet for many years I seem to be be working around it. Perhaps I am consistently doing something wrong, here's a test case below. -- Mark #include <alsa/asoundlib.h> #define always(r) _always(r, __LINE__) #define FORMAT SND_PCM_FORMAT_S16 #define ACCESS SND_PCM_ACCESS_MMAP_INTERLEAVED static void _always(int r, unsigned line) { if (r < 0) { fprintf(stderr, "%d: %s\n", line, snd_strerror(r)); abort(); } } static void set_hw(snd_pcm_t *pcm, unsigned rate, unsigned channels, snd_pcm_uframes_t buffer_size, snd_pcm_uframes_t period_size) { int r; snd_pcm_hw_params_t *hw; snd_pcm_hw_params_alloca(&hw); r = snd_pcm_hw_params_any(pcm, hw); always(r); r = snd_pcm_hw_params_set_access(pcm, hw, ACCESS); always(r); r = snd_pcm_hw_params_set_format(pcm, hw, FORMAT); always(r); r = snd_pcm_hw_params_set_rate(pcm, hw, rate, 0); always(r); r = snd_pcm_hw_params_set_channels(pcm, hw, channels); always(r); r = snd_pcm_hw_params_set_buffer_size(pcm, hw, buffer_size); always(r); r = snd_pcm_hw_params_set_period_size(pcm, hw, period_size, 0); always(r); r = snd_pcm_hw_params(pcm, hw); always(r); } static void set_sw(snd_pcm_t *pcm, snd_pcm_uframes_t start_threshold, snd_pcm_uframes_t avail_min) { int r; snd_pcm_sw_params_t *sw; snd_pcm_sw_params_alloca(&sw); r = snd_pcm_sw_params_current(pcm, sw); always(r); r = snd_pcm_sw_params_set_start_threshold(pcm, sw, start_threshold); always(r); r = snd_pcm_sw_params_set_avail_min(pcm, sw, avail_min); always(r); r = snd_pcm_sw_params(pcm, sw); always(r); } snd_pcm_uframes_t do_mmap(snd_pcm_t *pcm) { int r; snd_pcm_uframes_t frames, offset; const snd_pcm_channel_area_t *area; r = snd_pcm_wait(pcm, 1000); always(r); r = snd_pcm_mmap_begin(pcm, &area, &offset, &frames); always(r); r = snd_pcm_mmap_commit(pcm, offset, frames); always(r); return frames; } snd_pcm_uframes_t do_write(snd_pcm_t *pcm, unsigned channels, snd_pcm_uframes_t frames) { int r; void *buf; size_t len = channels * snd_pcm_format_size(FORMAT, frames); buf = alloca(len); bzero(buf, len); r = snd_pcm_writei(pcm, buf, frames); always(r); return frames; } int main(int argc, char *argv[]) { int r; snd_pcm_t *pcm; r = snd_pcm_open(&pcm, argv[1], SND_PCM_STREAM_PLAYBACK, 0); always(r); set_hw(pcm, 48000, 2, 2048, 512); set_sw(pcm, 1024, 512); r = snd_pcm_prepare(pcm); always(r); for (;;) { snd_pcm_uframes_t frames; if (ACCESS == SND_PCM_ACCESS_MMAP_INTERLEAVED) frames = do_mmap(pcm); else frames = do_write(pcm, 2, 512); fprintf(stderr, "written %lu\n", frames); } r = snd_pcm_close(pcm); always(r); return 0; }

1 0

Re: [RFC PATCH] ASoC: Intel: sof_es8336: Add DMI quirk for Huawei BOD-WXX9
by Mark Brown 23 Feb '26

23 Feb '26

On Mon, Feb 23, 2026 at 11:40:45AM +0300, Honey Tydik wrote: > Gentle ping on this RFC. I'm still investigating why GPIO control from > DAPM event doesn't work on Huawei BOD-WXX9, while the same code works > from probe context. Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled. Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed.

1 0

ucm2: sof-soundwire: Add support for Cirrus Logic CS47L47
by GitHub pull_request - opened 23 Feb '26

23 Feb '26

alsa-project/alsa-ucm-conf pull request #709 was opened from rfvirgil: Add the sof-soundwire and codec files for the CS47L47. This is a SDCA codec with headphone/headset and digital mic. The configuration is based on the CS42L45 files. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/709 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/709.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

USB-Audio: Add Audient EVO4
by GitHub pull_request - edited 23 Feb '26

23 Feb '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). The loopback interface requires software to configure what channels are mixed into its recording interface that's only available on Windows and macOS but there is an incomplete script to control the device's hardware registers at github.com/vijay-prema/audient-evo-linux-tools. 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 - opened 23 Feb '26

23 Feb '26

alsa-project/alsa-ucm-conf pull request #708 was opened 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. The loopback interface requires software to configure what channels are mixed into its recording interface that's only available on Windows and macOS but there is an incomplete script to control the device's hardware registers at github.com/vijay-prema/audient-evo-linux-tools. 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