Easiest way to install a realtime kernel on an existing system?

[bluebell]

Hi all,

I am somewhat happy with my Xubuntu 16.04 systems with a lowlatency kernel but I think I could improve them with a realtime kernel.

How can I install a realtime kernel without destroying/reinstalling the whole system and fiddling around with grub? And where can I get one?

[GMaq]

Hi,

Our AV Linux kernels work on Ubuntu as well, they are just Deb packages, if you install them, leave your existing kernel installed until you are sure everything works and if for some reason the new RT kernel doesn't work select and boot into your old kernel with GRUB and uninstall them like any other Deb, but they should work just fine... also our latest kernels in the repository have have the KPTI patch for the Intel 'Meltdown' exploit.

Read the instructions in the first post here and use the 'stretch' repository: http://bandshed.net/forum/index.php?topic=3719.0

BTW the Deb install scripts will look after running grub-update so no messing with GRUB is required.

[bluebell]

That was easy. indeed. Thank you.

[GMaq]

That was easy. indeed. Thank you.

No problem

It will be interesting to know what your findings are, so much depends on the system hardware... one person is easily be able to reduce their buffer settings by half with an RT and the next may see no real benefit over a lowlatency kernel. Unfortunately the KPTI patch is still a bit of a wild card with regards to it's performance impacts.

In my case with a Presonus 1818VSL interface I cannot get buffers below 1024fpp with a lowlatency kernel and I can get down to 256fpp with RT...YMMV.

[Michael Willis]

In my case with a Presonus 1818VSL interface I cannot get buffers below 1024fpp with a lowlatency kernel and I can get down to 256fpp with RT...YMMV.

I'm totally going to try this. The lowest consistently reliable buffer size I've been able to manage is 512, I'll report back how it goes using the realtime kernel.

[GMaq]

I'm totally going to try this. The lowest consistently reliable buffer size I've been able to manage is 512, I'll report back how it goes using the realtime kernel.

Hi Michael!

To generalize it seems to be USB-2 Audio devices that show the greatest potential improvements, Firewire when used with the the older FFado drivers seems to perform fairly consistently regardless of LL or RT and PCI(e) cards also are fairly consistent. On the other hand it is certainly unlikely that RT would worsen performance, will be interesting to see what your experience is.

[bluebell]

That was easy. indeed. Thank you.

No problem

It will be interesting to know what your findings are, so much depends on the system hardware... one person is easily be able to reduce their buffer settings by half with an RT and the next may see no real benefit over a lowlatency kernel. Unfortunately the KPTI patch is still a bit of a wild card with regards to it's performance impacts.

In my case with a Presonus 1818VSL interface I cannot get buffers below 1024fpp with a lowlatency kernel and I can get down to 256fpp with RT...YMMV.

In my case (Core i7, Qtractor songs with 50 tracks, Focusrite Scarlett 2i4) the realtime kernel caused a few xruns at 256 buffer size while a lowlatency kernel doesn't. So I'll stay with the lowlatency kernel. In my setup the main CPU load comes from the plugins, not from transporting audio frames to the interface.

But I will try the kernel on a Core i5 as well.

[Jack Winter]

IMO, the first step evaluating realtime vs lowlatency vs nonpreemtive, ought to be to evaluate how well kernel scheduling works, which is really the big improvement a realtime kernel can bring. Threads ought simply to be scheduled quicker on the realtime kernel than any other kernel.

This can be accomplished by running the cyclictest utility included in rt-tests.

Try something like: "cyclictest -n -m -Sp98", what you are interested in is the max value which is the highest latency (delay) detected when trying to schedule a thread. Possibly even "cyclictest -n -m -Sp98 -i100 -d0" could be used. Best is to run the utility for some hours or days while using the machine, or put it under an artificial load running: "hackbench -l1000000" (which is another utility found in the rt-tests package).

You are probably wanting to see max values lower than 100us (0.1ms), if you see max values of 20.000us (20ms) the kernel has some problem... Also a rt kernel might have problems that arise from hardware/drivers, NMI/SMIs, etc.

Now why a rt kernel would give more xruns than a lowlatency kernel is hard to explain, really shouldn't happen. But without knowing more about the situation it's really hard to say with any certainty...

[GMaq]

In my case (Core i7, Qtractor songs with 50 tracks, Focusrite Scarlett 2i4) the realtime kernel caused a few xruns at 256 buffer size while a lowlatency kernel doesn't. So I'll stay with the lowlatency kernel. In my setup the main CPU load comes from the plugins, not from transporting audio frames to the interface.

But I will try the kernel on a Core i5 as well.

Hi bluebell,

Well that isn't really what I hoped to hear...

Do you know if the lowlatency kernel you're using with Xubuntu has the KPTI patch? I wonder if that has anything to do with what you're seeing...?

[bluebell]

In my case (Core i7, Qtractor songs with 50 tracks, Focusrite Scarlett 2i4) the realtime kernel caused a few xruns at 256 buffer size while a lowlatency kernel doesn't. So I'll stay with the lowlatency kernel. In my setup the main CPU load comes from the plugins, not from transporting audio frames to the interface.

But I will try the kernel on a Core i5 as well.

Hi bluebell,

Well that isn't really what I hoped to hear...

Do you know if the lowlatency kernel you're using with Xubuntu has the KPTI patch? I wonder if that has anything to do with what you're seeing...?

I made another test: a Qtractor song with 49 tracks (mixed MIDI with softsynths and audio), now I switched back to 44100 Hz since all of the audio tracks are in 44100.

With "Linux bubu 4.13.0-38-lowlatency #43-Ubuntu SMP PREEMPT Wed Mar 14 16:20:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux" I could run it with -n2 -p128 in the 2nd attempt. In the 1st attempt there were some (<10) xruns when Qtractor/Linux loaded the audio files from SSD.

With the realtime kernel I had many more xruns already in the first seconds of the song.

Both kernels have kernel page table isolation enabled.

So on my machines the lowlatency kernels work better, don't ask me why.

[Michael Willis]

To generalize it seems to be USB-2 Audio devices that show the greatest potential improvements ... will be interesting to see what your experience is.

Great success! Yes, I'm running a USB 2 interface (1st gen Focusrite Scarlett 2i4, using it for midi and audio). When I was running the low latency kernel, the lowest buffer size that I could reliably use was 512. In preliminary tests with the realtime kernel, I haven't had any x-runs with a buffer size of 128, which is a big improvement in latency time. Then I tried dropping it to 64, which gave me x-runs like gunfire at a shooting range, but I'm very content with 128.

For what it's worth, I'm running the latest Elementary OS. I had already tweaked it with pretty much every suggestion from https://wiki.linuxaudio.org/wiki/system_configuration. I had absolutely no trouble installing and running the realtime kernel from the AVLinux repo.

[GMaq]

Hi Michael,

Well that is good to hear! Thanks for sharing your experience..

[protozone]

@GMaq, thanks so very much for those tasty kernels!
You and the AVLINUX (/ KXstudio) approach have made my Linux life so much easier.
I finally got back into making more music and less configuring.
Thanks for doing the heavy lifting. I have no idea of how to compile anything, so whenever something is nearly plug and play I feel really greatful, especially when technical challenges are overcome.

Credit is due to ya and your helpers.
Sincerely, protozone.

(32-bit wine-staging; 32-bit Reaper; 32-bit FL Studio; 32-bit VST(i)'s; thanks to 32-bit MX Linux 17, Horizon; 4.14.12-rt10avl1 #17 SMP PREEMPT RT ...Sun Jan 14 00:31:51 EST 2018 i686 GNU/Linux)

[GMaq]

@GMaq, thanks so very much for those tasty kernels!
You and the AVLINUX (/ KXstudio) approach have made my Linux life so much easier.
I finally got back into making more music and less configuring.
Thanks for doing the heavy lifting. I have no idea of how to compile anything, so whenever something is nearly plug and play I feel really greatful, especially when technical challenges are overcome.

Credit is due to ya and your helpers.
Sincerely, protozone.

(32-bit wine-staging; 32-bit Reaper; 32-bit FL Studio; 32-bit VST(i)'s; thanks to 32-bit MX Linux 17, Horizon; 4.14.12-rt10avl1 #17 SMP PREEMPT RT ...Sun Jan 14 00:31:51 EST 2018 i686 GNU/Linux)

Hi,

Glad to hear you're finding it useful! Thanks for sharing the PulseAudio tweaks, and your music is really good BTW, keep up the great work!!

[protozone]

Hi,
Glad to hear you're finding {AVLINUX RT KERNEL's} useful! Thanks for sharing the PulseAudio tweaks, and your music is really good BTW, keep up the great work!!

You're quite welcome. Thanks for appreciating my tunes. I just recently upgraded my studio so it should be improving.

I will try and coalate some of the other PulseAudio-related DAW optimizations. I learned some nice little tricks along the way good for Reaper, FL Studio, OcenAudio, EnergyXT and working with USB soundcards. (For example, if you turn off soundcard inputs within the software programs, CPU use goes down a lot and makes it easier to work with VST(i)'s). I just have to find a good way to upload the infos after I get them collected.

Your work is excellent, by the way. AVLINUX seems to be the first and the last and one of the best.