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

[Audiojunkie]

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!

Yes! I agree completely! It makes absolutely no sense to dump a perfectly working system for the next new shiny object. However, at the same time, recognize that many of us are very successfully using Pipewire—remind yourself of that the next time you hear someone complain about it. As for you, you can try it when the time is right for you, and not a moment before. This is the beauty of Linux—we get do do things how we want, when we want.

[LAM]

Yes! I agree completely! It makes absolutely no sense to dump a perfectly working system for the next new shiny object. However, at the same time, recognize that many of us are very successfully using Pipewire—remind yourself of that the next time you hear someone complain about it. As for you, you can try it when the time is right for you, and not a moment before. This is the beauty of Linux—we get do do things how we want, when we want.

I've heard of people successfully using PW for a year and a half, and every time I tried it to replace JACK2 with PW I had always switched back for serious and less serious problems.

A few times it wasn't PW fault, but was because some applications just acted in a way that PW JACK emulation seemed to not support (see BespokeSynth using JACK backend). Most of the times was because of PW incomplete JACK support or just PW bugs (stopping Ardour transport while recording crash).

Now, I'm aware that during this period most bugs have been resolved, still when working with JACK programs I encounter crashes using PW that will not happen when using JACK.

Another thing I can barely stand about PW is the fact you have sound devices and PA apps spamming in your graph, while with vanilla PA you have them contained in a PA JACK sink/source by default. At least for my usecase, PA allows to have a predictable routing, without having to write configuration files. Yes, this is exactly the opposite usecase used by streamers that love PW for this.

There are more technical things I'm still investigating, like how PW manage RT and other differences with JACK.

All this to say that many people didn't realize that "promoting" PipeWire as a pro audio server replacement for JACK, just because "works in my case", while it wasn't ready enough did more bad than good to PW at the end.

[Audiojunkie]

Yes! I agree completely! It makes absolutely no sense to dump a perfectly working system for the next new shiny object. However, at the same time, recognize that many of us are very successfully using Pipewire—remind yourself of that the next time you hear someone complain about it. As for you, you can try it when the time is right for you, and not a moment before. This is the beauty of Linux—we get do do things how we want, when we want.

I've heard of people successfully using PW for a year and a half, and every time I tried it to replace JACK2 with PW I had always switched back for serious and less serious problems.

A few times it wasn't PW fault, but was because some applications just acted in a way that PW JACK emulation seemed to not support (see BespokeSynth using JACK backend). Most of the times was because of PW incomplete JACK support or just PW bugs (stopping Ardour transport while recording crash).

Now, I'm aware that during this period most bugs have been resolved, still when working with JACK programs I encounter crashes using PW that will not happen when using JACK.

Another thing I can barely stand about PW is the fact you have sound devices and PA apps spamming in your graph, while with vanilla PA you have them contained in a PA JACK sink/source by default. At least for my usecase, PA allows to have a predictable routing, without having to write configuration files. Yes, this is exactly the opposite usecase used by streamers that love PW for this.

There are more technical things I'm still investigating, like how PW manage RT and other differences with JACK.

All this to say that many people didn't realize that "promoting" PipeWire as a pro audio server replacement for JACK, just because "works in my case", while it wasn't ready enough did more bad than good to PW at the end.

There is validity to what you say. A bad experience can turn someone against Pipewire. We don’t want that. But we don’t want people to be afraid of the new technology either. Pipewire is young, and is getting better with each release. It is now being included as the new default for the majority of the mainstream distros. While we certainly don’t want to be reimaging perfectly working distros, there are a lot of people with little experience that are just starting out with the default technology that comes in the distro. Pipewire is that new technology. It benefits us all to start being involved with the developers so they can understand the failing edge cases and fix the issues that cause them. If you experience an issue, please document it and report it. I personally can’t program, but I can write documentation. I can write detailed bug reports. We can all find a way to help, even if it is just posting well explained feature requests. And best of all, we can begin learning and sharing what we learn with each other.

[LAM]

While we certainly don’t want to be reimaging perfectly working distros, there are a lot of people with little experience that are just starting out with the default technology that comes in the distro. Pipewire is that new technology. It benefits us all to start being involved with the developers so they can understand the failing edge cases and fix the issues that cause them. If you experience an issue, please document it and report it. I personally can’t program, but I can write documentation. I can write detailed bug reports. We can all find a way to help, even if it is just posting well explained feature requests. And best of all, we can begin learning and sharing what we learn with each other.

I completely agree with you on supporting and helping libre software getting better (funding, bug reports, documentation etc.), but if you are talking about new users they will most likely not do any of these things, be it for lazyness, disinterest, or just lack of knowledge of this "new technology".

Then there is another kind of users that are more interested in supporting what can actually help you making music. Be it a midi sequencer, a DAW, a plugin, etc.

Until now PW has not enabled any additional possibility, or made it easier, to make music for me. Let's see what the future will bring. For others is different? Let it be, I'm happy for them.

[wjl]

A bad experience can turn someone against Pipewire. We don’t want that. But we don’t want people to be afraid of the new technology either.

I've tried PW very successfully on Arch, so when Debian Bookworm will default to it next year, I won't be afraid.

Thanks for your good tips, @Audiojunkie

[LAM]

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

No need to manually create it in Debian. When installing pipewire it will install pipewire-bin too, the latter will create the 95-pipewire.conf file, with that exact same content.

[Audiojunkie]

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

No need to manually create it in Debian. When installing pipewire it will install pipewire-bin too, the latter will create the 95-pipewire.conf file, with that exact same content.

That info I posted was a direct copy/paste from Wim Taymon’s instructions found here:

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

I’m sure things will be a “little” bit different depending on which distro is used, but the general idea and recommendation is sound. (Pun intended)

[folderol]

I do notice that this guy seems far more amenable to discussion than Poettering!

[Audiojunkie]

I do notice that this guy seems far more amenable to discussion than Poettering!

That goes without saying! . I never met Poettering, but I’m not sure I’d want to.

[folderol]

I haven't either - which is probably a good thing. I'm told (by people who have had the misfortune) that I'd probably want to punch his lights out. One person described him as:
"A rude and arrogant shit"

[Audiojunkie]

That’s what I read too. As I remember it, one time, his work one time had a huge security flaw, and he refused to even acknowledge it, despite the many warnings and alerts. He instead mocked those bringing it to hos attention. I’ve hear that Stallman is difficult too, but for different reasons. Intelligence and great talent and skill doesn’t always equate to social skills and humility.

[P.Blom]

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".

I'm trying to aply this sugestions on my Manjaro Machine. It says to add user to the Pipewire group but I dont have one..
Should I create the group myself?

[P.Blom]

Also I couldn´t find these settings in "jack.conf" but in pipewire.conf.

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

"

[Audiojunkie]

My experience is with Fedora workstation, which has pipewire installed by default. I think most setup instructions are distro specific. If pipewire is installed by default on Manjaro, i imagine that it has a group it is assigned to. You’ll need to find the name of the group Pipewire is added to in Manjaro. IIRC Arch systems have a realtime package that can be installed instead of manually setting up the groups. A lot of distros have the user create an “Audio” group. So it may be slightly different depending on the distro used.