Please add a way to limit GUI refresh rate

[Efenstor]

Thank you for the amazing plugin set! I use Debian stable (bookworm) with the latest Ardour. My problem is that GUI overloads the CPU, so I can barely use any plugin at all. If I disable vsync (TearFree) in the xorg settings and turn off the analysis then the responsiveness becomes better but still far from perfect. The responsiveness of the plugin GUI itself is good but Ardour at the background becomes very slow. I use the hi-dpi monitor, so the interface is scaled to 200%, and I guess it makes things even worse. I have this problem on both of my machines with any LSP plugin. Sometimes it takes 20-30 seconds for Ardour just to respond to me pressing the "stop" button (or the space key) if the analyzer is on, if it's off then it's useable but obviously could be better (for example none of the Calf plugins has such problems). I think the solution is to limit the GUI refresh rate, may be as a manual option.

[sadko4u]

Hello! The refresh rate of GUI is limited to 25 FPS.
LSP uses cairo for rendering which is pretty OK dealing with hardware resources.
I need more information about your system configuration.
You also may have issues with your graphics driver.

[Efenstor]

I did some more tests and the video card may be a problem indeed, I'll definitely do more testing. My video card is MSI Radeon RX 5600 XT OC with the open-source amdgpu driver (v23.0.0, 20230210-5 firmware). There were some problems with it in the past (random black screens/system reboots) but with the 6.5.10 kernel it finally seems stable. It also caused sound stuttering with my old sound card (PCI MIA Echo), which may or may not be related, but those were gone since I swapped the sound card. In general LSP plugins are now the only piece of software which definitely has some weird issues, Kdenlive (which also uses Cairo), for example, works fine.

[Efenstor]

Now I think the video card is not a problem, it's more to do with process/thread prioritization. The thing is that not the whole system becomes sluggish but only the Ardour GUI: the LSP plugin GUI is updated fine, I can run any other program and it works perfectly but the Ardour GUI is hardly redrawn at all while playback/processing is happening. My CPU is AMD Ryzen 7 2700, it's 8-core but has 16 virtual cores and internal dynamic overclocking. If I set in the Ardour preferences the number of signal processing threads to 7 or 8 and the CPU DMA latency setting to 400 usec it all becomes much less laggy. Too bad only the LSP plugins suffer from this, is there a way to lower their process priority?

[sadko4u]

The host sets the process and thread priority to plugins. LSP Plugins do nothing with this. All created threads are of default priority. If you use LV2 versions, the UI is handled by the host UI thread, see lv2:IdleInterface.
I think it is a good reason to set up the perf tool and watch what's happening on your system by launching perf top.

[Efenstor]

Not sure what to make of it.

Here is "perf top --sort comm,dso" when stopped:

When playing:

and just "perf top" when playing:

It is visible that the Ardour GUI is not redrawn for many seconds after the LSP window has been moved but the whole audio engine keeps playing perfectly.

[Efenstor]

REMOVED

[Efenstor]

Here is how it looks without any LSP plugin in the project:

[Efenstor]

I think now I see, it's really something with libcairo and my system because Calf does not use Cairo to draw anything, as well as any other plugin I use. Somehow it overloads the system. Not sure how to fix it.

[sadko4u]

I see the swapper process is eating too much CPU. It seems that you're having troubles with RAM and memory pages are constantly falling into drive's swap partition.

[Efenstor]

I don't think that's the case:

I can't even imagine why swapper may be so active. The only special thing about my swap partition is that it's LUKS-encrypted but as there's plenty of free RAM that should not be the case. Anyway I'll try to find out what's causing swapper to be so CPU-intensive.

To test out the bad video card theory I've dug out my old Radeon Aero, installed it and nope: the problem is still present, so it's unlikely the X11-amdgpu-libcairo problem.

[sadko4u]

I have Ryzen 4800H CPU with embedded graphics and all works very well. Many other people reported that UI works pretty well. You're the only one who has such problem. I have no idea how to help you at this moment.

[Efenstor]

Solved it:

1. echo "vm.swappiness = 10" >> /etc/sysctl.conf
2. Ardour > Preferences > Performance > Power Management, CPU DMA Latency = Unset
3. (optional, recommended) BIOS > AMD CBS (CPU settings) > C-State (Global C-State Control) = Disabled

Thank you again!

[sadko4u]

@Efenstor
Is there some recommendation you've found in internet?

[Efenstor]

Not quite: first I tried to deal with the swapper problem, here is the discussion on how to lower swappiness when there is enough of memory: https://unix.stackexchange.com/questions/265713/how-to-configure-swappiness-in-linux-memory-management. The second problem was the Ardour's clumsy integrated system of preventing modern CPUs (e.g. Ryzen) from going into the lowered power states (C-states), which also overloaded the swapper by continuously "pumping" the CPU; therefore I've deducted that it's much better to disable it in the BIOS completely.

[Efenstor]

I sorta reopen this issue, because a related problem still remains: when working on a complex project with lots and lots of processing and more than 10 tracks, and if an LSP plugin with analysis display is shown the refresh rate of the Ardour interface drops to about 1 fps (although it is not completely frozen for me anymore after the swapper tweaking). I mean, is the analyzer so important to be displayed with perfect frame rate, while the whole interface in the background becomes sluggish? The interface itself is pretty heavy and I see that it loads the GPU quite a bit when displayed (especially if scaled to 200%). Of course I can turn off the analyzer completely but it's a useful thing after all.

My suggestion is to add:

1. A switch to draw the graphic display elements (analyzer and the inline display) without anti-aliasing and using thin 1px lines ("low graphics mode").
2. If possible, an automatic adaptive refresh rate limit for the analyzer, deducing the value from the current GUI/DSP load or just the overall CPU load (I don't know whether it is possible or not).
3. If not possible, then at least a way to set the limit manually.

[derkrasseleo]

I know this is the opposite of the problem described, but in general some option to adjust the frame rate would indeed be nice. Sometimes I feel like a higher refresh rate (in the analyzer plugins, for example) just makes sense, especially on high refresh rate displays.

[sadko4u]

The main problem with libcairo is that it doesn't like to draw many line segments. I noticed that when worked on the Oscilloscope plugin.
@derkrasseleo there is also difference between the UI refresh rate and the data synchronization rate between DSP and UI. Just increasing the UI refresh rate probably won't give the increase of data synchronization rate and will require more engineering.

[wargreen]

Hi,
I have a similar issue, with very slow refresh rate when 2 plugins GUI (or more) are open.
After some talks with the ardour's team, it seem linked with opengl in many child windows...
I don't know if this can be usefull, so my 0.2 cents :)

[brummer10]

I dont know If you use already, but cairo_push and cairo_pop makes a huge Differenz.

[sadko4u]

@brummer10 how should it help? Do you mean that cairo_push_group and cairo_pop_group should accelerate line drawing calls cairo_move_to and cairo_line_to?

[sadko4u]

I've just updated cairo surfaces to use cairo_surface_create_similar instead of cairo_image_surface_create. Also I changed antialiasing mode from GOOD to FAST and pushed changes to devel branch.
@Efenstor @wargreen @derkrasseleo are you available to build from devel branch and test if something has changed?

[brummer10]

@brummer10 how should it help? Do you mean that cairo_push_group and cairo_pop_group should accelerate line drawing calls cairo_move_to and cairo_line_to?

It minimize the calls to th Graphik Server.

[Efenstor]

@Efenstor @wargreen @derkrasseleo are you available to build from devel branch and test if something has changed?

I've built it now (v1.2.16); may be there is an improvement but it's obviously not too drastic, the main Ardour canvas is still quite visibly lagging when the analyzers are on and is redrawn smoothly when they are off. The idea with cairo_push_group and cairo_pop_group is definitely worth a try, may be different drivers behave differently when it comes to initialization/uninitialization of hardware resources.

[derkrasseleo]

I've just updated cairo surfaces to use cairo_surface_create_similar instead of cairo_image_surface_create. Also I changed antialiasing mode from GOOD to FAST and pushed changes to devel branch. @Efenstor @wargreen @derkrasseleo are you available to build from devel branch and test if something has changed?

I tried building from devel branch but got this error at the end of the build:

cp: regular file '/usr/local/lib/pkgconfig/lsp-r3d-glx-lib.pc' cannot be created: No permission
make[5]: *** [Makefile:165: install] Error 1
make[5]: Directory "/home/leo/documents/git/lsp-plugins/modules/lsp-r3d-glx-lib/src" is left
make[4]: *** [Makefile:53: install] Error 2
make[4]: Directory "/home/leo/documents/git/lsp-plugins/modules/lsp-r3d-glx-lib" is exited
make[3]: *** [Makefile:1140: install_LSP_R3D_GLX_LIB] Error 2
make[3]: Directory "/home/leo/documents/git/lsp-plugins/modules/lsp-plugin-fw/src" is exited
make[2]: *** [Makefile:67: install] Error 2
make[2]: Directory "/home/leo/documents/git/lsp-plugins/modules/lsp-plugin-fw" is exited
make[1]: *** [Makefile:145: install] Error 2
make[1]: Directory "/home/leo/documents/git/lsp-plugins/src" is exited
make: *** [Makefile:68: install] Error 2

[sadko4u]

@derkrasseleo you need root privileges to run make install.

[derkrasseleo]

@derkrasseleo you need root privileges to run make install.

I've built them successfully but haven't noticed any change in framerate so far.