Open Massimo-B opened 3 days ago
Massimo-B
commented
3 days ago For higher loads I tried to increase quantum. Sometimes that helped in the past while accepting a higher latency, but with easyeffects it seems to get worse after I trying to tinker with quantum like
pw-metadata -n settings 0 clock.force-quantum 1024
or
pw-metadata -n settings 0 clock.force-quantum 2048
wwmm
commented
2 days ago The error column in pw-top indicate xrun errors. In most cases a xrun means that the soundcard is not receiving audio buffers as fast as it would like. In our case this means that for some reason PipeWire is not being able to do it. PipeWire/Pulseaudio apps send buffers to the server and not directly to the soundcard. So for some reason the additional load in PipeWire's realtime thread is being too much for it to handle on your system.
There isn't really much that can be done from the client side. The obvious solution would be to make the plugins code super fast. But besides the fact most of the ones we use come from third party projects they are probably already as optimized as they can be.
Something to try would be to change some server configuration options like ALSA Headroom or changing kernel versions. This has helped some users in the past. It is also worth to identify which plugins contribute the most to the xrun errors and avoiding using them in this machine.
As xrun errors depending strongly on the hardware it is hard to suggest a direct solution. For example on my current desktop even putting all the cores of my Ryzen 7700 under 100% stress test I have zero errors in pw-top while watching youtube videos on Firefox.
wwmm
commented
2 days ago Something I have been doing for years is booting with the kernel option threadirqs. Maybe this is helping somehow to play audio at higher loads. Does it make any difference?
tleb
commented
2 days ago Hi!
There isn't really much that can be done from the client side. The obvious solution would be to make the plugins code super fast. But besides the fact most of the ones we use come from third party projects they are probably already as optimized as they can be.
I've looked at spectrum code as that is the plugin with the most xrun and is implemented by EasyEffects.
What would you think about moving most of the processing to outside the realtime thread? Currently it does the DFT inside the RT thread and hands off a mono double buffer when done.
The idea would be that it would do the left+right average, put that to the end of a buffer and be done for the realtime thread. When the spectrum needs to be rendered, then this is copied and worked on from the thread doing the rendering.
Note: one issue of the current approach is that the DFT is done per process event. This might be much more frequent than needed if the PW quantum is really small. In that case, we would reduce work done in the RT thread but also overall CPU load by avoiding work.
Do you have any thoughts on that? I'll be able to work on that.
A tengant: how expensive are the util::idle_add() calls? There is one at the end of setup() (called when sample rate or quantum changes) and one at the end of process(). I see an allocation then a call to g_idle_add(). That call, I do not know about.
wwmm
commented
2 days ago What would you think about moving most of the processing to outside the realtime thread?
I updated our master branch now moving the fft call to the main thread. Let's see if this helps weaker processors to handle the extra load. The thing is that all this load was already avoided when the window was hidden. So unless all those people having xruns are with EE window always opened I do not expect much change.
A tengant: how expensive are the util::idle_add() calls? There is one at the end of setup() (called when sample rate or quantum changes) and one at the end of process(). I see an allocation then a call to g_idle_add(). That call, I do not know about.
g_idle_add schedules the execution of a function in glib/gtk main thread.
tleb
commented
2 days ago Ah, nice! Thanks.
g_idle_addschedules the execution of a function in glib/gtk main thread.
This sounds like something that requires synchronization and might even be blocking. Nothing great in the audio processing codepath. I see it gets used by most plugins to export results.
wwmm
commented
2 days ago Ah, nice! Thanks.
g_idle_addschedules the execution of a function in glib/gtk main thread.This sounds like something that requires synchronization and might even be blocking. Nothing great in the audio processing codepath. I see it gets used by most plugins to export results.
It does not require blocking or synchronization. And we must use it because of the usual requirement from graphical toolkits about not having other threads messing with widgets. Sooner or later a move to the main thread will have to be done.
tleb
commented
2 days ago It does not require blocking or synchronization.
The underlying implementation is idle_add_full (code). I'm counting two malloc calls in idle_source_new, one in g_source_set_callback and a mutex lock in g_source_attach.
I'm wondering if putting data in the plugin and letting the main thread access it, without creating a new idle task on each process() call, wouldn't be more efficient? I'd be down to attempt a proof-of-concept if you want.
wwmm
commented
2 days ago I'm wondering if putting data in the plugin and letting the main thread access it, without creating a new idle task on each process() call, wouldn't be more efficient? I'd be down to attempt a proof-of-concept if you want.
Besides the fact you would have to rewrite considerable amounts of EE code because what you propose is the opposite of what is done everywhere in EasyEffects code I am skeptical about the performance gains being worth of such a radical change. Looking at perf top output the calls to g_idle_add are not a bottleneck.
And like I said before when the window is hidden (EE in background) none of this code is operational. But some machines will still have xrun. So it is unlikely that the calls to g_idle_add are the source of problem.
wwmm
commented
2 days ago I'm wondering if putting data in the plugin and letting the main thread access it, without creating a new idle task on each process() call, wouldn't be more efficient?
This would probably require to put the main thread in some kind of polling mode. Possibly involving the insertion of our own mutex objects because now we have to worry about what is being done to the data structures inside the plugins. It does not seem very appealing.
EasyEffects Version
7.1.3
What package are you using?
Gentoo
Distribution
Gentoo 23.0
Describe the bug
On higher system loads I have drops and errors in pw-top when running easyeffects. This also happens when CPU is not fully used (about 50%), but with Chrome and a MS Teams session with video. Load AVG is about 20 with some btrfs workers in the back. The issue is usually solved when killing easyeffects. I also disabled the spectrum now as it also did a lot of load.
Expected Behavior
No response
Debug Log
Additional Information