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
