On my Arch Linux 12-core desktop, on a fresh start of Ardour with a new project without any plugins the top command shows Ardour using around 4% of a core. After I add the Sonobus plugin, Ardour usage jumps to 13% of a core. But then opening the GUI results in Ardour using around 75% of a core and Xorg usage going up from around 1% to an ridiculous 60% of a core.
However if I run SonoBus VST3 inside Ardour 6.6 in WINDOWS, the SonoBus GUI is very responsive and I don’t notice heavy CPU usage:
Windows Task Manager says Ardour alone uses just under 1% total processsor utilization on clean start. When I add SonoBus VST without its GUI open, Ardour CPU usage is around 1.4% total processsor utilization. When I open SonoBus VST’s GUI, cpu usage only goes to around 1.7% total processsor utilization.
Curiously when I try SonoBus VST3 inside Carla host in Linux, I don’t notice any CPU hogging either. And from other users on the SonoBus forum have said the SonoBus VST3 runs fine in Reaper in Linux.
So as far as I can gather, this GUI performance bug only happens when hosted in Ardour in Linux. Why Ardour Linux but not Ardour Windows, I don’t know. I’m trying to debug this issue so any pointers please let me know. I am able to build debug modes of both Ardour in qtcreator and of SonoBus in qtcreator, though I don’t really know to debug running the SonoBus vst plugin inside Ardour.
(as an aside, if anyone can point me to how to use waf to build debug mode and run via debug mode in qtcreator so I can set breakpoints, that would be nice. I guess I must have lied when I earlier said I could run debug mode in qtcreator…seems I can build and run, but not debug)
The default build is debuggable (unless you explicitly use ./waf configure --optimize ...), and the easiest is to run it in gdb directly from the source-tree: ./gtk2_ardour/ardbg
I don’t know nor use qtcreator, so I cannot help you with that end.
PS. For debugging I also recommend to use Audio-System: Dummy. That can halt and allows single-stepping without any interference of realtime audio threads.
What I’m looking at now that seems suspicious is that the following two functions keep alternatively hitting the breakpoint I set at the start of their function:
This type of “view size” function seems like something that should only happen like once at start and then whenever use modifies the view size. Not continuously.
And the _req_width is always 1140 and _req_height is always 660. So the view size is not actually changing…
I’m noticing the CHOW plugin doesn’t allow me to resize it with the mouse by putting mouse near the corner. But the SonoBus plugin does allow me to resize it with the mouse.
So maybe I should try another JUCE plugin that has resize ability, and see if it is affected as well, so I can determine if this problem is SonoBus-specific or rather happens with any resizable JUCE VST3 plugin. I’m not familiar with VST3 plguins, so I will just try installing a few to find one.