Live mixing with Linux - State of the art 2018

[Nuri]

The i7-9700K was only released last month right? I would steer clear of that, it'll be overpriced and potentially might not be supported by even the latest kernel (I can't actually find anything about it in relation to linux). Get something older and use the saved money on soundcard.

yes, you're right. This CPU is "too new" on the market.
Me too, I've found nothing related to the Linux kernel and this CPU.

I've now read a lot about the currently available PC hardware. My conclusions are:
- AMD's Ryzen and Threadripper are very powerful for everything, excepted for RT audio processing --> OUT
- Intel's core i9 is obviously not supported by the Linux kernel --> OUT
- Intel's core i7-8yyyX and i7-7yyyX are powerful but expensive and the suitable mainboards are really expensive and I need to buy an extra GPU --> OUT
- Intel's Xeon are expensive (if you want a powerful one) and their features are a bit "overkill" for an audio workstation --> OUT
- Older overclocked Intel's CPU is not an option because of stability and reliability considerations --> OUT

At the moment, best choice seems to be Intel's core i7-8yyyK or i7-7yyyK.
For example, an i7-8700K performs almost as well as an i7-7820X but the whole configuration CPU+mainboard+GPU of the K is about 200-400€ cheaper as that of the X.

Other aspects of the hardware config:

The Ferrofish Pulse 16 has only line levels inputs. OOOOTCH!
That's a problem because I have 8 mics for the drums and 1 for the vocal. It's means I have also to buy 9 microphone preamps. It becomes too expensive...
I've reconsidered the new Behringer ADA8200 (with the red front plate) because it has built-in mic preamps (with switchable phantom power) and line level inputs ON EACH CHANNEL.
I've also found this review: https://www.soundonsound.com/reviews/be ... n-ada-8200
According to the link, the unit has been really improved by Behringer:

The ADA 8200 employs different converters, the new devices being made by Cirrus, and the latency through the unit is substantially lower, measuring just 0.55ms at a 44.1kHz sample rate (compared with 1.46ms for the old ADA 8000).

I think this is only the input latency, but I'm not sure.

[sysrqer]

I've now read a lot about the currently available PC hardware. My conclusions are:
- AMD's Ryzen and Threadripper are very powerful for everything, excepted for RT audio processing --> OUT
- Intel's core i9 is obviously not supported by the Linux kernel --> OUT
- Intel's core i7-8yyyX and i7-7yyyX are powerful but expensive and the suitable mainboards are really expensive and I need to buy an extra GPU --> OUT
- Intel's Xeon are expensive (if you want a powerful one) and their features are a bit "overkill" for an audio workstation --> OUT
- Older overclocked Intel's CPU is not an option because of stability and reliability considerations --> OUT

At the moment, best choice seems to be Intel's core i7-8yyyK or i7-7yyyK.
For example, an i7-8700K performs almost as well as an i7-7820X but the whole configuration CPU+mainboard+GPU of the K is about 200-400€ cheaper as that of the X.

Of course you can't go too wrong with getting a super fast (and supported) processor but if you are only live mixing I don't think you would need anything that special, I'm sure most i7s or higher end i5s would be fine. I have a Core i7-720QM (I think this is it, not at home right now but it's one of the ones that came with the HP EliteBook 8540w) and I can mix many many tracks with tons of plugins on them yet it's a pretty old processor.

[Nuri]

@ sysrqer

mmm.. when you want to reach 32 samples buffer for minimal latency, the CPU load explodes very fast (even without Izotope or convolution reverb plugins).
If 16 samples are feasible without xruns, I will go for 16 samples .
For these goals, I think a high end core i7 is mandatory, but I could be wrong...

If the whole system has a perceptible latency, the other members of the band won't want to play with and will claim:
"bring our Soundcraft Ui24r back!!!"
It's as simple as this, sadly...

[sysrqer]

Yeah you're probably right. Well let us know how you get on, I would be curious to see what you end up with.
I could be completely wrong but I wonder how realistic it is to do in 16 or even 32 samples buffer.

[CrocoDuck]

Hi there! Interesting discussion. Just dropping by to share a link about a post on latency I written on my blog:

https://thecrocoduckspond.wordpress.com ... ive-study/

It contains a "review" of a scientific study of latency perception, and it is the last of a series I written on the topic. It is very long, and perhaps boring, so maybe I will do a final post to wrap the entire series up, but towards the bottom you can see a table summarizing the latency perceptions thresholds. The result of the study suggest to me that in most situations a latency lower than 5 ms will be overkill. Perhaps not the final "truth", but most likely a good rule of thumb.

[Nuri]

@ sysrqer

I will start a campaign of tests in the next weeks. My plan is clear now. Thank you all for your comments and suggestions!

I will borrow a complete PC (with i7-8700K) and buy 2 Behringer ADA8200 (that I can return if the results are not satisfying).
I've already found an used RME HDSPe Raydat on €bay Germany. It comes tomorrow home .
On the SSD, I will dual boot Windows 10 and AVLinux (it could be interesting to see the differences in behavior and latency...).
Both operating systems with Reaper and its built-in VST and JSFX plugins.
Maybe some Airwindows plugins too, as they are available in VST for Windows and for Linux.
That's it!

Now I'm thinking about the whole routing in Reaper. It's not easy at all...
It's crazy, almost everything is possible

I will post here the results of the tests (obviously only in rehearsal).

@ CrocoDuck

ha ha!
I have already read your blog. Not everything but the most important parts.
Your blog was the core of my plan and I read it before I posted here a new thread.

5ms ROUNDTRIP latency is still a huge challenge. Of course without xruns...
About 1ms is stolen from the A/D and D/A conversions. It remains only 4ms for the CPU. It's very tight.
And I've not considered the latency produced by pre-processing devices for the bass and the guitars (Line 6 Helix and Kemper). Ok, it's not huge but it will be added in the total latency sum.

I'm afraid that the perception of latency becomes more accurate when it comes to in-ear monitoring.

[Nuri]

Ok, short info about the current status:

- the RME HDSPe RayDat is here
- the two Behringer ADA8200 are here
- iso of AVlinux is downloaded
I'm still waiting for the i7-8700K Workstation to be delivered...

On the software side, I've decided to only use Reaper built-in plugins. They can do everything I need and want.
I've discovered the ReaVerb plugin and downloaded some free impulse responses. It's awesome .
Don't know why I've always overseen it in the past... Maybe because I had to read the manual of Reaper to understand how this plugin works .

I'm always impressed of what Reaper can do out-of-the-box.
The Linux release seems to be really stable while it's still tagged as "experimental".
I directly asked Justin Frankel about this:
https://www.askjf.com/index.php?q=4454


I found also this:
https://www.askjf.com/index.php?q=4443

...In the studio I have a Q9400 (2.6ghz, 8GB RAM maybe?) running Linux for recording, using a RME HDSP 9652 (PCI card).

I can not be on the wrong way...

[Nuri]

Still waiting for the workstation...

But a question since I can not found so much informations about this topic:

There are several Linux distros running completely from RAM, like Knoppix, Puppy Linux, etc.
There is also the well known Studio 13.37 distro which claims to be the best thing in the world for audio processing (or something like that...) and it is "designed" to run from RAM.

Can achieve a Linux OS running from RAM better real time performances than an installed Linux OS?!?
(I'm mean in terms of audio latency, buffer size, xruns...)
If yes, why?
If yes, why are not all audio Linux distros (KX, AV...) tuned/tweaked to run directly from RAM?

The question came to me as I discovered this commercial distro (which also can be boot into RAM): http://www.audio-linux.com/

[Jack Winter]

Running from RAM would minimize any bottle necks related to disk i/o. I don't think it could in any way lower usable audio latency though. Please let us know if you test!

Probably useful to have a usb stick that loads the OS/DAW into RAM for using on any computer you come across.

[Nuri]

Hi again
Ok, here are the results of the first tests!

I have not already tested the system with the whole band. I've only made some "dry runs" :
- building the RME HDSPe RayDAT in the workstation
- installing Windows 10 and KXStudio (dual boot)
- configuring Windows audio and Cadence (jack)
- installing Reaper
- loading test project in Reaper, playing the audio tracks
- looking at the performance meter of Reaper

The tested hardware is:
- Intel CPU i7-8700K
- ASUS mainboard Prime Z390-P
- 8GB RAM DDR4-2400

The Reaper test project contains:
- 54 tracks (22 for main mix and 32 for in-ear submixes)
- 49 effect plugins running on the main mix tracks
- 14 audio tracks (old recording of a rehearsal session)
All plugins are Reaper's built-in VST and JSFX. This way, it's much more convenient to compare the results among the different operating systems.

First, I had installed AVLinux but the RT performance was not good, so I decided to install KXStudio.
It's surprising to notice that Windows 10 performs everywhere better than AVLinux and KXStudio.

Here some screenshots showing the same Reaper project running in Win10 and in KXStudio.
The RME HDSPe RayDAT is set at 48kHz, 24bits, 32 samples buffer, 2 periods.

[Nuri]

I'm a bit disappointed about Linux

I've made absolutely no tweaks in KXStudio. I use it as "vanilla" as possible.
I've only configured Cadence.

In Windows 10, I've only disabled some GUI effects and some services related to firewall, anti-virus, update...
I've disabled systems sounds and I've set the priority on "background services", instead of "programs".
I've installed the last RME driver and I've flashed the audio interface latest firmware.
That's it!

Xruns are literally raining in KXStudio at 32 samples. The same with AVLinux.
In Windows 10, I've encountered 0 Xruns. Never, not only one, also at 32 samples.

Both Win10 and Linux are not able to play anything in 16 samples buffer.

I think the rest of the tests is no more related to Linux anymore...
Should we close the topic?
I'm not really interested in more Linux tweaking, since it never ends (according to my experience).
The system seems to run very good with Win10 and it's ok for us.
On the next Wednesday, I will try to play with the whole band and not only playing back audio tracks.

[folderol]

You may want to check up on this, but I was told that Microsoft plays games with what it calls 'buffers' and 'latency'. I can't think of a practical way to test this, unless you have another system to measure and compare the overall latency of both.

Edit
I frequently run complex 12+ part songs that are entirely generated algorithmically on-the-fly at 64 frames (2.67mS latency), most of them would run at 32 frames, but why bother?

[Michael Willis]

literally

[JamesPeters]

I wonder if your kernel is using more CPU than necessary to keep Reaper operating stable and at as low a latency as possible.

Here's my story:

When choosing a distro, I wanted it to be "not heavy-weight" ("lightweight" distros might be a bit too slim on options, but I didn't want a "bloated" one either or one that used more resources for graphics), it had to be relatively well-maintained (which ends up meaning: relatively popular) so it would be updated for security fixes and also I won't have to "swap" distros often, have access to more repos (so I wouldn't be waiting "forever" to get the latest version of something, or have to install flatpaks much), and I wanted to avoid Ubuntu-based distros based on what happened with Unity in the past (that's me being overly picky, but it left a Microsoft-flavored taste in my mouth). AVlinux and KXstudio were recommended but it seemed they both didn't meet a couple of those goals of mine (I say "seem" because I'm only going by what I read on forums...I'm new to this, so no offense to those distros!)

I chose MX Linux. It also allowed me to try low-latency kernels from the repos (as well as other kernels), so I figured let's give it a try.

After doing some tests with Reaper's own plugins in Windows 7 and saving my results, I migrated to MX Linux (in October) and then did the same tests. My audio system of choice in Linux is ALSA (since I have no need for JACK).

My audio card was capable of lower latency than in Windows (with manufacturer-specific ASIO driver), using the stock MX Linux kernel, so that's a bonus I didn't expect. Also my CPU usage in these tests (apples-to-apples, Reaper using its own plugins) was more efficient by around 30%! I didn't pay attention so much to the CPU usage at first because I could just "load down Reaper" and see "when it started to break up". Even if my CPU usage meter in Windows wasn't close to 100%, I could get dropouts, so I knew it wasn't all about whether it showed 100% usage or not. In Linux not only could I push the CPU right to 90% with no problems at all (stable, smooth, no dropouts), I could see more even loading of the cores/threads (in Conky, etc.) compared to in Windows.

In Linux I did have to set my CPU frequency governor to "performance" (so it wouldn't "throttle down" to a lower speed), something akin to what I'd done in Windows' "Power options" using the "high performance" plan. But that was it, no further tweaks necessary. (I did have a graphics issue so I had to tell MX Linux to use the Intel-based driver for my onboard GPU, but that was something I figured might happen, and it didn't affect the performance in Reaper anyway.)

After some more testing I decided to swap kernels. First was Liquorix, for low latency use (or so I'm told). I did the necessary changes to ensure it would work for low latency (a couple changes to limits.conf). I tested after I did that, before swapping kernels, and I saw no performance difference (there might be, but it would be only at the very edge of my CPU when pushed to its limit). Then I installed Liquorix and rebooted. During my test in Reaper I noticed it was about as stable at high CPU use, but it didn't allow me any lower latency for my audio device and it actually increased my CPU usage noticeably (around 15%). I swapped back to the stock MX Linux kernel, and confirmed this. Later I swapped to an AntiX kernel (since it's updated with the latest Spectre/Meltdown mitigations and the stock MX Linux kernel currently isn't), and I did the same test. The AntiX kernel performed on par with the MX Linux kernel. Later I updated the Liquorix kernel and tested it again. I got the same results as before.

I've also tested all these kernels with Reaper using JACK and got virtually the same results.

My takeaway, as anecdotal as this is: I don't think I need a specific low-latency or realtime kernel. The one I did try only seemed to increase my CPU usage. I can't say why, but there it is.

Also: did you set your CPU frequency governor to "performance" (or at least check that it is)? If not, I'd recommend it.

I hope you can use this info somehow, maybe it points you in the right direction.

PS. a great reverb which is also very reasonable on CPU: Dragonfly (try that latest/experimental version, since it allows for 10 second-long decays!)

[Drumfix]

@Nuri: Please upload the reaper project without the samples of the audio tracks. What looks odd at first sight is that reaper's own realtme code requires twice as much CPU on Linux as on W10. And why on earth are you using jack?