SonoBus VST3 GUI hogs CPU only when ran inside Ardour on Linux (but not Windows)

Installation & Configuration Linux
#1

I’m trying to figure out why SonoBus (GitHub - essej/sonobus: Source code for SonoBus, a real-time network audio streaming collaboration tool.) when run as a VST3 inside Ardour 6.6 in LINUX 5.11.2, the SonoBus GUI is very sluggish and I notice heavy CPU usage:

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.

#2

yep, see also Recording remotely via network - #5 by jesse

1 Like
#3

I’d probably start adding some printf() in the X11 Runloop:

or check if the plugin uses timers instead of callbacks. Those have a low priority:

This is VST3/Linux specific. For Windows and macOS the runloop integration happens on system level.

1 Like
#4

PS. try changing the events perhaps comment out | G_IO_ERR | G_IO_HUP in

@jesse may also have some insight.

#5

I tried commenting out those two flags, though I still see Xorg process taking ~50% of a core. And I still notice the sluggish behavior of the GUI.

#6

I put printf(“registerEventHandler\n”) and printf(“registerTimer\n”) at the top of those corresponding functions.

Rebuilt and ran and I don’t see any printf output when I add the SonoBus plugin, though when I remove the SonoBus plugin I see:

registerEventHandler
registerEventHandler
PluginWindow deleted for 0x56300aa066f0
aoo_client: not connected
aoo_client: not connected

So it seems that the Timer is not being used.

#7

(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)

#8

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.

#9

Am noticing VST3X11Runloop:registerEventHandler() gets called twice when adding a VST3 plugin, with this same call stack:

image
image515×637 63.3 KB

Happens either with SonoBus VST3 plugin or CHOW VST3 plugin. I’m still familiarizing myself with the code, but this looks fishy.

#10

Curiously, the first time in registerEventHandler the variables initially look like:

image

The second time the variables initially look like:

image

And then upon deleting the SonoBus plugin, then unregisterEventHandler() only gets called once, with this initial state of the variables:

image

#11

This is JUCE’ doing. A plugin registers itself twice yet unregisters only once:

#12

ok, well that commit (prevent registering multiple identical file descriptors · Ardour/ardour@c075d3a · GitHub) is included in the current master code I’m working with. And that if statment is skipped over both times, so the subsequent registering happens twice still.

#13

I guess the “fd” file descriptor variable is different on each call (48 first time, 52 second time).

#14

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:

VST3X11PluginUI::view_size_request()
VST3X11PluginUI::view_size_allocate()

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…

#15

CHOW on the other hand only calls those resize functions just a few times initially, but after startup complete will run fine forever.

So somehow the SonoBus is producing a constant stream of way too many resize triggers.

1 Like
#16

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.

#17
#18

Robin, should I try that PR and see if it works?

#19

Preferably re-compile sonobus with VST3 in Ardour on Linux - resizing fix by ctsexton · Pull Request #867 · juce-framework/JUCE · GitHub

1 Like
#20

ok will do…skimming that PR and sounds like the problem lies with JUCE.