linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [BISECTED] Kernel 5.11.x breaks pulseaudio
@ 2021-02-25 17:01 Heinz Diehl
  2021-02-25 17:10 ` Takashi Iwai
  0 siblings, 1 reply; 7+ messages in thread
From: Heinz Diehl @ 2021-02-25 17:01 UTC (permalink / raw)
  To: linux-kernel; +Cc: tiwai, lpoetter

Hi,

from kernel 5.11 on, pulseaudio always resamples audio to the sample
rate specified by default-sample-rate, despite "avoid-resampling =
true". Audio that matches alternate-sample-rate is resampled in the same way.
This means that both "alternate-sample-rate" and
"avoid-resampling=true" are no longer working.

Steps to Reproduce:
1. Set "avoid-resampling = true" in daemon.conf
2. Set default-sample-rate = 44100 in daemon.conf
3. Set alternate-sample-rate 48000 in daemon.conf
4. Restart pulseaudio
5. Play a 48000 (or any other) audio file

Actual results:
File is played as 44100 audio. Pacmd list-sink-inputs shows that
resampling is happening. Play an audio file with any other sample
rate, and it will be resampled to 44100.

Expected results:
Audio file plays at 48000. Any other file is played in its own sample rate.

In my case, this affects USB audio. Tried both a Dragonfly Red, a
Fostex HP-A4 and an unknown Soundblaster USB audio dac/amp, and all of
them show the same behaviour as described here. Most probably, the
regression affects all USB audio devices.

All kernels from the 5.10 series are fine. Here's the offending patch
that introduced the regression. Reverting it on top of kernel 5.11 /
5.11.1 resolves the problem:

[root@chiara linux-stable]# git bisect good
e4ea77f8e53f9accb9371fba34c189d0447ecce0 is the first bad commit
commit e4ea77f8e53f9accb9371fba34c189d0447ecce0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 11 09:16:11 2021 +0100

    ALSA: usb-audio: Always apply the hw constraints for implicit fb sync
    
    Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for
    implicit fb sync"), we apply the hw constraints for the implicit
    feedback sync to make the secondary open aligned with the already
    opened stream setup.  This change assumed that the secondary open is
    performed after the first stream has been already set up, and adds the
    hw constraints to sync with the first stream's parameters only when
    the EP setup for the first stream was confirmed at the open time.
    However, most of applications handling the full-duplex operations do
    open both playback and capture streams at first, then set up both
    streams.  This results in skipping the additional hw constraints since
    the counter-part stream hasn't been set up yet at the open of the
    second stream, and it eventually leads to "incompatible EP" error in
    the end.
    
    This patch corrects the behavior by always applying the hw constraints
    for the implicit fb sync.  The hw constraint rules are defined so that
    they check the sync EP dynamically at each invocation, instead.  This
    covers the concurrent stream setups better and lets the hw refine
    calls resolving to the right configuration.
    
    Also this patch corrects a minor error that has existed in the debug
    print that isn't built as default.
    
    Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync")
    Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

 sound/usb/pcm.c | 171 +++++++++++++++++++++++++++++++++++---------------------
 1 file changed, 108 insertions(+), 63 deletions(-)
[root@chiara linux-stable]#

Feel free to contact me if you think I can help.

Thanks, Heinz.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-25 17:01 [BISECTED] Kernel 5.11.x breaks pulseaudio Heinz Diehl
@ 2021-02-25 17:10 ` Takashi Iwai
  2021-02-25 17:28   ` Heinz Diehl
  0 siblings, 1 reply; 7+ messages in thread
From: Takashi Iwai @ 2021-02-25 17:10 UTC (permalink / raw)
  To: Heinz Diehl; +Cc: linux-kernel, lpoetter

On Thu, 25 Feb 2021 18:01:53 +0100,
Heinz Diehl wrote:
> 
> Hi,
> 
> from kernel 5.11 on, pulseaudio always resamples audio to the sample
> rate specified by default-sample-rate, despite "avoid-resampling =
> true". Audio that matches alternate-sample-rate is resampled in the same way.
> This means that both "alternate-sample-rate" and
> "avoid-resampling=true" are no longer working.
> 
> Steps to Reproduce:
> 1. Set "avoid-resampling = true" in daemon.conf
> 2. Set default-sample-rate = 44100 in daemon.conf
> 3. Set alternate-sample-rate 48000 in daemon.conf
> 4. Restart pulseaudio
> 5. Play a 48000 (or any other) audio file
> 
> Actual results:
> File is played as 44100 audio. Pacmd list-sink-inputs shows that
> resampling is happening. Play an audio file with any other sample
> rate, and it will be resampled to 44100.
> 
> Expected results:
> Audio file plays at 48000. Any other file is played in its own sample rate.
> 
> In my case, this affects USB audio. Tried both a Dragonfly Red, a
> Fostex HP-A4 and an unknown Soundblaster USB audio dac/amp, and all of
> them show the same behaviour as described here. Most probably, the
> regression affects all USB audio devices.
> 
> All kernels from the 5.10 series are fine. Here's the offending patch
> that introduced the regression. Reverting it on top of kernel 5.11 /
> 5.11.1 resolves the problem:
> 
> [root@chiara linux-stable]# git bisect good
> e4ea77f8e53f9accb9371fba34c189d0447ecce0 is the first bad commit
> commit e4ea77f8e53f9accb9371fba34c189d0447ecce0
> Author: Takashi Iwai <tiwai@suse.de>
> Date:   Mon Jan 11 09:16:11 2021 +0100
> 
>     ALSA: usb-audio: Always apply the hw constraints for implicit fb sync
>     
>     Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for
>     implicit fb sync"), we apply the hw constraints for the implicit
>     feedback sync to make the secondary open aligned with the already
>     opened stream setup.  This change assumed that the secondary open is
>     performed after the first stream has been already set up, and adds the
>     hw constraints to sync with the first stream's parameters only when
>     the EP setup for the first stream was confirmed at the open time.
>     However, most of applications handling the full-duplex operations do
>     open both playback and capture streams at first, then set up both
>     streams.  This results in skipping the additional hw constraints since
>     the counter-part stream hasn't been set up yet at the open of the
>     second stream, and it eventually leads to "incompatible EP" error in
>     the end.
>     
>     This patch corrects the behavior by always applying the hw constraints
>     for the implicit fb sync.  The hw constraint rules are defined so that
>     they check the sync EP dynamically at each invocation, instead.  This
>     covers the concurrent stream setups better and lets the hw refine
>     calls resolving to the right configuration.
>     
>     Also this patch corrects a minor error that has existed in the debug
>     print that isn't built as default.
>     
>     Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync")
>     Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de
>     Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
>  sound/usb/pcm.c | 171 +++++++++++++++++++++++++++++++++++---------------------
>  1 file changed, 108 insertions(+), 63 deletions(-)
> [root@chiara linux-stable]#
> 
> Feel free to contact me if you think I can help.

It's no regression but the right behavior.  This indicates that you're
trying a stream in 44.1kHz in one side of the full duplex stream while
48kHz in another rate, and this cannot work properly with the implicit
feedback devices.

It might have worked casually by some reason on your device, but it
was just a coincidence, as it didn't follow exactly what the implicit
feedback mode requires (i.e. the playback packet must follow exactly
the incoming recording packet).

That said, for the device like this, the sample rate has to be fixed
for both streams.

Hope that clarifies the situation.


Takashi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-25 17:10 ` Takashi Iwai
@ 2021-02-25 17:28   ` Heinz Diehl
  2021-02-25 18:01     ` Takashi Iwai
  0 siblings, 1 reply; 7+ messages in thread
From: Heinz Diehl @ 2021-02-25 17:28 UTC (permalink / raw)
  To: linux-kernel; +Cc: tiwai, lpoetter

On 25.02.2021, Takashi Iwai wrote:

> It's no regression but the right behavior.  This indicates that you're
> trying a stream in 44.1kHz in one side of the full duplex stream while
> 48kHz in another rate, and this cannot work properly with the implicit
> feedback devices.
[....]

Well, I'm by no means an audio or recording professional, but if what you describe
is the correct behavior, it means that absolutely all audio files played on
my machine always will be resampled to 44.1kHz. Youtube from native 48kHz,
highres audio 24/96, virtually anything I play. Could that be correct? And
what can I do to be able to listen to highres audio again?

Thanks,
 Heinz

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-25 17:28   ` Heinz Diehl
@ 2021-02-25 18:01     ` Takashi Iwai
  2021-02-26  9:23       ` Heinz Diehl
  0 siblings, 1 reply; 7+ messages in thread
From: Takashi Iwai @ 2021-02-25 18:01 UTC (permalink / raw)
  To: Heinz Diehl; +Cc: linux-kernel, lpoetter

On Thu, 25 Feb 2021 18:28:41 +0100,
Heinz Diehl wrote:
> 
> On 25.02.2021, Takashi Iwai wrote:
> 
> > It's no regression but the right behavior.  This indicates that you're
> > trying a stream in 44.1kHz in one side of the full duplex stream while
> > 48kHz in another rate, and this cannot work properly with the implicit
> > feedback devices.
> [....]
> 
> Well, I'm by no means an audio or recording professional, but if what you describe
> is the correct behavior, it means that absolutely all audio files played on
> my machine always will be resampled to 44.1kHz. Youtube from native 48kHz,
> highres audio 24/96, virtually anything I play. Could that be correct? And
> what can I do to be able to listen to highres audio again?

As already mentioned, it's about the sample rate of full duplex
streams, i.e. both playback and capture streams need to be aligned to
the same rate.  IOW, if both streams are in the same 48kHz, it should
be fine as is.

Check which streams are running when you get the unexpected sample
rate by inspecting /proc/asound/card*/pcm* entries.


Takashi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-25 18:01     ` Takashi Iwai
@ 2021-02-26  9:23       ` Heinz Diehl
  2021-02-28  8:18         ` Takashi Iwai
  0 siblings, 1 reply; 7+ messages in thread
From: Heinz Diehl @ 2021-02-26  9:23 UTC (permalink / raw)
  To: linux-kernel; +Cc: tiwai, lpoetter

On 25.02.2021, Takashi Iwai wrote: 

> Check which streams are running when you get the unexpected sample
> rate by inspecting /proc/asound/card*/pcm* entries.

I see, thanks for explaining! Pulseaudio no longer works properly for me, but
after configuring my audio player to use ALSA directly, all is fine so
far and all audio files are played with the correct sample rate and
without any resampling, just as they should.

Thanks, Heinz.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-26  9:23       ` Heinz Diehl
@ 2021-02-28  8:18         ` Takashi Iwai
  2021-02-28 11:46           ` Heinz Diehl
  0 siblings, 1 reply; 7+ messages in thread
From: Takashi Iwai @ 2021-02-28  8:18 UTC (permalink / raw)
  To: Heinz Diehl; +Cc: linux-kernel, lpoetter

On Fri, 26 Feb 2021 10:23:55 +0100,
Heinz Diehl wrote:
> 
> On 25.02.2021, Takashi Iwai wrote: 
> 
> > Check which streams are running when you get the unexpected sample
> > rate by inspecting /proc/asound/card*/pcm* entries.
> 
> I see, thanks for explaining! Pulseaudio no longer works properly for me, but
> after configuring my audio player to use ALSA directly, all is fine so
> far and all audio files are played with the correct sample rate and
> without any resampling, just as they should.

The fix I merged today can also work around your problem.
Please give it a try.
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5f5e6a3e8b1df52f79122e447855cffbf1710540


Takashi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [BISECTED] Kernel 5.11.x breaks pulseaudio
  2021-02-28  8:18         ` Takashi Iwai
@ 2021-02-28 11:46           ` Heinz Diehl
  0 siblings, 0 replies; 7+ messages in thread
From: Heinz Diehl @ 2021-02-28 11:46 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linux-kernel, lpoetter

On 28.02.2021, Takashi Iwai wrote: 

> The fix I merged today can also work around your problem.
> Please give it a try.
>   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5f5e6a3e8b1df52f79122e447855cffbf1710540

Applied on top of 5.11.2 - now pulseaudio works perfectly again, many
thanks!

Heinz



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-02-28 11:49 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-25 17:01 [BISECTED] Kernel 5.11.x breaks pulseaudio Heinz Diehl
2021-02-25 17:10 ` Takashi Iwai
2021-02-25 17:28   ` Heinz Diehl
2021-02-25 18:01     ` Takashi Iwai
2021-02-26  9:23       ` Heinz Diehl
2021-02-28  8:18         ` Takashi Iwai
2021-02-28 11:46           ` Heinz Diehl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).