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

Hi Nicholas,

Le dim. 15 oct. 2023 à 23:27, Nicholas D Steeves <sten@debian.org> a écrit :

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

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

Hi Nicholas,

Le mar. 17 oct. 2023 à 19:59, Nicholas D Steeves <sten@debian.org> a écrit :

Great! :-)

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?).

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

We discussed this bug at
https://lists.debian.org/debian-doc/2024/12/msg00001.html -
Have you considered fixing this in a bookworm point release rather
than only stable-backports?

If that isn't a solution, there are quite a few unanswered questions
at https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/201

The merge request has new text from Nicholas. However one of the CI
step fails, I have no idea why.

Maybe someone else can carry this through?

Chris