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

[scott.thomason]

I was able to reduce my Jack latency from 85ms down to 2.7ms. This is what I did to get there...

First, I installed the Liquorix kernel, which is specially built for these kind of high-performance low-latency situations: https://liquorix.net/

Then I implemented some-but-not-all of the suggestions at https://wiki.linuxaudio.org/wiki/system_configuration. That document is pretty dated, but still contains a lot of good information. These are the steps I took:

1. In the LinuxAudio doc, it suggests using QuickScan, but the current tool is actually rtcqs from https://codeberg.org/rtcqs/rtcqs. I downloaded and unpacked that, then cd'ed into the new directory and ran:

Code: Select all

./rtcqs

This gave me a bunch of good leads to look into.

2. In /etc/default/grub, I modified the GRUB_CMDLINE_LINUX_DEFAULT line to look like this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs mitigations=off"

After that, on Ubuntu-like systems you have to run:

Code: Select all

update-grub

3. I didn't want to login and start Jack right away, so I created a script at /usr/local/bin/audio-setup that I could run when I wanted to start a recording/playing session. Inside I added this line of code:

Code: Select all

echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

That puts the CPUs into a higher-performance state.

4. I created a PulseAudio configuration file at ~/.config/pulse/client.conf and included this line to prevent PA from respawning:

Code: Select all

autospawn = no

5. In /usr/local/bin/audio-setup I added another line:

Code: Select all

pulseaudio -k

This will kill PulseAudio when you run the script, and because of the previous step, it won't automatically re-spawn.

6. At the end of /etc/sysctl.conf, I added these two lines, which tell the kernel to be less swap-happy, and increases the number of files the system can monitor for changes:

Code: Select all

vm.swappiness = 10
fs.inotify.max_user_watches = 524288

7. There are a number of ways to start a Jack session. I use Cadence, Catia, and Claudia from https://kx.studio/ to make the whole process very simple. Other people swear by qjackctl. However you do it, I set the real-time priority to 80 in the configuration...90 is the highest priority. By default Cadence will start the PulseAudio->Jack bridge, but since I killed PA I just disable that. If you don't need Alsa MIDI, you can disable that too.

After doing all that, my latency went from more than 85ms down to just 2.7ms. I can work with that, but if you need even more speed, there are still plenty of suggestions to follow in the LinuxAudio guide I linked to earlier.

Last but not least... My workstation is a desktop computer with an 8-core AMD 3800X processor. It's water-cooled with a huge 3-fan radiator which almost never needs to run. It's worth spending a few extra bucks on your motherboard...mine makes it easy to do two things: 1) I've been running that processor overclocked to 4.5GHz, and 2) I can create a "performance curve" for the water cooler so the fans are essentially silent at low temperatures and only run audibly if the system starts to stress. With that much processor power, that rarely happens.

[scott.thomason]

Actually, with this setup I can run with a 64-sample buffer if I increase the period count to 3, giving me a new latency figure of 1.3ms. Cool.

[sunrat]

Is that latency as reported in Cadence, or actual round-trip latency measured with jack_iodelay?

[scott.thomason]

Is that latency as reported in Cadence, or actual round-trip latency measured with jack_iodelay?

That's what Cadence reports. I'll measure with jack_iodelay later on.

---scott

[bluzee]

I've been happy with the liquorix kernel. I run it on everything except for one old machine stuck with an nVidia card. Just for laughs I decided to do some tests. All things equal except the kernel. Jack running at 48K/64/3. Intel E6750 4gb ram.

Default Mint 20.3 kernel 5.4
Mackie Artist 1-2
13.930ms round trip
412 extra frames
Behringer UMC404HD
12.514ms
344 extra frames

Liquorix 5.17
Mackie
8.576ms
155 extra frames
Behringer
7.472ms
102 extra frames

[folderol]

Hmmm. Devuan chimaera (rt kernel)
samplerate 48kHz
64 frames/period
3 periods/buffer
Oldish Intel dual core (no hyperthreading) @ 3.1MHz
Somewhat elderly KA6
round trip 7.725 mS

2 periods/buffer (not supposed to be a good idea)
6.516 mS

So this is mostly the hardware/converters

[tapenade]

Hey, thanks very much for this thread! Great topic.

Do you guys have any recommendations for which filesystem is most practical to use for a new system?

I used to swear by ext3, just as ext4 was becoming more dominant. The built-in system ext4 support handled the ext3 filesystems just fine and supposed has some specific backwards compatibility in terms of buffering and yet without having to worry about locking or unlocking the partitions, unlike pure ext4.

But a couple of weeks ago, somewhere on YouTube some guy seemed to claim and demo that btrfs was good enough for a DAW and it made his system partition backups really fast or something. I was kind of amazed but pleased to consider btrfs, but I had previously thought that filesystems with complex extents and journaling might be too much excessive writing to the drive(s). Any thoughts on this?

Sorry I don't have any stats yet, I'm about to be setting up a system from scratch in a few weeks, so I thought I'd ask amongst those who comprehend and are into tweaking and optimizing. Some might call us 'tinkerers' since we like to tinker with (calibrate) our systems.

[scott.thomason]

Is that latency as reported in Cadence, or actual round-trip latency measured with jack_iodelay?

This is what I get from jack_delay:

Code: Select all

405.845 frames    8.455 ms

I assume when you said "jack_iodelay" that you really meant "jack_delay".

My latency as measured by Cadence is now down to 1.3ms.

---scott

[folderol]

This becomes diminishing returns. Also you've not included the hardware delays. Round trip is the only really meaningful figure. Added to that, if you're just 1 metre from your speakers you added another 3mS to the real latency.

Drummers are often credited with being able to detect very low latencies. It's not true. Like everyone else, they subconsciously compensate. What they can detect is small latency differences, and once inside the computer getting those to a few milliseconds is trivial these days.

[merlyn]

Hmmm. Devuan chimaera (rt kernel)
samplerate 48kHz
64 frames/period
3 periods/buffer
Oldish Intel dual core (no hyperthreading) @ 3.1MHz
Somewhat elderly KA6
round trip 7.725 mS

2 periods/buffer (not supposed to be a good idea)
6.516 mS

So this is mostly the hardware/converters

I tend to think latency is mostly down to software buffers. Taking the 3 periods/buffer result you got we add to that 1 input period and have :
4*64/48000 = 5.3ms
If JACK is running in async mode then another period is added to that.
5*64/48000 = 6.7ms

In bluzee's results the 'extra frames' are the difference between the calculated value and the measured value and they may be due to the hardware. I've yet to see anyone post results that show whether or not the 'extra ALSA USB buffer' has been taken out. It was supposed to happen. I don't know if it did, and I don't have a suitable USB interface to check.

[scott.thomason]

But a couple of weeks ago, somewhere on YouTube some guy seemed to claim and demo that btrfs was good enough for a DAW and it made his system partition backups really fast or something. I was kind of amazed but pleased to consider btrfs, but I had previously thought that filesystems with complex extents and journaling might be too much excessive writing to the drive(s). Any thoughts on this?

I use btrfs everywhere nowadays. It's snapshot capabilities are great. And I don't think the performance is any worse than ext4.

---scott

[scott.thomason]

This becomes diminishing returns. Also you've not included the hardware delays. Round trip is the only really meaningful figure. Added to that, if you're just 1 metre from your speakers you added another 3mS to the real latency.

It was quite painless to do the tasks listed above, so AFAIK, lower is better. I play guitar through JACK and when it was way up to 85ms it was unusable. Besides...who doesn't like hotrodding their computer?

[tavasti]

2. In /etc/default/grub, I modified the GRUB_CMDLINE_LINUX_DEFAULT line to look like this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs mitigations=off"

After that, on Ubuntu-like systems you have to run:

Code: Select all

update-grub

Giving this kind of instructions without warning is bad idea. That mitigations=off means disabling spectre/meltdown mitigations, and is security risk! If you have separate music workstation which is not used in general network use, then it is ok.

[j_e_f_f_g]

Now how much do you want to bet that Pipewire will make all of that non-functional? Because the tradition among Linux programmers is to constantly re-invent the wheel at the expense of backward compatibility. That means that configuration files can become obsolete/nonfunctional at any moment, and the method for setting some parameter or enabling some feature will abruptly change to a completely different method (which of course won't be documented nor explained because OSS developers don't do documentation).

[tavasti]

Now how much do you want to bet that Pipewire will make all of that non-functional? Because the tradition among Linux programmers is to constantly re-invent the wheel at the expense of backward compatibility. That means that configuration files can become obsolete/nonfunctional at any moment, and the method for setting some parameter or enabling some feature will abruptly change to a completely different method (which of course won't be documented nor explained because OSS developers don't do documentation).

This part, kernel parameter tuning for audio performance does not change if jack is replaced with pipewire.