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@xxxxxxx> 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
