Pipewire Pro Audio profile

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Post Reply
thebutant
Established Member
Posts: 171
Joined: Sun Nov 18, 2012 12:59 pm
Has thanked: 53 times
Been thanked: 8 times

Pipewire Pro Audio profile

Post by thebutant »

What are your experiences with the Pro Audio profile?
I have a RME Babyface Pro FS, which runs just great on my system (Pop!_OS 22.04).
However, when I switch the profile in pavucontrol from Analog Stereo Duplex to Pro Audio, it performs noticably poorer.

Just yesterday I was recording some guitar track, and I tested this.
In Mixbus with a few plugins, the recording went flawlessly on a buffer size of 64 with Analog Stereo Duplex. No signs of trouble.
When changing to Pro Audio (and restarting and everything), the 64 setting was just a noisy mess of xruns. 128 also risky business, 256 performs well.

However, with the Analog Stereo Duplex I'm not able to use more than the first 2 inputs of my Babyface, so I'd really like the Pro Audio profile to shine.

How's it working for you? Do I make any obvious mistakes here?

tseaver
Established Member
Posts: 497
Joined: Mon Mar 13, 2017 6:07 am
Has thanked: 35 times
Been thanked: 143 times

Re: Pipewire Pro Audio profile

Post by tseaver »

I don't see anything in your description which suggests an obvious misconfiguration on your part. I'm only guessing here, as I don't have the device, but the symptom you describe could be related to Pipewire's willingness to resample to match client's desired / expected sample rates, which could in theory lead to excessive CPU usage when more channels are in play.

Things to check:

  • Does the RME Babyface Pro FS support the sample rate you mean to use for recording? Is there any way to check what sample rate at which the hardware is running?
  • Does your DAW request the same sample rate (or the JACK configuration, if you are using Pipewire's JACK emulation)?
  • Are there any other apps running before you start recording which might cause Pipewire to choose a different sample rate than the one you desire?

On the whole, I'd rather that everything on my system used a single, nailed-down sample rate: Pipewire's willingness to "fake it" (by resampling) for different clients is unsat for my use cases.

Ubuntu, Mixbus32C; acoustic blues / country / jazz
thebutant
Established Member
Posts: 171
Joined: Sun Nov 18, 2012 12:59 pm
Has thanked: 53 times
Been thanked: 8 times

Re: Pipewire Pro Audio profile

Post by thebutant »

This is what I find so strange with the situation:
When using the interface as Analog Stereo Duplex, I'm rather impressed with the performance of my system.
I run 48 khz / 24 bit, quite simple setting.
But as soon as I change to Pro Audio, running the exact same sample rate, exact same Pipewire settings, same Jack settings for Pipewire, same projects, everything else the same, my system performs remarkably less good.
I don't really know why it would resample anything to match, as the settings are the same.

I haven't found a file that stores specific Pro Audio settings, that these could be different than the other pipewire settings. If there is such a file, please tell me. I'd love to check it out and configure it.

What I'd want from the Pro Audio Profile is simply to open up the rest of my inputs and outputs, but it does something else which I don't know what is, and it's really bad for audio performance. It makes me stick to Analog Stereo Duplex and cope with 2 inputs instead of being able to use them all :|

User avatar
Audiojunkie
Established Member
Posts: 627
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 530 times
Been thanked: 285 times

Re: Pipewire Pro Audio profile

Post by Audiojunkie »

The Pro Audio profile uses a different scheduling system than the rest of Pipewire. When switched to the Pro Audio profile, it uses IRQ based scheduling, and the IRQs need to be prioritized, in order to benefit from the IRQ Scheduling. This is how JACK did it as well. So, if you are running a generic kernel, consider using the realtime and threadirqs kernel parameters, and then get a script that prioritizes the Audio IRQs the higest. Once done, you should notice a big improvement over what you were using before.

It's getting a bit outdated, but this guide that I put together, based off of the Arch Linux Pro audio guide (amongst other things)--but made for Fedora, gives the majority of the details regarding these things:

viewtopic.php?t=27121

Post Reply