Unubtu20.04 /linux-image-5.x-lowlatency, useful or not?

[dailybug2]

With JACKD I had a lot of XRUNs, but I managed to eliminate most of them with the tweaks I found in the web:
- Plug USB interface to different USB of PC
- disable some BIOS features
- uninstall Linux daemons useless for audio
- disable all vulnerability mitigations (kernel command line mitigations=off); probably not related to XRUNs, but gives nice extra performance anyway
- add to group audio and check /etc/security/limits.conf
Now there are few XRUNs left @ 128/3 frames/buffers with latency ~9msec. XRUNs occur at irregular intervals now like 1 in 1..10 minutes.

Does it actually make sense to switch to the lowlatency kernel? In the web you can find any answer you like. Most of the statements refer to older kernels and nobody states explicitly that the lowlatency kernel resolved an issue. Does anybody have experience with this?

(MusE 3.1 @ Ubuntu-20.4 @ i5-3470, 16Gib RAM)

[Openmastering]

First of all, xruns are not to be taken this seriously except if you record/overdub. Having a low latency is not having better sound.
The lowlatency kernel will help you getting lower latency if you want to. Though the normal kernel can cope quite well with not too heavy projects.

Just install it, try it and you'll see.

[dailybug2]

First of all, xruns are not to be taken this seriously except if you record/overdub.

Yep, I do record and the blips are in the recording too! Not so often, not really a showstopper.

The lowlatency kernel will help you getting lower latency if you want to.

Nope, "lowlatency" at kernel level should reduce the preemtion-disabled sections within the kernel, without effect on the average audio latency. A lowlatency kernel could reduce the peak (kernel) latency which causes the XRUNs.

Just install it, try it and you'll see.

My concern: 1) install 2) nothing good for 3) uninstall 4) serious trouble 4) reinstall PC

[sysrqer]

It's very easy to install and/or remove the low latency kernel as it is in the Ubuntu package manager. Just use your package manager or apt and you will be fine.

[merlyn]

If we use a car analogy -- you put new shock absorbers in your car. Then you drive it and ... there's no difference. "That's a load of rubbish about shock absorbers," you think. Then you do a bit of internet research to find out how you managed to get ripped off, and you find these shock absorbers only make a difference when you're going at 100 miles an hour. You never go at 100 miles an hour, so they were a waste of money.

I've got a real time kernel, and when I first booted it ... there was no difference. But when you push the system it makes a difference. I would think it's the same going from a stock kernel to a low latency kernel.

[dailybug2]

OK, installed linux-lowlatency and got kernel 5.4.0-40-lowlatency which boots without issues.
Tested ~15 minutes playing a 1-bar loop in MusE with MDA-ePinao and 2 LV2 effects, Calf chorus and plate reverb; not actually challenging.

Result: 1 XRUN after ~5 minutes - no change, as expected. Probably a BIOS issue and/or something with the beloved Intel Management Engine.

Of course I will use the lowlatency kernel from now on; may it be good for something, probably if there are some more synths / audio tracks / effects.

[khz]

Real time is a question of timeliness, not speed. As long as the system complies with all time requirements, the so-called deadlines, it does not matter whether reactions occur within a second or a millisecond. Despite this definition, however, it has become commonplace that users of real-time systems expect worst-case latencies in the micro- or at least the lower millisecond range.

Latency is the time that elapses between the triggering of an event (interrupt) and the start of the associated interrupt service routine (interrupt latency) or the computing process (process latency). If strictly interpreted, the manufacturer must prove that his real-time operating system complies with the latency time specified by him under all circumstances.

https://www.linux-magazin.de/ausgaben/2 ... chtzeitig/ - Translators https://www.deepl.com/translator

In other words, a lowlatency / RT kernel guarantees that a process is executed in a certain time. If the kernel does not manage this, it has failed.
Install via the package manager and test a lowlatency / RT kernel, this is useful because it guarantees a jitter-free audio process.

All optional audio optimizations (see for example links in my signature) reduce the audio latencies. Test what makes sense and is best for you.
Good hardware is of course the basis of everything!

[dailybug2]

Humm, I know exactly what the definition of "real time" is; this is my job btw. I was rather asking if someone actually reduced the XRUNs with the lowlatency kernel. PC-Desktop-Linux will never ever become a true realtime system!

But: IN THE MEANTIME I MANAGED TO GET RID OF ANY XRUN! NO XRUN AT ALL! NIENTE! NICHTS! NADA!

And this is what did the trick, after one more hour of googlemania: Do use the linux-lowlatency kernel
AND
add kernel parameter "threadirqs".

This is the setting in /etc/default/grub:
...
GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off threadirqs quiet splash"
...
And then do the "update-grub" as ROOT user.

mitigations=off just disables the mitigations for Spectre, Meltdown and friends, which are slowing down the system a little. I'm not running a server.

Explanation: The default setting of the lowlatency kernel does not enable the preemption points in the interrupt service code of device drivers because some drivers may malfunction or crash. The kernel parameter "threadirqs" enables this preemption points and the Linux kernel becomes a little bit more "realtimey" this way, enough to get rid of the XRUNs (on my PC).

[Toejam76]

Great it worked out for you. I used this script (perl)to diagnose what tweaks are needed : https://github.com/raboof/realtimeconfigquickscan
The Ubuntu Studio repository has a useful package (ubuntustudio-performance-tweaks) for this.
I still had xruns after doing everything and it turned out that the wlan card was causing it.

[dailybug2]

... The Ubuntu Studio repository has a useful package (ubuntustudio-performance-tweaks) for this.
I still had xruns after doing everything and it turned out that the wlan card was causing it.

Thanks for the info; I'll try this Perl script, just for curiosity.

The web is full of relaltime voodoo stuff, mostly outdated or dedicated to some very specific issue not related to the actual problem you have. "You must use a realtime kernel". "It is not necessary to use a relaltime kernel, lowlatency is sufficient" (but no info about "threadirqs").

Should there be all the necessary information somewhere on one web page ... you never will find it because Google rates the outdated stuff much higher. Well, welcome to the internet

[christobal]

Should there be all the necessary information somewhere on one web page ... you never will find it because Google rates the outdated stuff much higher. Well, welcome to the internet

Maybe a curated pinned topic in here could be an idea?

[khz]

I also find it difficult to find well-founded information about the current state of this topic on the internet or here in the forum.
My dream would be to collect all this information and then update it here in the forum as well as on the wiki's and so on the internet.
But my technical background knowledge is too small to make provable statements here, so I hope for you.
These were my ideas:

• How much RT optimization is still needed? >> viewtopic.php?p=121734#p121734
• Wiki update >> viewtopic.php?p=98325#p98325

Feel free and participate.

Here I have written down a few things because I hardly have a complete overview of this topic:
GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info >> viewtopic.php?p=30105#p30105

[dailybug2]

Yes, It would be extremely helpful if the MusE docu would provide up-to-date information about the necessary Linux system tweaks. I must admit that this is a challenging issue, mostly because of the variety of different Linux systems.

The script https://github.com/raboof/realtimeconfigquickscan is extremely useful to show remaining issues. In my case it shows that there are issues with the accuracy or RTC and timers.

The packet ubuntustudio-performance-tweaks seems to install some tweaks, but it is "heavily incomplete". At least a step in the right direction.

Btw; my problem is the time wasted with this configuration issues, not the knowledge.

[khz]

There's also the music-daw >> viewtopic.php?p=121543#p121543 >> https://github.com/joao4linux/music-daw which is kindly developed by @basstrombone and a friend of his. THX!
There is also a lot of potential in it if you critically adapt the music-daw to the current state.

Btw; my problem is the time wasted with this configuration issues, not the knowledge.

Full agree!

[sdel]

Hi all,

I'm a newcomer. Correct me if I misbehave.

I'd like to optimise my lowlatency audio (for internet rehearsal mainly). I have followed many of the suggestions on this and other forums.

I have xruns every 2-5 minutes. Please suggest anything I could try to reduce them.

Dell 7390 Laptop, Intel Core i7 8650U, 16GB RAM.
Focusrite Scarlett 4i4 (3rd Gen)
Xubuntu 20.04 with kernel 5.4.0-51-lowlatency
Kernel Parameters: ro quiet splash threadirqs mitigations=off intel_pstate=disable vt.handoff=7
Buffer settings: 128 frames/period, 3 periods/buffer

I used github.com/raboof/realtimeconfigquickscan, and I pass all tests ("good" in all cases).

Other things I tried:

• Noatime
  Wifi disabled
  Networking disabled
  Frequency scaling disabled (as shown in kernel parameters)
  Spectre / Meltdown mitigations disabled,
  Hyperthreads disabled
  Swap disabled
  Huge pages disabled
  Numa balancing disabled
  Kernel Samepage Merging disabled
  echo 0 > /sys/kernel/mm/ksm/run

Last resorts I have not yet tried (because I use this laptop for other things, and other people get good results without them):

• Realtime kernel
  isolcpus parameter combined with careful CPU affinity for IRQs and software.

All suggestions welcome. I may have forgotten some things I tried - I'll update if so.