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: sof-hda-dsp: HP OmniBook X Flip 14 — Speaker sink removed when HDMI connected (profile switches to Headphones)
Date: Thu, 12 Mar 2026 09:46:28 +0100 (CET)	[thread overview]
Message-ID: <189c0bab8b136600-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <189c0bab89f95100-webhooks-bot@alsa-project.org>

alsa-project/alsa-ucm-conf issue #720 was opened from zommuter:

(assisted by Claude Opus 4.6 which also prepared a pull request)

## Environment

- **Device:** HP OmniBook X Flip Laptop 14 (Intel Core Ultra 7 258V, Lunar Lake)
- **OS:** Manjaro Linux, kernel 6.18.12-1-MANJARO
- **Packages:**
  - alsa-ucm-conf 1.2.15.3-1
  - sof-firmware 2025.12.2-1
  - PipeWire 1.4.10
  - WirePlumber 0.5.13
- **Audio controller:** Intel Lunar Lake-M HD Audio Controller (00:1f.3)
- **Codec:** Realtek ALC245 (subsystem 103c:8d9f)
- **Card:** sof-hda-dsp / skl_hda_dsp_generic
- **Card longname:** `HP-HPOmniBookXFlipLaptop14_fm0xxx-Type1ProductConfigId-8D9F`

## Problem

When an HDMI monitor is connected, the Speaker sink completely disappears. The card has two mutually exclusive HiFi profiles (Speaker and Headphones share the same PCM `hw:sofhdadsp`):

```
HiFi (HDMI1, HDMI2, HDMI3, Headphones, Mic1, Mic2): priority 10300, available: yes
HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker):    priority 10200, available: yes
```

When HDMI is connected, both profiles become `available: yes` (because HDMI1 is available in both). WirePlumber selects the higher-priority Headphones profile (10300) — even though the Headphone Jack reports `off` and no headphones are plugged in. This removes the Speaker sink entirely.

Without HDMI connected, the Headphones profile is correctly `available: no` (no ports with availability groups report as available), so the Speaker profile is selected.

## Expected behavior

The Speaker sink should remain available regardless of HDMI connection state. When no headphones are plugged in, the Speaker profile should be preferred.

## Steps to reproduce

1. Clear WirePlumber saved state: `sed -i '/alsa_card.pci.*skl_hda_dsp/d' ~/.local/state/wireplumber/default-profile`
2. Boot or restart WirePlumber with no HDMI connected
3. Verify Speaker sink is present: `pactl list short sinks` — Speaker sink exists
4. Connect an HDMI monitor
5. `pactl list short sinks` — Speaker sink is gone, replaced by Headphones

Note: WirePlumber persists profile selection in `~/.local/state/wireplumber/default-profile`. If the Speaker profile was previously manually selected, the bug won't reproduce until this saved state is cleared.

## Diagnostic data

Full `alsa-info.sh` output can be uploaded if needed.

### Jack status (HDMI connected, no headphones plugged in)

```
HDMI/DP,pcm=3 Jack: values=on    (monitor connected)
HDMI/DP,pcm=4 Jack: values=off
HDMI/DP,pcm=5 Jack: values=off
Headphone Jack:     values=off    (nothing plugged in)
Mic Jack:           values=off
Speaker Phantom Jack: values=on   (always on)
```

### Profile and port listing (HDMI connected — broken state)

```
Profiles:
  off: (priority: 0, available: yes)
  HiFi (HDMI1, HDMI2, HDMI3, Headphones, Mic1, Mic2): (priority: 10300, available: yes)
  HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker):    (priority: 10200, available: yes)
  pro-audio: (priority: 1, available: yes)

Active Profile: HiFi (HDMI1, HDMI2, HDMI3, Headphones, Mic1, Mic2)   ← WRONG

Ports:
  [Out] HDMI3:      priority 700, not available
  [Out] HDMI2:      priority 600, not available
  [Out] HDMI1:      priority 500, available         (monitor connected)
  [Out] Speaker:    priority 100, availability unknown
  [In]  Mic2:       priority 200, not available
  [In]  Mic1:       priority 100, availability unknown
  [Out] Headphones: priority 200, not available      ← jack is off, nothing plugged in
```

### Profile and port listing (no HDMI — working state)

```
Profiles:
  HiFi (HDMI1, HDMI2, HDMI3, Headphones, Mic1, Mic2): (priority: 10300, available: no)   ← correctly unavailable
  HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker):    (priority: 10200, available: yes)

Active Profile: HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker)   ← CORRECT
```

### UCM device dump

```
Verb.HiFi {
  Device.Headphones {
    PlaybackPriority 200
    PlaybackPCM "hw:sofhdadsp"
    JackControl "Headphone Jack"
  }
  Device.Speaker {
    PlaybackPriority 100
    PlaybackPCM "hw:sofhdadsp"
    # No JackControl — uses Speaker Phantom Jack (always on)
  }
}
```

### wpctl status (broken state, HDMI connected)

```
Audio
 ├─ Sinks:
 │      HDMI / DisplayPort 2 Output [vol: 1.00]
 │  *   HDMI / DisplayPort 1 Output [vol: 1.00]
 │      Headphones [vol: 1.00]                    ← present despite nothing plugged in
 │      HDMI / DisplayPort 3 Output [vol: 1.00]
 │                                                 ← Speaker is MISSING
```

## Root cause analysis

Speaker and Headphones share the same PCM device (`hw:sofhdadsp`), so PipeWire/ACP correctly generates separate mutually exclusive profiles. The UCM config in `ucm2/HDA/HiFi-analog.conf` assigns:

- **Headphones**: `PlaybackPriority 200`
- **Speaker**: `PlaybackPriority 100`

This results in profile priorities of 10300 (Headphones) vs 10200 (Speaker). The profile availability logic works as follows:

1. **Without HDMI**: All HDMI ports are `not available`, Headphones port is `not available`. The Headphones profile has no available ports (ports with `availability unknown` like Mic1 don't make the profile available), so the profile is `available: no`. Speaker profile is selected correctly.

2. **With HDMI**: HDMI1 becomes `available`. Since HDMI1 is shared by both profiles, both become `available: yes`. WirePlumber then selects purely by priority: Headphones (10300) wins over Speaker (10200), **ignoring that the Headphones port itself is `not available`**.

There are no `ConflictingDevices` declarations in the UCM config — the profile split is entirely due to the shared PCM.

## Suggested fix

**Swap `PlaybackPriority` values** in `ucm2/HDA/HiFi-analog.conf` so Speaker (200) > Headphones (100). This makes the Speaker profile the default (priority 10200 → 10300), while the Headphones profile would only be preferred when the Headphone Jack reports as plugged (WirePlumber boosts priority for profiles with available ports).

This seems correct as a general default: built-in speakers should be the default output, with headphones taking over only when detected via jack. When headphones are plugged in, the Headphone Jack becomes `available`, which should cause WirePlumber to re-evaluate and switch to the Headphones profile based on port availability — regardless of the lower base priority.

Note: headphone jack switching behavior has not been tested on this hardware (no 3.5mm cable available). Feedback from others with similar hardware welcome.

Alternatively, this could be addressed in WirePlumber's profile selection logic by weighting port availability more heavily — but the UCM priority swap is the simpler and more targeted fix.

## Workaround

Force the Speaker profile via WirePlumber:

```lua
-- ~/.config/wireplumber/wireplumber.conf.d/51-force-speaker.conf
monitor.alsa.rules = [
  {
    matches = [
      { device.name = "~alsa_card.pci*skl_hda_dsp*" }
    ]
    actions = {
      update-props = {
        device.profile = "HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker)"
      }
    }
  }
]
```

Or manually: `pactl set-card-profile alsa_card.pci-0000_00_1f.3-platform-skl_hda_dsp_generic "HiFi (HDMI1, HDMI2, HDMI3, Mic1, Mic2, Speaker)"`

Note: Headphone behavior when actually plugging in headphones has not been tested with this workaround (no 3.5mm cable available at time of report).

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

       reply	other threads:[~2026-03-12  8:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <189c0bab89f95100-webhooks-bot@alsa-project.org>
2026-03-12  8:46 ` GitHub issues - opened [this message]
     [not found] <189c0c1224249c00-webhooks-bot@alsa-project.org>
2026-03-12  8:53 ` sof-hda-dsp: HP OmniBook X Flip 14 — Speaker sink removed when HDMI connected (profile switches to Headphones) GitHub issues - edited

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=189c0bab8b136600-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