Linux music production workflow without a low-latency kernel

Question

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. I'd also be interested in people's opinion here on whether a linux workflow for music production is more suitable for this forum, and particularly with respect to the comments on that post (i.e. regarding whether the "Music Production" stackexchange proposal should be scrapped in favour of (cross)posting here and at music.SE instead, as per the discussions on the proposal site)

Answer 1

Forum suitability: sure, this concerns music production much more than music playing, so it would seem more appropriate here.

Generic kernel will make dropouts ("xruns") more likely even when using jackd with realtime priority. The jitter introduced in Midi is not that much of an issue since signals are time-stamped in the kernel and traditional 31250bps Midi hardware comes with time lags attached anyway.

You can already improve latency issues by booting the kernel with threadirqs on its command line (no idea whether this is already standard: I've not worked without this option for years): that way interrupt response and interrupt payload are decoupled. My guess is that this will help time-stamping but not Jackd processing. However, it also gives you the leeway to use rtirq for assigning interrupt processing priorities outside of the direct hardware priorities. This can help somewhat, but not if your kernel runs in some higher-latency code path not permitting the second interrupt processing layer to kick in.

At any rate, it may still be a good idea to get rid of that Nvidia graphics card for a system used for sound processing: proprietary drivers are interested in showing gaming performance at the cost of the rest of the system and nobody will bother fixing latency issues caused by them. Your best bet are graphics cards (or much more likely mainboard-mounted cards potentially integrated with a chipset) with Open Source drivers maintained in the kernel.

That has the added advantage that the life time of driver support matches the life time of your sound processing setup better. Good audio hardware is good for decades. Also it is nice to be able to suspend/hibernate at will without the graphics card driver freezing (something that proprietary drivers are notorious for). Though you'll find that jackd with realtime priorities will postpone the system doing either while it is running.

Answer 2

Just give a chance to Ubuntu Studio. All music stuff including low latency kernel are ready to use in this distribution and you can still enjoy all advantages of debian-based distros. I use it for everything.