Message ID | 20220907100421.6443-1-tiwai@suse.de |
---|---|
State | Accepted |
Commit | 809f44a0cc5ad4b1209467a6287f8ac0eb49d393 |
Headers | show |
Series | ALSA: usb-audio: Clear fixed clock rate at closing EP | expand |
On Wed, Sep 7, 2022 at 12:04 PM Takashi Iwai <tiwai@suse.de> wrote: > > The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple > accesses on the single clock") tries to manage the clock rate shared > by several endpoints. This was intended for avoiding the unmatched > rate by a different endpoint, but unfortunately, it introduced a > regression for PulseAudio and pipewire, too; those applications try to > probe the multiple possible rates (44.1k and 48kHz) and setting up the > normal rate fails but only the last rate is applied. > > The cause is that the last sample rate is still left to the clock > reference even after closing the endpoint, and this value is still > used at the next open. It happens only when applications set up via > PCM prepare but don't start/stop the stream; the rate is reset when > the stream is stopped, but it's not cleared at close. > > This patch addresses the issue above, simply by clearing the rate set > in the clock reference at the last close of each endpoint. Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index a42f2ce19455..8c8f9a851f89 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -925,6 +925,8 @@ void snd_usb_endpoint_close(struct snd_usb_audio *chip, endpoint_set_interface(chip, ep, false); if (!--ep->opened) { + if (ep->clock_ref && !atomic_read(&ep->clock_ref->locked)) + ep->clock_ref->rate = 0; ep->iface = 0; ep->altsetting = 0; ep->cur_audiofmt = NULL;
The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") tries to manage the clock rate shared by several endpoints. This was intended for avoiding the unmatched rate by a different endpoint, but unfortunately, it introduced a regression for PulseAudio and pipewire, too; those applications try to probe the multiple possible rates (44.1k and 48kHz) and setting up the normal rate fails but only the last rate is applied. The cause is that the last sample rate is still left to the clock reference even after closing the endpoint, and this value is still used at the next open. It happens only when applications set up via PCM prepare but don't start/stop the stream; the rate is reset when the stream is stopped, but it's not cleared at close. This patch addresses the issue above, simply by clearing the rate set in the clock reference at the last close of each endpoint. Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Reported-by: Jason A. Donenfeld <Jason@zx2c4.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/ Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620 Signed-off-by: Takashi Iwai <tiwai@suse.de> --- sound/usb/endpoint.c | 2 ++ 1 file changed, 2 insertions(+)