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 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.