wwmm
Very high CPU usage while the GUI is open since EasyEffects 8.x
EasyEffects Version
8.0.6
What package are you using?
Flatpak (Flathub)
Distribution
Linux raspberrypi 6.12.25-rt14-v8-16k+
Describe the bug
First of all, thank you for your continued work on EasyEffects. I really appreciate the ongoing development and improvements.
I previously mentioned this behavior briefly in another thread, but I would like to formally report it here as a separate issue.
Since EasyEffects 8.x, I am seeing very high CPU usage (around 90% or more) while the GUI is open. As a result, EasyEffects sometimes terminates unexpectedly. With version 7.2.5 and earlier, CPU usage on the same system and with the same configuration was typically around 20%.
Observations so far:
-
CPU usage is very high while the GUI window is open. Once the GUI is closed and EasyEffects continues to run in the background, CPU usage drops back to around 20%.
-
This behavior occurs regardless of whether the audio signal routing is set to Input or Output. Simply opening the GUI causes the CPU usage to increase significantly.
-
While the GUI is open, toggling the spectrum analyzer ON/OFF does not produce a significant change in CPU or GPU load.
-
According to observations using pw-top, the processing time of individual plugins does not appear to change when the GUI is opened or closed. This suggests that the increased CPU usage is likely occurring outside the audio processing plugins, possibly within the GUI layer itself.
These are the results of my testing so far. If there are additional diagnostics I should perform, please let me know — I am happy to help investigate and provide further information.
Expected Behavior
No response
Debug Log
Debug Log
Paste your log here
Additional Information
No response
While the GUI is open, toggling the spectrum analyzer ON/OFF does not produce a significant change in CPU or GPU load.
That is odd. Drawing the spectrum is probably the heaviest operation done by the window when it comes to drawing something in the screen.
Our preferences window now has a setting that allows the fps cap applied to the spectrum and level meters drawing to be configured. What happens if you set them to just 1 fps?
Try to run
sudo perf top -p
pidof easyeffects
.It may not give full information without using a binary built with debug symbols but it should give some idea about which functions are being called the most.
Does activating the Pipewire tab changes CPU usage? On my computer showing it has the same on the CPU usage as closing the window.
Here is an additional observation I discovered during further testing. It may help narrow down the cause of the high CPU usage when the GUI is open.
As previously reported, CPU usage becomes very high when the EasyEffects GUI is visible. However, I found a very strange behavior:
If I open a web browser such as Chromium or Firefox and switch it to full-screen mode, the CPU usage immediately drops to below 20%, even though the EasyEffects GUI is still running in the background (not closed, just hidden behind the browser window).
When I exit the browser’s full-screen mode and the EasyEffects window becomes visible again, the CPU usage jumps back up to the very high level.
This phenomenon does not only occur with web browsers. If I open LibreOffice and switch it to full-screen mode, the CPU usage also drops to the low level. Again, EasyEffects is still running; it is simply hidden behind the full-screen window.
This suggests that the high CPU usage may be related to GUI repainting only while the EasyEffects window is visible on screen, and not merely because the GUI process is active.
In response to your questions:
• The spectrum FPS I tested values from 1 to 120, but there was no noticeable change in CPU/GPU usage.
• Does activating the PipeWire tab change CPU usage? Yes. When the PipeWire tab is active, the CPU usage becomes low — the same as when the GUI is completely closed.
If you need additional traces, perf output, or further testing, I am happy to help.
When the PipeWire tab is active, the CPU usage becomes low — the same as when the GUI is completely closed. I tested values from 1 to 120, but there was no noticeable change in CPU/GPU usage.
In the audio section there is another fps cap that affects the level meters. But it does not seem that it will make any difference. This may be a Qt bug that affects the ARM architecture. The difference between pipewire's tab and the others is that the input/output tab has a few Qt frame animation objects that are used to call the functions that draw the spectrum and the level meters.
If the reason for high cpu usage were the calculation required by the spectrum and the level meter or even the window repainting reducing the fps cap should have made a difference. But as it does not it feels like some kind of bug affect Qt's frame animation. And considering I do not see something like this on my computers my guess is that it is a Qt bug that affects the raspberry architecture.
If I remember well the frame animation callback is supposed to be invoked at the monitor's refresh rate. Maybe something weird is happening and Qt is trying to go way beyong that and overloading the cpu.
If you need additional traces, perf output, or further testing, I am happy to help.
It may be interesting to run
sudo perf top -p
pidof easyeffects
so we have an idea about which function is being called more often.
Here is a short summary of what the perf top results show:
Most of the CPU time is spent inside [JIT] code, not in EasyEffects DSP functions. This strongly suggests the load comes from Qt/QML rendering or animation logic.
Several libgallium entries appear near the top, which indicates the GUI is triggering GPU-accelerated redraws at a very high frequency.
__tz_compute (libc) shows up consistently around ~4%, which is unusual and may point to repeated time/locale queries inside the GUI loop.
Taken together, these results support your hypothesis that Qt’s frame animation callback may be firing far more often than intended on ARM, rather than spectrum/meter computation being the bottleneck.
I can provide deeper profiling (e.g., perf record -g) if that would help.
############## Log ################## mac@raspberrypi:~/rpi-linux-6.12.25/tools/perf $ sudo ./perf top -p $(pidof easyeffects)
PerfTop: 11295 irqs/sec kernel: 0.7% exact: 0.0% lost: 0/0 drop: 0/0 [4000Hz cycles:P], (target_pid: 1219)
6.24% [JIT] tid 1219 [.] 0x00007fff3639c1f4
4.17% libc.so.6 [.] __tz_compute
2.89% [JIT] tid 1219 [.] 0x00007fff3639c160
1.98% [JIT] tid 1219 [.] 0x00007fff35954620
1.39% [JIT] tid 1219 [.] 0x00007fff359ac1f0
1.00% [JIT] tid 1219 [.] 0x00007fff340142f0
0.70% libgallium-25.2.6.so [.] 0x000000000087c5a8
0.65% [JIT] tid 1219 [.] 0x00007fff3639c854
0.64% libgallium-25.2.6.so [.] 0x0000000000781b80
0.63% libgallium-25.2.6.so [.] 0x0000000000885d98
0.62% [JIT] tid 1219 [.] 0x00007fff3639c384
0.56% [JIT] tid 1219 [.] 0x00007fff36354348
0.53% [JIT] tid 1219 [.] 0x00007fff3639c608
0.53% [JIT] tid 1219 [.] 0x00007fff3639c73c
0.53% [JIT] tid 1219 [.] 0x00007fff3639c50c
0.52% [JIT] tid 1219 [.] 0x00007fff3639c750
0.51% [JIT] tid 1219 [.] 0x00007fff3639c708
0.50% [JIT] tid 1219 [.] 0x00007fff3639c884
0.48% [JIT] tid 1219 [.] 0x00007fff36354218
0.48% [JIT] tid 1219 [.] 0x00007fff3639c6d4
0.47% [JIT] tid 1219 [.] 0x00007fff3639c9bc
0.47% [JIT] tid 1219 [.] 0x00007fff3639c6a8
0.46% [JIT] tid 1219 [.] 0x00007fff3639c3cc
PerfTop: 11523 irqs/sec kernel: 0.5% exact: 0.0% lost: 0/0 drop: 0/0 [4000Hz cycles:P], (target_pid: 1219)
6.35% [JIT] tid 1219 [.] 0x00007fff3639c1f4
4.15% libc.so.6 [.] __tz_compute
2.89% [JIT] tid 1219 [.] 0x00007fff3639c160
2.00% [JIT] tid 1219 [.] 0x00007fff35954620
1.29% [JIT] tid 1219 [.] 0x00007fff359ac1f0
1.00% [JIT] tid 1219 [.] 0x00007fff340142f0
0.72% libgallium-25.2.6.so [.] 0x000000000087c5a8
0.66% [JIT] tid 1219 [.] 0x00007fff3639c854
0.66% libgallium-25.2.6.so [.] 0x0000000000781b80
0.64% [JIT] tid 1219 [.] 0x00007fff3639c384
0.64% libgallium-25.2.6.so [.] 0x0000000000885d98
0.57% [JIT] tid 1219 [.] 0x00007fff3639c1c0
0.53% [JIT] tid 1219 [.] 0x00007fff3639c50c
0.51% [JIT] tid 1219 [.] 0x00007fff36354348
0.51% [JIT] tid 1219 [.] 0x00007fff3639c9bc
0.51% [JIT] tid 1219 [.] 0x00007fff3639c750
0.51% [JIT] tid 1219 [.] 0x00007fff3639c608
0.50% [JIT] tid 1219 [.] 0x00007fff3639c708
0.50% [JIT] tid 1219 [.] 0x00007fff36354218
0.50% [JIT] tid 1219 [.] 0x00007fff3639c73c
0.48% [JIT] tid 1219 [.] 0x00007fff3639c884
0.48% [JIT] tid 1219 [.] 0x00007fff3639c95c
0.47% [JIT] tid 1219 [.] 0x00007fff3639c6d4
PerfTop: 12354 irqs/sec kernel: 0.6% exact: 0.0% lost: 0/0 drop: 0/0 [4000Hz cycles:P], (target_pid: 1219)
6.26% [JIT] tid 1219 [.] 0x00007fff3639c1f4
4.12% libc.so.6 [.] __tz_compute
2.84% [JIT] tid 1219 [.] 0x00007fff3639c160
1.88% [JIT] tid 1219 [.] 0x00007fff35954620
1.29% [JIT] tid 1219 [.] 0x00007fff359ac1f0
0.98% [JIT] tid 1219 [.] 0x00007fff340142f0
0.71% libgallium-25.2.6.so [.] 0x000000000087c5a8
0.68% [JIT] tid 1219 [.] 0x00007fff3639c854
0.67% [JIT] tid 1219 [.] 0x00007fff3639c384
0.66% libgallium-25.2.6.so [.] 0x0000000000885d98
0.63% libgallium-25.2.6.so [.] 0x0000000000781b80
0.57% [JIT] tid 1219 [.] 0x00007fff3639c1c0
0.52% [JIT] tid 1219 [.] 0x00007fff36354348
0.52% [JIT] tid 1219 [.] 0x00007fff3639c884
0.52% [JIT] tid 1219 [.] 0x00007fff3639c9bc
0.51% [JIT] tid 1219 [.] 0x00007fff3639c50c
0.51% [JIT] tid 1219 [.] 0x00007fff3639c95c
0.51% [JIT] tid 1219 [.] 0x00007fff3639c608
0.50% [JIT] tid 1219 [.] 0x00007fff3639c750
0.48% [JIT] tid 1219 [.] 0x00007fff3639c708
0.47% [JIT] tid 1219 [.] 0x00007fff3639c73c
0.47% [JIT] tid 1219 [.] 0x00007fff3639c6d4
0.47% [JIT] tid 1219 [.] 0x00007fff36354218
PerfTop: 12432 irqs/sec kernel: 0.6% exact: 0.0% lost: 0/0 drop: 0/0 [4000Hz cycles:P], (target_pid: 1219)
6.23% [JIT] tid 1219 [.] 0x00007fff3639c1f4
4.13% libc.so.6 [.] __tz_compute
2.87% [JIT] tid 1219 [.] 0x00007fff3639c160
1.92% [JIT] tid 1219 [.] 0x00007fff35954620
1.33% [JIT] tid 1219 [.] 0x00007fff359ac1f0
0.98% [JIT] tid 1219 [.] 0x00007fff340142f0
0.71% libgallium-25.2.6.so [.] 0x000000000087c5a8
0.67% [JIT] tid 1219 [.] 0x00007fff3639c384
0.65% [JIT] tid 1219 [.] 0x00007fff3639c854
0.64% libgallium-25.2.6.so [.] 0x0000000000885d98
0.62% libgallium-25.2.6.so [.] 0x0000000000781b80
0.56% [JIT] tid 1219 [.] 0x00007fff3639c1c0
0.53% [JIT] tid 1219 [.] 0x00007fff3639c750
0.51% [JIT] tid 1219 [.] 0x00007fff3639c95c
0.51% [JIT] tid 1219 [.] 0x00007fff36354348
0.51% [JIT] tid 1219 [.] 0x00007fff3639c608
0.51% [JIT] tid 1219 [.] 0x00007fff3639c9bc
0.50% [JIT] tid 1219 [.] 0x00007fff3639c884
0.49% [JIT] tid 1219 [.] 0x00007fff3639c50c
0.49% [JIT] tid 1219 [.] 0x00007fff3639c73c
0.49% [JIT] tid 1219 [.] 0x00007fff3639c6d4
0.49% [JIT] tid 1219 [.] 0x00007fff3639c65c
0.49% [JIT] tid 1219 [.] 0x00007fff3639c708
For reference this is what I see on my system when effects are disabled and the only thing changing in our window is the spectrum:
__tz_compute (libc) shows up consistently around ~4%, which is unusual and may point to repeated time/locale queries inside the GUI loop.
It is very unusual. What is printed by Qt when you run QSG_INFO=1 easyeffects? Is Qt using the gpu backend or the CPU for rendering?
Is there any change between QSG_RENDER_LOOP=threaded easyeffects and QSG_RENDER_LOOP=basic easyeffects?
I am not sure if vulkan is an option in the raspberry. But if yes it may be worth testing with QSG_RHI_BACKEND=vulkan easyeffects. I think that it is not recommended to use Qt's vulkan backend yet. But who knows... Maybe it helps.
Most of the CPU time is spent inside [JIT] code, not in EasyEffects DSP functions.
An interesting detail is that my perf output has no line starting with [JIT]. Even after scrolling to see the rest of perf output the only ones I see are like [kernel], [amdgpu] and [gpu_sched]. It seems safe to assume Qt's is not doing in the raspberry the same optimizations it does in other architectures.
Another important detail is that I am not using the flatpak package. I wonder if it could be contributing to the difference in our perf's outputs. What do you see when running perf top @vchernin ?
It might be the same situation as https://stackoverflow.com/questions/47899501/raspbian-qml-bad-performance.