Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Rong Zhang <i@rong.moe>
Cc: Takashi Iwai <tiwai@suse.de>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>, Steve Smith <tarkasteve@gmail.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: Set the value of potential sticky mixers to maximum
Date: Sun, 31 May 2026 16:07:12 +0200	[thread overview]
Message-ID: <87y0gzoepb.wl-tiwai@suse.de> (raw)
In-Reply-To: <47f764913c6a7ee6e01825f711a30ec44bf2d7bb.camel@rong.moe>

On Sun, 31 May 2026 15:55:46 +0200,
Rong Zhang wrote:
>> 
> Hi Takashi,
> 
> On Sun, 2026-05-31 at 15:23 +0200, Takashi Iwai wrote:
> > On Sat, 30 May 2026 21:52:49 +0200,
> > Rong Zhang wrote:
> > > 
> > > It makes no sense to restore the saved value for a sticky mixer, since
> > > setting any value is a no-op.
> > > 
> > > However, in some rare cases, SET_CUR is effective despite GET_CUR always
> > > returns a constant value. These mixers are not sticky, but there's no
> > > way to distinguish them. Without any additional information, the best
> > > thing we can do is to set the mixer value to the maximum before bailing
> > > out, so that a soft mixer can still reach the maximum hardware volume if
> > > the mixer turns out to be non-sticky. Meanwhile, all channels must be
> > > synchronized to prevent imbalance volume.
> > > 
> > > Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers")
> > > Signed-off-by: Rong Zhang <i@rong.moe>
> > > ---
> > >  sound/usb/mixer.c | 33 +++++++++++++++++++++++++++++----
> > >  1 file changed, 29 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
> > > index 5fba456eb4a9..fb37bb8ad9a9 100644
> > > --- a/sound/usb/mixer.c
> > > +++ b/sound/usb/mixer.c
> > > @@ -1371,10 +1371,8 @@ static int get_min_max_with_quirks(struct usb_mixer_elem_info *cval,
> > >  				goto no_checks;
> > >  
> > >  			ret = check_sticky_volume_control(cval, minchn, saved);
> > > -			if (ret < 0) {
> > > -				snd_usb_set_cur_mix_value(cval, minchn, 0, saved);
> > > -				return ret;
> > > -			}
> > > +			if (ret < 0)
> > > +				goto sticky;
> > >  
> > >  			if (cval->min + cval->res < cval->max)
> > >  				check_volume_control_res(cval, minchn, saved);
> > > @@ -1431,6 +1429,33 @@ static int get_min_max_with_quirks(struct usb_mixer_elem_info *cval,
> > >  	}
> > >  
> > >  	return 0;
> > > +
> > > +sticky:
> > > +	/*
> > > +	 * It makes no sense to restore the saved value for a sticky mixer,
> > > +	 * since setting any value is a no-op.
> > > +	 *
> > > +	 * However, in some rare cases, SET_CUR is effective despite GET_CUR
> > > +	 * always returns a constant value. These mixers are not sticky, but
> > > +	 * there's no way to distinguish them. Without any additional
> > > +	 * information, the best thing we can do is to set the mixer value to
> > > +	 * the maximum before bailing out, so that a soft mixer can still reach
> > > +	 * the maximum hardware volume if the mixer turns out to be non-sticky.
> > > +	 * Meanwhile, all channels must be synchronized to prevent imbalance
> > > +	 * volume.
> > > +	 */
> > > +	if (!cval->cmask) {
> > > +		snd_usb_set_cur_mix_value(cval, 0, 0, cval->max);
> > > +	} else {
> > > +		for (i = 0; i < MAX_CHANNELS; i++) {
> > > +			idx = 0;
> > > +			if (cval->cmask & BIT(i)) {
> > > +				snd_usb_set_cur_mix_value(cval, i + 1, idx, cval->max);
> > > +				idx++;
> > > +			}
> > > +		}
> > > +	}
> > > +	return ret;
> > 
> > This change is supposed to be applied only to 7.1, 
> > 
> 
> This patch is meant for both 7.1 and 7.2.
> 
> > and 7.2 should take
> > another your series ("ALSA: usb-audio: MIXER_GET_CUR_BROKEN related
> > changes for 7.2") instead, right?
> > 
> 
> Right.
> 
> >   If so, at merging the latter, I'll
> > revert this one as a preliminary.
> 
> Please don't revert this one in 7.2.
> 
> It is needed to make any future devices like that to at least have
> audible volume out-of-box. Without it, users will have to wait for an
> quirk table entry for their devices (or add one themselves). Since
> setting the mixer value to maximum should be safe on both categories of
> devices (sticky, effective SET_CUR but broken GET_CUR), I'd prefer to
> retain this patch in 7.2 too.
> 
> Another reason of retaining it is that the current error path only
> "restores" the garbage GET_CUR value for minchn, so it could lead to
> imbalance volume if the mixer has multiple channels. In the effective
> SET_CUR but broken GET_CUR case, we would still have to fix the error
> path anyway to synchronize all channels. Since this patch does the job
> and synchronize all channels using a non-garbage value, it should be
> fine to retain it in 7.2.
> 
> That being said, this patch has a trivial single-line conflict in 7.2
> because my series adding QUIRK_FLAG_MIXER_GET_CUR_BROKEN narrowed the
> sticky path down to `ret == -ENODEV'. I can resubmit the series for 7.2
> to include a rebased version of this patch, should you prefer.

OK, then let me merge this one to for-linus, and merge to for-next
branch at first.  Then resubmit the patches that can be applied
cleanly on for-next branch.  I can merge and resolve conflicts
locally, but this would become a problem when backporting to older
stable kernels in future.


thanks,

Takashi

  reply	other threads:[~2026-05-31 14:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30 19:52 [PATCH] ALSA: usb-audio: Set the value of potential sticky mixers to maximum Rong Zhang
2026-05-31  5:12 ` Steve Smith
2026-05-31 13:23 ` Takashi Iwai
2026-05-31 13:55   ` Rong Zhang
2026-05-31 14:07     ` Takashi Iwai [this message]
2026-05-31 14:19       ` Rong Zhang
2026-05-31 14:50         ` Takashi Iwai

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=87y0gzoepb.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=i@rong.moe \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tarkasteve@gmail.com \
    --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