Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for Linux

Reply
 
Thread Tools Display Modes
Old 08-05-2018, 10:11 AM   #1
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default What is your experience with the preempt_rt patch vs. an rt-linux kernel?

Looking forward to getting my desktop set up for best low latency audio performance and some general purpose use. What has been your experience with the preempt_rt patch vs. rt kernel? Most recommendations I see these days say to go with a regular kernel with the preempt_rt patch, but along with those recommendations is a lack of elaboration. It seems to me that an rt kernel has the potential for dialing in a best balance of solid audio reliability and lowest latency, where the preempt_rt patch provides solid audio reliability for a general purpose machine albeit a little more latency.

Anyone done any comparison testing? Any tips to share?

Also on that topic, what stable roundtrip latency are you seeing with your machine/audio device, whether you are using a regular kernel, a regular kernel with preempt_rt applied, or a a realtime kernel? And for those who are running a realtime kernel, have you ran into any major issues for general purpose use?
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 08-05-2018 at 10:19 AM.
brainwreck is offline   Reply With Quote
Old 08-05-2018, 10:56 AM   #2
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

After a little more reading: Are actual realtime kernels still being maintained/developed today?
__________________
It's time to take a stand against the synthesizer.
brainwreck is offline   Reply With Quote
Old 08-05-2018, 11:57 AM   #3
Tobbe
Human being with feelings
 
Tobbe's Avatar
 
Join Date: Sep 2009
Location: Backe, Jämtland, Sweden
Posts: 355
Thumbs up

Hi,

I just installed Ubuntu Studio 18.04 lowlatency kernel 4.15.0-29 couple of days ago. I have a cheap Behringer U-PHORIA UMC22 USB audio interface and running that with these settings:

Sample Rate: 48000
Buffer Size: 512
Periods/Buffer: 3

Gives 10.7ms latency, works great with the VST instruments i use:

* AmpleSound Acoustic
* AmpleSound Bass
* Keyzone Classic, piano
* Stock Reaper Plugins and a bunch of free ones
* HoRNet plugins
* SForzando Soundfonts, like violin, cello, piano and other instruments

I do everything in MIDI these days and I get pretty good sound I might add. Good enough for me.

15-30 tracks with no errors so far, everything's is running smooth as butter.

I have a Lenovo IdeaCentre 23" All-In-One computer with 8GB RAM and a SSD 256GB. I might upgrade it to 16GB RAM in the future, but it runs well right now.
__________________
OS: Linux Mint XFCE 19.01, Reaper For Linux (64Bit) and native linux-vst plugins (16GB RAM) LSP-Suite, Drumgizmo, TpL-Plugins, LinuxSampler/Fantasia, Behringer U-PHORIA UMC22.
Tobbe is offline   Reply With Quote
Old 08-05-2018, 12:16 PM   #4
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

Quote:
Originally Posted by brainwreck View Post
Anyone done any comparison testing? Any tips to share?
http://www.linux-magazin.de/ausgaben...-echtzeitig/3/ (Test from 2008. picture, from page 3, see appendix.)
https://wiki.linuxaudio.org/wiki/real_time_info, https://linuxmusicians.com/viewtopic.php?f=26&t=9845
Quote:
Originally Posted by brainwreck View Post
And for those who are running a realtime kernel, have you ran into any major issues for general purpose use?
Yes. https://mirrors.edge.kernel.org/pub/...l/projects/rt/
Attached Images
File Type: jpg tb1.jpg-4-768x256.jpg (38.6 KB, 136 views)
khz is offline   Reply With Quote
Old 08-05-2018, 12:55 PM   #5
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

I'm seeing some microsecond figures in the pic at the first link. What are those measurements of? It is not round-trip audio latency or even half-trip latency. The latencies presented there are too low to be audio specific.

From a translation of that page, I see this near the end of the article:
Quote:
The numbers in Table 1 are taken from article [12]. The jitter described there can be interpreted for simplicity as (task) latency.
So then, what are the effects of task latency on audio latency in terms of milliseconds?
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 08-05-2018 at 01:09 PM.
brainwreck is offline   Reply With Quote
Old 08-05-2018, 02:31 PM   #6
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

Technically, it's too complex for me, I can't explain it. My English is also too bad. SRY
khz is offline   Reply With Quote
Old 08-05-2018, 03:21 PM   #7
shosty
Human being with feelings
 
Join Date: Aug 2015
Posts: 144
Default

I've noticed a slight improvement in latency and xruns but not enough to be very noticeable. Not really worth the effort vs a low latency kernel in my opinion but it depends what your target is and undoubtedly what your hardware/setup is.
shosty is offline   Reply With Quote
Old 08-05-2018, 03:58 PM   #8
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

I don't know what to make of this:

Quote:
These are some simple guidelines provided to help you understand which kernel, and in which order, you should test to fit your use case.

If you do not require low latency for your system then please use the -generic kernel.

If you need a low latency system (e.g. for recording audio) then please use the -preempt kernel as a first choice. This reduces latency but doesn't sacrifice power saving features. It is available only for 64 bit systems (also called amd64).

If the -preempt kernel does not provide enough low latency for your needs (or you have an 32 bit system) then you should try the -lowlatency kernel. If the -lowlatency kernel isn't enough then you should try the -rt kernel

If the -rt kernel isn't enough stable for you then you should try the -realtime kernel

https://askubuntu.com/questions/1266...r-realtime-one
It is a 6 year old post, so maybe not all is not still relevant. But according to that, an rt kernel is different than a realtime kernel, and a low latency kernel provides lower latency than a preempt_rt kernel (which I thought was the other way around).

Anyone have a definitive source on untangling this?

Edit: Found more info here:

Quote:
Kernel Types

-generic kernel - this is the stock kernel that is provided by default in Ubuntu.

-preempt kernel - this kernel is based on the -generic kernel source tree but is built with different configurations (settings) to reduce latency. Also known as a soft real-time kernel.

-rt kernel - is based on the Ubuntu kernel source tree with Ingo Molnar maintained PREEMPT_RT patch applied to it. Also known as a hard real-time kernel.

-lowlatency kernel - very similar to the -preempt kernel and based on the -generic kernel source tree, but uses a more aggressive configuration to further reduce latency. Also known as a soft real-time kernel.

-realtime kernel - is based on the vanilla kernel source tree with Ingo Molnar maintained PREEMPT_RT patch applied to it. Also known as a hard real-time kernel.

At the moment only the first three kernels are available through official Ubuntu archives.

https://help.ubuntu.com/community/Ub...RealTimeKernel
I'm not sure how this all plays out per distro. At past points I have ran either an rt or realtime kernel (on Debian) and a preempt_rt kernel (on Arch). But that was years ago, and I only vaguely remember sorting through the naming/distinction mess back then. I have highlighted key terms here. So according to that (and some personal clarification):

Vanilla kernel comes from original linux kernel devs.
Generic kernel (stock kernel) comes from distro devs.

And so:

Generic, preempt_rt, rt, and lowlatency are all of the distro specific kernel source, with preempt_rt being soft real-time, rt being hard real-time, and lowlatency being soft real-time with more agressive config.

Vanilla and realtime are of the original linux source, with realtime being hard real-time.

Anyone confused yet?
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 08-05-2018 at 04:26 PM.
brainwreck is offline   Reply With Quote
Old 08-05-2018, 11:10 PM   #9
eric71
Human being with feelings
 
Join Date: Feb 2008
Location: Finland
Posts: 160
Default

Another thing to look at is how the kernel's timer is set. Some of the basic RT-kernels that distros have were not specifically intended for pro audio. My info may be outdated, but the Ubuntu lowlatency kernels have the timer set for 1000 Hz, which is needed for good low latency work, especially midi. That's one reason they were added, as the Ubuntustudio project was gaining traction. But I've see RT-kernels that use 100 Hz, and although they are full realtime preempt, the timer may be too slow for midi. In short, it's good to dig a little deeper into the kernel configuration. That's one reason the AVLinux RT kernels are good - they have been specifically configured for audio, and have the timer set accordingly.
eric71 is online now   Reply With Quote
Old 08-06-2018, 09:01 AM   #10
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

Quote:
Originally Posted by eric71 View Post
Another thing to look at is how the kernel's timer is set. Some of the basic RT-kernels that distros have were not specifically intended for pro audio. My info may be outdated, but the Ubuntu lowlatency kernels have the timer set for 1000 Hz, which is needed for good low latency work, especially midi. That's one reason they were added, as the Ubuntustudio project was gaining traction. But I've see RT-kernels that use 100 Hz, and although they are full realtime preempt, the timer may be too slow for midi. In short, it's good to dig a little deeper into the kernel configuration. That's one reason the AVLinux RT kernels are good - they have been specifically configured for audio, and have the timer set accordingly.
Do you know if AVLinux is running a realtime kernel (vanilla), a debian kernel, or something else?
__________________
It's time to take a stand against the synthesizer.
brainwreck is offline   Reply With Quote
Old 08-06-2018, 09:45 AM   #11
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

http://www.bandshed.net/2018/06/25/a...ixes-released/
Old AVLinux version: installed packages. https://linuxmusicians.com/viewtopic.php?p=81668#p81668

It's also a live distribution. Download it, install to USB and start/test.
You can also ask GMaq (AVLinux) directly.

Last edited by khz; 08-06-2018 at 11:23 AM. Reason: AV Linux 2017.4.9 RT-Kernel picture
khz is offline   Reply With Quote
Old 08-06-2018, 11:16 AM   #12
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

It looks to be that AVLinux is running a customized preempt_rt kernel.
__________________
It's time to take a stand against the synthesizer.
brainwreck is offline   Reply With Quote
Old 08-06-2018, 11:20 AM   #13
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

Quote:
Originally Posted by eric71 View Post
Another thing to look at is how the kernel's timer is set. Some of the basic RT-kernels that distros have were not specifically intended for pro audio. My info may be outdated, but the Ubuntu lowlatency kernels have the timer set for 1000 Hz, which is needed for good low latency work, especially midi. That's one reason they were added, as the Ubuntustudio project was gaining traction. But I've see RT-kernels that use 100 Hz, and although they are full realtime preempt, the timer may be too slow for midi. In short, it's good to dig a little deeper into the kernel configuration. That's one reason the AVLinux RT kernels are good - they have been specifically configured for audio, and have the timer set accordingly.
A little suplementary info for understanding what the timer is for:

Quote:
Timer Wheel, Jiffies and HZ (or, the way it was)

The original kernel timer system (called the "timer wheel) was based on incrementing a kernel-internal value (jiffies) every timer interrupt. The timer interrupt becomes the default scheduling quantum, and all other timers are based on jiffies. The timer interrupt rate (and jiffy increment rate) is defined by a compile-time constant called HZ. Different platforms use different values for HZ. Historically, the kernel used 100 as the value for HZ, yielding a jiffy interval of 10 ms. With 2.4, the HZ value for i386 was changed to 1000, yeilding a jiffy interval of 1 ms. Recently (2.6.13) the kernel changed HZ for i386 to 250. (1000 was deemed too high).

https://elinux.org/Kernel_Timer_Syst..._way_it_was.29
If anyone has a link to better info (or first hand knowledge), please post it.

So it seems that the timer frequency is the interval for scheduling interrupts or context switching.
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 08-06-2018 at 11:29 AM.
brainwreck is offline   Reply With Quote
Old 08-08-2018, 09:52 AM   #15
X2theL
Human being with feelings
 
Join Date: Oct 2009
Posts: 25
Default

I just recently installed my first rt kernel (4.16.18-rt9-1-rt) on my Thinkpad X220 and have experienced a big improvement over the stock Arch kernel. I can now run my RME Babyface with a buffer size of 128 without any xruns whereas I would always get xruns with the stock kernel even at 256 frames. I haven't tried to go even lower because I don't feel the need. I haven't experienced any issues with the rt kernel when doing non audio computing.

And since I'm at it, disabling wifi has been the single most effective tweak to get fewer xruns independent from the kernel, even though it's not sharing any interrupts and all priorities are set as they should be.

So I would suggest: try an rt kernel (or use a distro that has one installed already)
X2theL is offline   Reply With Quote
Old 08-08-2018, 10:25 AM   #16
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

:-D

Disabling unnecessary services (for example WIFI) makes sense, yes.
My tip: Some (which makes sense for you) of it (no matter which distribution you use):
"Linux Audio Workstation LAW" (see signature).

Must have: the limits.conf entry.

"rtirq", "realTimeConfigQuickScan" and "shm" next to the RT Kernel and ... :-)

HF

Last edited by khz; 08-08-2018 at 10:30 AM.
khz is offline   Reply With Quote
Old 08-08-2018, 10:50 AM   #17
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

Quote:
Originally Posted by X2theL View Post
I just recently installed my first rt kernel (4.16.18-rt9-1-rt) on my Thinkpad X220 and have experienced a big improvement over the stock Arch kernel. I can now run my RME Babyface with a buffer size of 128 without any xruns whereas I would always get xruns with the stock kernel even at 256 frames. I haven't tried to go even lower because I don't feel the need. I haven't experienced any issues with the rt kernel when doing non audio computing.

And since I'm at it, disabling wifi has been the single most effective tweak to get fewer xruns independent from the kernel, even though it's not sharing any interrupts and all priorities are set as they should be.

So I would suggest: try an rt kernel (or use a distro that has one installed already)
Disabling wifi seems to be universally beneficial to low latency stability across operating systems. What I'm thinking about for setting up my desktop is just ditching the wifi card and running an ethernet cable for when I need internet. Another universal thing that has greatly helped my low latency stability is disabling powersaving features in the bios and os.

It would be great to be able to switch all these things through a script for 'daw' mode and 'general use' mode. But I don't know if that is possible (including bios settings).
__________________
It's time to take a stand against the synthesizer.
brainwreck is offline   Reply With Quote
Old 08-08-2018, 12:07 PM   #18
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

Quote:
Originally Posted by brainwreck
Disabling wifi seems to be universally beneficial to low latency stability across operating systems.
100 % Yes
Quote:
Originally Posted by brainwreck
What I'm thinking about for setting up my desktop is just ditching the wifi card and running an ethernet cable for when I need internet.
100 % Yes
Quote:
Originally Posted by brainwreck
Another universal thing that has greatly helped my low latency stability is disabling powersaving features in the bios and os.
100 % Yes & performance
Code:
perl -I ./ ./realTimeConfigQuickScan.pl
(
Quote:
Checking CPU Governors... CPU 0: 'powersave' CPU 1: 'powersave' CPU 2: 'powersave' CPU 3: 'powersave' - not good
Set CPU Governors to 'performance' with 'cpufreq-set -c <cpunr> -g performance'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=844
Code:
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 4.9.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'powersave' CPU 1: 'powersave' CPU 2: 'powersave' CPU 3: 'powersave' - not good
Set CPU Governors to 'performance' with 'cpufreq-set -c <cpunr> -g performance'
See also: http://linuxmusicians.com/viewtopic.php?f=27&t=844
Checking swappiness... 10 - good
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Checking access to the high precision event timer... readable - good
Checking access to the real-time clock... readable - good
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... found - good
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
not found.
** Warning: no tmpfs partition mounted on /tmp
For more information, see:
- http://wiki.linuxaudio.org/wiki/system_configuration#tmpfs
- http://lowlatency.linuxaudio.org
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
)
# http://fluxbox.org/ ;-)
Quote:
Originally Posted by brainwreck
It would be great to be able to switch all these things through a script for 'daw' mode and 'general use' mode. But I don't know if that is possible (including bios settings).
Install 2 different Linux or 2 different computers.
Changing over bios automatically is not possible. IMHO

But it's not necessary. IMHO
I have been using a computer, a distribution for: Music, Internet, Video, Graphics, ... .
Games and such areas would be different, other special optimizations.

Last edited by khz; 08-08-2018 at 12:26 PM.
khz is offline   Reply With Quote
Old 08-08-2018, 01:32 PM   #19
Jack Winter
Human being with feelings
 
Jack Winter's Avatar
 
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,787
Default

I've kept away from this thread as it was just too hot to think

FWIW, this seems incredibly complicated if you google it. A prime example of how times have moved on, and what to be useful advice starts to become just jumbled information, confusing, and sometimes outright wrong..

The RT kernel and the RT patch are the same thing.

In the interest of brevity I'm gonna play a little loose with the facts

There are different scheduler models in Linux, this means different ways of switching between running programs. Unfortunately we can't change this at run time, so it has to be decided when the kernel gets built. Reaper will work with any kernel, but if you are interested in low latency audio with no dropouts there are two scheduler models that come into question. The kernels are colloquially known as either a lowlatency, or a realtime kernel.

The only relevant difference is that the realtime kernel is slightly faster at scheduling (switching to another thread), but on some systems it might also be contra indicated (heresay, but for instance it also needs patching for nvidia) :S

If you have 1.5ms to finish processing your audio, and it takes the kernel 3ms to schedule your work, you'll get an audio dropout.

There are other kernel configuration options that are also important for low latency audio, like high resolution timers, dynamic ticks, etc. Hopefully your distro does a good job at making a kernel suitable for low latency audio.

A system might have problems with low latency scheduling due to many different problems, ranging from bad hardware/drivers to the BIOS stopping the processor to run it's own code.. Sometimes blacklisting a kernel module (driver) can help, WIFI is a common candidate..

On my haswell laptop I exchanged the broadcom wifi/bt card with an intel and things got a lot better

There are a few more practical things to attend to. Like running the soundcard and the audio thread at a high priority, being able to lock memory, disable CPU powersave (on some systems), etc.

I have a vacation coming up and I my plan is to work a bit at the wiki (see below), if you guys haven't read it, a lot of this stuff is already explained there..
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040,etc. :)
Jack Winter is offline   Reply With Quote
Old 08-08-2018, 02:55 PM   #20
brainwreck
Human being with feelings
 
Join Date: Jul 2006
Posts: 20,840
Default

Jack thanks much for the post and the info in the wiki. It seems hard to come by good info in this area, so us plebs are left digging through random muck to try and make some sense of it all.

In case you are looking for any topic suggestions for later writing, it would be good to know something about measuring any relevant system latencies and benchmarking system changes with low latency audio performance in mind. Also, any suggested reading for gaining a better understanding of the kernel in general would be welcome.
__________________
It's time to take a stand against the synthesizer.

Last edited by brainwreck; 08-08-2018 at 03:01 PM.
brainwreck is offline   Reply With Quote
Old 08-08-2018, 10:48 PM   #21
khz
Human being with feelings
 
Join Date: Jul 2008
Posts: 43
Default

LAC2011: Configuring your system for low-latency real-time audio processing

https://www.youtube.com/watch?v=2Oim2BIhamc

# http://lac.linuxaudio.org/2011/downl..._workshop1.pdf
# http://lac.linuxaudio.org/2011/downl...ier_slides.pdf

/AutoStatic # https://linuxmusicians.com/
khz is offline   Reply With Quote
Old 08-09-2018, 11:45 PM   #22
gennargiu
Human being with feelings
 
gennargiu's Avatar
 
Join Date: Jul 2013
Location: Napoli
Posts: 18
Default

Hi i used kernnel rt liquorix 4.9.76 on avlinux64 release 06/2018 on all programs for audio production and work perfect on my hp elite 8200 i3 processor quad core 3100 ghz and 16 giga ram. Reaper 5.9 for gnu linux work perfect

https://imgur.com/ox8Mwwo
__________________
reaper 5.984 windows 10 - gnu linux (Ubuntu Studio 18.04.3)
http://gennargiu.altervista.org/?doi...33752441406250
gennargiu is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:40 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.