USB-Audio: Common/HeadphonesOnly PlaybackMixerElem "PCM" does not match Topping D10s mixer (152a:8750)

USB-Audio: Common/HeadphonesOnly PlaybackMixerElem "PCM" does not match Topping D10s mixer (152a:8750)

[GitHub issues - opened]

alsa-project/alsa-ucm-conf issue #850 was opened from z23:

USB ID `152a:8750` is mapped to `Common/HeadphonesOnly`, which hard-codes `PlaybackMixerElem "PCM"`. A Topping D10s using that same Thesycon ID has no `PCM` mixer control. PipeWire/WirePlumber then falls back to software volume and leaves the DAC Feature Unit volume untouched, so desktop volume (e.g. 70%) stacks on top of a quiet hardware fader (here 84/127 = -43 dB).

## Hardware

- Device: Topping D10s (USB DAC)
- `lsusb`: `152a:8750 Thesycon Systemsoftware & Consulting GmbH D10s`
- iManufacturer: Topping; iProduct: D10s
- Distro: Arch Linux (`alsa-ucm-conf 1.2.16.1-1`, `alsa-lib 1.2.16.1-1`)
- Kernel: `7.2.3-arch1-2`
- Session: PipeWire 1.6.8 + WirePlumber 0.5.17

## Actual mixer controls

There is no control named `PCM`. The playback volume is named after the product string (note the trailing space):

```
numid=2,iface=MIXER,name='D10s  Playback Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on
numid=3,iface=MIXER,name='D10s  Playback Volume'
  ; type=INTEGER,access=rw---R--,values=1,min=0,max=127,step=0
  : values=84
  | dBminmax-min=-127.00dB,max=0.00dB
```

(`values=84` was the live hardware volume when the mismatch was noticed: 66% / -43.00 dB.)

## What UCM applies

`alsaucm -c D10s dump text`:

```
Verb.HiFi {
Comment Default
Device.Headphones {
Comment Headphones
Values {
CaptureCTL "_ucm0001.hw:D10s"
PlaybackCTL "_ucm0001.hw:D10s"
PlaybackMixerElem PCM
PlaybackPCM "_ucm0001.hw:D10s,0"
}
}
}
```

This comes from:

- `ucm2/USB-Audio/USB-Audio.conf`: `Macro.hp-only.StringMatch "Id='152a:8750' Profile='Common/HeadphonesOnly'"`
- `ucm2/USB-Audio/Common/HeadphonesOnly-HiFi.conf`: `PlaybackMixerElem "PCM"`

## Session manager effect

WirePlumber logs this on every start:

```
spa.alsa: Path PCM is not a volume or mute control
```

The PipeWire sink is created (`HiFi: Headphones`) but **without** `HW_VOLUME_CTRL`. Flags were `HARDWARE DECIBEL_VOLUME LATENCY`. Desktop volume therefore only applies software gain. The USB Feature Unit stays at whatever the DAC last stored (class-compliant volume is in the device), which made output far quieter than the UI suggested.

## History

`152a:8750` was originally added for a Topping DX3 Pro+ ([03fed99](https://github.com/alsa-project/alsa-ucm-conf/commit/03fed99a96da3effebbef1f2830a5ac19834c102)). That profile only set `PlaybackPCM` and did **not** name a mixer element.

When it was generalized to `Common/HeadphonesOnly` ([93d015d](https://github.com/alsa-project/alsa-ucm-conf/commit/93d015d12c68a0516d181a5c2682037f1ec256a7)), `PlaybackMixerElem "PCM"` was added. Several Thesycon-based Topping devices share `152a:8750` (DX3 Pro+ and D10s at least), and the D10s mixer is `D10s `, not `PCM`.

## Suggested fix

`Common/HeadphonesOnly` should not assume a mixer named `PCM`.

Preferred: drop `PlaybackMixerElem "PCM"` (back to the original DX3 Pro+ snippet) so ACP/PipeWire can bind the card's real playback volume control.

Alternative: only set it when the control exists:

```
If.pcm {
	Condition {
		Type ControlExists
		Control "name='PCM Playback Volume'"
	}
	True.Value.PlaybackMixerElem "PCM"
}
```

Hard-coding `PlaybackMixerElem "D10s "` would fix this one unit but is fragile (trailing space, and the USB ID is shared).

## Workaround

```
amixer -c D10s sset 'D10s ' 100%
alsactl store
```

That puts the Feature Unit at 0 dB so the desktop software volume is the only attenuation.

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