Page 7 of 7

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

Posted: Sun Jan 20, 2019 3:38 pm
by thebutant
Musicteacher wrote: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!
Of course, if your system gives no xruns or problems - there's no need to fix it.
I'm not saying everyone should get a realtime kernel or even that it is necessary for live gigs. Just that this is the case for me.
I can give some thoughts on it here:

1/ I can generally put more plugins into a live setup before xruns appear with a rt-kernel. When editing projects this is of little relevance, but on stage that difference is of course important. Trying to stay at frames/period 64 in the cases of "this vocal needs a compressor and a reverb, the guitar sounds better with. . ., and then this synth eats some cpu" and suddenly there are a few plugins at play - my experience is that a low latency kernel more easily becomes wobbly, while the rt-kernels I've used behave more trustworthy. But i've never used arch standard kernel for audio, my audio experience is limited to Debian/Ubuntu related kernels.

2/ this whole thing started for me some years ago when I was doing a perfomance on national radio, in front of an audience. I was using Ubuntu Studio at the time, with their stock low-latency kernel. Xruns were always near, but I thought it had to be that way. Suddenly while we're playing, all sound stops. For 6 seconds. Dead silence. Not a sound. 6 seconds are an eternity of time when you're on stage in the middle of a performance and sound breaks off. Suddenly everything came back like a wall, xruns were running down my screen, it really was a nightmare for me. I was so ashamed and stressed out. Of course this was not only related to the kernel, but after this experience I started optimizing my system more carefully, and started using a rt-kernel. The improvement in stability when using a rt-kernel amazed me. Some time after I did a similar performance with a rt kernel, and not a single xrun appeared for the 4 hours my computer was on.
Using a rt-kernel actually gave me back the trust for using GNU/Linux live.

3/ When it comes to vnc, even if that would work (I know nothing about it), I'd personally feel a lot safer sending the sound by cable to this other computer or to a mixer. Wired from audio interface to audio interace. When doing live stuff, I prefer to turn off all network, so that it doesn't influence the sound stability. But hey - testing it wouldn't do any harm. It might work just fine.

Actually, the whole question of rt / low latency-kernels is rather easy to check.
Install a rt-kernel without getting rid of the low latency (or standard) one. Compare them, try different projects on them, test how heavy a workload they can take. See which one works the best for you. Trying out a kernel is really rather easy, you lose nothing by it. Then pick the one you trust the most. :)

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

Posted: Sun Jan 20, 2019 3:54 pm
by khz
I think that GNU/Linux has simply reached its limit because @Nuri wants to use +/- 50 effects (resource-hungry VST with Wine) in real-time (time critical).
In theory this is already a feat.

Pure mixing/routing should not be a problem, few effects should work.
But +/- 50 effects (resource-hungry VST with Wine) is already extreme. IMHO
An RT kernel is recommended for such a purpose.

GNU/Linux will hopefully soon be completely a realtime operating system by default.
Real-time operating systems have been around since 1970.
GNU/Linux is about 48 years behind.
With all the cloud/Internet/... Tasks where GNU/Linux is in use, realtime is useful and should be in the default kernel, not only what has been integrated from the realtime branch into the kernel so far. IMHO

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

Posted: Sun Jan 20, 2019 3:59 pm
by Musicteacher
the vnc would be for manupilation of the gui, only (modify a volume slider, for instance). Of course not for sound!

I have so far only done the following:

- use a cheap notebook + usb interface for pianoteq. This worked, but only with no network + cpu governor performance + no desktop environment (I used ICE WM for that). I have used that on several occasions, but once I added another instrument, I had gotten xruns (it had a pentium n low-end processor, this was the bottleneck here)

- a not so cheap notebook with 8-channel input soundcard for mixing a small band

is there a tool that saves the dsp-load as a graph? To see afterwards how near an xrun had been?

I think that in my case it would be easiest to see how many identical plugins I can use till I get xruns and compare rt-kernel vs. stock kernel.

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

Posted: Sun Jan 20, 2019 4:02 pm
by Musicteacher
@khz : For cloud + internet, realtime is nonsense. Here you want a task scheduler such that everyone gets his share of system power. If you have 500 users instead of 50 on a busy day, the system will still work, but slower.

With a realtime kernel, the one with the highest priority would get his packages spot-on, the others would get nothing. In realtime apps, "slower" is not an option.

"realtime" does not make sense at all in certain environments.

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

Posted: Sun Jan 20, 2019 4:29 pm
by khz

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

Posted: Sun Jan 20, 2019 4:30 pm
by thebutant
Musicteacher wrote:the vnc would be for manupilation of the gui, only (modify a volume slider, for instance). Of course not for sound!
Oh, sorry for that.
As you probably understood, I know nothing about it. :D

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

Posted: Sun Jan 20, 2019 4:38 pm
by khz
Musicteacher wrote:For cloud + internet, realtime is nonsense.
khz wrote:Would that make sense for your LAW? ;-)
Nswap and Nswap2L are backing storage devices specifically designed for general purpose Linux clusters. Nswap is a Network RAM system that is designed to scale to large-sized clusters. It provides a block device interface to Network RAM that can be added as a swap device on individual cluster nodes. Nswap2L/Nswap2L-FS is a virtualization layer on top of a heterogeneous collection of cluster storage devices including Nswap Network RAM, Flash SSD, disk, or any other cluster-wide storage. It implements an single block device interface to the the Linux kernel and transparently implements data placement, migration and prefetching between underlying storage devices it manages. Nswap and Nswap2L can be added to individual cluster nodes as a swap partition or a partition for temporary file storage. We are currently investigating extensions and other uses for Nswap and Nswap2L cluster-wide backing store. Nswap is currently part of Nswap2L.