Linux 5.19 regression causing 44100 to initially be the only supported sample rate after PW (re-)start
- PipeWire version (
pipewire --version
): git master commit 34c1c161 (the issue was found in all previous versions, too, with back to 0.3.52 or 0.3.53 having been tested) - Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
): Gentoo Linux - Desktop Environment: KDE
- Kernel version (
uname -r
): 5.19.0-gentoo
Description of Problem:
When PipeWire daemon starts up the SPA ALSA plugin always reports 44100 as the only supported sample rate (96000 may or may not have been reported at some point, too). However after pausing the first stream and waiting for device suspend timeout to cause the ALSA HW node to get closed, upon unpausing that same device will then report [44100; 192000] as the supported sample rate range (this is still not entirely correct as the HW is capable of up to 384000 Hz sample rate).
How Reproducible:
Likely depends on HW. Some people have no issue at all, others may need to allow multiple sample rates or change the default from 48000 to 44100 before they might see 48000 and 96000 streams using 44100 (one of the problems reported in #2614 (closed)). Finally for me it seems to happen nearly (but not exactly) always with the default 48000 being the only allowed sample rate.
Steps to Reproduce:
systemctl --user restart pipewire{,-pulse}.socket
- Use a native or PulseAudio client to play a file that's not using 44100 sample rate;
mpv --ao=pulse <file>
works well - Use
grep rate /proc/asound/card*/*/*/hw_params
to observe the actual ALSA HW configuration which, if this issue is present, will probably be 44100 but could be another unexpected rate - Pause the client for at least 5 seconds (the default suspend timeout) and optionally check with the grep above that no configured rate is reported (all devices are closed)
- Unpause the client and check the grep again to see that it's now using the expected file rate (for multiple sample rates) or the default sample rate
Actual Results:
If the issue affects the particular HW, it will use an unexpected sample rate (most often or even always 44100) instead of either the default rate or the stream's sample rate, if that sample rate is allowed).
Expected Results:
PW should have used the graph rate, which by default is always 48000.
Additional Info (as attachments):
State after daemon restart and before any client has played anything:
During first stream playing:
That same file playing on that same device but after the node has been suspended and then the stream unpaused:
SPA ALSA debug log from journald: