I would like to do some music composition on my linux mint pc, but I have run into instabilities while trying to install and use a low-latency kernel (system freezes, possibly due to conflicts with the nvidia proprietary graphics drivers). So as I see it, I have three options:

  1. Either use my current system, i.e. the normal, generic kernel
  2. Install a dedicated audio distribution like Ubuntustudio
  3. Install the low-latency kernel on my current system but disable my graphics card.

Option 2 involves repartitioning etc so I'd like to avoid that, and option 3 is pretty ugly and tedious to work with. So I would like to know, if I go with option 1, what am I missing out on by not using a low-latency kernel for music production? (both in general, and w.r.t. the linux toolchain in particular)?

If I choose to use a generic kernel for music production, what side-effects, problems can I expect that a low-latency kernel is supposed to solve? Will I not be able to use JACK effectively? Will I be able to record? Will there be a lag in my recordings? Noise / skips / screetches? Will midi input accuracy via piano keyboard suffer?

PS. This question is crossposted from music.SE as per a comment there suggesting this may be a more appropriate forum. I'd be interested in people's opinion here on whether a linux workflow for music production is a suitable topic for this forum.

  • 1
    I don't have a lot of experience with music production, but I use a PC with a standard Linux kernel as a guitar amplifier. Many people use OS X for sound things, and I don't believe that is a low-latency system
    – Fox
    May 1, 2017 at 23:13
  • 2
    I guess it entirely depends on how powerful your hardware is, and how much processing power the things you plan to do need. I've done relatively simple music production on a stock kernel with no problems at all. Just give it a try, and see what happens.
    – dirkt
    May 2, 2017 at 5:46

1 Answer 1


Your question is unclear but I'll answer some interpretation of it so that you can formulate a better question in future. I think it would make sense not to start morphing this question into something else after the fact.

The low-latency kernel will make it possible to handle interrupts and short tasks with lower latency. It's not using true real time kernel patches on Ubuntu but so called PREEMPT configuration. The idea is that without PREEMPT support, once kernel starts to execute some syscall it will not be interrupted even if hardware request comes in (e.g. MIDI command). With PREEMPT the syscall will be interrupted if needed.

If you run generic kernel which cannot interrupt any syscalls, the maximum latency you can get is the maximum length syscall any process in your system makes. As such, it makes much harder to assume anything about your latency and often the workaround is to use bigger buffers which obviously cause longer delay for your audio processing.

The kernel features needed to make that pre-emption possible cause some overhead (maybe 0-2%) in total CPU usage and that's the reason those features are not enabled in generic kernel. In addition, the pre-emption triggers some yet-unknown programming bugs in kernel more easily. This is because syscalls can get interrupted and incorrectly written kernel code may accidentally only work when that code is never interrupted (e.g. it doesn't acquire memory locks for some shared structure that's cannot be actually shared unless the syscall is interrupted but shared structure can be modified by multiple CPU cores at the same time if syscall is interrupted).

I don't know about the current situation with NVIDIA drivers but for example VirtualBox kernel drivers used to have major problems with low-latency kernels because of multitude of bugs in those drivers. Nowadays VirtualBox kernel drivers appear to work much better with low-latency kernel – I haven't seen any problems in a couple of years.

If you don't have broken device drivers and you want low latency processing for hardware interrupts, you definitely want to use low-latency kernels all the time.

I have a cheap USB attached microphone and use motherboard integrated sound card for audio out and that's enough to get well under 10 ms latency from mic recording audio to soundcard playing it out after the audio passing through the full pulseaudio stack. With better hardware you should be able to get under 2 ms latency, especially with JACK.

TL;DR: low-latency kernel should reduce your latency for all actions but it will increase CPU usage a bit. And without low-latency kernel the maximum latency for incoming data depends on maximum syscall latency of the whole system. If you're not careful about background processes you end up with sound skipping or randomly delayed MIDI behavior. With low-latency kernel the background jobs do not really matter until you run out of RAM. Unless you're doing High-Performance Computing (HPC) or mine crypto-coin you usually want lower latency over maximum CPU throughput for everything so only reason not to use low-latency kernel should be bad device drivers.

If you get audio skipping or latency problems with low-latency kernel, I'd recommend testing with open source GPU drivers (Nouveau drivers for NVIDIA GPUs) and if the problem goes away, you've found the problem.

I've been running low-latency kernel for around a decade on all my systems and I've been much happier with it than with the generic kernel.

And check your memory clocks; low-latency kernel may cause more spikey power demands for your motherboard and if your motherboard or PSU power delivery is not good enough, trying to run memory clocks very high may cause memory errors which will cause all kind of random instabilities. Try running mprime in stress test mode using at least 50% of your RAM in the background while doing other tasks - if it detects any errors your RAM is not working correctly and you shouldn't run neither low-latency nor generic kernel if you want a stable system. The generic kernel may be less demanding for the hardware and you'll see less errors from faulty memory but be assured that it will cause problems sooner or later even with generic kernel.

  • 1
    Thank you. This isn't quite the kind of answer I was after at the time of asking it, but it offers a lot of useful info which may be useful to future viewers, so I will accept it. Sep 5, 2021 at 17:34
  • 1
    I slightly tweaked the answer to underline that the syscall latency depends on all processes and if you're careful with processes running in the background, you can get pretty good results with generic kernel, too. The idea with low-latency kernel is that background tasks cannot mess with your work too much so you can run everything without tweaking so much. Sep 6, 2021 at 8:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .