Linux Sound subsystem development
 help / color / mirror / Atom feed
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

      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