[RFC] sound: usb: design for quirk 'mixer_min_mute'

[RFC] sound: usb: design for quirk 'mixer_min_mute'

[Cryolitia PukNgae]

We are discussig about the problem that, on some devices the lowest
playback value represents muted state instead of minimum audible volume.
In the previous discussion, we have shown that this problem is widespread
across a wide range of hardware[1][2]. And we have already added a bit for
it[1].

Firstly, we need to discuss about how to design a module param for it. As
it is needed to debug the device for end users instead of ignoring
hardware mixer and using soft mixer only in pipewire, which has already
written in Arch Linux wiki[3], as an imperfect workaround.

Inspired by Takashi Iwai[4], I would like to design a module param named
`quirk_names`, to be passed like
`1234:abcd:mixer_min_mute,4567:efef:ignore_ctl_error`, so that we can
apply one or more quirk on a specific USB device. And the already existed
param `ignore_ctl_error` could be deleted, because of included in the
one.

>    /* lowest playback value is muted on some devices */
>    if (mixer->chip->quirk_flags & QUIRK_FLAG_MIXER_MIN_MUTE)
>        if (strstr(kctl->id.name, "Playback"))
>            cval->min_mute = 1;

Secondly, all efforts so far is only for the Playback. But we have found
some devices have the same problem on the Capture. So for the problem
that the lowest playback value represents muted state instead of minimum 
udible volume:

  1. On some devices we already tested, only happens on their Playback,
     but their Capture works perfectly. Or they are just a simple
     earphone without audio input.
  2. On some devices we already tested, have the problem both on Playback
     and Capture.
  3. Maybe on some devices we havn't found yet, have the problem only on
     Capture but not Playback.

How could we deal with them? Would two quirk bit seems a little waste?

Thirdly, the most complex situation. We found a device: `3302:12db
MOONDROP Quark2` , that its volume control has a range 0-120, but acts to
mute when less than 8. I have no idea about how to deal with it simplly.
We are actively contacting the manufacturer and informing them of this
matter.

I sincerely hope that my poor English explains the current situation clearly.

1. https://lore.kernel.org/all/20250827-sound-quirk-min-mute-v1-1-4717aa8a4f6a@uniontech.com/
2. https://lore.kernel.org/all/20250829-sound_quirk-v1-1-745529b44440@uniontech.com/
3. https://wiki.archlinux.org/index.php?title=PipeWire&oldid=804138#No_sound_from_USB_DAC_until_30%_volume
4. https://lore.kernel.org/all/87bjnyimu9.wl-tiwai@suse.de/

Best regards,
Cryolitia PukNgae <cryolitia@uniontech.com>

Re: [RFC] sound: usb: design for quirk 'mixer_min_mute'

[Takashi Iwai]

On Fri, 29 Aug 2025 11:29:22 +0200,
Cryolitia PukNgae wrote:
> 
> We are discussig about the problem that, on some devices the lowest
> playback value represents muted state instead of minimum audible volume.
> In the previous discussion, we have shown that this problem is widespread
> across a wide range of hardware[1][2]. And we have already added a bit for
> it[1].
> 
> Firstly, we need to discuss about how to design a module param for it. As
> it is needed to debug the device for end users instead of ignoring
> hardware mixer and using soft mixer only in pipewire, which has already
> written in Arch Linux wiki[3], as an imperfect workaround.
> 
> Inspired by Takashi Iwai[4], I would like to design a module param named
> `quirk_names`, to be passed like
> `1234:abcd:mixer_min_mute,4567:efef:ignore_ctl_error`, so that we can
> apply one or more quirk on a specific USB device.

I suppose this will turn on each quirk bit?  We may want to turn *off*
the quirk bit, too, e.g. extend the syntax with '!' marker
`1234:abcd:!mixer_min_mute`.

Also, allowing multiple quirk bits by numbers would be also handy,
e.g. `1234:abcd:003f`.  So, if the last part represents a hex number,
it's treated as the quirk bits.

One more thing would be to allow a wildcard to the device matching,
e.g. `*:*:mixer_min_mute`.

An open question is whether we may want yet a new module option or
rather extend the existing quirk option to accept the strings
instead.  Basically, when the given argument has a colon, it's a new
syntax.  If it's only a number, it's an old syntax, and parse like
before.  But, I'm open for either way (a new option or extend the
existing one).

> And the already existed
> param `ignore_ctl_error` could be deleted, because of included in the
> one.

Dropping an existing option isn't so easy.  It can break users who
already applied it for long time.  So, unless it's really conflicting
and does harmful, I'd rather keep the old option as is.

> >    /* lowest playback value is muted on some devices */
> >    if (mixer->chip->quirk_flags & QUIRK_FLAG_MIXER_MIN_MUTE)
> >        if (strstr(kctl->id.name, "Playback"))
> >            cval->min_mute = 1;
> 
> Secondly, all efforts so far is only for the Playback. But we have found
> some devices have the same problem on the Capture. So for the problem
> that the lowest playback value represents muted state instead of minimum 
> udible volume:
> 
>   1. On some devices we already tested, only happens on their Playback,
>      but their Capture works perfectly. Or they are just a simple
>      earphone without audio input.
>   2. On some devices we already tested, have the problem both on Playback
>      and Capture.
>   3. Maybe on some devices we havn't found yet, have the problem only on
>      Capture but not Playback.
> 
> How could we deal with them? Would two quirk bit seems a little waste?

It's a good question.  My gut feeling so far is to make another quirk
bit for the capture, but we may find some compromised solution, too.
> 
> Thirdly, the most complex situation. We found a device: `3302:12db
> MOONDROP Quark2` , that its volume control has a range 0-120, but acts to
> mute when less than 8. I have no idea about how to deal with it simplly.
> We are actively contacting the manufacturer and informing them of this
> matter.

If that kind of behavior becomes common, we can add a common quirk bit.
Until then, it's handled as an own fix.


thanks,

Takashi