Bug#1054019: broken sample rate passthrough

[Dylan Aïssi]

Hi Nicholas,

Le mar. 17 oct. 2023 à 19:59, Nicholas D Steeves  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

Bug#1054019: broken sample rate passthrough

[Nicholas D Steeves]

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


signature.asc
Description: PGP signature

Bug#1054019: broken sample rate passthrough

[Dylan Aïssi]

Hi Nicholas,

Le dim. 15 oct. 2023 à 23:27, Nicholas D Steeves  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

Bug#1054019: broken sample rate passthrough

[Nicholas D Steeves]

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  libass91: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  libavutil577: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  libdrm22.4.114-1+b1
ii  libdvdnav4 6.1.1-1
ii  libegl11.6.0-1
ii  libgbm122.3.6-1+deb12u1
ii  libjack-jackd2-0 [libjack-0.125]   1.9.21~dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  liblcms2-2 2.14-2
ii  liblua5.2-05.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  libswscale67: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-22.17.0-1
ii  libva2