LinuxMusicians

laptop is really the best for some tasks, but anyway it performs more reliably when not pushed to its limits. that was the main reason for me to buy my 1st hardware synth. but when i saw its physical dimensions (1/4 of a 13″ laptop), i immediately wanted the 2nd.

PS, DJ's & Produsas love to convince themselves and everyone else that they're musicians.

i know, that's why i wrote special remark about )
it's like if a person making collages calls [him|her]self a painter )

Watch this space for indignant howls of protest, LOL. People who believe that Wine + Doze Apps gel well with live shows where reliable, glitch free and consistent operation is required? Hehehe, good luck with that.

that's why i have 2 laptops in my live setup. it's still the most probable point of failure. but with some sort of redundancy, the performance continues in case of a single laptop crash.
(no, i don't like hardware sequencers. programming them for something really complex is a nightmare, period.)

asbak wrote:In all my years of experiments I never managed to get better audio performance from a RT kernel vs a PREEMPT kernel.
Results were more or less identical. Stock kernels are utterly useless for low-latency audio. Agree with you about disabling unneeded services and mystery jobs which start up from nowhere.

Then you probably have some driver or other hardware problem that prevents achieving the lowest latency. As a matter of interest how low can you go with a loaded system? Also have you tried cyclictest/hackbench to see how low/high the kernel schduling latency is on your system (preferably both with lowlat and rt kernel)?

Then you probably have some driver or other hardware problem

So do you mean you're achieving flawless xrun-free results using a Linux stock kernel, when measured over a length of time, when live playing softsynths (Obxd for example) via keyboard MIDI? Jack set at 64 frames and < 4ms latency?

+ for added bonus points, all this being achieved while at the same time having laptop wireless running, browser sessions open etc?

If so, that's impressive.

chaocrator wrote:laptop is really the best for some tasks, but anyway it performs more reliably when not pushed to its limits.

Agree

that was the main reason for me to buy my 1st hardware synth. but when i saw its physical dimensions (1/4 of a 13″ laptop), i immediately wanted the 2nd.

Gear addiction... dangerous.

that's why i have 2 laptops in my live setup. it's still the most probable point of failure. but with some sort of redundancy, the performance continues in case of a single laptop crash. (no, i don't like hardware sequencers. programming them for something really complex is a nightmare, period.)

Smart move. Some years ago I had a student roadie gig with an EM group. They pre-recorded part of the soundtrack & effects to digital reel-to-reel (consumer grade computers weren't powerful or considered reliable enough at the time) and synced two of these units in case one went down.

asbak wrote:

Then you probably have some driver or other hardware problem

So do you mean you're achieving flawless xrun-free results using a Linux stock kernel, when measured over a length of time, when live playing softsynths (Obxd for example) via keyboard MIDI? Jack set at 64 frames and < 4ms latency?

+ for added bonus points, all this being achieved while at the same time having laptop wireless running, browser sessions open etc?

If so, that's impressive.

What I mean is that if you don't get better results with a realtime kernel as opposed to a lowlatency one, then there is something else causing problems with the kernel's scheduling. Maybe some hardware driver or some other problem with the system. Don't expect browsers to cause any low latency problems, but some wifi hardware/drivers are known to be problematic for low kernel scheduling latency.

That said, I'm not a midi user even if I have some midi gear here. I did recently play with LinVst and kontakt at low buffer sizes and discovered something fishy. If I have only jack1 (-Xseq) running with no other client than qjackctl (to monitor the xruns), I get xruns from banging on too many keys at once... Happens both with the multiface and the babyface. Still have to investigate this, but it made it unfeasable to test linvst/kontakt since xruns happens with nothing but midi connected to jack...

asbak wrote:

that was the main reason for me to buy my 1st hardware synth. but when i saw its physical dimensions (1/4 of a 13″ laptop), i immediately wanted the 2nd.

Gear addiction... dangerous.

not really ) with portability in mind, i'm limited by the number of channels of my mixer, by physical dimensions of my mixer, and by backpack volume. so, four hardware synths (2 FM and 2 subtractive) is the limit for me.

Jack Winter wrote: What I mean is that if you don't get better results with a realtime kernel as opposed to a lowlatency one, then there is something else causing problems with the kernel's scheduling.

I think there's a misunderstanding, because we're basically saying the same thing.

A PREEMPT kernel = a "low-latency" kernel. Ubuntu's "low-latency" kernel = a PREEMPT kernel.
Ubuntu usually sets their low-latency kernel timer freq to 250Hz whereas in the past it was usually recommended for audio prod purposes to have a 1000Hz kernel. (Although the timer freq setting won't affect the latency results.) So for this and other reasons I prefer to compile my own PREEMPT kernels.

I didn't find much if any audio performance difference between a RT or PREEMPT / low-latency kernel either. But there's massive difference between a standard kernel and a low-latency aka PREEMPT or RT kernel. The standard kernel will produce xruns at low-latency settings whereas the other kernels are more xrun resistant.

I avoid RT kernels because they can be finicky and crash prone (depending on version) and didn't appear to offer any performance advantage for my usage purposes.

Guys who use CNC and industrial production control equipment however have to use RT kernels to avoid having their expensive equipment self-destruct while executing jobs.