LinuxMusicians

chaocrator wrote:nice to hear, but Podolski by itself is quite simple due to its single-oscillator architecture.

I didn't just test Podolski, I tested about 30 plugins ranging from Kontakt to Amplitube.

I've had complex synths in Reaktor and Drums in Kontakt etc.

I don't use Wine much and I didn't use it for years, so when I tested LinVst with Wine 2.0 I was expecting performance issues due to Wine but there weren't any real issues which surprised me and it shows IMO how far Wine has progressed and how modern fast computers can deal with Wine very well.

I'm not including wineasio as that's a different thing, I'm commenting on using Wine in Linux Daws (with Jack connections) to run Windows vst's and that doesn't involve wineasio which seems to have it's own audio pipeline setup.

It hasn't got much to do with latency, whether it's single oscillator or not unless the cpu is very slow (old single core).

That's more of a cpu power issue and i7's and quad cores don't have much trouble with more complex code.

A very slow cpu will slow things down.

A modern cpu won't have many issues running Windows vst's under Wine.

The other more important issues affecting latency on Linux are the kernel (real time) and the audio drivers and hardware.

I think the point is, that a well configured linux can use many high-end windows vsts
well enough, that one is not forced to use windows or 0Sx. I have Zebra2, Hive, ACE,
SynthMaster, Synthmaster One, Wusikstation, IK's
Sampletank, Sonic Synth2, T-Racks, and Amplitube,
Cakewalk's Dimension Pro, Rapture, and z3ta+, along with Native Instruments Razor, Prism, Komplete Elements,
and their sundry free player versions, and for percussion, DrumCorps, EZDrummer, and GURU.
For Daw's I have Mixbus and Reaper linux versions, and enjoy the Bitwig demo, looking to buy
their 8-track version.

32bit bridging in 64 bit linux is still a problem for some old favorite Synthedit plugins, but I keep
a 32bit setup active, so I don't have to suffer. Some of the greatest presets were crafted
for those old Synthedit dinosaurs.
Cheers

ubuntuuser wrote:so when I tested LinVst with Wine 2.0 I was expecting performance issues due to Wine but there weren't any real issues which surprised me

It could be we have it all backwards, that we usually look at wine, assuming because it is a subset of a full windows install,
that it is automatically 'the problem' in an audio production setup, but that in reality,
a plugin that must compete with the ENTIRE windows/mac installation, for priority, is actually at some disadvantage,
performance wise, compared to the same plugin in a well configured linux/wine,
and the wine team has leveraged just the necessary parts well enough, to the advantage and surprise
of musicians, that windows and 0sx are now optional extras in some cases.
Cheers

ubuntuuser wrote: I tested and compared the Windows Podolski (using LinVst and Wine 2.0) and the native Mac Podolski on a Quad core Mac and the latency was about the same, pretty low as I remember it, something like 64 samples being pretty easy to get.

OK, but how did NI Reaktor & Kontakt fare at low-latency settings and playing chords on a midi keyboard for 30 mins to an hour or so, while making patch changes etc to switch between sounds?

glowrak guy wrote:I'm guessing you dont' have a PCI soundcard? I do, by luck, not by plan, and I've never had latency problems,
massive numbers of xruns, random crashes, and have had the best 0f linux audio experiences, if I can believe
all the misery I read on various linux forums.

Axiom of the universe # 17: Laptops were designed for office dweebs, not musicians.

Axiom of the universe # 94: youtube video proves jack_shite

Axiom of the universe 221: If you can afford a mac, a pc, and a linux computer,
stick to the first two, you'll live longer, and make the people around you happier.
(all that senseless pounding makes for angry neighbors.)

^That doesn't answer anything.

The point I was making is that real life live usage scenarios with NI Kontakt & Reaktor running in Wine are very much hit and miss.

Even a none-self-proclaimed specialist such as myself can technically get it to sort of work at low latencies, for a while, but ultimately it's going to just end up crashing or xrunning at some point when doing patch changes or even when just using it for long enough.

There is no way that Komplete runs better in Wine than it does natively on Windows. It's amusing to see how close one can get to making it sort of usable, but ultimately it's just self-delusion that it's going to be fit for purpose for serious use.

No sane performer will risk going live with such a setup.

ubuntuuser wrote:

asbak wrote:

ubuntuuser wrote: I tested and compared the Windows Podolski (using LinVst and Wine 2.0) and the native Mac Podolski on a Quad core Mac and the latency was about the same, pretty low as I remember it, something like 64 samples being pretty easy to get.

OK, but how did NI Reaktor & Kontakt fare at low-latency settings and playing chords on a midi keyboard for 30 mins to an hour or so, while making patch changes etc to switch between sounds?

There is hardly anything to make a difference.

Wine runs the Windows dll audio processing code and it's Intel code, so not much of a performance hit.

Wine translates the Windows vst's GUI D3D etc code to OpenGL X11, so maybe a small performance hit.

Put simply, Wine and LinVst/Airwave are all wrappers around the Windows vst and the audio just goes directly to Jack/Alsa via the Linux native Daw.

That's about it.

Fast cpu's and video cards, will result in not much of a difference.

In the case of LinVst or Airwave, the Windows vst is wrapped up in a linux vst wrapper and the audio that Wine has processed from the Windows vst (Intel code), get's sent to the Linux native Daw that then outputs it as usual to Jack/Alsa (same for audio inputs into the Linux native Daw).

If someone is running a Windows Daw (such as Windows Reaper) under Wine then that's a different case, and Wine is handling and managing the audio in/out (probably through wineasio/pulseaudio/alsa) and the latency could be different to the LinVst/Airwave Linux native Daw case, because the Wine/wineasio/pulseaudio/alsa audio pipeline is different.

Things that make a difference and bring Linux more in line with Coreaudio latency performance on the Mac, are a real time kernel (interrupt priorities etc).

Possible Linux audio hardware/driver issues are a different case.

As I've said, I've tested LinVst on a quad core/Nvidia setup on Yosemite Mac and Ubuntu 16.10 with a real ime kernel and Reaktor and Kontakt did not have much performance difference from the Windows and Mac native versions.

Podolski was used for testing as well because it's got Windows, Mac and Linux native versions and the Windows version running under Wine with LinVst could be directly compared to the Mac and Linux versions in terms of latency and there was basically no difference, and things like it being one oscillator don't really come into it because that's (floating point) code for the cpu to handle and not anything to do with audio pipelines.

I've just been testing an Amp Sim with it's source code (a lot of floating point filter code) ported to Linux from Windows and I've had the Windows Amp Sim vst running in Linux native Reaper using LinVst and I've had the ported Linux native vst running in Linux native Reaper and the cpu performance (Reaper has cpu plugin usage readouts) is basically exactly the same, so that means that Wine is running the Windows Amp Sim code with hardly any performance hit as compared to the ported Linux native vst Amp Sim code.

Audo performance depends on how fast LinVst can get the Windows vst's Amp Sim's Wine processed audio back to Linux Reaper and it's just a case of copying the Wine processed audio back to Linux Reaper which is very fast, so there is basically no real audio performance hit.

The Windows Amp Sim's GUI doesn't seem to have much of a performance hit with Wine handling the GUI.

There are basically 3 things going on with Wine when it's running a Windows vst.

The Windows vst's cpu (floating point) effect code which results in the processed audio to be sent to the Daw/audio hardware, the Windows vst's GUI code, and the audio in/out, and in the case of LinVst/Airwave the audio in/out is not handled by Wine, so that leaves the cpu and GUI code for possible performance hits and on a fast computer the performance hit isn't that much.

Wine isn't perfect and it could have trouble with some Windows code, but for a lot of things Wine is ok and it's being updated constantly.

asbak wrote:
The point I was making is that real life live usage scenarios with NI Kontakt & Reaktor running in Wine are very much hit and miss...

...No sane performer will risk going live with such a setup.

Reaktor is not a softsynth such as zynaddsubfx. It is a specialised developement system
that can host the results of said developements, in the form of instruments and effects that are
in their own proprietary formats, with extensions of .ens or .rkplr, of which there exists a parallel universe
of sonic jewels, myriad in number and purpose, none of which have a .dll extension.

After having learned to play the NI rating system, it was pretty easy to aquire two hundred + that serve
my musical needs and fantasies, many of which are machines in their own right, and mastering them
bears a worthy learning curve. One must also consider that Reaktor hosts creations that are commercial,
or from the hobbyist, and from the beginner, so care should be taken accordingly in a live stage setting.

Now enter in the number of wine versions in use across the win-escapee userbase, levels of configuration skill,
even the willingness to add a few required over-rides...and top it off with the folly of trying
to do live performances based in part, at least, using an office computer as one of the main instruments?
(there is a reason words like korg, roland and motif are printed on the backsides
of workstation synths, and impressing the wall in the studio isn't one of them!)

And do be clear, a laptop with jackd and wineasio is still just an office computer.
An actual DAW computer running linux will be capable of much more, and will have had
thorough modifications and additions, compared to a tower that Dell might be proud to ship,
to an office...

As for Kontakt, we have yet another parallel universe from NI. I think it's both ugly and poorly designed,
and prefer Dimension Pro, and Sampletank for my limited needs for quasi-real sounds.
But Kontact is an industry standard, and many great instruments have their home in Kontakt, so be it.
I even have one on my to-buy list. Again, there are myriad purchases awaiting a Kontakt system owner,
not all created equal, some requiring a beefy and thoroughly pro system to run effectively.

All that longwinded pedantic blowhardery to say 'sure, one might experience some "hit and miss",
as part of the journey', it is the very nature of the beast. But we try new things, learn, and move on.
I really doubt Reaktor and Kontakt were created with live perfornce in mind. But times and desires change.
They are deep and wide, and well worth exploring.
Cheers

@ubuntuuser: Thanks for the look under the hood at how wine and vst wrappers
do their magic. It's good to know the mechanics are working well!
Cheers

ubuntuuser wrote: There is hardly anything to make a difference.

Wine runs the Windows dll audio processing code and it's Intel code, so not much of a performance hit.

........................

Thanks for the post but none of that addresses what I actually asked for which was:

How long did Reaktor and Komplete last at low latency settings at 64 to 128 frames settings in Wine before crashing or xrunning, when doing actual live playing from a MIDI keyboard and when doing multiple patch & instrument changes?

Setting aside all the theory in the post, how well does it actually work where things really matter to actual musicians. (As opposed to hobbyists & tinkerers.)

I've run NI and other VST's in Wine for years and am well acquainted with what can be achieved under optimal conditions when the stars are in alignment and the gods are smiling. However, I'm a lot less convinced about how reliably and consistently reproducible such results are where it really counts.

I'm happy to be proven wrong, but thus far nobody has shown any concrete results or evidence which refutes my skepticism about NI (and most other VST) performance and reliability under Wine being anything more than a novelty.

There are commercial products (Receptor for example) which do work reasonably well but they're closed source and often the VST's have been custom coded specifically to work in that environment.

1. you will never have 'optimal conditions' on stage, with a laptop.
2. xruns are not an issue unless they produce noises or audio dropouts.
3. latency is not an issue until it damages your natural playing flow.
4. you can't limit the definition of an 'actual musician', to those attempting
to use office computers for running developement systems as primary instruments,
'in concert', for xyz minutes r u serious?

I have 7 reaktor instruments and ensembles that I use most often,
Razor, Prism, Steampipe2, Nord-Rack, and, and secret favs, using Reaper as the host,
none has ever crashed. Razor and Prism are very cpu intensive,
at their highest settings, using multiple instances is i7/RT kernel territory.
It would be easy for them to lock up a dual-core 2ghz computer, just playing a chord,
on any OS.

You keep referring to Kontakt as Komplete, which might confuse someone.
I don't use Kontakt much(yet) I use it's free and Elements versions
to load up some fine drumkits and pads, but thats as far as I take it for now.

NI switching from Service Center to Native Access for product updates and registration
is a blunder, and only guarantees greater market share for the wonderful U-he linux synths.
I own three of those, and they don't crash either. With a powerhouse computer,
they would be great choices for a live linux band setting.
Cheers

The u-he stuff is available as linux native vst2/3 too.

„actual musicians as opposed to hobbyists & tinkerers“ mostly tend to prefer hardware solutions over software, if posible.
(p.s. DJs, turntablists, etc. are not considered as musicians at all. sorry in advance )

asbak wrote:

ubuntuuser wrote: There is hardly anything to make a difference.

Wine runs the Windows dll audio processing code and it's Intel code, so not much of a performance hit.

........................

Thanks for the post but none of that addresses what I actually asked for which was:

How long did Reaktor and Komplete last at low latency settings at 64 to 128 frames settings in Wine before crashing or xrunning, when doing actual live playing from a MIDI keyboard and when doing multiple patch & instrument changes?

Setting aside all the theory in the post, how well does it actually work where things really matter to actual musicians. (As opposed to hobbyists & tinkerers.)

I've run NI and other VST's in Wine for years and am well acquainted with what can be achieved under optimal conditions when the stars are in alignment and the gods are smiling. However, I'm a lot less convinced about how reliably and consistently reproducible such results are where it really counts.

I'm happy to be proven wrong, but thus far nobody has shown any concrete results or evidence which refutes my skepticism about NI (and most other VST) performance and reliability under Wine being anything more than a novelty.

There are commercial products (Receptor for example) which do work reasonably well but they're closed source and often the VST's have been custom coded specifically to work in that environment.

Right now I've got the Windows Podolski running (Linux native Reaper) on an old dual core Dell laptop with crap inbuilt sound with Jack set to 48000Hz 128 Frames/Period and 2 Periods/Buffer and the Latency is 5.33 msec.

The Dell laptop has slow memory, slow cpu and a crap audio device, and that's why I use it for testing, so I know that if it works on the Dell then anything above it will be ok.

Wine 2.0 stable, Linux native Reaper, LinVst.

There are no instability problems happening that I'm aware of and just plug in a midi keyboard and whatever.

What I did was install a real time kernel.

I sometimes use the real time kernel but I'm only using Ubuntu Studio's low latency kernel for the above Podolski results but the installation of the real time kernel seems to have altered the interrupt priorities which even work when I just use the low latency kernel, so that is helping in getting low latency audio.

Before that, I just had the stock standard Ubuntu low latency kernel and I could get 10.7ms latency with the Windows Podolski but with occasional audio breakups probably caused by some daemon(s) running in the background interfering with the audio.

The services (daemons) that were stopped by a mod script were

resolvconf
pulseaudio
apport
cron
cups-browsed
grub-common
speech-dispatcher
whoopsie

so the 10.7ms latency with audio breakups had something to do with what those (some) services were doing.

It's just easier installing a real time kernel rather than playing around with stopping some services and altering interrupt priorities at startup.

Wine's performance might even be affected by what daemons are currently running and how they are running, as the wineserver is a daemon itself but I'm not certain of it as I'm not an expert on daemons and the inner workings of Linux etc.

I'm getting the same latency results for other Windows vst's besides Podolski and whether it's Podolski or some other Windows vst is basically irrelevant if the cpu can handle the vst plugins code.

A cpu intensive vst plugin or a non cpu intensive vst plugin doesn't really matter to the audio latency if the cpu is fast enough.

If I was testing on an i7 with some great audio hardware then I'd say I could achieve even lower latency.

There are other things involving Linux audio latency besides Wine, like interrupt priorities and maybe some audio drivers.

Wine is not introducing much/hardly any audio latency into the audio chain with the Linux Reaper/LinVst/Wine combo.

Running a Windows audio program under Wine is a different thing as I've said because the audio path is different.

I tried to explain that if someone is getting not very good audio performance, then they need to look at the parts that can affect the audio.

Linux Reaper's in/out connections to Jack/Alsa are not part of the problem unless there is something not quite right about the audio driver or jack/alsa setup.

Wine running the Windows vst's effect processing Intel code is usually not part of the problem (can contribute in certain cases).

Wine running the Windows vst's GUI Intel code is often ok but D3D etc might cause some problems in some cases (depending on the video drivers and/or maybe some unimplemented D3D features in Wine).

The audio in and out of the Windows vst is interfaced directly through Linux Reaper/LinVst and passed straight onto the Windows vst, so no real lag is happening as LinVst is just basically a passthrough vst wrapper between Linux Reaper (the DAW) and the Windows vst.

The other parts are the kernel and the audio hardware/drivers and these are where a lot of the audio latency problems are probably originating from.

I'm just relating my experiences with Wine and audio latency with Linux Daws while testing LinVst, that's all.

From all of my testing from Kontakt to amp sims to synths etc, Wine was pretty stable and not crashing all over the place.

The Wine version that I last used before Wine 2.0 was years ago, maybe Wine 1.2, and the Wine available now is quite capable of handling a lot of Windows vst's at pretty low latencies in a stable way on moderns systems with a real time kernel or some interrupt priority mods, but there are a lot of Linux distro variations and audio hardware variations, so things might need to be tailored for a particular system.

if one wants as low latencies and good performance as possible, the right approach is installng RT kernel AND stopping / not running unnecessary services.

for example, i have custom systemd target named «live» on both my laptops, which runs only a few necessary services and autologins me to ultraminimalistic GUI session. it's only for live/rehearsals, not for regular desktop use, and it definitely rocks.

chaocrator wrote:„actual musicians as opposed to hobbyists & tinkerers“ mostly tend to prefer hardware solutions over software, if posible.
(p.s. DJs, turntablists, etc. are not considered as musicians at all. sorry in advance )

Quite right - hardware is by far the most reliable solution but there's no shortage of Macs on stage with bands so presumably they're being used for live shows and are deemed to be reliable enough to do whatever it is that they're being used for ie running Ableton or whatever.

PS, DJ's & Produsas love to convince themselves and everyone else that they're musicians. 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.

(I know that you know better, but not many others get it.)

if one wants as low latencies and good performance as possible, the right approach is installng RT kernel AND stopping / not running unnecessary services.

for example, i have custom systemd target named «live» on both my laptops, which runs only a few necessary services and autologins me to ultraminimalistic GUI session. it's only for live/rehearsals, not for regular desktop use, and it definitely rocks.

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.