How I reduced my Jack latency from 85ms to 2.7ms

[folderol]

From what I've been hearing from various sources, pipewire is not fit for high quality audio creation. I've no intention of even looking at it until I start hearing much more positive reporting. My main music setup has only Jack and ALSA, no pulseaudio etc. It is stable and never gives me any problems. I usually run at 64 frames/48kHz. I could work at higher resolution and lower latency, but why bother? Nobody will hear any difference!

[Audiojunkie]

I find it interesting that the people complaining the loudest against pipewire are the ones who have so far refused to learn it and give it a fair shot. I'm using Fedora with vanilla pipewire straight from the distro. I do not have JACK installed at all on my system. I run everything straight from pipewire-jack, pipewire-pulseaudio, and pipewire-alsa. Everything is working fine for me at 1.3ms latency on my Lenovo X1 Yoga Gen 5 2-in-1 laptop. Pw-top seldom shows xruns, and when they do show up, it's almost always when I am starting or closing my DAW--not when I'm actually in the middle of something. I have my realitme priorities set, my memlock configured, my threadirqs kernal parameter and my preempt=full kernel parameter set. I configured pipewire to run 24bit/48Khz at 1.3ms. (a Quantum of 64). That's it. No other configuration or tweaks have been done. Now, granted, I raise my latency up to around 5ms for full projects, but this is pretty much what everyone has been expecting and doing for years with the JACK server. Pipewire is usable in every way except with rare edge cases, and it's getting better with each and every release.

Use a non-production machine or a separate boot partition, and instead of hearsay, experience it for yourself. I know new things are scary, but we all signed up for the learning curve when we started using Linux. I find it actually easier than JACK ever was. If you try it, you may find that too.

[Audiojunkie]

I'll try to answer the best I can for you:

I configure my buffer settings through the pipewire configuration files. Just about everything that you can imagine can be configured in pipewire. The key locations for making the changes are in the following paths:

/usr/share/pipewire/pipewire.conf for the PipeWire daemon settings

/usr/share/pipewire/pipewire-pulse.conf for the PipeWire pulseaudio server

/usr/share/pipewire/client-rt.conf for the PipeWire native client settings

/usr/share/pipewire/jack.conf for the PipeWire JACK clients

In my particular case, I only use apps that support JACK for my audio work, so I keep everything default except for the jack.conf file. I copy the /usr/share/pipewire/jack.conf over to /etc/pipewire/

I then edit jack.conf in the new location and uncomment the following lines:

#default.clock.rate = 48000
#default.clock.allowed-rates = [ 48000 ]
#default.clock.quantum = 1024

I then set my settings to the desired amounts. "Quantum" = buffer size -- test and find the ideal setting for your personal system.

That's really all there is to it for me as far as pipewire configuration. Since there is currently no easy tool for changing the quantum, I go into this file and change the quantum when I want to change the buffer size. I can totally see this becoming simple once someone develops a GUI based tool to easily make these changes. At the moment, I don't know of such a tool yet, but editing this single file is very easy when I need to make a change.

---------------------

My ultimate goal is to document the easiest process possible for the majority of users to very easily start using Linux. Because of this, I've tried to keep things as simple as possible with my configuration. I don't use RT kernels. I use the standard generic vanilla kernel, but I use it with the threadirqs and preempt=full kernel parameters to make my system run as a real time machine.

Note that it is entirely possible to go much further with configurations to get even better performance at ultra low latencies. For example, the rtirq script can be used to prioritize the threads, but I'm purposely trying to avoid needing any settings other than what already comes in the default distro.

Aside from that, I just adjust the realtime priorities and the memlock limits:

Real-time priority limits are usually stored in /etc/security/limits.conf and /etc/security/limits.d/. The best option is to add a new file 95-pipewire.conf in /etc/security/limits.d/ with this content:

# Default limits for users of pipewire
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304

Then add your user to the PipeWire group so that you can use these priorities.

That's really it. That's really all someone needs to get really usable low latencies.

EDIT: For more information and additional options, see the pipewire wiki's performance tuning page:

https://gitlab.freedesktop.org/pipewire ... nce-tuning

EDIT#2: I guess I should had that I run my CPU governor set at "Performance".

[j_e_f_f_g]

That's "simple" to setup???

[GMaq]

@Audiojunkie

That is really good info, much appreciated! I agree PipeWire can't be ignored and it has indeed gotten to a point now where it seems to work well across most use cases and the time has come to get with the program (pun intended). I've found some of the Wikis out there overwhelming, thanks for the concise explanation!

[sysrqer]

I'll and my vote of support for pipewire. I'm certainly not a professional but it works really well for me even with default configs and I would hate to go back to using Jack and pulseaudio now. For what I need it's perfect and is much more set and forget than Jack ever was.

[bluzee]

Manually editing config files and creating a set and forget system has always been an option with Jack as well. The system tuning steps are identical. The only real change is people's attitudes. Doing this work to setup a system with Jack was considered difficult. Now that we are doing it for Pipewire it's not.

I'm glad Pipewire is getting better but in the end I can only think that that the difference is that distros will ship preconfigured to work well with Jack/Pipewire/Pulse whereas no distro (other than AVL) ever bothered to do this with Jack/Pulse.

[k410]

Aside from that, I just adjust the realtime priorities and the memlock limits:

Real-time priority limits are usually stored in /etc/security/limits.conf and /etc/security/limits.d/. The best option is to add a new file 95-pipewire.conf in /etc/security/limits.d/ with this content:

# Default limits for users of pipewire
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304

RE: that strange-seeming number for memlock

On a hunch I divided it by 1024, which results in 4096 -- so that number probably corresponds to 4GB of RAM -- is that right?

My system has 32GB of RAM, so I didn't set up a swap partition. Was that a bad idea?

Is memlock even relevant on a system with no swap?

If it is, would a larger value for memlock be more appropriate, or should it just be set to "unlimited" (or not specified at all in that 95-pipewire.conf file)?

[sysrqer]

Manually editing config files and creating a set and forget system has always been an option with Jack as well. The system tuning steps are identical. The only real change is people's attitudes. Doing this work to setup a system with Jack was considered difficult. Now that we are doing it for Pipewire it's not.

Jack was less forget for me in general, it was stable but there were a few annoyances with it like having to stop the whole server to change a setting, I wouldn't go back to that.

I'm glad Pipewire is getting better but in the end I can only think that that the difference is that distros will ship preconfigured to work well with Jack/Pipewire/Pulse whereas no distro (other than AVL) ever bothered to do this with Jack/Pulse.

That's certainly not the only difference but isn't that a huge improvement in general?

[LAM]

Jack was less forget for me in general, it was stable but there were a few annoyances with it like having to stop the whole server to change a setting, I wouldn't go back to that.

If it's buffersize jack_bufsize or RaySession can do it for example, or jack_control for other parameters.

PW has a nice CLI interface to change its settings, true , but the real problem is how applications react to the change of these settings.
PW will not magically avoid an application crash when changing settings if the application is not developed with this case in mind.

Who tried PW in the last year and an half has surely stumbled in crashes caused by PW changing samplerate, for example.

So, at the end I would not blame anyone for staying on JACK (as I am) or to prefer PW instead. With time the needle will go towards PW but there will be still preference for JACK in some cases.

In the last months I have installed PW on a machine that I don't use for audio work and is doing its PA job very well.

[folderol]

Well, regardless of all the comments here, I'm still firmly of the opinion "If it ain't broke, don't fix it!". My setup ain't broke and hasn't been for a very long time.
Typically I walk into the room with a mug of tea or coffee, press one button, and by the time I've had a couple slurps, fidgeted a bit on the seat, everything is up and running - ready for me to just play.

[GMaq]

Well, regardless of all the comments here, I'm still firmly of the opinion "If it ain't broke, don't fix it!". My setup ain't broke and hasn't been for a very long time.
Typically I walk into the room with a mug of tea or coffee, press one button, and by the time I've had a couple slurps, fidgeted a bit on the seat, everything is up and running - ready for me to just play.

Hi Will,

I don't think anyone is suggesting otherwise for an end user happy with what works, in my own studio I'm still running a system based on Debian 10 that hasn't been updated for about a year. Like you, I switch it on and it works.. The focus is on those newly coming to Linux for production with Distros already providing PipeWire or in my case to align with the realities of the next Debian release.

Do your thing, enjoy your thing!

[GMaq]

Another question, just curious...

I'm sure it will literally take some Distros months or years to fix the dependencies of their Packages to not depend on PulseAudio or JACK.. For those who are running with PipeWire how are you managing Audio applications that want to install JACK or Pulse from your Repositories?

[sysrqer]

Another question, just curious...

I'm sure it will literally take some Distros months or years to fix the dependencies of their Packages to not depend on PulseAudio or JACK.. For those who are running with PieWire how are you managing Audio applications that want to install JACK or Pulse from your Repositories?

I haven't come across anything like that on Arch since I started with pipewire about this time last year, they seem to have been really quick to make the necessary changes to packages.

[Audiojunkie]

Aside from that, I just adjust the realtime priorities and the memlock limits:

Real-time priority limits are usually stored in /etc/security/limits.conf and /etc/security/limits.d/. The best option is to add a new file 95-pipewire.conf in /etc/security/limits.d/ with this content:

# Default limits for users of pipewire
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304

RE: that strange-seeming number for memlock

On a hunch I divided it by 1024, which results in 4096 -- so that number probably corresponds to 4GB of RAM -- is that right?

My system has 32GB of RAM, so I didn't set up a swap partition. Was that a bad idea?

Is memlock even relevant on a system with no swap?

If it is, would a larger value for memlock be more appropriate, or should it just be set to "unlimited" (or not specified at all in that 95-pipewire.conf file)?

Yes, I believe so. I have actually increased mine to almost double that number (and I’m thinking about increasing it even more). I have 16GB in my machine. I’m thinking 12GB might be my magic number. You will likely need to adjust to the amount that works best for you. Those values that I listed above were the initial defaults—a safe starting place.