Re: [PATCH] USB Audio Class 2 Mixer unit support for GET_CUR, SET_CUR and RANGE

[Takashi Iwai <tiwai@suse.de>]

On Tue, 15 Sep 2026 14:54:38 +0200,
Zipdox wrote:
> 
> On 9/15/26 1:08 PM, Takashi Iwai wrote:
> > Hmm, for UAC2, UAC_GET_CUR & co isn't passed as is at all, but the
> > call is translated to UAC2_CS_CUR and UAC2_CS_RANGE accordingly in
> > get_ctl_value_v2() (that is called from get_ctl_value()
> > conditionally).  So this translation path was skipped somehow with
> > your device...?
> 
> The request is translated yes, but wValue is incorrect. UAC2 uses a
> Mixer Control Number ("mcn") in the low byte to identify the mixer
> control, along with a control selector in the high byte (UAC2_MU_MIXER
> in this case). UAC1 on the other hand uses the low and high byte to
> identify the mixer control. It seems get_ctl_value_v2 doesn't change
> wValue to the appropriate format (mcn and control selector). This code
> was, as far as I understand it, never correct to begin with for UAC2.

OK, point taken.

> To get the MIN, MAX, and RES, get_min_max_with_quirks currently calls
> get_ctl_value three times to get the values separately. It looks like
> get_ctl_value_v2 was written to send RANGE requests and extract the
> appropriate part of the RANGE response, depending on the request. This
> doesn't actually work though, because wValue is incorrect as I stated
> above. It also unnecessarily sends three requests instead of one. That's
> why I bypassed it entirely and wrote the get_ctl_range_16 function. This
> could in theory be consolidated, but there's quite a bit of other code
> so I'm hesitant to touch it. Supplying the correct wValue to
> get_ctl_value in get_cur_mix_raw fixed getting the current value, and
> the same applies to the call to snd_usb_mixer_set_ctl_value in
> snd_usb_set_cur_mix_value.

But your code also blindly assumes the MU_MIXER_CONTROL that doesn't
fit with other units like feature unit?  I guess we have to set the
proper Control Selector value depending on the unit type.

After all, this is about the correct setup of wValue.  Let's try to be
minimalistic at first -- just tweak wValue in get_ctl_value_v2() and
snd_usb_mixer_set_ctl_value() at first.  If this becomes too ugly, we
can think of redesigning.


> > Could you try to reformat in a proper patch format?
> > Also, it looks containing many unnecessary / unrelated changes that
> > make review more difficult.  Please try to concentrate only on the
> > change you really need.
> 
> Perhaps you are referring to the indentation changes resulting from
> wrapping existing code in an if statement? I can't really do anything
> about that. I don't think I changed any unrelated code itself. If there
> are unrelated changes, please point them out to me.

Well, get_ctl_value_v2() changes look all unrelated and just breaking
indentations.

> In any case, I
> changed the patch to the "canonical patch format" as written in the
> kernel docs.
> 
> From: Zipdox <zipdox@zipdox.net>
> 
> The USB Audio Mixer Unit driver (sound/usb/mixer.c) sends audio class
> 1.0 format control messages to devices, regardless of the actual audio
> class version. This means audio class 2.0 devices will receive incorrect
> messages, stall, and cause the driver to error (e.g. alsamixer exits
> with a broken pipe error). This patch implements the GET_CUR, SET_CUR,
> and RANGE control requests for mixer units according to the Audio Class
> 2.0 specification.
> 
> Subject: [PATCH] USB Audio Class 2 Mixer unit support for GET_CUR, SET_CUR and RANGE

The subject line must be at the beginning right after From tag.


> Signed-off-by: Zipdox <zipdox@zipdox.net>

... and both From and Signed-off-by should be with a real name (or a
known identity).  It's a legal requirement.


thanks,

Takashi