Live mixing with Linux - State of the art 2018

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

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

Post by raboof »

Nuri wrote:At 32 and 64 samples I get (a lot of) clicks and pops on both Win10 and Linux. The only difference between Win10 and Linux is that the performance meter of Reaper reports xruns in Linux and no xrun at all in Win10.
Too bad we did not succeed in 'beating' Win10 in this case, but good that we are at least 'on par' (and slightly better at giving insight in what is going on). Perhaps we simply reached the limits of what your hardware can realistically do, or more engineering might be needed - hard to say.
Nuri wrote:We also decided to stick with Win10 since we can use our Waves plugins natively.
If a plugin you're relying on heavily is only available for Win10 that can certainly be a valid reason for sticking to that - I certainly stick with Linux because I have come to rely on tools that are not available on Windows ;). Thanks for reporting your findings!
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

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

Post by Jack Winter »

Nuri wrote:The only difference between Win10 and Linux is that the performance meter of Reaper reports xruns in Linux and no xrun at all in Win10.
But what you hear out of the audio is the same at 32 and 64 samples with both systems: krkkr, kzzz, shrshr...
That's because even though there is an ASIO callback to report xruns, we haven't found a single windows driver that actually does... The cynic in me thinks this might be due to wanting to sell hardware and not wanting to be the only one that report errors... :(

What might help you to get lower buffersizes working well, is to look at your fx chains and routing. The simpler you make the routing the faster reaper will be able to finish calculating the audio. Regarding fx, maybe it's just a single fx on some track or the master that is taking a long time to finish calculating the DSP. Check the rt cpu and the rt longest block in the reaper performance window, they indicate how close you are to exceeding the deadline. IIRC the cpu use of fx for each track is also indicating a similar measure (and not really the cpu use), if that is high on some track or the master, try disabling the different plugins to see if that helps. Minimizing the amount of fx on each track and the master might also allow you to go a step lower.

Still happy to see that reaper for linux is performing on par to the windows version for you. That is encouraging to see.
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: 32
Joined: Mon Oct 29, 2018 10:27 am

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

Post by Nuri »

@raboof
Too bad we did not succeed in 'beating' Win10 in this case, but good that we are at least 'on par'
Yes it's a bit disappointing!
I get the best results with a "stock" Xubuntu 18.04 and the Liquorix RT-Kernel. All music distros I've tested (AV and KX) were garbage on my system.
I probably could better tweak Linux to do the job but it's really hard to understand every relevant setting and test it, test it, test it...
Now comes the time we only want to play music!


@Jack Winter
The cynic in me thinks this might be due to wanting to sell hardware and not wanting to be the only one that report errors...
It's probably true!!! :roll:
I mean, the audio playback at 32 and 64 samples buffer size is EXACTLY THE SAME for Win10 and Linux: full of glitches...
The simpler you make the routing the faster reaper will be able to finish calculating the audio
I know, but the Reaper project was already set in this direction. I cannot simplify anymore.
It's actually pretty easy:
12 input tracks (8 for drums, 1 for bass, 1 for git1, 1 for git2, 1 for vox). These tracks contains all the plugins and all automated features (level, pan, effect preset changes).
Then:
1 sub-mix for the master output (no plugin).
1 sub-mix for the drummer (no plugin).
1 sub-mix for the bassist (no plugin).
1 sub-mix for the guitarist (no plugin).
1 sub-mix for the guitarist/singer (no plugin).
And you get 90 tracks in total!!! :shock:
Regarding fx, maybe it's just a single fx on some track or the master that is taking a long time to finish calculating the DSP
No, I'm pretty sure this is the sum of all effects that becomes too heavy.
Minimizing the amount of fx on each track and the master might also allow you to go a step lower.
I've already minimized the amount of effects!
For sure I need some EQ, comp and reverb on a snare track. If not, I can make a better mix with our Soundcraft Ui24R.
There is no effect on the master track.
Still happy to see that reaper for linux is performing on par to the windows version for you. That is encouraging to see.
mmm... Yes, but only with the RT Liquorix kernel, in my case.
Tweaking Win10 for audio takes about 30 minutes.
Tweaking Linux for audio takes... errr... and unknown amount of time. It never ends up :? . It's good if you know what you're doing but it's really difficult if you're a nood or semi-noob like me :wink: .
Jack Winter
Established Member
Posts: 381
Joined: Sun May 28, 2017 3:52 pm

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

Post by Jack Winter »

Nuri wrote: I've already minimized the amount of effects!
For sure I need some EQ, comp and reverb on a snare track. If not, I can make a better mix with our Soundcraft Ui24R.
There is no effect on the master track.

Tweaking Linux for audio takes... errr... and unknown amount of time. It never ends up :? . It's good if you know what you're doing but it's really difficult if you're a nood or semi-noob like me :wink: .
Sounds like you minimized as far as possible, still getting rid of the busses and making the reverb a send instead of an insert might be worth trying.

Yes installing and tweaking Linux for the best low latency performance is somewhat confusing. A lot of conflicting or old advice out there. I think it's something we could probably improve on as a community. Still there are quite a few users having somewhat of a nightmare with this on Windows too :)

Well best of luck and hope to see you back in a few years :)

Edit: Ah forget about eliminating the busses... You'll need those for the in ear monitoring... Didn't think that far. :oops:
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
Drumfix
Established Member
Posts: 299
Joined: Mon Jan 26, 2009 5:15 pm
Been thanked: 11 times

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

Post by Drumfix »

Nuri wrote:Tweaking Win10 for audio takes about 30 minutes.
Tweaking Linux for audio takes.
No, tweaking Linux for audio takes about 5 minutes, provided you know what to do and have an RT kernel installed.
And, after the tweaks have been done, you still have xruns, there is either a kernel bug, cpu overload or the audio application not programmed realtime safe.
User avatar
khz
Established Member
Posts: 1648
Joined: Thu Apr 17, 2008 6:29 am
Location: German
Has thanked: 42 times
Been thanked: 92 times

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

Post by khz »

Jack Winter wrote:A lot of conflicting or old advice out there. I think it's something we could probably improve on as a community.
Full approval!
That's what the thread "Wiki update" is for. Keeping our knowledge - as a community - up-to-date, correct and complete is important and useful for everyone.
Welcome! If you inform yourself about GNU/Linux, e.g. in the wiki, and find outdated, further, new entries you can report it immediately, you are invited to contribute.

Since it is sometimes hard for me as a non computer technical specialist to keep track of things, I have written these ~confusing "GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info" && "GNU/Linux Debian installing >> Linux Audio Workstation LAW" articles, as a personal meta reminder. ;-)
. . . 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: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

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

Post by Musicteacher »

Interesting thread.

I also want to transfer my live-mixing to be completely digital, but on a much smaller stage.

The reason is that we use our rehearsal room together with others and thus start from scratch every time we plug in our microphones and instruments.

I will approach things completely differently.

Hardware:
- Behringer UMC1820 (has 8 xlr / instrument combo in's, extensible by another 8 via adat)
- notebook with Core™ i5-8250U (4 CPUs, 8 Threads)
Software:
Jack + non session manager + non session mixer + some effects (calf), linuxsampler for piano sounds, maybe guitarix

4 Singers
3 Guitars
1 Bass Guitar
1 Keyboard

This makes 9 in total, so with 8 inputs the keyboard will have to come in by Midi-In and use a virtual instrument.

The guitars will come processed from their amp-simulators. Bass and singers will need compressors (one for each). I will use a reverb for the complete mixdown. The keyboard will probably use linuxsampler with salamander piano.

I have never really measured round-trip-latency with my setup at home, but with period buffer 128 byte, 2 periods in Jack i percieve no latency (jack shows 5,xx ms, but the roundtrip latency will surely be a bit more) when playing virtual instruments (piano, guitar).

With 252 byte it feels a bit "late", to be honest, but still playable. One must not forget that in 10 ms of time sound is able to travel about 3 m, so if you mind 10 ms latency, be sure not to stand too far away from your speakers (I know that the OP uses in-ear-monitoring, so there is no acoustic latency there, but many people still use speakers).

Next tuesday is the first rehearsal with that setup. What do you think, will this (very much simpler, more amateurish) approach work for rehearsals?
JamesPeters
Established Member
Posts: 188
Joined: Fri Jun 29, 2018 6:35 pm
Has thanked: 8 times
Been thanked: 15 times

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

Post by JamesPeters »

Drumfix wrote: No, tweaking Linux for audio takes about 5 minutes, provided you know what to do and have an RT kernel installed.
And, after the tweaks have been done, you still have xruns, there is either a kernel bug, cpu overload or the audio application not programmed realtime safe.
I didn't even need a RT kernel. Although I'm only expecting my audio device to perform at least as well as it does in Windows (and it actually performs a bit better than in Windows, while the CPU use is actually around 30% better than in Windows...so I'm happy). I don't expect latency of 1ms or something. If others can achieve that, I'm impressed, but I know it won't make a difference for my workflow anyway.
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

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

Post by merlyn »

Musicteacher wrote:What do you think, will this (very much simpler, more amateurish) approach work for rehearsals?
Going into the risky business of prediction -- I would think yes, it will work. Live MIDI may be a problem for reasons outlined on other threads that I don't fully understand. :)

@Nuri For research purposes it would be interesting if you compiled and ran this program :

xruncounter.c

Code: Select all

#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <math.h>

#include <jack/jack.h>

/*   gcc -Wall xruncounter.c -lm `pkg-config --cflags --libs jack` -o xruncounter */

jack_client_t *client;
jack_port_t *in_port;
jack_port_t *out_port;

static int xruns = 0;
static int grow = 1;
static int first_x_run = 0;
static float dsp_load = 0;
static int run = 1;


void
jack_shutdown (void *arg)
{
   exit (1);
}

int
jack_xrun_callback(void *arg)
{
   /* count xruns */
   xruns += 1;
   if (xruns == 1) {
       first_x_run = grow/100;
       dsp_load = jack_cpu_load(client);
   }
   fprintf (stderr, "Xrun %i at DSP load %f\n",xruns , jack_cpu_load(client));
   if ((int)jack_cpu_load(client)>95) run = 0;
   return 0;
}

int
jack_srate_callback(jack_nframes_t samplerate, void* arg)
{
    fprintf (stderr, "Samplerate %i \n", samplerate);
    return 0;
}

int
jack_buffersize_callback(jack_nframes_t nframes, void* arg)
{
    fprintf (stderr, "Buffersize is %i \n", nframes);
    return 0;
}

int
jack_process(jack_nframes_t nframes, void *arg)
{
    double d = 0;
    for (int j ; j < grow; ++j) {
        d = tan(atan(tan(atan(tan(atan(tan(atan(tan(atan(123456789.123456789))))))))));
    }
    grow +=100;
    d = 0;
    return (int)d;
}

void
signal_handler (int sig)
{
   jack_client_close (client);
   fprintf (stderr, " signal %i received, exiting ...\n", sig);
   exit (0);
}

int
main (int argc, char *argv[])

{

   if ((client = jack_client_open ("xruncounter", JackNullOption, NULL)) == 0) {
      fprintf (stderr, "jack server not running?\n");
      return 1;
   }

   in_port = jack_port_register(
     client, "in_0", JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
   out_port = jack_port_register(
        client, "out_0", JACK_DEFAULT_AUDIO_TYPE, JackPortIsOutput, 0);

   signal (SIGQUIT, signal_handler);
   signal (SIGTERM, signal_handler);
   signal (SIGHUP, signal_handler);
   signal (SIGINT, signal_handler);

   jack_set_xrun_callback(client, jack_xrun_callback, 0);
   jack_set_sample_rate_callback(client, jack_srate_callback, 0);
   jack_set_buffer_size_callback(client, jack_buffersize_callback, 0);
   jack_set_process_callback(client, jack_process, 0);
   jack_on_shutdown (client, jack_shutdown, 0);

   if (jack_activate (client)) {
      fprintf (stderr, "cannot activate client");
      return 1;
   }
   
   if (!jack_is_realtime(client)) {
       fprintf (stderr, "jack isn't running with realtime priority\n");
   } else {
      fprintf (stderr, "jack running with realtime priority\n");
   }
   
   while (run) {
      usleep (100000);
      fprintf (stderr, "DSP load %f  \r", jack_cpu_load(client));
   }
   
   fprintf(stderr, "in complete %i Xruns in %i circles\nfirst Xrun happen at DSP load %f circle %i\n", xruns, grow/100, dsp_load, first_x_run);

   jack_client_close (client);
   exit (0);
}
The results would help decide if Ubuntu isn't configured optimally, or your hardware isn't fast enough.
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

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

Post by Musicteacher »

Hi,

this worked (with low latency, I used 64 bit, 2 periods, 48 kHz).

However, it didn't sound well at first, because I used way too much compression for the vocals, so everything sounded "boring", which lead to a quite unpleasant atmosphere.

Also, I am not happy with the non-mixer, as it doesn't allow lv2 plugins. So for lv2-plugins to work you have to start them manually and connect them with jack, which leads to quite a nasty jack-graph.

I think, I will start a new thread for that. I consider using QTractor as an alternative to non-mixer.
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

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

Post by merlyn »

Musicteacher wrote:this worked (with low latency, I used 64 bit, 2 periods, 48 kHz).
And did live MIDI play back acceptably?
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

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

Post by Musicteacher »

Yes. I had a piano plugged in my usb-interface, the sound was generated through pianoteq.

I used jack midi (as non session manager can only restore jack connections, not alsa connections), and the midi + audio (capture and playback) were all on the same card, maybe this matters.
merlyn
Established Member
Posts: 1392
Joined: Thu Oct 11, 2018 4:13 pm
Has thanked: 168 times
Been thanked: 247 times

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

Post by merlyn »

Musicteacher wrote:Yes. I had a piano plugged in my usb-interface, the sound was generated through pianoteq.

I used jack midi (as non session manager can only restore jack connections, not alsa connections), and the midi + audio (capture and playback) were all on the same card, maybe this matters.
Thanks. Good to know.
Musicteacher
Established Member
Posts: 194
Joined: Mon Nov 13, 2017 5:54 am
Has thanked: 8 times
Been thanked: 4 times

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

Post by Musicteacher »

I did some tests yesterday evening, because I had learnt about the "DSP load" (I had seen the term in some posts, bud had not known what it really is and where it is shown).

It seems to me that live-mixing with effects and virtual instruments is really demanding. While on one hand this might seem pretty obvious, I had not thought it would be that demanding, as I have done live effects (for vocals, for instance) for years, and with much slower machines than what I have now.

I have prepared a setup with 8 channels in, Virtual Instruments Pianoteq, SetBFree and one SFZ synth (exported to .lv2 via carla) switched "on", Compression on one vocal channel, Guitarix as Insert for one Guitar Channel. Of course I cannot play/sing 8 channels simultanously, but if monitoring is on for all of them (I used QTractor as host) this should not matter.

Jack-Setting was 48 kHz, 128 Samples, 3 Periods (Jack-Latency 8 ms)
Then I played piano. 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). One would need more cores for that. On the other hand, @Nuri did not use virtual instruments.

If I use Pianoteq only, I can go down to 32 Samples, 2 Periods, with no XRUNs. But not with many channels.

So this probably is the occasion where you might want a Ryzen Threadripper ;)
User avatar
Nuri
Established Member
Posts: 32
Joined: Mon Oct 29, 2018 10:27 am

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

Post by Nuri »

@ merlyn:

thanks for your program but I have recently removed Linux from my DAW-Workstation because of a fresh installation of Win10.
Furthermore, some instructions to compile it would be very useful for users like me at "noob" level :oops: .

@ Musicteacher

Glitch free with a 64 samples buffer size is pretty good for a USB interface :) .
128 samples is also good and should be ok to play over speakers (when it comes to human perception of latency).

Why do you not try Reaper for your mixing purposes? Reaper is known as very efficient. Maybe you could add more tracks without drawbacks...
The main limitation of Reaper is that you cannot use LV2 plugins as insert. But you can use them standalone (Calf plugins?) through the Jack connection patch bay, as you already did with NonMixer.
So this probably is the occasion where you might want a Ryzen Threadripper
I have read that Threadrippers are not very good for real-time audio, at least the 1xxx generation. I've also read that the 2xxx generation brought some improvements in this area but I don't know much more.
I think the choice of the motherboard is much more important than pure CPU power.
On the RME forum, I have been advised about Supermicro motherboard (server grade component) using an Intel C612 chip. Here the link to the thread:
https://www.forum.rme-audio.de/viewtopi ... 19#p137119. This is a Windows only discussion but everything related to the hardware should also apply to Linux.
Post Reply