There are many distributions today, and all of them have strengths. There have been some relatively recent divergences in best applications. At this time we will not recommend CentOS or Red Hat on the digital audio workstation; we need the full range of current audio libraries, audio applications, and of course kernels and drivers.
For a long while, in my experiences, this generally meant the Testing release of Debian. Sparky Linux, a best-of-many-versions Debian, has also been excellent. There is an Ubuntu variant for this sort of audio too, reportedly very good, and there are others.
I have found Manjaro to be my personal best choice, because given just a touch of recompilation arcana, 'yaourt' makes it so very easy to build and install everything we need, and even optimized for the CPU at hand, including the fastest kernels available. Manjaro is an Arch superset, which is a very good thing in many ways, not the least bit being the unusually thorough Arch documentation wiki, and the growing Manjaro wiki.
Do see "desktop environment" below, because you'll want to start off as smoothly as possible. But we do need to talk about hardware.
Not all sound cards are worthwhile for us: we need low latency, which empirically means “works very well and processes its data very fast”. Having been burned by more than one sound card which were claimed to be such, I recommend care and flexibility. All kinds of motherboard sound, not surprisingly, seem to be widely supported, but any very new hardware may need a new kernel to support it (see the Kernels section below). But it's not just support that we need, we need quality.
One of the obvious items, is the sampling rate. Consumer-grade audio generally will input and output a maximum of 48 kHz. (The original audio CD sampled at 44.1 kHz.) Modern professional-grade recording apparatus will handle 96 kHz and sometimes 192 kHz. If your hardware and software and Linux setup is all excellent, I can confirm that a Mackie Onyx Artist USB interface will deliver 96 kHz very nicely, and also, I can confirm that if your patches include thready strings or smoothness, you will notice significant improvement over 48 kHz. On the other hand, I can also confirm that dozens of people in various places will demand that you recant if you claim to notice the difference. Just before the Mackie I used the 48 kHz Peavey USB-P, which does work extremely well and provides a highly protected and garbage-filtered XLR output.
There are a number of important items for audio support in Linux. Here are some practical definitions which will help you a lot in understanding what comes next.
The choice of desktop environment can make a big difference. Today we have quite a few more choices than we used to have; there have been forks. It is useful to notice that the forking happened, in part, explicitly to get away from the huge horsepower-and-memory-chomping graphics shells and fancy environmental add-ons which the very largest distro managements appear to think everyone wants. For a BNR, where we want every free cycle we can get, I heartily recommend an environment called LXDE, which can now be installed automatically by the package managers of any distro I would consider. As of recently I can also recommend XFCE4, at least as setup in Manjaro's default.
Interference is the major concern. The most common is something called gvfs, which although it is very nice to have in the general-purpose desktop, will often get in the way of smooth high-performance realtime audio, it causes cutouts in the audio called “xruns”, producing static and skips. So far I have seen LXDE use gvfs as an option, not as a make-or-break, so LXDE I very much recommend. As of most recently, XFCE4 from Manjaro likewise makes it very easy to remove gvfs.
There are many more issues which can hinder us. Anything which interrupts or inhibits the algorithmic delivery of the tonal datastream and signal to the audio hardware, and anything which unnecessarily eats processor cycles, may need to be addressed. These include certain automatic USB flash drive mounters (which is one of the functions of gvfs), PulseAudio, some Bluetooth-related items, and many others.
PulseAudio, the de facto consumer/general-purpose audio transport, is a good case in point. A number of years ago PulseAudio was a very significant gotcha on almost every distro I tried, it just would not cooperate with JACK. But the two have begun to cooperate much more. It is now possible to keep Pulse around in a rig like we are discussing here – but you will sacrifice some of your available JACK capacity. Yesterday's test showed 0.5% without Pulse, and about 5% in use with Pulse, without any applications attached. So in my production BNRs I do get rid of Pulse. But I don't have to do so anymore, because MultiJACK is much more efficient, I don't need that 4.5% to run well. If I ever build a desktop BNR, one intended to run usually as a desktop but then to be brought into "BNR mode" sometimes, I will leave PulseAudio in, and even gvfs now, the most recent build has seen both of them work much less intrusively.
There's just one tool this writer has heard of which does this well, and that's something called realTimeConfigQuickScan. It helps you find tweaks helpful and essential, though its reporting is a bit out of date at this writing.
For a very long time, a tool called "qjackctl" was the universal all-purpose tool for getting JACK to work. It is GUI, and it contained everything needed, automating every parameter of JACK (and there are a whole lot of them). However, everything changes. Today the setup tool recommended by the JACK developers, is called Cadence, and it is amazing, particularly so to those who struggled with qjackctl for extended sessions ☺ Cadence handles Pulse/JACK cooperation setup, among other things, and it comes with a wiring tool and other interesting things too.
The kernel is the root core of the OS; nothing happens without the kernel, and a significant improvement in the kernel is usually a major improvement in everything else. One major benefit of Debian Testing and Sparky Linux, is we get to use the very high-performance kernels being put out by Liquorix. These are not only highly tweaked for speed and responsiveness, but they also are using very recent kernel code versions, which means the most complete driver sets which exist for Linux, and support of the most recent hardware available. On Manjaro, 'yaourt' gives many more options, but my latest BNR build uses the default Manjaro kernel, which is set up very nicely for our needs. There is something called a "realtime kernel" which used to be helpful, but in recent years I have found better performance available using non-realtime kernels, for some reason.
If you are interested in custom kernel building, my last custom which I enjoyed greatly was linux-pf-bfq, recompiled full tickless, 1000 Hz timer, CPU optimization native.