* Re: [PATCH] ALSA: usb-audio: Refcount multiple accesses on the single clock
[not found] <20220516104807.16482-1-tiwai@suse.de>
@ 2022-09-05 9:58 ` Jason A. Donenfeld
2022-09-05 10:14 ` Jason A. Donenfeld
0 siblings, 1 reply; 2+ messages in thread
From: Jason A. Donenfeld @ 2022-09-05 9:58 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, 89q1r14hd, linux-kernel, Wim Taymans
Hi Takashi,
On Mon, May 16, 2022 at 12:48:07PM +0200, Takashi Iwai wrote:
> When a clock source is connected to multiple nodes / endpoints, the
> current USB-audio driver tries to set up at each time one of them is
> configured. Although it reads the current rate and updates only if it
> differs, some devices seem unhappy with this behavior and spew the
> errors when reading/updating the rate unnecessarily.
>
> This patch tries to reduce the redundant clock setup by introducing a
> refcount for each clock source. When the stream is actually running,
> a clock rate is "locked", and it bypasses the clock and/or refuse to
> change any longer.
This breaks things on 5.19+. Specifically, it causes pipewire and
pulseaudio to be stuck using 44.1khz rather than 48.0khz (or anything
else). The reason is that initially devices are started at 44.1khz, and
then the list of supported sample rates is read, and finally the best
one is chosen. With this commit, the returned list of sample rates is
locked at 44.1khz, which means pulseaudio and pipewire can't change it
to 48.0khz (or anything else).
This headscratcher is being tracked over at:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620
where I triaged it to this commit.
Can we revert this for the time being and backport the revert to stable?
Or might you have some other fix idea in mind?
Thanks,
Jason
^ permalink raw reply [flat|nested] 2+ messages in thread