Live mixing with Linux - State of the art 2018

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Musicteacher
Established Member
Posts: 37
Joined: Mon Nov 13, 2017 5:54 am

Re: Live mixing with Linux - State of the art 2018

Postby Musicteacher » Sat Jan 12, 2019 12:48 pm

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
Established Member
Posts: 323
Joined: Sun May 28, 2017 3:52 pm

Re: Live mixing with Linux - State of the art 2018

Postby Jack Winter » Sat Jan 12, 2019 1:43 pm

FWIW, Pianoteq is available in the linux vst format.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc 8) For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

User avatar
Nuri
Established Member
Posts: 31
Joined: Mon Oct 29, 2018 10:27 am

Re: Live mixing with Linux - State of the art 2018

Postby Nuri » Sun Jan 13, 2019 8:15 pm

@ 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. :roll:

Musicteacher
Established Member
Posts: 37
Joined: Mon Nov 13, 2017 5:54 am

Re: Live mixing with Linux - State of the art 2018

Postby Musicteacher » Sun Jan 13, 2019 11:14 pm

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
Established Member
Posts: 428
Joined: Fri Feb 25, 2011 6:40 pm

Re: Live mixing with Linux - State of the art 2018

Postby varpa » Mon Jan 14, 2019 2:26 am

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
Established Member
Posts: 37
Joined: Mon Nov 13, 2017 5:54 am

Re: Live mixing with Linux - State of the art 2018

Postby Musicteacher » Mon Jan 14, 2019 6:00 am

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.

User avatar
Nuri
Established Member
Posts: 31
Joined: Mon Oct 29, 2018 10:27 am

Re: Live mixing with Linux - State of the art 2018

Postby Nuri » Mon Jan 14, 2019 8:27 am

@ 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
Established Member
Posts: 77
Joined: Thu Oct 11, 2018 4:13 pm

Re: Live mixing with Linux - State of the art 2018

Postby merlyn » Tue Jan 15, 2019 12:05 am

Musicteacher wrote: 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
Established Member
Posts: 37
Joined: Mon Nov 13, 2017 5:54 am

Re: Live mixing with Linux - State of the art 2018

Postby Musicteacher » Tue Jan 15, 2019 7:12 am

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!

User avatar
khz
Established Member
Posts: 925
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Tue Jan 15, 2019 2:37 pm

@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
FZ - Does humor belongs in Music?
GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
    I don't care about the freedom of speech because I have nothing to say.

Musicteacher
Established Member
Posts: 37
Joined: Mon Nov 13, 2017 5:54 am

Re: Live mixing with Linux - State of the art 2018

Postby Musicteacher » Tue Jan 15, 2019 10:26 pm

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.


Return to “System Tuning and Configuration”

Who is online

Users browsing this forum: Google [Bot] and 0 guests