Re: [BUG] snd-usb-audio: Audient iD14 (2708:0008) 20 dB channel imbalance

[Takashi Iwai <tiwai@suse.de>]

On Mon, 10 Aug 2026 21:25:20 +0200,
Neil Andrews wrote:
> 
> Hi,
> 
> On an Audient iD14 (USB 2708:0008), snd-usb-audio exposes a mixer control
> "Speaker Playback Volume" that covers only 4 of the device's 6 playback
> channels, and does not cover PCM channel 0. Userspace (PipeWire, PulseAudio)
> adopts it as the card's hardware playback volume, so any setting below 100%
> attenuates some channels but not others. At a typical 80% setting the
> inter-channel imbalance is 20 dB. The device is balanced under Windows, where
> the vendor driver does not drive this control.
> 
> Not a regression: I diagnosed it on kernel 6.19.14 and re-measured on 
> 7.1.6 with identical results.
> 
> System:
>   Kernel:        7.1.6-1-cachyos (CachyOS)
>   alsa-lib:      1.2.16.1, alsa-utils 1.2.16
>   PipeWire:      1.6.8, WirePlumber 0.5.15
>   Device:        Audient iD14, USB 2708:0008, bcdDevice 1.11
> 
> The control, against a playback stream that is 6 channels
> (Channels: 6, Channel map: FL FR FC LFE RL RR):
> 
>   numid=11,iface=MIXER,name='Speaker Playback Volume'
>     ; type=INTEGER,access=rw---R--,values=4,min=0,max=127,step=0
>     : values=107,107,107,107
>     | dBminmax-min=-127.00dB,max=0.00dB
> 
> The driver records the partial coverage itself (from alsa-info):
> 
>   Unit: 12
>     Control: name="Speaker Playback Volume", index=0
>     Info: id=12, control=2, cmask=0xf, channels=4, type="S16"
> 
> Descriptor origin. FEATURE_UNIT bUnitID=12 advertises Volume on only 4 of its
> 6 logical channels:
> 
>   bmaControls(0)     0x00000000
>   bmaControls(1..4)  0x0000000c   Volume Control (read/write)
>   bmaControls(5)     0x00000000
>   bmaControls(6)     0x00000000
> 
> FU 12 is also not in the direct playback path. USB streaming input to Speaker
> output runs:
> 
>   INPUT_TERMINAL 2 (USB Streaming, 6ch)
>     -> EXTENSION_UNIT 51 (6ch)
>     -> FEATURE_UNIT 10 (6ch, bmaControls(0..6) all 0x00000000, no controls)
>     -> OUTPUT_TERMINAL 20 (0x0301 Speaker)
> 
> whereas FU 12 sits on the monitor-mixer branch:
> 
>   EXTENSION_UNIT 50 (16ch) -> MIXER_UNIT 60 (6ch) -> FEATURE_UNIT 12
>     -> EXTENSION_UNIT 54 (6ch) / EXTENSION_UNIT 55 (3ch)
>     -> back into EXTENSION_UNIT 51 and 52
> 
> So FU 12 is traced through to the Speaker output terminal and named
> "Speaker Playback Volume", but it is a partial-coverage control on a mixer
> branch rather than a master volume for the stream. Consistent with that, the
> measured coverage does not match a naive reading of cmask=0xf (logical
> channels 1-4): it is PCM channel 0 that escapes attenuation and PCM channel 1
> that receives it.
> 
> Measurements. The iD14 loops output channels 0 and 1 back onto capture
> channels 10 and 11. I played 6-channel S32_LE WAVs carrying a -12 dBFS sine in
> exactly one channel, straight to hw: with the card profile set to off so
> PipeWire was out of the path, and recorded all 12 capture channels. The two
> files are bit-identical in amplitude and differ only in which channel carries
> the tone.
> 
>   Speaker Playback Volume = 107/127 (-20.00 dB):
>     output ch0 -> loopback ch10   RMS -15.89 dBFS
>     output ch1 -> loopback ch11   RMS -35.89 dBFS
>     delta: 20.00 dB
> 
>   Speaker Playback Volume = 127/127 (0.00 dB):
>     output ch0 -> loopback ch10   RMS -15.89 dBFS
>     output ch1 -> loopback ch11   RMS -15.89 dBFS
>     delta: 0.00 dB
> 
> The delta tracks the control's own dB value exactly. PCM channel 0 is
> unaffected at either setting; PCM channel 1 is attenuated by precisely the
> amount the control reports. Output channels 2-5 are not carried on the
> loopback, so I could not measure them. Those four figures came out the same on
> 6.19.14 and 7.1.6.
> 
> Workaround. Setting api.alsa.soft-mixer = true for the device in WirePlumber,
> so PipeWire does volume in software and leaves the control at 0 dB, fixes it
> completely. That also requires the ALSA state saved at 0 dB, or alsa-restore
> reinstates the attenuation at the next boot and soft-mixer leaves it there.
> 
> Suggested fix. Ignoring the unit via sound/usb/mixer_maps.c looks like the
> minimal change, so no hardware volume control is exported and userspace falls
> back to software volume:
> 
>   /* Audient iD14: FU 12 advertises Volume on only 4 of 6 logical channels and
>    * sits on the monitor-mixer branch, but is traced to the Speaker output
>    * terminal and adopted by userspace as the stream's hardware volume,
>    * producing a large inter-channel imbalance. Ignore it.
>    */
>   static const struct usbmix_name_map audient_id14_map[] = {
>        { 12, NULL },
>        { 0 }
>   };
> 
> and in usbmix_ctl_maps[]:
> 
>   {
>        .id = USB_ID(0x2708, 0x0008),
>        .map = audient_id14_map,
>   },
> 
> Untested, and you may prefer a different approach - such as declining to
> export any feature unit whose channel coverage is narrower than the stream it
> is attached to, which would presumably help other interfaces with the same
> descriptor shape. Happy to test patches; I have the device and a measurement
> rig that gives an objective pass/fail in about thirty seconds.

It's fine to skip the volume if it actually improves -- so please test
it ;)

Judging from your description, an alternative with keeping the volume
control would be to just rename it; the problem is that it's tied with
"Speaker".  You can name it a different, some non-standard one,
instead, too.


thanks,

Takashi