Hey people. I’ve just come around another thread, and found info on how to make a Linux system ready for realtime audio performance a bit lacking.
I don’t know what audio optimizied distros preconfigure in this regard. But you can make many other distributions realtime ready with a few tunings.
There are already some rather nice pages on this like https://wiki.linuxaudio.org/wiki/system_configuration, but I think it’d be cool to have a more simple guideline on what methods to try to make a machine ready for stable realtime renoise action.
For beginners: Latency is the delay between keypress or mic input and the sound coming to the speakers, a ling delay sounds and feels unnatural, a short delay feels tight and alive. But short delays need more processing power, and if other programs or drivers can jam up the cpu time, you get crackles and dropouts in sound - ideally you’ll want none at all until the cpu is burdened too much.
So if you get these crackles and dropouts and just want to quickly fix them, just set the buffer sizes in the sound settings higher until the sound is glitch free again. The other programs can only jam for so long, and if you set the latency higher you will have good sound again. If you want to get tighter, you must tune your system right.
The latency is the delay between the action input or the event cause in the program, and the sound becoming audible. So a latency of 20ms means, when the computer processes/triggers your sound, there will be a short delay before it becomes audible. If you press a key on your keyboard, there will be an additional short delay before it triggerst the sound processing. If you use a microphone, you have a second latency like the first, it must first be read into the computer with a delay, then the computer can process the sound, and the same delay is needed again to make audible the processed result.
This is important if you want to use your computer as a realtime effects device or instrument, i.e. for singing or for playing a guitar or bass or keyboard live with it, letting the computer make the sounds by processing with VSTs or using programs like renoise.
To make it simple, the shorter the latency is, the tighter and snappier and more “live and real” such live action will feel for the artists. If there is a long delay, it will all feel unnatural. If it is a short delay, it is better. If it is real tight (<10ms), for example a guitar modling software can feel like a real live amp. A short latency makes all live audio feel tighter for the artists.
The latency is what you tweak with the buffer settings for the sound card output in renoise settings or in the jack settings. It if defined by the buffer length - The longer it is, the longer is the latency. Usually people use powers of two (64,128,256,512,…) and the delay is calculated with the buffer length divided by the sample rate, so at 44100 khz a 1024 sample buffer means a delay of ~23ms, but if you then use 2 buffers, you are already at 46ms, because the buffers add up.
Here’s what I do on Ubuntus and it probably applies well to other distos, as well. Some steps are straighforward to give more stability, others only work when you have specific hardware problems.
Each step can have the potential to make the system a little more realtime stable. I think I will write them in the order that you may apply them or try applying them when tuning a system until you’re satisfied. You should test your performance i.e. with cyclictest after applying more specific steps each time you change something in your system.
The first 4 steps I’d always apply first are:
- stop all background (user or decorative) programs you don’t need. You can run other tools, but try to avoid unnecessary candy or other ressource-intensive programs.
- Activating the RT priorities, rtprio+memlock, this is distro specific i.e. with dpkg reconfigure or manually in limits.conf or with another package manage, or sometimes it can be done while installing things like jack
- The next vital step is turning off CPU frequency stepping. Each time the CPU switches, the realtime audio can get corrupted due to the delay. I use the command
cpupower frequency-set -g performance(orcpupower frequency-set -g powersaveto disable), and put it into a suoders enabled script that is executed before starting the jack server (and another one after closing it down to reset the tuning). Take care with this step, only do it on a system that is safe to run at thermal load. You may have to or want to use other programs that cpupower, or use different frequency mode names. On older systems of Ubuntu it may have been necessary to disable a daemon in Ubuntu that would reset the CPU to ondemand or powersave, you can do such things in the same script. - The last important step seems to be file system/sata driver related, on many systems with ext4 filesystem I need to put the mount options of the system drives (root) and other physical drives the system is using during audio load to “noatime”, else the system will have a lot of dropouts. It seems it is the “jdbx” task locking up the interrupts which causes the dropouts.
If there’s still a heavy latency penalty, rtirq, and a realtime/lowlatency kernel might already make the win from here…
General tuning means not allowing intensive jobs running in the background of the computer. Uninstall or stop automatic tasks that eat your CPU or do background processing. You can do this (turning on and off) like I do in the script that would switch CPU scaling when starting the audio server. I of use my PC and internet for other tasks or to assist tracking while running renoise, but it’s better not to let it do other demanding things at the same time.
After this tuning, I’d test the system, it should already be much more stable. The next steps depend on what kind of system you are using and your hardware or kernel. Sometimes these things only make sense, when you’re sure of what you’re doing and when you’re doing it right.
- Use a tuned kernel, lowlatency or realtime…sometimes it will help very much, sometimes, if the culprit is some odd hardware misconfiguration or incompatibility it may seem that it doesn’t help, at first
- You can always try disabling certain devices like wifi or bluetooth, especially external dongles or connected devices if you are using an USB sound card. Howerver the next step can address issues coming from this while still allowing other devices being used
- The rtirq script is something very good when you configure it right, and it can become even more powerful if you use a proper lowlatency or realtime kernel that would support such action. You need to put your sound card interrupt high up above the priority list, and put anything nonvital related to hardware to sound processing below the audio threads of the sound program and also below the audio server (jack…). If using USB, you may have to tweak and poke a little, even disabling devices, to find that magic USB jack that is not jammed up by other devices and that you could individually priorize to get a stable sound
- maybe you can also have performance gains if you configure even more aggressive file system tunings like disabling journaling or using alternate file systems. I find noatime usually already cuts this well. You’ll see if you monitor latency, when a lot of file system related tasks break the realtime audio you need to do more about it.
- graphics drivers often come in multiple flavors, i.e. proprietary and open source. If you find you have the choice to use either without drawbacks, or have problems with one of them, you might find that using the other one can give you a better realtime performance. Also there may be different graphics driver options that can affect the realtime performance, so this is also a place to investigate if the driver makes problems. Also try to disable needless eye candy, heavy visual desktop fx etc. Yet nowadays moderate FX shouldn’t be a problem until you want to go real low latency.
- You can try to disable further CPU speed stepping or sleep modes, to reduce the amount of lag due to CPU spikes. Somtimes this can be done in the bios, or with special tools. Take much care with this what you do, so you don’t mess up your CPU scaling or overheat devices not cooled well enough. Even if you use a system of full throttle with audio only giving it a low load, there may suddenly come situations where all cores are maxed for a while (rendering etc.), and then you need a pc that keeps cool. Keep checking the lm-sensors!
So this is what I found are the most vital steps to try. For troubleshooting when unexpected problems occur (xruns keep rolling in despite all rteasonable tunings done), then you need tools to investigate the problem.
The latencytop, cyclictest and hwlatdetector, and similar are way better than just starting jack and looking for the xrun counter, or even just using alsa and listening for gaps. If you know a hardware/system latency by long term realistic measurements in µs, i.e. 1200 or 260, then you know that there will be a possibility for hardware dropouts as long as that number of microseconds, i.e. there will be 1.2ms dropouts, or 0.26ms. This is the numbers that tools like cyclictest or hwlatdetector spit out. This means, i.e. for a latency of 5ms, you have to assume that the CPU can only handle so much load until the operation would be interrupted by a stray or regular latency dropout that is i.e 1.2 or 0.26 ms long. So the lower the measurement, the better the system is and the lower your latency can go.
Cyclictest measures how well your audiothread can process. Hwlatdetector measures if there are system calls (SMI) from the BIOS, which the operating system cannot see. This is stuff you cannot interrupt, so if you have long SMIs, then you have to either tweak the BIOS, or you have to swap the hardware or use a different system, if the SMIs make it too unstable and when you cannot resolve them. This is why some machines can be better for realtime load than others, i.e. workstation computers might fare better than some cheap consumer gear. Somtimes you have odd situations where it’s the other way around, then a cheap PC is really good, while an expensive one decides to calculate lots of system optimizations in BIOS that break your realtime performance…
tools like latencytop then again can help you finding certain tasks that jam up your system, i.e. when you find some “jdb” threads blocking everything, then you may know that the file system driver is jamming things up and you need to tune or disable atime or journalling, or it may be a thread related to another user space process locking the system for too long.
The last and ultimate rabbit hole when you cannot find the culprit is stuff like ftrace/trace-cmd or perftools i.e. perf sched. This is stuff you need deep knowledge for, but if nothing helps, it may help you debug the kernel and find the kernel/driver module/thread that locks up the interrupts for too long so your sound gets jammed up (and cyclictest will show you by how much…). Sometimes it’s literally individual drivers, and changing options, the driver, or disabling or reconfiguring some hardware can help things. Sometimes it’s and upgrade or downgrade, or you need to fix it with kernel command line options enabling or disabling the culprit. Stuff like this already helped me fixing it by identifying file system tasks (atime) and graphics driver issues as culprit for bad latency stability. I don’t know how many people would go as far as baking their own kernel to fix a problem, I already did this to enable options that would help identifying the problem (ftrace options).
So this has still become a quite lengthy post, but I hope it can help others to make their system more realtime stable. I think you can drive renoise down to 5-8ms latency in jack, but then renoise itself can make problems and cause xruns. You can definitely get a system down to like 1 or 2 ms if you tweak it hard enough and the audio software you are using is not too intensive and optimized well (renoise is not fit for this yet, I believe…). This goes especially for recording or realtime effects applicatoins. I’d rather stay withing 4-8ms to stay safe, because else you need a really stripped down system and still risk hickups when you use more intensive recording software. The lower you go in latency, the more CPU the audio processing will eat. That’s the price of having a low latency.
If you have some experience with tuning your system and want to brag how low it gues, when you know other vital steps to do or consider, or other tools or methods to help tuning or identifying culprits, please post up here. Linux systems tweaked right can give you this solid ship that never breaks and that drives sound like a rocket. A linux system will not do random junk in the background, and even if it does, you’ll be able to find out how to disable this. Keep it rocking! 