Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1054019: broken sample rate passthrough
45 views
Skip to first unread message
Nicholas D Steeves
Oct 15, 2023, 5:30:05 PM10/15/23
to
Package: pipewire
Version: 0.3.65-3
Severity: normal
Hi,
Unfortunately using mpv's Pipewire driver results in audio being
resampled, which introduces resampling artifacts. While I discovered
this bug in bookworm's mpv_0.31.1-4, I've confirmed that it is still
present in 0.36.0-1. That said, as a result of the investigation when
filing this bug, I found what seems to be evidence that points to
Pipewire as the true cause of the bug. Any software that uses Pipewire directly, or pipewire-jack appears to be affected.
Steps to reproduce:
1. Uninstall and disable pulseaudio (if it's installed).
2. Install pipewire-pulse.
3. Cp /usr/share/pipewire/pipewire.conf /etc/pipewire/pipewire.conf
4. Set "default.clock.allowed-rates = [ 44100 48000 88200 96000 ]"
5. Restart pipewire's --user session.
6. mpv --ao=pipewire 01.ripped.from-CD.flac
7. cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate
rate: 48000 (48000/1)
When playing music with mpd (with Pulse audio backed) or with "mpv
--ao=pulse", the sample rate is correctly passed through to Pipewire, and thus to the hardware:
rate: 44100 (44100/1)
Yes, I tested to see if the creation of a pipewire.conf with
"default.clock.allowed-rates", and it appears to be for bookworm's
Pipewire 0.3.65-3.
The people who would probably be bothered the most by this bug are
those who purchased "High-resolution audio" files (sample rates up to
192kHz, and usually 24bit), because playback will be limited to 48kHz
due to this bug, as well as people who can hear 44.1khz to 48khz
resampling artifacts.
With the hypothesis that it was a Pipewire bug, I tried running
Audacious with pipewire-jack (with JACK output configured), and a popup dialogue showed "Error"
The JACK server requires a sample rate of 48000 Hz, but
Audacious is playing at 44100 Hz. Please use the Sample rate
Converter effect to correct the mismatch.
And testing with "pw-jack mpv --ao=jack 01.ripped.from-CD.flac" shows
AO: [jack] 48000Hz stereo 2ch floatp
and of course cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate shows
rate: 48000 (48000/1)
So yeah, it looks like Pipewire's default sample rate is always
applied when using pipewire or JACK sinks, despite
"default.clock.allowed-rates" being set, except with using pulseaudio.
I'm not sure why this is the case, but it seems wrong that everything
is buggy except Pipewire and Pulseaudio...and that's why I'm reporting
this bug against pipewire. Please feel free to reassign if this is a
naive assessment.
I hope this is enough to identify which package[s] is[are] affected as
well as to forward the bug upstream. Please let me know if any more
info is required.
Thanks,
Nicholas
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mpv depends on:
ii libarchive13 3.6.2-1
ii libasound2 1.2.8-1+b1
ii libass9 1:0.17.1-1
ii libavcodec-extra59 [libavcodec59] 7:5.1.3-1
ii libavdevice59 7:5.1.3-1
ii libavfilter8 7:5.1.3-1
ii libavformat59 7:5.1.3-1
ii libavutil57 7:5.1.3-1
ii libbluray2 1:1.3.4-1
ii libc6 2.36-9+deb12u3
ii libcaca0 0.99.beta20-3
ii libcdio-cdda2 10.2+2.0.1-1
ii libcdio-paranoia2 10.2+2.0.1-1
ii libcdio19 2.1.0-4
ii libdrm2 2.4.114-1+b1
ii libdvdnav4 6.1.1-1
ii libegl1 1.6.0-1
ii libgbm1 22.3.6-1+deb12u1
ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3
ii libjpeg62-turbo 1:2.1.5-2
ii liblcms2-2 2.14-2
ii liblua5.2-0 5.2.4-3
ii libmujs2 1.3.2-1
ii libpipewire-0.3-0 0.3.65-3
ii libplacebo208 4.208.0-3
ii libpulse0 16.1+dfsg1-2+b1
ii librubberband2 3.1.2+dfsg0-1
ii libsdl2-2.0-0 2.26.5+dfsg-1
ii libsixel1 1.10.3-3
ii libswresample4 7:5.1.3-1
ii libswscale6 7:5.1.3-1
ii libuchardet0 0.0.7-1
ii libva-drm2 2.17.0-1
ii libva-wayland2 2.17.0-1
ii libva-x11-2 2.17.0-1
ii libva2 2.17.0-1
ii libvdpau1 1.5-2
ii libvulkan1 1.3.239.0-1
ii libwayland-client0 1.21.0-1
ii libwayland-cursor0 1.21.0-1
ii libwayland-egl1 1.21.0-1
ii libx11-6 2:1.8.4-2+deb12u2
ii libxext6 2:1.3.4-1+b1
ii libxinerama1 2:1.1.4-3
ii libxkbcommon0 1.5.0-1
ii libxpresent1 1.0.0-2+b10
ii libxrandr2 2:1.5.2-2+b1
ii libxss1 1:1.2.3-1
ii libxv1 2:1.0.11-1.1
ii libzimg2 3.0.4+ds1-1
ii zlib1g 1:1.2.13.dfsg-1
Versions of packages mpv recommends:
ii xdg-utils 1.1.3-4.1
ii yt-dlp 2023.09.24-2~bpo12+1
Versions of packages mpv suggests:
pn libcuda1 <none>
-- no debconf information
Version: 0.3.65-3
Severity: normal
Hi,
Unfortunately using mpv's Pipewire driver results in audio being
resampled, which introduces resampling artifacts. While I discovered
this bug in bookworm's mpv_0.31.1-4, I've confirmed that it is still
present in 0.36.0-1. That said, as a result of the investigation when
filing this bug, I found what seems to be evidence that points to
Pipewire as the true cause of the bug. Any software that uses Pipewire directly, or pipewire-jack appears to be affected.
Steps to reproduce:
1. Uninstall and disable pulseaudio (if it's installed).
2. Install pipewire-pulse.
3. Cp /usr/share/pipewire/pipewire.conf /etc/pipewire/pipewire.conf
4. Set "default.clock.allowed-rates = [ 44100 48000 88200 96000 ]"
5. Restart pipewire's --user session.
6. mpv --ao=pipewire 01.ripped.from-CD.flac
7. cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate
rate: 48000 (48000/1)
When playing music with mpd (with Pulse audio backed) or with "mpv
--ao=pulse", the sample rate is correctly passed through to Pipewire, and thus to the hardware:
rate: 44100 (44100/1)
Yes, I tested to see if the creation of a pipewire.conf with
"default.clock.allowed-rates", and it appears to be for bookworm's
Pipewire 0.3.65-3.
The people who would probably be bothered the most by this bug are
those who purchased "High-resolution audio" files (sample rates up to
192kHz, and usually 24bit), because playback will be limited to 48kHz
due to this bug, as well as people who can hear 44.1khz to 48khz
resampling artifacts.
With the hypothesis that it was a Pipewire bug, I tried running
Audacious with pipewire-jack (with JACK output configured), and a popup dialogue showed "Error"
The JACK server requires a sample rate of 48000 Hz, but
Audacious is playing at 44100 Hz. Please use the Sample rate
Converter effect to correct the mismatch.
And testing with "pw-jack mpv --ao=jack 01.ripped.from-CD.flac" shows
AO: [jack] 48000Hz stereo 2ch floatp
and of course cat /proc/asound/card0/pcm0p/sub0/hw_params | grep rate shows
rate: 48000 (48000/1)
So yeah, it looks like Pipewire's default sample rate is always
applied when using pipewire or JACK sinks, despite
"default.clock.allowed-rates" being set, except with using pulseaudio.
I'm not sure why this is the case, but it seems wrong that everything
is buggy except Pipewire and Pulseaudio...and that's why I'm reporting
this bug against pipewire. Please feel free to reassign if this is a
naive assessment.
I hope this is enough to identify which package[s] is[are] affected as
well as to forward the bug upstream. Please let me know if any more
info is required.
Thanks,
Nicholas
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mpv depends on:
ii libarchive13 3.6.2-1
ii libasound2 1.2.8-1+b1
ii libass9 1:0.17.1-1
ii libavcodec-extra59 [libavcodec59] 7:5.1.3-1
ii libavdevice59 7:5.1.3-1
ii libavfilter8 7:5.1.3-1
ii libavformat59 7:5.1.3-1
ii libavutil57 7:5.1.3-1
ii libbluray2 1:1.3.4-1
ii libc6 2.36-9+deb12u3
ii libcaca0 0.99.beta20-3
ii libcdio-cdda2 10.2+2.0.1-1
ii libcdio-paranoia2 10.2+2.0.1-1
ii libcdio19 2.1.0-4
ii libdrm2 2.4.114-1+b1
ii libdvdnav4 6.1.1-1
ii libegl1 1.6.0-1
ii libgbm1 22.3.6-1+deb12u1
ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3
ii libjpeg62-turbo 1:2.1.5-2
ii liblcms2-2 2.14-2
ii liblua5.2-0 5.2.4-3
ii libmujs2 1.3.2-1
ii libpipewire-0.3-0 0.3.65-3
ii libplacebo208 4.208.0-3
ii libpulse0 16.1+dfsg1-2+b1
ii librubberband2 3.1.2+dfsg0-1
ii libsdl2-2.0-0 2.26.5+dfsg-1
ii libsixel1 1.10.3-3
ii libswresample4 7:5.1.3-1
ii libswscale6 7:5.1.3-1
ii libuchardet0 0.0.7-1
ii libva-drm2 2.17.0-1
ii libva-wayland2 2.17.0-1
ii libva-x11-2 2.17.0-1
ii libva2 2.17.0-1
ii libvdpau1 1.5-2
ii libvulkan1 1.3.239.0-1
ii libwayland-client0 1.21.0-1
ii libwayland-cursor0 1.21.0-1
ii libwayland-egl1 1.21.0-1
ii libx11-6 2:1.8.4-2+deb12u2
ii libxext6 2:1.3.4-1+b1
ii libxinerama1 2:1.1.4-3
ii libxkbcommon0 1.5.0-1
ii libxpresent1 1.0.0-2+b10
ii libxrandr2 2:1.5.2-2+b1
ii libxss1 1:1.2.3-1
ii libxv1 2:1.0.11-1.1
ii libzimg2 3.0.4+ds1-1
ii zlib1g 1:1.2.13.dfsg-1
Versions of packages mpv recommends:
ii xdg-utils 1.1.3-4.1
ii yt-dlp 2023.09.24-2~bpo12+1
Versions of packages mpv suggests:
pn libcuda1 <none>
-- no debconf information
Dylan Aïssi
Oct 17, 2023, 11:10:07 AM10/17/23
to
Hi Nicholas,
Le dim. 15 oct. 2023 à 23:27, Nicholas D Steeves <st...@debian.org> a écrit :
>
> So yeah, it looks like Pipewire's default sample rate is always
> applied when using pipewire or JACK sinks, despite
> "default.clock.allowed-rates" being set, except with using pulseaudio.
> I'm not sure why this is the case, but it seems wrong that everything
> is buggy except Pipewire and Pulseaudio...and that's why I'm reporting
> this bug against pipewire. Please feel free to reassign if this is a
> naive assessment.
>
> I hope this is enough to identify which package[s] is[are] affected as
> well as to forward the bug upstream. Please let me know if any more
> info is required.
pipewire 0.3.65 is quite old now. May I ask you to test with pipewire
in bookworm-backports (i.e. 0.3.82-1~bpo12+1)? To check if this bug
is already fixed in the latest version.
Best regards,
Dylan
Le dim. 15 oct. 2023 à 23:27, Nicholas D Steeves <st...@debian.org> a écrit :
>
> So yeah, it looks like Pipewire's default sample rate is always
> applied when using pipewire or JACK sinks, despite
> "default.clock.allowed-rates" being set, except with using pulseaudio.
> I'm not sure why this is the case, but it seems wrong that everything
> is buggy except Pipewire and Pulseaudio...and that's why I'm reporting
> this bug against pipewire. Please feel free to reassign if this is a
> naive assessment.
>
> I hope this is enough to identify which package[s] is[are] affected as
> well as to forward the bug upstream. Please let me know if any more
> info is required.
in bookworm-backports (i.e. 0.3.82-1~bpo12+1)? To check if this bug
is already fixed in the latest version.
Best regards,
Dylan
Nicholas D Steeves
Oct 17, 2023, 2:10:05 PM10/17/23
to
Hi Dylan,
Oops! Yes, thank you, I forgot to test a newer pipewire after tiring
and running out of time during the initial investigation.
0.3.82-1~bpo12+1 solves the bug :)
Rather than close this bug as fixed right away, do you think it would be
worthwhile to keep it open and/or add something to the bookworm release
notes? I could write a few words if you'd prefer. There are always
questions of "can I switch to $new_technology without regressions", and
I think this would help answer them.
It's also the case that pipewire-jack makes taking one's first steps in
Linux music production much easier, but sample rate mismatches are RC
for this use case...so at a minimum release notes should be provided.
What you do you think?
Regards,
Nicholas
Oops! Yes, thank you, I forgot to test a newer pipewire after tiring
and running out of time during the initial investigation.
0.3.82-1~bpo12+1 solves the bug :)
Rather than close this bug as fixed right away, do you think it would be
worthwhile to keep it open and/or add something to the bookworm release
notes? I could write a few words if you'd prefer. There are always
questions of "can I switch to $new_technology without regressions", and
I think this would help answer them.
It's also the case that pipewire-jack makes taking one's first steps in
Linux music production much easier, but sample rate mismatches are RC
for this use case...so at a minimum release notes should be provided.
What you do you think?
Regards,
Nicholas
Dylan Aïssi
Oct 23, 2023, 4:10:05 AM10/23/23
to
Hi Nicholas,
Le mar. 17 oct. 2023 à 19:59, Nicholas D Steeves <st...@debian.org> a écrit :
>
> Oops! Yes, thank you, I forgot to test a newer pipewire after tiring
> and running out of time during the initial investigation.
>
> 0.3.82-1~bpo12+1 solves the bug :)
Great! :-)
> Rather than close this bug as fixed right away, do you think it would be
> worthwhile to keep it open and/or add something to the bookworm release
> notes? I could write a few words if you'd prefer. There are always
> questions of "can I switch to $new_technology without regressions", and
> I think this would help answer them.
Sure, if you think it could be useful then it is worth adding something in the
bookworm release note (maybe also in the debian pipewire wiki page?).
> It's also the case that pipewire-jack makes taking one's first steps in
> Linux music production much easier, but sample rate mismatches are RC
> for this use case...so at a minimum release notes should be provided.
Yep, I would recommend using pw from bookworm-backports to use pipewire-jack
as there have been many improvements on this point in the latest versions.
Would you be willing to write it? :-)
Best regards,
Dylan
Le mar. 17 oct. 2023 à 19:59, Nicholas D Steeves <st...@debian.org> a écrit :
>
> Oops! Yes, thank you, I forgot to test a newer pipewire after tiring
> and running out of time during the initial investigation.
>
> 0.3.82-1~bpo12+1 solves the bug :)
> Rather than close this bug as fixed right away, do you think it would be
> worthwhile to keep it open and/or add something to the bookworm release
> notes? I could write a few words if you'd prefer. There are always
> questions of "can I switch to $new_technology without regressions", and
> I think this would help answer them.
bookworm release note (maybe also in the debian pipewire wiki page?).
> It's also the case that pipewire-jack makes taking one's first steps in
> Linux music production much easier, but sample rate mismatches are RC
> for this use case...so at a minimum release notes should be provided.
as there have been many improvements on this point in the latest versions.
Would you be willing to write it? :-)
Best regards,
Dylan
0 new messages