Live mixing with Linux - State of the art 2018

[Musicteacher]

The problem with standalone jack-apps is, that the jack-graph gets really huge.

I would not want to do without lv2-plugins. For me, the most important plugin is pianoteq, that's lv2.

Also, for me this setup is for rehearsals and small gigs only. For really big concerts (we are a school with emphasis on music) with orchestra, brass-ensemble and big choirs, we have a professional PA-technician.

So it is not likely that I will upgrade my setup. Maximum would be 3 guitarix-instances + one synth plugin (and effects), I will try if this is possible. If not, the guitar sound will have to come from standalone devices.

Does your windows-based setup work now?

Regards,

Andreas

[Jack Winter]

FWIW, Pianoteq is available in the linux vst format.

[Nuri]

@ Musicteacher

The problem with standalone jack-apps is, that the jack-graph gets really huge.

Ok, but it should only be a problem the first time you set everything up. After that, you can load a preset config and you're done.

Maximum would be 3 guitarix-instances

Sadly we cannot use guitarix on Win10 but i could not imagine running 3 instances of Line 6 Helix Native to process 2x guitars and 1x bass signals.
It would be way too heavy for the CPU. And I'm already struggling with a high load produced by VST plugins.
So, I think guitarix should be a really good and efficient amp simulation.

Does your windows-based setup work now?

Yes, at 128 samples buffer size, where latency become slightly perceptible over in-ear monitoring.
Until now, I can not more optimize the setup to run at 64 or even 32 samples.

Another idea would be to build a Hackintosh since the hardware we purchased (i7-8700K + ASUS Prime Z390-P) should be macOS compatible.
I'm currently writing from an iMac (mid-2017, 21,5" Retina) with Ubuntu 18.04. Sadly, I've completely removed macOS from this machine since I thought I will never need this OS...
Technically speaking, it means that I cannot create a bootable USB stick with macOS. I would have to reinstall macOS on the iMac and then Ubuntu again...
It's too much work only to "give it a try" and see if macOS performs better in this situation.

[Musicteacher]

I have done some more experiments with pianoteq alone.

I started with my normal kde session. If I go at 64 samples (3 periods) at 96 kHz or 32 samples at 48 kHz, I get the occasional dropout. (every minute or so)

Then I started an ICE-WM session as an alternative.

Here I have no dropouts at this latency. So there must be a background-process from KDE that brings Jack out of sync from time to time.

So for my next rehearsal I will use ICE-WM.

If I use 16 samples 48 kHz I can still play single notes with not dropouts, but as soon as there is a little polyphony, pianoteq stops with an error-message (thousands of xruns).

So, this shows: 32 bit / 48 kHz latency is possible with a cheap usb 2.0 device, when there is not-too-high audio load (though I used maximum polyphony on pianoteq, so it was not extremely low).

The question is: How does this scale for faster computer / more cores / more input / more effect?

If all of this was a c++ program, I would use a profiler (I used to do realtime graphics programming), but I would not know what to do in a complex setup like this.

@nuri: Which desktop environment did you use for your experiments?

[varpa]

Getting x-runs is only weakly affected by processor speed. It is much more a problem of having background processes wake up and do some scan, for example a wifi network scan. So you should disable all unneeded services. Actually, I sort of wonder why people are so obsessed with running at absolutely the lowest latency. I can run Pianoteq with no xruns at 48k 32k 2 periods with AVLinux and a firewire interface which is 1.33 milli-sec (ms) latency. But that is ridiculous, I can't really detect latency below 10 ms. I usually play at 5 ms or 10ms which gives a bit more DSP headroom (which lets me play things other than Pianoteq).

[Musicteacher]

In my case it was just easier using one virtual instrument and go for extreme low latency to detect problems (in this case, as you said, there were background processes, but not network, which was off) than testing this at the rehearsal.

For me when playing piano or guitar, everything up to 128 samples / 3 periods feels really snappy. 256 samples is still usable (it depends on the sound and the song, of course).

In the case of nuri, I wonder if the (presumably very low) latency of the guitar-amp-simulation adds up to the latency of the audio-system and thus makes the 128 bit buffer seem bad.

Also, it is interesting from a techncal point of view if lowest latency is possible with a complex setup. I would sure be interested where in nuris case is the bottleneck that prevents 64 bit from working.

[Nuri]

@ Musicteacher

@nuri: Which desktop environment did you use for your experiments?

First I tried KXStudio (the distro, not only the repos), that is KDE4 desktop environment.
Then I tried AVLinux (XFCE) and I ended up with a stock Xubuntu (XFCE) coupled with a Liquorix RT kernel.

In the case of nuri, I wonder if the (presumably very low) latency of the guitar-amp-simulation adds up to the latency of the audio-system and thus makes the 128 bit buffer seem bad.

Sure!
I think something between 2 and 5ms is added to the computer latency because of the external pre-processors (Kemper & Line 6 Helix), the AD/DA conversions and the in-ear preamps with radio transmitter.
It means that the computer should process everything in less than 5-8ms to stay below 10ms roundtrip latency, which is ok to play through in-ear monitoring.

[merlyn]

The DSP Load went up to 30%...40% (never over 40%) on my Core I5-8250U (4 Cores, 8 Threads).

While this is useable , I think it would not be possible to do very much more with this setup (like 16 Channels with individual effects, for instance).

My current thinking is that you could get twice as much out this system. If what you had takes up 40%, then you could get twice as much and take the DSP load to 80%. This is based on the assumption that the number of tracks, plugins and instruments has a linear relationship to DSP load. This is complicated by the fact that the DSP load reported by JACK is an average taken over 60 samples. However, if 40% is a maximum, then it should be possible to get to 80% with a good margin.

One thing I have heard is that hyperthreading isn't good for a realtime system, so you'd be best using 4 cores without the virtual threads. I don't have a processor with hyperthreading, so I can't speak from experience. Your results seem good, so maybe you've disabled hyperthreading already.

[Musicteacher]

Interesting.

At first I thought this must be nonsense (switching off hyperthreading), but I did some research.

You are right, it is generally recommended to turn it off for realtime applications (at least on linux). See here: http://linuxrealtime.org/index.php/Hard ... -Threading

The reason (if I understood correctly): The linux kernel abstracts the hyper-threading such that the application sees 8 cores even if there are just 4 real cores. There is no possibility for the application programmer to distinguish between a real core and a virtual core.

If a realtime-thread and a lesser priority thread run on the same physical core, the lower priority thread can interrupt the realtime thread - even if it shouldn't.

This way with hyperthreading on, your system might show a lesser dsp-load, but you will still get more xruns. If you search the internet, you will find that people get different results, I refer to this post: http://mixbus.harrisonconsoles.com/foru ... l#pid41054

I will try, for sure, but not right now. Thanks for the input!

[khz]

@Nuri
An attempt would be to contact Adrian Knoth (a RME ALSA ~contact person) via mail and together solve the problem, possibly via ssh.
Mail address see links. Kernel 2.6.39 :: 3.12

[Musicteacher]

Short update:
For this evenings rehearsal, I used
48 kHz, 64 bit buffer, 3 periods (jack showed 4 ms latency).

I switched off hyperthreading and used icewm instead of kde (which is my normal desktop).

I used 6 channels out of 8, pianoteq, compressor + eq + cabinet simulation for the bass, reverb + limiter for the master channel.

I had 2 xruns the whole evening, both of them were when I loaded files in QTractor, not while playing.

I went away from non mixer + non session manager, because I found it easier to do all in qtractor (esp. because of the lv2-plugin-architecture).

So, to sum it up: It all went really smooth, very low latency, no xruns, good sound. However, I was busy making music and did not have time at all to look at the dsp load or to test if I would get xruns with hyperthreading turned on (which would have been interesting).

To sum it up: low latency linux live sound is definitely possible, though I must admit that it's just a small band. But, on the other hand: It's just my normal notebook, with a 200 € interface, free software, and it just works and sounds great - really cool. When I started my first band in the late 80s, this would have been pure science-fiction.

[Nuri]

Yesterday in rehearsal I've got some performance improvements on Windows 10 by changing some UEFI settings.
For those who are interested:
https://www.forum.rme-audio.de/viewtopi ... 73#p137573

@ khz

Sorry but I think I won't give Linux another try in the next months.
The main reasons are:
- the other band members want to use the Waves VST plugins (I agree they are very nice )
- the other band members run Win10 at home
- Linux performs not better than Win10 in our case
As I started the thread on this forum, I though Linux could bring some better performance but my experience has shown that it was not the case FOR THE NEEDS OF MY BAND.

@ Musicteacher

Your experience is also full of knowledge and shows that Linux performs very good on "low-level" setups (older computer, cheap USB interface, few tracks and few hardware inputs). Good to know it

On my machine, I re-enabled hyperthreading and Win10 performs better than before.
But... To be really honest, I've no idea which UEFI setting made my Win10 now performs better. Absolutely no idea...
In the UEFI of the Asus Prime Z390-P, there are many, many parameters which could be changed, , it made me run crazy...

When I started my first band in the late 80s, this would have been pure science-fiction.

Same for me!
But I started in the mid-90's (you know, Win95...)

[Musicteacher]

I had a small gig this evening, and we used the setup I discussed here for our mix.

Nuri, this might be interesting for you: Instead of small adjustments (which I had expected) rather big adjustments were necessary, because we used a different P.A. than for our rehearsals. This one had much more power in the lower end, so the bass guitar was much too loud. Also it makes a whole lot of a difference in what kind of room / hall you play.

After those adjustments were made, the sound was quite good (as people said, I didn't hear it, because I was behind the speakers, and I always wear hearing protection when playing live, so I cannot judge if it sounds good or not anyway).

There was one small problem with qtractor: At first, there was no connection for midi from soundcard to qtractor. But this connection had been present when the document had last been saved. Are the midi-connections not saved together with the qtractor document? Maybe I accidently disconnected it somehow, who knows.

One question for you all: It came to my mind that it might be cool to start a vnc server on the notebook where the mixing is done. Then one could connect to that with another notebook (or tablet, or whatever) and adjust the mix from wherever he wants in the room. But this would need a network connection (most probably WLAN). Has anyone tried something of the kind? I had switched the network off, because I didn't want that to get in the way of audio-processing, but if both could be done, this would be very cool. Any experience here? If not, I will try it and report here.

[thebutant]

Just a small note after reading this whole thread:

I've seen several people here on LinuxMusicians claim that a realtime kernel is not necessary, that a low latency will do just as fine for live stuff.
This has never been my experience. I've used GNU/Linux for live gigs the last 5 years, and on different OSs, on a few different computers, changing from a low latency kernel to a rt-kernel has always been a game changer for my setups.
I simply wouldn't do live stuff without a rt-kernel. Not even with a Liquorix one.
My experience is that it just doesn't work well enough with frames/persiod set to 64, which is what I use live.

I realize this is too late for @Nuri, who is now on a Windows setup, but if someone else reads this thread, wanting to get a good live setup:
I would highly recommend either Debian's rt-kernel (if you're on Debian), or installing one of the realtime kernels from http://bandshed.net/forum/index.php?topic=3719.0 if you're on a Ubuntu based system.

At least for me that's a necessity when doing live stuff.

[Musicteacher]

Could you point out in which situations exactly you did get xruns with a non-realtime kernel?

I had used a 64 bit buffer, and I had no xruns during that gig except when loading / saving files, not while playing.

As I said, using network for remote-acces via vnc would be interesting for me, would, for instance, a realtime kernel prevent the network from interrupting the audio-processes?

Or, to put it differently: I will try a realtime kernel as soon as I run into unsolvable problems with the standard kernel (I use arch standard kernel, which seems to be better suited for realtime anyway, though not a real realtime kernel if I understand correctly).

Thanks for your input!