public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: GitHub issues - opened <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: Generic HDA UCM (HDA/HiFi-analog.conf + HiFi-mic.conf) creates phantom devices on jackless Framework Laptop 16 (ALC285, f111:000d) causing wrong PipeWire defaults
Date: Sat,  3 Jan 2026 10:08:22 +0100 (CET)	[thread overview]
Message-ID: <18872d6537bfbd00-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <18872d6535fb4300-webhooks-bot@alsa-project.org>

alsa-project/alsa-ucm-conf issue #673 was opened from dniku:

**DISCLOSURE**: the text below was written with heavy assistance from a language model.

---

### Summary

On Framework Laptop 16 (AMD Ryzen AI 300 series) with `alsa.mixer_name = "Realtek ALC285"`, `alsa.components = "HDA:10ec0285,f111000d,00100002"`, the generic HDA UCM profile creates a `Headphones` playback device even though the codec exposes no headphone jack/controls. WirePlumber then selects a phantom `Headphones` sink by default (higher UCM priority than `Speaker`), requiring a manual switch to `Speaker`.

Separately: UCM also exposes an HDA “Stereo Microphone” capture path (`Mic2`) which records silence; the real microphone is provided by the ACP/DMIC path.

This is reproducible after wiping WirePlumber state and restarting PipeWire/WirePlumber.

### Hardware / software
- Machine: Framework Laptop 16 (AMD Ryzen AI 300 series)
- Codec: Realtek ALC285, subsystem id f111:000d
- Distro: NixOS 25.11
- PipeWire: 1.4.9
- WirePlumber: 0.5.12
- alsa-ucm-conf: 1.2.14

### Steps to reproduce
1. Ensure you are using the stock alsa-ucm-conf UCM2 files (no overrides).
2. Clear WP state and restart user audio services:
   ```sh
   wpctl clear-default
   rm -rf ~/.local/state/wireplumber
   systemctl --user restart wireplumber pipewire pipewire-pulse
   ```

3. Observe the default sink:

   ```sh
   wpctl status -n
   wpctl inspect @DEFAULT_AUDIO_SINK@
   ```

### Observed behavior (before fix)

Default sink becomes the phantom Headphones profile:

```sh
$ wpctl status -n
# ...
 ├─ Sinks:
 │  *   59. alsa_output.pci-0000_c2_00.6.HiFi__Headphones__sink [vol: 0.40]
```

```sh
$ wpctl inspect @DEFAULT_AUDIO_SINK@
# ...
    device.profile.name = "HiFi: Headphones: sink"
  * node.name = "alsa_output.pci-0000_c2_00.6.HiFi__Headphones__sink"
```

But ALSA exposes no headphone controls on that codec/card:

```sh
$ amixer -c 2 scontrols
Simple mixer control 'Master',0
Simple mixer control 'Speaker',0
Simple mixer control 'Bass Speaker',0
Simple mixer control 'PCM',0

$ amixer -c 2 controls
numid=7,iface=CARD,name='Speaker Front Phantom Jack'
numid=8,iface=CARD,name='Speaker Surround Phantom Jack'
numid=6,iface=MIXER,name='Master Playback Switch'
numid=5,iface=MIXER,name='Master Playback Volume'
numid=13,iface=MIXER,name='PCM Playback Volume'
numid=4,iface=MIXER,name='Bass Speaker Playback Switch'
numid=3,iface=MIXER,name='Bass Speaker Playback Volume'
numid=2,iface=MIXER,name='Speaker Playback Switch'
numid=1,iface=MIXER,name='Speaker Playback Volume'
numid=10,iface=PCM,name='Capture Channel Map'
numid=9,iface=PCM,name='Playback Channel Map'
numid=11,iface=PCM,name='Capture Channel Map',device=2
numid=12,iface=PCM,name='Capture Channel Map',index=1,device=2
```

The codec dump also contains no “Headphone/Headset” pins:

```sh
$ grep -nEi 'Headphone|Headset|Front Headphone' /proc/asound/card2/codec\#0
# (no output)
```

### Root cause hypothesis

[`ucm2/HDA/HiFi-analog.conf`](https://github.com/alsa-project/alsa-ucm-conf/blob/5d175e1f7e3df15973945a9cc15e82fa7ca0d7b6/ucm2/HDA/HiFi-analog.conf) defines `SectionDevice."Headphones"` unconditionally and assigns it `PlaybackPriority 200`, while `Speaker` is `PlaybackPriority 100`. On jackless hardware with no headphone controls/jack, this results in a “Headphones” UCM device that WirePlumber prefers.

Similar problem exists in [`ucm2/HDA/HiFi-mic.conf`](https://github.com/alsa-project/alsa-ucm-conf/blob/5d175e1f7e3df15973945a9cc15e82fa7ca0d7b6/ucm2/HDA/HiFi-mic.conf)

### Proposed fix

Guard creation of `SectionDevice."Headphones"` so it is only instantiated when relevant headphone controls/jack controls exist (e.g. `Headphone Playback Volume`, `Headphone Playback Switch`, or `iface=CARD,name='Headphone Jack'`).

Similarly guard the HDA analog capture device on this platform when it is not functional, leaving the working ACP/DMIC capture path as the only mic.

---

(end of section written with language model assistance)

I have proposed a patch for Framework 16 in https://github.com/NixOS/nixos-hardware/pull/1718. Please see the diagnostics shared in that PR. I would appreciate feedback on the specific workaround that is implemented there from someone familiar with `alsa-ucm-conf`.

For the output of `nix shell nixpkgs#alsa-utils -c alsa-info --no-upload --stdout` before/after applying the patch, as well as the diff between the two, please see [this gist](https://gist.github.com/dniku/d9b5095aef0e926399ebd772d0b40bd0).

Issue URL     : https://github.com/alsa-project/alsa-ucm-conf/issues/673
Repository URL: https://github.com/alsa-project/alsa-ucm-conf

           reply	other threads:[~2026-01-03  9:09 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <18872d6535fb4300-webhooks-bot@alsa-project.org>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18872d6537bfbd00-webhooks-bot@alsa-project.org \
    --to=github@alsa-project.org \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox