All of lore.kernel.org
 help / color / mirror / Atom feed
From: GitHub issues - opened <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: # Regression in 1.2.16: ALC4080 S/PDIF device dropped on MSI X870 Tomahawk (`0db0:cd0e`)
Date: Thu,  4 Jun 2026 01:43:32 +0200 (CEST)	[thread overview]
Message-ID: <18b5b6cab33c8800-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <18b5b6cab30e9300-webhooks-bot@alsa-project.org>

alsa-project/alsa-ucm-conf issue #773 was opened from CeaseFunction:

## Summary

After upgrading `alsa-ucm-conf` from `1.2.15.3` to `1.2.16`, the S/PDIF output device on my MSI X870 Tomahawk disappeared. The board matches the `Realtek/ALC4080` profile, and S/PDIF previously worked fine. Reverting **only** `alsa-ucm-conf` to `1.2.15.3` (leaving `alsa-lib 1.2.16` in place) immediately restored it, which isolates the regression to the profile data — specifically a new conditional in `USB-Audio/Realtek/ALC4080-HiFi.conf` that drops the S/PDIF device on boards whose PCM subdevice naming the new probe fails to match.

## Environment

- **Distribution:** CachyOS (Arch-based), rolling
- **`alsa-ucm-conf` broken:** 1.2.16-1
- **`alsa-ucm-conf` working:** 1.2.15.3-2
- **`alsa-lib`:** 1.2.16 (NOT reverted — see below)
- **Board / device:** MSI X870 Tomahawk, USB-attached audio, ID `0db0:cd0e`
- **Matched profile:** `Realtek/ALC4080` (via `USB-Audio/USB-Audio.conf`)
- **Kernel:** 7.0.10-2-cachyos
- **Audio server:** PipeWire 1.6.6 / WirePlumber 0.5.14

## Symptom

The S/PDIF output is no longer enumerated. Analog outputs on the same card are unaffected, and a separate USB DAC is unaffected. The S/PDIF device returns when `alsa-ucm-conf` alone is downgraded to 1.2.15.3.

## Root cause

Device matching is unchanged between versions — `0db0:cd0e` matches the ALC4080 block in `USB-Audio/USB-Audio.conf` in both 1.2.15.3 and 1.2.16, confirmed by:

```
grep -rl "0db0:cd0e" /usr/share/alsa/ucm2/           # 1.2.15.3 -> USB-Audio.conf
grep -rl "0db0:cd0e" .../1.2.16/.../ucm2/            # 1.2.16   -> USB-Audio.conf
```

The regression is inside `USB-Audio/Realtek/ALC4080-HiFi.conf`. 1.2.16 refactored the `Define` block so PCM values hold only the subdevice index (e.g. `SpdifPCM "3"`) and each `SectionDevice` rebuilds the full path as `hw:${CardId},${var:SpdifPCM}`. As part of that refactor, the S/PDIF section gained a device-probe gate:

```
If.spdif_dev2 {
    Condition { Type RegexMatch; String "${CardComponents}"; Regex "USB(0b05:(1996|1a5[23c])|0db0:1feb)" }
    True.Define { SpdifName "S/PDIF Output"; SpdifPCM "2" }
    False.If.spdif_nodev {
        Condition {
            Type String
            Empty "$${find-device:type=pcm,stream=playback,field=subname,regex='Audio #3'}"
        }
        True.Define.SpdifName ""        # <-- drops S/PDIF device entirely
    }
}
```

In 1.2.15.3 there was no such probe for this path; S/PDIF was unconditionally defined at subdevice 3. On the X870 Tomahawk, the `find-device ... subname regex='Audio #3'` lookup evidently does not match the board's actual subdevice subname, so `SpdifName` is set to `""` and the device is removed.

## Hardware confirmation — the probe queries the wrong field

`cat /proc/asound/card5/pcm*p/info` shows the S/PDIF PCM exists in hardware (device 3) and reveals exactly why the probe fails:

```
device: 0
name: USB Audio
subname: subdevice #0
...
device: 3
name: USB Audio #3
subname: subdevice #0
subdevices_count: 1
subdevices_avail: 0
```

The S/PDIF device (device 3) is present and works under 1.2.15.3. The string `Audio #3` appears in the **`name`** field (`USB Audio #3`). But the 1.2.16 probe searches **`field=subname`**:

```
Empty "$${find-device:type=pcm,stream=playback,field=subname,regex='Audio #3'}"
```

Every subdevice's `subname` on this board is just `subdevice #0` — `Audio #3` never appears in any `subname`. So `find-device` always returns empty, `spdif_nodev` always fires, and S/PDIF is dropped, even though device 3 plainly exists. The probe is matching against the wrong field.

## Steps to reproduce

1. On a board matching `Realtek/ALC4080` (e.g. `0db0:cd0e`) with working S/PDIF under `alsa-ucm-conf 1.2.15.3`.
2. Upgrade `alsa-ucm-conf` to 1.2.16.
3. Restart the audio stack: `systemctl --user restart pipewire pipewire-pulse wireplumber`.
4. S/PDIF output is gone.

## Expected vs actual

- **Expected:** S/PDIF output remains enumerated, as in 1.2.15.3.
- **Actual:** S/PDIF device is removed because the new `spdif_nodev` probe evaluates to empty on this board.

## Suggested fix direction

The `spdif_nodev` probe queries `field=subname` but the discriminating string (`Audio #3`) lives in the device's `name` field, not `subname`. On this board every `subname` is `subdevice #0`, so the probe can never match and S/PDIF is always suppressed. The probe should query `field=name` instead:

```
Empty "$${find-device:type=pcm,stream=playback,field=name,regex='Audio #3'}"
```

This likely affects all ALC4080 boards that hit the `spdif_nodev` fallback rather than the whitelisted `spdif_dev2` IDs (`0b05:1996`, `0b05:1a5[23c]`, `0db0:1feb`). Worth confirming the field name against whichever board originally motivated the probe, so the fix doesn't merely move the breakage.

## Workaround

Downgrade `alsa-ucm-conf` to 1.2.15.3 (no need to downgrade `alsa-lib`).

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

           reply	other threads:[~2026-06-03 23:44 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <18b5b6cab30e9300-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=18b5b6cab33c8800-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.