Plugin GUI interaction slow w/ CPU spikes

[brandoninvergo]

I'm a recent adopter of LinVst so there may be a user misconfiguration here, but just in case...

Any interaction with any plugin GUI is unusably slow. E.g. rotating a knob is very jumpy rather than smooth and continuous. In Bitwig, with an empty project, only a single LinVst-bridged plugin loaded (any bridged plugin that I have tried), and no audio playing, rotating a knob causes CPU spikes of up to 100% (based on the DSP CPU usage meter within Bitwig). With audio playing, this results in glitched out audio while moving the knob.

Interestingly, while I'm turning a knob in the plugin GUI and it's slow/discontinuous, I can see the matching parameter in Bitwig's generic plugin interface changing smoothly. If I change the parameter directly in the generic interface, the knob in the plugin GUI moves smoothly and the DSP CPU usage remains constant. So it's really only when I interact with the plugin GUI directly with the mouse.

I have added all the suggested realtime settings for the audio group. I have verified that the behavior exists under Wayland and under Xorg and it is not affected by display resolution (4k vs 1080p...hey, it was worth a try) nor winecfg's DPI setting. It also behaves the same in Mixbus 32C as it does in Bitwig (including the smooth behavior of generic controls). The computer is wildly over-specced for audio, so system resources shouldn't be an issue.

Are there any settings/tweaks I may have missed?

Distro: Arch Kernel: linux 6.0.10.arch2-1 Wine: 7.22 LinVst: 4.77 CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor RAM: 128G GPU: AMD Radeon RX Vega 64

[osxmidi]

I'm a recent adopter of LinVst so there may be a user misconfiguration here, but just in case...

Any interaction with any plugin GUI is unusably slow. E.g. rotating a knob is very jumpy rather than smooth and continuous. In Bitwig, with an empty project, only a single LinVst-bridged plugin loaded (any bridged plugin that I have tried), and no audio playing, rotating a knob causes CPU spikes of up to 100% (based on the DSP CPU usage meter within Bitwig). With audio playing, this results in glitched out audio while moving the knob.

Interestingly, while I'm turning a knob in the plugin GUI and it's slow/discontinuous, I can see the matching parameter in Bitwig's generic plugin interface changing smoothly. If I change the parameter directly in the generic interface, the knob in the plugin GUI moves smoothly and the DSP CPU usage remains constant. So it's really only when I interact with the plugin GUI directly with the mouse.

I have added all the suggested realtime settings for the audio group. I have verified that the behavior exists under Wayland and under Xorg and it is not affected by display resolution (4k vs 1080p...hey, it was worth a try) nor winecfg's DPI setting. It also behaves the same in Mixbus 32C as it does in Bitwig (including the smooth behavior of generic controls). The computer is wildly over-specced for audio, so system resources shouldn't be an issue.

Are there any settings/tweaks I may have missed?

Distro: Arch Kernel: linux 6.0.10.arch2-1 Wine: 7.22 LinVst: 4.77 CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor RAM: 128G GPU: AMD Radeon RX Vega 64

Seems like it might be related to this https://github.com/osxmidi/LinVst/issues/217

I've made a Bitwig version with different priorities, let me know if it works.

LinVst-4.77-Bitwig.zip

LinVst-master.zip

[brandoninvergo]

Thanks for looking into it.

So, first I should report something that I hadn't noticed before: I see the CPU spiking with VST3s only. First I loaded a very old VST2 plugin (fuzzpilz Charseisis) that I hadn't tried yet and saw that it was very smooth. This tipped me off that something was different with VST2. Next, I installed a VST2 version of a known-problematic VST3 (Waldorf Streichfett, which causes big CPU jumps). The VST2 GUI of Streichfett was still very slow when trying to change controls, but the Bitwig CPU-usage meter at least did not show any jumps in CPU.

Next, I installed LinVst-4.77-Bitwig, set up my VST2 plugins again, and tried the same two plugins in Bitwig. Charseisis was of course still smooth. I am happy to report that Streichfett was very smooth as well. I then tried Streichfett in Mixbus 32C and, sadly it's still slow in that program.

So, to summarize:

1. GUI smoothness is affected with both LinVst and LinVst3
2. As far as I've observed, the CPU spikes are with LinVst3 only (so perhaps I should have made the initial report in LinVst3, sorry)
3. The -Bitwig version does, indeed, work better in Bitwig
4. The -Bitwig version does not help performance in Mixbus 32C

[osxmidi]

Thanks for the feedback, it's very helpful.

I've changed the priorities in LinVst3-Bitwig below.

I havn't been able to duplicate the problem but that's just on my test system, on other systems some sort of priority problems could appear as in your case.

I think I will change the priorities for LinVst 4.78.

The other thing is how are your priorities setup on your system?.

I generally follow https://github.com/osxmidi/LinVst/tree/master/Realtime-Audio-Config

LinVst3-4.77-Bitwig.zip

LinVst3-master.zip

[brandoninvergo]

Thanks, I have a lot more VST3s installed that I could test. Strangely, it's a mixed bag:

• The following were smooth: Waldorf Streichfett (VST3); Valhalla SuperMassive, FreqEcho, and SpaceModulator; GForce M-Tron Select; Two Notes Torpedo Wall of Sound; AudioThing Things:Motor and Things:Crusher
• Soundtoys plugins in general are not smooth
• AudioThing Things:Texture was not smooth and it had massive CPU peaks
• Having multiple VST3 plugins in a track can cause previously smooth plugins to become slow. For example, if SuperMassive is the first plugin you put in a track, it works smoothly, even if you then add more plugins before/after it in the track. But, if you start with a different plugin and then add SuperMassive to the track, its GUI becomes slow.

I already had the realtime priorities set up as described in the wiki (except the rtirq bit, which should only affect communication with hardware, but this problem happens even without any audio even playing...or have I misunderstood rtirq?)

[brandoninvergo]

OK I've set up rtirq, but there's no discernable change from the description above.

Further observation: the slowness appears to be -- as far as I can tell -- stochastic. If I remove and reload the same plugin over and over, sometimes it'll be smooth, sometimes it'll be slow. Probably around 50-50 although I haven't estimated carefully.

To be clear, all of the above is with the Bitwig variant of linvst3-4.77. Without the Bitwig variant, it's all slow all the time.

[osxmidi]

OK I've set up rtirq, but there's no discernable change from the description above.

Further observation: the slowness appears to be -- as far as I can tell -- stochastic. If I remove and reload the same plugin over and over, sometimes it'll be smooth, sometimes it'll be slow. Probably around 50-50 although I haven't estimated carefully.

To be clear, all of the above is with the Bitwig variant of linvst3-4.77. Without the Bitwig variant, it's all slow all the time.

I tried AudioThing Things:Texture vst3 with Reaper and the LinVst3 I posted in this topic and I couldn't see any problem with cpu spiking or gui smoothness (see below).

I'm using Wine tkg from https://github.com/Kron4ek/Wine-Builds and a very old (10 years or so) laptop with a Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz cpu which is very slow, but I use it for low end testing.

I'm using EndeavorOS and I've also got the Arch Zen kernell installed.

Bitwig is harder to test as all I've got is the demo and I'm not sure how much it's like the full version and Bitwig is not that suited to 10 year laptops in terms of speed and response, but I tried it out in the Bitwig demo and got the same result as with Reaper, no cpu spiking and no gui smoothness problems.

Then I went back to the regular LinVst3 with the original priorities and I did notice some sluggishness with the gui knobs and I know that that is because the gui thread priority is set too low and LinVst 4.78 will use the updated increaded gui priority like the LinVst3 does that is posted in this topic.

The cpu spiking/slowness could be caused some sort of video hardware/software problem, maybe, it's very hard to say for sure.