Is it really possible to get down to 0 Xruns?

Hi folks,
I’m running Ardour 4.2 on Ubuntu GNOME 15.04 64-bit. My processor is a 6-core AMD FX-6300 and my system has 8 GB of RAM and a solid state drive.

That’s a reasonably powerful system for audio production, right? But for some reason I’m still getting occasional Xruns. They are pretty rare; maybe once every 5-6 minutes, sometimes even 10-15 minutes. If I only have Ardour and Hydrogen open, it’s usually 10 minutes or so before I get an Xrun, but I still get them. They don’t seem to occur with any regularity.

I really don’t understand why, since people with low-power laptops and rigs from 6 years ago seem to be able to run their systems at extremely low latencies (5 ms and under) without getting Xruns unless they’re under a very heavy load? My system temps are all pretty low. My CPU isn’t being pushed past 16% when I’m running JACK, “DSP” in Ardour isn’t breaking 17% and yet every once in a while I’ll see reports of Xruns in the JACK messages window.

I’m running JACK 2 through a Focusrite ScarlettSolo USB interface. My settings are as follows:
Realtime, Force 16-bit, 128 Frames/Period, 3 Periods/Buffer, 44100/48000 (I use both depending on source audio but notice no difference in performance.)
The system has been configured by the Ardour installer to allow realtime audio, CPU governor is set to performance and I’m using the lowlatency kernel with SMP, PREEMPT and 1000Hz available in Ubuntu’s repositories.

So my question is: is it possible to fully eliminate Xruns, or is this just a pipe dream?

Yes it is entirely possible. But …

Remember that “CPU power” has almost nothing to do with x-runs at all.

Try using a real time kernel. I know people say that you don’t need an RT kernel, but on all the hardware I’ve tried it on, I can get lower latency on a RT kernel than with a standard low latency kernel.

I hardly ever get xruns at the same settings you are running at… and that’s usually when loading software …
try setting your preempt a bit lower… I think there is a setting at around 300, use an RT kernel if you can

I have found that after the hard drive, the motherboard is the biggest impediment to xruns… things like the “south” bridge and USB chipsets will make a bigger difference than CPU… of course having decent RAM helps… but I think these days the latency on RAM is so low that it has little bearing anymore…

On 3 machines, I have not been able to get USB-devices to work reliably (x-run free) with buffersizes < 256fpp without a realtime kernel.

With preempt-rt and rtirq, 64fpp USB2 soundcards are fine for days at a time (Presonus 1818VSL, Forusrite Scarlett 18i6) on a Thinkpad X60 and a i5 Giga-Byte Mainboard Series/3400 USB Host Controller and another i5 with a Broadcom USB Chipset.

An easy check is to try AVLinux live from DVD or USB-stick (which includes a preempt-rt kernel by default).

Alternatively try running at 1024 fpp. If there are still occasional, periodic x-runs, this hints at system-management IRQs (health checks: power/voltage, temperature, etc) and will be very hard to get rid of. If you have the option, disable some power-saving options in the BIOS, particularly pci-bus frequency scaling, EIST, and C1E halt-states.

1 Like


Just to clarify, The current AV Linux doesn’t ship with an RT Kernel on the LiveDVD/USB, it ships with a lowlatency kernel to facilitate nVidia and AMD video drivers, that said it’s lowlatency kernel does have pretty good performance, however an RT kernel is provided as a post-install option for those who want it… Future releases of AV Linux which will be based on Debian Testing will most likely have an RT kernel as default…

I think that things have come full circle as far as the need for RT kernels, before there were many USB-2 devices available for Linux users very good results could be had with USB-1, PCI(e), and FireWire devices on lowlatency kernels when used in conjunction with IRQ threading and rtirq, however it seems that many USB-2 devices need the full preempt patching to work best, I’ve also seen this in my own experience with both a Presonus 1818VSL and a Scarlett 2i2, with both devices latency can easily be halved when running an RT Kernel vs lowlatency.

@GMAQ… on the MIDI side of things, I’ve never had good timing with a standard low latency kernel, only the RT kernels have provided me with good solid timing.

Thanks everyone, this is very helpful information. I would like to try running a system with a realtime kernel but it’s hard to find a modern version of the kernel with RT patch packaged for Ubuntu these days. I might try AVLinux and see how that treats me, though.

Regarding testing for IRQs, I’ll leave JACK running with 1024 fpp as suggested and see what happens. As far as I can see, Xruns occur most often if I have a browser open; otherwise they pretty much seem to be rare.

How recent does it have to be? Kernel 4.1.3-rt3-avl1 was announced in July at (note the original posting was in 2012, but the message has been updated to the latest available kernel version.
That’s more than new enough to fully support a Focusrite Scarlett. It is 32 bit only, which is a show-stopper if you want to drop it into an existing 64 bit system, but it shouldn’t be hard to look elsewhere and find a 64 bit RT kernel 4.x build in a .deb package somewhere.

In my limited experience, a kernel .deb for Ubuntu will install and work on AV Linux, and I don’t see why the converse shouldn’t be true. It’s certainly worth a try.

doesn’t have to be that recent… I believe almost any of the 3.x series kernels should support a scarlett.

That’s the thing, AVLinux is literally the only distro I know of that has .deb packages of newer rt-kernels and they’re exclusively 32-bit.
I’ve been searching for a while now and I’ve not been able to find anything for Ubuntu (or Debian) that isn’t really, really old. Ubuntu 15.04 is currently on 3.19 and I’d settle for anything that supports my hardware. It doesn’t have to be insanely new; I just need something than the 2.6.x rt-kernels that seem to be everywhere.

On a side note, I tried setting JACK to 1024 frames/period and it did indeed eliminate all Xruns from JACK. It might not solve my latency issues but at the very least it keeps things stable if I just want to sequence or mix things, which is very nice.

anything 3.x is not really old. :slight_smile: … unless you have a very new PC with a very new chipset it is unlikely that you will have any problems with something like 3.13 (which I think is what kxstudio is using now) …
If you do you can always compile your own … (but on newer distros you may need to install toolchains e.t.c. to be able to do that)

From what I’ve seen, KXStudio’s regular and lowlatency kernels are up to date but their realtime kernel is… 2.6.X. It’s from 2010. As you suggested: guess I’m gonna have to learn to compile my own!

Thank you everyone for your help; it’s been a very informative day for me.
And kudos to GMaq: I took some time to try AVLinux and I have to say it runs incredibly well! Even on the regular lowlatency kernel, running off a USB thumbdrive it has fantastic performance. I was actively TRYING to cause Xruns and nothing could shake it. I’ll be getting an extra SSD in the future just to give it a proper home. :slight_smile:

Isn’t this what you want?
Kernel 4.1, RT, 64 bit.
I must admit, I was surprised to find it on the Debian site!

Isn't this what you want? Kernel 4.1, RT, 64 bit. I must admit, I was surprised to find it on the Debian site!

Thanks! I was amazed at how hard it was for me to find anything kernel-related while digging through the Debian archives last night. For some reason my searches weren’t returning many results…
Anyway, I did learn how easy (if slightly time-consuming) it can be to build your own kernel with the RT patch, thanks to this tutorial:
Replacing the kernel version mentioned in the tutorial with the most current one available (4.1.7) and the most recent RT patch (4.1.7-rt8) allowed me to get a brand new kernel running with RT enabled. :smiley:

It did indeed bring my Xruns down to 0 at my previously-mentioned settings but I can’t seem to find any straightforward way to make my proprietary drivers to play nice with it. I’ve seen (very old, no longer compatible) patches that allow you to install NVIDIA drivers with an RT kernel but nothing that applies to the current NVIDIA drivers, from versions 342 onwards.

My current solution is to have two separate installs; one with the RT kernel and nouveau drivers enabled and one with a regular lowlatency kernel but NVIDIA drivers enabled.
I’m also considering booting AVLinux from an external drive because it has insanely good performance but the software is a bit older than what I’m using now so I’m probably going to wait for the AVL 8 to release.

If any of you folks know a straightforward (or at least confirmed working) method to get the NVIDIA installer to work with an RT kernel on Ubuntu, I’d be extremely grateful!

wireless ap scanning can often be the culprit. maybe a/b wlan enabled/disabled.

Oh, thanks David. I’m currently running Ardour on a desktop machine so I don’t have to worry about wireless causing issues for now but I do plan to get a laptop just for music stuff in the future.

On a side note, my little experiment with a second OS running a real time kernel has been a fantastic success. Depending on the application, I can get down to 64 frames/period without Xruns!

Again, thank you everyone for your help. I’m very happy with the results. Definitely worth the money I put into both the hardware and the latest version of Ardour. :slight_smile:

1 Like

@MikeIronFist… Based on this thread it got me to check kxstudio. The kernel was a lowlatency one, not an RT one.
I installed an rt kernel (from a different repo) into kxstudio (it is a 3.14 version) … I am getting solid performance at 64 periods/frames and 3 buffers on a firewire device… this makes my entire system latency (including the i/o device, as your i/o device will add it’s own latency from the converters) at a little over 8ms… I have not seen an xrun yet.
I could not ask for better latency performance…

CPU performance . I did a test recording in Harrison Mixbus (which is similar to loading ardour up with a very large bunch of plugins) and stayed south of 32% DSP utilisation… (admittedly I am running an Intel 4930k with 6 cores overclocked to 3.9GHZ) YMMV

I tested on a 12 simultaneous channel recording… Then playback of 12 and recording of 4.

This has me rethinking my project to go back to Gentoo … I have seen better CPU performance on Gentoo, but with the amount of headroom I have, I’m not sure it will be worth the effort (especially as all my synthesis is in hardware)

A pre-compiled 3.18.7-rt1_0_amd64 for Ubuntu 14.04 is available here: