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 :
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?
256 frames per period with 3 periods is a noticeable amount of latency. At 44.1k that’s around 17ms. If you were playing a virtual instrument the latency would be 34ms + hardware latency. That would be noticeable. (EDIT : correct figure for jack2 in async mode : 29ms + hardware latency. )
A low latency would be 5ms round trip – that wouldn’t be perceptible.
For the settings you’re using a low latency kernel is fine .Computers have been able to handle eight tracks of audio since 1999. For applications like live virtual instruments or monitoring through the computer where low latency is important a real time kernel could improve performance.
Maybe I’m mistaken about what settings I use for recording virtual instruments. The latency really is imperceptible (and better than I can achieve in ASIO land). Whatever the actual values (lower than 128?) I can record without any distracting latency (and more importantly without x-runs). I’ll report back with actual settings at some point.
No doubt I am confused about the numbers. I loaded Cadence with my pre-existing settings and I see 44.1k, 128 samples (with 3 periods). Block latency says 2.9ms. That’s the number I’ve always understood to be the same as reading a latency number in Windows. Clearly I am incorrect if @merlyn is suggesting that 256 buffers equates to 34ms. I know what sub 10ms feels like on Windows (according to the control panel of my interface) and the performance I get on antiX is better.
@anon60445789 if you can show me a link to where I can find that Zen dorky tool I’d be interested to look more into it. There isn’t any… Maybe that stat is just a copy-paste text fake … All the statistics around MuQSS and Liquorix against stocked things shows no beneficial difference… I offered a link – but I had a little spew with development because we’re not allowed to elaborate into the topic… and I was a little upset that I wasn’t allowed to get more feedback into it… but we’re all cool…
Cadence reports ‘block latency’ which is (number of frames per period)/(sample rate). In this case 128/44100 = 2.9 ms.
If you were using QjackCtl latency is reported as (block latency)*(number of periods). In this case 8.7 ms.
When going through the computer there is an input buffer and an output buffer so the total round trip latency is 2*(block latency)*(number of periods). In this case 17.4 ms. (EDIT : the correct formula for jack2 in async mode is (block latency) * (2 + number of periods) giving 14.5ms. See @x42’s post below.)
Then there is hardware latency which on my soundcard is 30 samples or 0.7 ms at 44100 on the input and output making a total of 18.8 ms. (EDIT : correct figure 15.9ms)
I’m so totally and utterly confused by both your long post and this following one. I’m simply repeating how people on the web refer to Liquorix: as low-latency. For example, here: https://forum.mxlinux.org/viewtopic.php?t=45544
Now, the post of this topic was about reaching zero x-runs which I do, comfortably while recording music that requires zero perception of latency. I do that with a combination of antiX 17 (soon to be 19), a lowly UMC204HD or other similar device and the Liquorix kernel. I stated I might just be lucky and it obviously depends on what else is going on on my OS and particular hardware combination.
Thanks. So would this be the same in Windows if it reported under 10ms in the interface control panel? If so, 18.8ms seems absolutely fine for my harpsichord and organ recordings. It feels instantaneous!
You’ll need statistics and benchmarks. When it comes to performance, you need charts to back up the claim there is a difference, so far when I look at things on phoronix I don’t see any gain with the Liquorix kernel.
Phoronix is a pretty established name for Linux benchmarks, I am kind of surprised you never heard or mention them…
You can measure the actual latency with jack_iodelay by connecting a lead from the input to the output of your soundcard. That also tells you the hardware latency which you can put into the fields in Cadence called ‘Input Latency’ and ‘Output Latency’.
Once again another absurd post to these forums. I’ve deleted it.
It helps no one whatsoever for you to do this sort of “brain dump” about kernels (or whatever). If you want to write up a post about RT kernels, that’s entirely welcome, but it should be structured, accurate, and actually helpful to real people. It should probably have its own thread. It must be kept up to date. Etc. etc.
You are allowed to go into details. What you cannot do is an un-structured brain dump full of incoherent, inaccurate information that ultimately isn’t helpful to actual users.
While you’re effectively right (assuming you use jack2 with default settings), the proper calculation for this is slightly different. The number of periods applies only to playback.
The nominal round-trip latency for Ardour/ALSA , jack1, and jack2 in sync-mode is
nominal round trip latency = (samples per period) * (1 + periods per cycle)
jack2 in async mode (the default) adds 1 cycle extra latency:
nominal round trip latency = (samples per period) * (2 + periods per cycle)
Keep in mind that this does not include systemic latencies.
If you use JACK, you can easily query them with jack_lsp -l and sum playback + capture latency. jack_lsp -l does include configured systemic latencies.
Do not make disparaging remarks about other forum members.
Remain focused on factual basis of the topic(s) at hand.
Do not post overly long or complex or high-information content posts. These are either typically unhelpful for a specific topic, or become outdated (yet still cross-referenced by search engines and discovered by later readers), or both.
If another forum poster has made a mistake, point out (gently) the nature of the mistake without criticizing the poster’s personal qualities. If possible, suggest an improvement rather than just the mistake.
There are no limits on what can be discussed here, but discussions must follow these rules.
And then … specifically: there is a large body of inaccurate information available online about linux kernels, realtime audio, latency and scheduling. When posting about these topics in ways that attempt to provide “answers” or “information”, it is of the utmost important that your post does not contribute to the misinformation or the confusion.
In addition, when posting about these topics, please recall that these forums are frequented by people who have been close to or even a part of the kernel development process for more than 2 decades, and that as a result, the forums’ threshold for “accurate” and “useful” information in this area is very high.
Wow, very interesting info as I work on USB only, thanks.
Does it mean that working on PCI express soundcards would be easier to get no xrun?
Any of you guys working on such a kernel in Ubuntu/Debian? I found those packages but I’m not sure it is what you meant by prempt-rt or rtirq https://wiki.ubuntu.com/RealTime (no more support for realtime, but the post looks outdated) https://wiki.ubuntu.com/UbuntuStudio/rtirq (there’s a link to a script)
Yes. The first refers to a realtime-kernel – the main benefit of which is that it allows reliably prioritize devices. The latter is a script to set this up.
Tweaking your system for pro-audio requires quite some expertise and time. This is why there are dedicated GNU/Linux distros out there. – Before diving into system-config, perhaps try eg. AVLinux (runs live from USB-key or DVD) as second opinion to see if things work nicely with the hardware you have.
For applications like live virtual instruments or monitoring through the computer where low latency is important a real time kernel could improve performance.
