linux-kernel - Re: [PATCH] ALSA: usb-audio: Don't refcount multiple accesses on the single clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r10qj8th.wl-tiwai@suse.de>
Date:   Mon, 05 Sep 2022 14:37:46 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     alsa-devel@...a-project.org, LKML <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Niklāvs Koļesņikovs 
        <89q1r14hd@...ay.firefox.com>, Wim Taymans <wtaymans@...hat.com>
Subject: Re: [PATCH] ALSA: usb-audio: Don't refcount multiple accesses on the single clock

On Mon, 05 Sep 2022 14:06:45 +0200,
Jason A. Donenfeld wrote:
> 
> On Mon, Sep 5, 2022 at 1:44 PM Takashi Iwai <tiwai@...e.de> wrote:
> >
> > On Mon, 05 Sep 2022 12:14:03 +0200,
> > Jason A. Donenfeld wrote:
> > >
> > > This reverts commit 03a8b0df757f1beb21ba1626e23ca7412e48b525.
> > > This reverts commit c11117b634f4f832c4420d3cf41c44227f140ce1.
> > >
> > > Pipewire and PulseAudio start devices with 44.1khz before changing them
> > > to 48khz (or something different). By locking the rate, daemons are
> > > unable to enumerate possible rates, and so they never change them to a
> > > more optimal rate. This revert patch should allow 48khz audio again.
> >
> > Well, in that case, the revert is no right solution, IMO.
> > If the patch caused a problem, it means that the application tries to
> > change the rate while it's being still running by another.  If it
> > worked, it worked just casually without noticing the bad behavior.
> 
> Not sure this is really what's happening. I think the issue is that
> alsa reports that the device only supports a limited set of rates.

This patch doesn't change the "report" mechanism.  Instead what this
patch does is to bail out as an error if you try to change the rate of
a coupled stream while another stream is already running.

> Pipewire then doesn't see 48khz, so it doesn't try to
> stop,reclock,start.
> 
> Maybe Wim or Niklavs can provide more info about this.

More information is appreciated :)


Takashi