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
http://bandshed.net/forum/index.php?topic=1917.0 (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. 
… 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.
Isn’t this what you want?
https://packages.debian.org/jessie-backports/linux-image-rt-amd64
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? https://packages.debian.org/jessie-backports/linux-image-rt-amd64 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: http://ubuntuforums.org/showthread.php?t=2273355
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. 
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.
@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: https://bitbucket.org/thismaechler/ubuntustudio-14.04-realtimeaudio/
Hi,
FWIW, the kernel I get the best performance with is this one: 4.0.0-040000-lowlatency #201504121935 SMP PREEMPT. I honestly can’t remember where I got it - some googling might be able to retrieve it. My system is an AMD FX 4300 on an ASUS M5A78L-M motherboard, running Linux Mint with the usual audio tweaks.
I’ve compiled a good few rt kernels, installed pre-compiled rt kernels… and with the same settings in jack (64 frames/period; 2 periods/buffer, onboard sound card) I always get xruns; for some reason the above lowlatency kernel is the one that performs the best (no xruns), and I don’t even have to set the cpu governor to ‘performance’. Also, rt kernels tend to freeze the pc on me at random moments, so I’ve ended up staying away from them.
I just run Addictive Drums with vsthost to play an electronic drum kit via MIDI, but I think zero xruns with the above settings and with an onboard sound card is pretty impressive.
I have the same feeling… There is something fishy going on regarding low latency andmodern linux distros. Some people suggests avoiding systemd and go for Devuan witch is basically Debian without systemd
I don’t know if that is a solution but none the less, Modern distros does not seem to work well out of the box. Have been using Lenovo/IBM laptops for a long time and used to be able to go down to 32 frames/period without x-runs but nowdays 256 still makes x-runs occasionally even without any significant load.
To make things even more difficult, Information on the web is scattered with knowledge and tips and tricks that are no longer valid.
What we would need is a tool that does what realtimeconfigquickscan does but with up2date and monitoring capabilities. Prefferable a GUI based or wizard style or ncurses tool.
Launch the tool and let it make basic suggestions how to improve low latency. Kernel, RT-prio, Soundcard-prio, Frequency scaling and so on.
When every suggestion is dealt with, one can launch the tool again and let it monitor what happens during the session and if x-runs occur, it can tell what other things did happen at the same time, like lots of interrupts from other devices.
I guess that is a similar approach as Dtrace in Solaris systems…
If I was a developer I would try to make this a reality since the number one issue Using Linux as a professional DAW platform is IMO “Glitch free Audio on modern computers using up2date distros”
Used to run Gentoo many years ago but that should not be necessary 2019 to make good use of a decent computer.
there’s UbuntuStudio and AvlLinux that are RT-kernel ready for the end-user. Normally the mainstream distributions do not come with an RT-kernel installed and kernel sysctl settings need to be tuned to meet RT things…
Also allank last posted up on here in 2015 
I’m only adding to the conversation because like the OP I still use an AMD FX-6300 system. By contrast I have 16 GB of ram but use 7200-rpm drives. I run antiX 17, essentially vanilla but added the Liquorix low-latency kernel (not the most recent at the time as it interfered with mouse cursor fluidity). I have also run Ardour on MXLinux with the same kernel. In addition, I have also installed various Ubuntu-based distros and tried running Ardour for a short time.
My own results are as follows:
Each and every Ubuntu variant presented problems related directly to audio performance. Whether it was overly-high CPU usage in an empty Mixbus session or regular x-runs in both Ardour and Mixbus the systems were unacceptable for my usage.
AVLinux worked out of the box with zero x-runs. The same for antiX and MXLinux. The interface used for testing was a UMC204HD. I now use both an M-Audio 192 and most recently an Audient iD44 with zero issues. I will go as far as to say that antiX (and AVLinux) is superior to Win10 ASIO performance at or under 256fpp and 3ppb (2ppb for my non-USB device though not sure this is critical). The only reason I ended up with antiX as my OS is because I didn’t need the vast amount of software included with AVLinux so chose to install a lean distro and install only what was necessary. I align with the advice that real-time kernels are unnecessary in 2019 (I re-posted the reasoning elsewhere on this forum, I believe).
Disclaimer: I might just be lucky with my particular combination of hardware and choice of OS. It works for me so I thought I’d pass it on given I have the same CPU and having gone through hours of testing and subsequent rejection of Ubuntu-based for audio work (at least valid for distros of 2018).
A second disclaimer: I don’t do any projects with huge numbers of tracks. My usage is generally 2-8 audio tracks with modest number of effects on the tracks and master bus.
I’ve used Manjaro Linux (Xfce) for audio for a couple of years now and there’s been zero problems. No xruns either, but I always use 1024 / 3 buffers. Manjaro lets you install several kernels (normal and realtime). You choose the kernel when booting up.
Thanks. I should clarify that I increase the buffers in Ardour and Mixbus for mixing/mastering. I only use lower when I’m recording virtual instruments (via Jack and Grandorgue). I used to do the same in Samplitude/Sequoia too, switching from “hybrid” low-latency to the “economy” engine. That said, Magix preferences/settings for audio are now simply mind-boggling and who knows what is the best setting these days… Thanks to Ardour developers for keeping things simple with regards audio settings!
The difference between a low latency and a real time kernel is their respective kernel scheduling latencies. A real time kernel has a lower maximum scheduling latency.
Kernel scheduling latency is the amount of time it takes a thread to wake up – the amount of time between a thread being asked for a result and the kernel starting to process it. This is measured in microseconds, so you’d think it wouldn’t matter. But if you are running at a low latency 500 us can matter.
To make the numbers easier say we are using a buffer that must be calculated within 5ms. If the DSP load is 90% then the audio process took 4.5ms to calculate a buffer. 500us = 0.5ms, so a kernel scheduling latency of 500us would cause an Xrun.
Most of the time kernel scheduling latency is low – under 100us, but it can spike and these spikes can cause Xruns. A real time kernel has less spikes and the maximum value is lower.
It’s possible to investigate this with cyclictest, part of the rt-tests package. Or you could draw a graph with this script :
http://www.osadl.org/Create-a-latency-plot-from-cyclictest-hi.bash-script-for-latency-plot.0.html
This is a graph of a low latency kernel :
This is a graph of a real time kernel :
A real time kernel helps get latency to its minimum without Xruns.
Could you explain why it could spike in a bare bones system with networking etc disabled? An honest question…If indeed this is the case, I might consider switching to RT. As I said, I’ve had zero problems so far but there is, of course, some law in the universe that states when I most need zero x-runs, there will be an x-run.
With all due respect, I don’t know what you have running on your system and the kernel numbers don’t match. Are these from your own system? I might be missing something. Have you tried graphing Liquorix low-latency? If similar to Windows LatencyMon recommendations anything below 500us you are fine for real time audio work.
EDIT: In a nutshell, laws of the universe withstanding, If I can get 128 and 256 buffers at my 3 periods for USB interface with low-latency kernel, why would I need to do any better than this for typical recording and mixing/mastering tasks?