From: Takashi Iwai <tiwai@suse.de>
To: Neil Andrews <neil@androos.io>
Cc: Takashi Iwai <tiwai@suse.de>,
linux-sound@vger.kernel.org, tiwai@suse.com, perex@perex.cz
Subject: Re: [BUG] snd-usb-audio: Audient iD14 (2708:0008) 20 dB channel imbalance
Date: Wed, 12 Aug 2026 07:27:37 +0200 [thread overview]
Message-ID: <87pkzn29iu.wl-tiwai@suse.de> (raw)
In-Reply-To: <0102019ff207ccda-7b65c5af-5c39-4218-ae8e-5ef8d55701e0-000000@eu-west-1.amazonses.com>
On Tue, 11 Aug 2026 20:13:45 +0200,
Neil Andrews wrote:
>
> On Tue, 11 Aug 2026, Takashi Iwai wrote:
> > 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.
>
> Hi Takashi,
>
> I tested both on 7.1.6 with sound/usb rebuilt out of tree, measured with
> the loopback rig from the original report. Both fix it. I would suggest
> the rename.
>
> Baseline, unpatched, PipeWire at 50% (control driven to 109/127):
> 18.00 dB imbalance.
>
> 1. { 12, NULL }
>
> Control gone, userspace falls back to software volume, 0.00 dB. So it
> does improve.
>
> One wrinkle: FU 12 keeps its value across a module reload, so if the
> quirk arrives while the hardware is already attenuated, the imbalance
> stays and there is no longer a control with which to undo it (measured:
> 18.00 dB, control absent). Only a power cycle clears it, which matters
> for anyone whose saved ALSA state holds a value below 0 dB.
>
> 2. { 12, "Monitor Mix Playback" }
>
> --- a/sound/usb/mixer_maps.c
> +++ b/sound/usb/mixer_maps.c
> @@ -495,6 +495,19 @@
> {}
> };
>
> +/* Audient iD14: FU 12 advertises Volume on only 4 of its 6 logical channels
> + * and sits on the monitor-mixer branch, but it is traced through to the
> + * Speaker output terminal and gets named "Speaker Playback Volume". Userspace
> + * then adopts it as the stream's hardware volume, and any setting below 0 dB
> + * attenuates some channels but not others (20 dB imbalance at 80%). Give it a
> + * non-standard name so that it is no longer taken for the stream's master
> + * volume, while remaining reachable for anyone who wants the monitor gain.
> + */
> +static const struct usbmix_name_map audient_id14_map[] = {
> + { 12, "Monitor Mix Playback" }, /* FU, partial coverage */
> + {}
> +};
> +
> /*
> * Control map entries
> */
> @@ -579,6 +592,11 @@
> .map = maya44_map,
> },
> {
> + /* Audient iD14 */
> + .id = USB_ID(0x2708, 0x0008),
> + .map = audient_id14_map,
> + },
> + {
> /* KEF X300A */
> .id = USB_ID(0x27ac, 0x1000),
> .map = scms_usb3318_map,
>
> Gives numid=11,name='Monitor Mix Playback Volume'. PipeWire no longer
> picks it up (control stays at 127, 0.00 dB), and it still works when set
> deliberately, so an attenuated device can be recovered: 107 by hand
> gives 20.00 dB, back to 127 gives 0.00 dB. The name ends in "Playback"
> because a mapped name suppresses the automatic " Playback" but still
> gets " Volume" appended.
>
> 3. A qualification to my report
>
> I said userspace adopts the control as the card's hardware playback
> volume, without qualifying it. That is too broad.
>
> alsa-ucm-conf 1.2.16.1 ships
> USB-Audio/Audient/Audient-iD14-HiFi-0008.conf, which splits the device
> into 2-channel sinks and declares no playback mixer element. With it in
> use PipeWire never touches FU 12: the control stays at 127 at every
> volume setting, on both split sinks and on the underlying node.
> Reproducing needs the ACP path instead, which I got by setting
> api.alsa.use-ucm = false for the device in WirePlumber (then 100% ->
> 127, 80% -> 122, 50% -> 109). All measurements above were taken that
> way.
>
> So the affected set is narrower than I implied: the ACP path rather than
> that UCM profile, plus anyone whose saved ALSA state carries a value
> below 0 dB, since that is restored at boot either way. The descriptor
> problem itself is unchanged.
>
> Happy to send either version as a proper patch with a Signed-off-by, and
> to test anything else on the hardware.
Let's take the rename approach, then. Dropping can be done anytime
later if really needed, too. Please submit a formal patch.
thanks,
Takashi
prev parent reply other threads:[~2026-08-12 5:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 19:25 [BUG] snd-usb-audio: Audient iD14 (2708:0008) 20 dB channel imbalance Neil Andrews
2026-08-11 6:09 ` Takashi Iwai
2026-08-11 18:13 ` Neil Andrews
2026-08-12 5:27 ` Takashi Iwai [this message]
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=87pkzn29iu.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=linux-sound@vger.kernel.org \
--cc=neil@androos.io \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/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