Hyper Low-Latency Audio with a Real-Time Kernel


The promise of zero or near-zero latency audio is a huge asset to the the Linux operating system. Sometimes, achieving super low-latency audio is tricky, but not if your kernel is hard-realtime capable. Cut your latency to under 3 ms with this tutorial.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Great video posting, and

Pedro Lopes's picture

Great video posting, and obviously great work on tweaking the parameters for low latency. Ill try the RT patch myself because I've been waiting t have some time to do that a while ago. So you're tutorial will come in handy this days.

Once again,
very well done.

p.s.: for all audio producers that are thinking about giving linux a go, don't think: try it. Results and freedom of choice will ultimatly speak louder.

Sorry about some typo

Pedro Lopes's picture

Sorry about some typo mistakes, I'm too sleepy actually.


thorgal's picture

"realtime" is not about small latency but duration predictability. A hard RT system is supposed to be 100% predictable per a given process. A soft rt system guaranties predictability on average so it is less reliable per a given process but keeps the average time predictable.

Realtime kernels

Arnout Engelen's picture

Before diving in and compiling your own kernel patched with realtime support, I'd suggest checking whether your distro comes with a kernel tuned for realtime use.

Watch this space: http://wiki.linuxmusicians.com/doku.php?id=system_configuration#installing_a_real-time_kernel

Ubuntu Studio

evilsoccerfiend's picture

Ubuntu Studio has a full suite of audio recording and manipulation applications. You can of course build your own real time kernel (do a google search for make-kpkg or kernel-package for help on the Debian/Ubuntu specifics of this process), but since Ubuntu Studio provides its own real time kernel there is no need to do this.

Personally I have 64 Studio on my dedicated audio workstation, and Ubuntu Studio on my laptop. You can also convert an existing K/X/Ubuntu install by adding the Ubuntu Studio sources to your package manager. The Ubuntu Studio site provides the details on this. I know it works because that is what I have done.


which one is better?

arpo's picture

So I think I need your help: I'm going to install a linux distro on my AMD64 laptop. I need it mainly to play software synths live with my MIDI keyboard so I think I need a fast (low latency) and reliables OS. What would you suggest for this? Ubuntu Studio 64 or 64 Studio?

Ubuntu -> Ubuntu Studio even easier

Arnout Engelen's picture

You can also convert an existing K/X/Ubuntu install by adding the Ubuntu Studio sources to your package manager. The Ubuntu Studio site provides the details on this.

In fact, all Ubuntu Studio packages have nowadays been merged into mainline Ubuntu, so all of the power of Ubuntu Studio is now at the fingertips of all Ubuntu users - even without having to add an extra package source.

More info can be found here.

hard realtime is when you

Anonymous's picture

hard realtime is when you have bounded latency or all hell breaks loose (people die, or lots of money is lost).
soft realtime is when you statistically (usually) have a bounded latency.

preempt_rt improves Linux latency so that less things affect the longest latency.

you can have soft realtime systems that measure latency in minutes too. But the professional audio case needs ms range.

There is no hard-realtime kernel for Linux. If you want hard realtime, use WindRiver, QNX or RTLinux. Non of them resemble what you describe.

Good tutorial though.

good presentation !

Dave Phillips's picture

Hi Elliot:

Thanks for the excellent breakdown. Alas, I fear it's all too much for any average musician, Linux-based or otherwise. In place of the process you've described I now routinely advise installing a latency-optimized distribution such as 64 Studio or Planet CCRMA. Those systems are also optimized re: MIDI, which is bound to be of importance for modern computer-based music-making. Your demonstration does appear to include setting support for the realtime clock (RTC), perhaps that should be mentioned for the benefit of the more MIDI-minded musician. In addition to the RTC there is a frequency setting (in the firmware drivers configuration, IIRC) that should also be set to CONFIG_HZ=1000. The default is often far too low (250 or even 100 Hz) for decent resolution of a MIDI event stream, especially a heavy one.

One other note: From what I understand, hard realtime is not what we get from these optimizations, and the collective knowledge seems to agree that hard realtime is unnecessary for even professional audio requirements. If I'm wrong corrections are welcome. :)

Otherwise, a good demonstration of the effect of the realtime optimizations. Thanks again ! :)


Dave Phillips


Similis sum folio de quo ludunt venti.

Hard realtime

Kjetil Matheussen's picture

Hi Dave,

I have a small correction to your comment:

Ingo's patches does actually provide hard realtime scheduling to linux, that's the point of it. You need some kind of hard realtime scheduling to play audio if you want a guarantee that no sound glitches will occur. The reason for this is that hard realtime scheduling gurantees that processes set to run in realtime wakes up within a certain timeframe. And this also means that hard realtime most certainly is necessary for professional audio requirements, since "professionals" usually don't want glitches in sound.

With all this said, you can in practice avoid glitches in non-realtime systems as well, but you have no guarantee. With Ingo's patches, you have.

Hi Dave, I've learned a lot

Elliot Isaacson's picture

Hi Dave,

I've learned a lot from your articles and linux-sound.org is a great resource, keep up the great work.

You're right about the kernel options for MIDI users. I'm pretty sure that 1000Hz is the default timer frequency for all desktop systems, with 250Hz reserved for servers, but it's worth mentioning anyway. I do sometimes forget that people are going to want to use MIDI, I'm very old-fashioned with my acoustic instruments and such.

What I think you mean by your other comment is that the audio system does not run in hard realtime even with a hard-realtime kernel, and I totally agree. Hard realtime latencies are measured in microseconds and the latency for the audio system is measured in milliseconds. But for my system with my lame hardware, the unpatched scheduler doesn't allow me push Jack much below ~25ms without risk, while with Molnar's patch I can force it to under 3ms.

Best Regards,

No, you missed the point

Anonymous's picture

No, you missed the point again. And I'm not even the same anonymous. 'Hard' in the context of realtime systems does not mean 'hard as in difficult', but 'hard as in inflexible'.

'Hard realtime' is an embedded system concept, whereby the combination of OS, kernel, compiler, libraries, etc. provide scheduling guarantees. The guarantees are the important bit here: you'd typically use an extremely C-unlike programming language, and you'd be able to do static analysis on your system to prove that no matter what the circumstances, your system can cash its cheques.

Again, it's nothing to do with the kind of response times that the system can achieve, but whether or not it can guarantee to meet the deadline.

For instance, in an automated dairy (there's one on an episode of How it's Made), a hypothetical hopper thing that feeds the cows needs to operate within at most a few hours of the feeding time. Not exactly a short deadline, but still a constraint within which the system absolutely must operate: the system can't crash, or only activate after a few days, or all the cows will starve. That's a hard realtime constraint. Similar example might include a fire-exit with a breakglass to unlock it, or a fill sensor on a dishwasher. None of the aforementioned need to operate within three milliseconds, but they all have hard deadlines which, if passed, will endanger people or damage stuff.

And now, finally, to get to the point: Linux is not a hard-realtime kernel. It can't make performance guarantees. It may be on the way to becoming a good realtime kernel, but that's not the same thing.

You wrote: "And now,

Kjetil Matheussen's picture

You wrote:

"And now, finally, to get to the point: Linux is not a hard-ealtime kernel. It can't make performance guarantees. It may be on the way to becoming a good realtime kernel, but that's not the same thing."

I'm not sure if you are referring to vanilla or the rt patches,
now, so to clear up: The point of the rt patches are simply to make the linux kernel hard realtime capable.

I think it does this by making all code (including interrupt handlers) pre-emptable (somehow). Search for monta vista realtime kernel, which Ingo builds his work on, if I'm not much mistaken.

Wikipedia's page about Mingo Molnar,
says: "One of his recent projects is the realtime preemption patch, which aims to bring hard-realtime scheduling latencies (50–60 microseconds worst-case execution time) to the Linux kernel."

Ubuntu Studio?

Anonymous's picture

How much of this is available by default in Ubuntu Studio? I know that it uses Jack with a real time kernel.

"so how is ubuntu"

Anonymous's picture

what IS IT keeping people from downloading the live cd and trying it out for themself?? you could have it downloaded, running and installed with time to spare while your other computer downloads it's daily dose of antivirus definitions, windows security updates and thinks for what will feel like hours about rebooting. just sayin :)