March 2026 - 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