"Invalid sample rate" using JACK w/ PipeWire @ 44.1 kHz

[echozio]

Bug Description

I'm getting the following message when starting Mixxx using the JACK backend with PipeWire v0.3.83:

My hardware as well as other applications use 44.1 kHz, but Mixxx seems determined to use 48 kHz, or at least that's what it sets in its config, even if I change it to 44.1 kHz.

The only way I've managed to make it work is to open a 48 kHz project in Ardour (also using JACK). Then Mixxx doesn't complain, but playback slows down if I close the Ardour session (sample rate changes from 48k to 44.1k according to Carla).

Everything worked until a day or two ago, and only broke either after a system update or after starting to use my DJ controller as the primary output (I believe the sound card I used before always ran at 48 kHz).

Version

2.3.6

OS

Debian Sid

[echozio]

(edit: removed irrelevant details in favor of more reliable way to reproduce issue)

It appears I'm able to reliably reproduce the issue by playing audio in another application. E.g. if I play audio in Firefox, Mixxx shows the error. If I pause the audio in Firefox, Mixxx starts without issue. (FWIW Firefox was playing at 48 kHz according to pw-top.)

I don't really know what to make out of this, but will leave it open in case someone deems it worth looking further into. For my own purposes I guess it appears I'm able to work around it somehow by stopping and starting other applications.

Here's the log from one of the times it didn't start properly: https://gist.github.com/echozio/eef8c6801263eaabe77d87d8e74c2fcd

[Swiftb0y]

Can reproduce reliably as well, though I wasn't able to find any time to look into the issue. It's definitely related to a recent pipewire upgrade. My current workaround is just using ALSA again, though that's not great either.

[Swiftb0y]

My current hypothesis is that Mixxx always tried to open a device with Jack with the wrong samplerate. Until recently it has worked because pipewire just silently resampled the signal. This is a bug on our part that.

[Swiftb0y]

I think the audio slowdown issue is from the fact that mixxx doesn't respond well to pipewires dynamic adjustment of the audio graph. In any case. I'm not sure how to fix this properly. You may be able to work around this by forcing pipewire to stay on 48 KHz no matter what.

[Swiftb0y]

requesting help from @daschuer. Why do we / does portaudio not adapt the samplerate to the rate of the jack graph?

[daschuer]

You find some hints here:
https://github.com/PortAudio/portaudio/blob/24c8d575e588d557d28f4011becb753421346860/src/hostapi/jack/pa_jack.c#L616C2-L616C2

In JACK, there is one server with one sample rate.

In case of Pipewire which implements this server interface you need to adjust the sample rate of this "Server" before Mixxx starts:
pw-metadata -n settings 0 clock.force-rate 44100

Portaudio cannot do it, because it dos not know that it is not talking to a real JACK server.

Portaudio has recently been extended with a Pulse API. This will be able to set the Pipewire samlple rate. There is however some pending work to make that usable for all Mixxx users:
PortAudio/portaudio#336

[Swiftb0y]

Shouldn't mixxx be able to at least reconnect to the (fake) Jack server without shutting the entire application down?
I'm not sure PulseAudio is the right abstraction for this. Portaudio definitely needs a Pipewire implementation as well (in the long term) that can deal with the dynamic samplerate and quantum changes.

[daschuer]

Yes, that was the reason we have offered a GSoC project that targets this:
https://github.com/mixxxdj/mixxx/wiki/GSOC-2023-Ideas#first-class-pipewire-support

The main issue with Portaudio is its device based model, that does not allow full Jack/Pipewire support. So I assume that becoming a native Pipewire (or Jack) app is the solution with the least hassle.

[Swiftb0y]

I agree. At that point its probably easier to switch to RtAudio across the board as it follows the channel-oriented model IIUC.

[eXWoLL]

Still getting this when trying a mixed ALSA controller/laptop setup.

Edit: pw-metadata -n settings 0 clock.force-rate 44100 and selecting ALSA 44100 fixed the issue!