easyeffects killed by DBUS without any reason #3450
Comments
|
After some investigations i can easily recreate issue using telegram-desktop application : easyeffect killed by systemd after pause video and start video playback again . |
|
What is the output of |
Hi thanks for your reply . This is output from easyeffects : |
|
The scheduling priorities are fine. So that is not the source of problem. Which plugins are you using in the effects pipeline? Maybe the system was not fast enough to handle them in the realtime thread and the system killed EasyEffects. But it is hard to see this happening in a recent CPU. Here on my Arch Linux installation I've never seen the system killing EasyEffects. So there must be something different on Manjaro triggering this. The question is what. |
|
i using autogain(MS)->limiter . Well i have i7-14700KF i think it is more than enough. Especisally that it is idle andnot have any another tasks. PS: i know about modern issues with core i7 but i almost sure that this is not an issue. |
This CPU should not have issues with any of the plugins in EasyEffects. I wish the system printed the reason why it kills the process. Some weeks ago several users were having a similar issue but in that case the problem was the presence of ananicy rules that were doing something they should not to do to EasyEffects priorities. But this isn't the case here. Based on the kill message a memory leak also does not seem to be the case =/ |
|
Today got bit more details : During youtube playback got core : PS: sorry after some investigation i found that this is another issue. |
Maybe these issues are related. Problems in glib can hit EasyEffects depending on what it is. |
|
hi. In my original issue that systemd send kill signal to easyeffect it is not crashing. Core dump happend only once before it never happend . Can it be that in a moment when you register service with dbus some parameters wrong installated and systemd detect it as bogus or zombie and send kill ? Is it possible somehow unbind from systemd relation ? Look what interesting thing i found : In case if i attach to easyeffects with strace using : strace -p -ff -o sss i cannot recreate issue anymore. |
As the registration isn't done by EasyEffects code but by glib/gtk even if this is the source of the problem it can not be fixed on our side.
Hum... I can understand this making a difference when there is a segmentation fault caused by thread racing. Running through strace will probably change the timing between threads events. But I do not see how this can make the system to not kill the process. Usually taking too long using critical resources is what makes the system kill a process. |
|
Is it possible somehow to disable autokill ? i see that most often EE killed if exist "output_level.cpp:45 soe: output_level: PipeWire blocksize: 512" if blocksize bigger kill almost never happens. extra trace |
Maybe. I never tried to disable the
Hum... Maybe it just happens to be the last print before whatever is actually triggering the issue. Even if the delete that comes after easyeffects/src/node_info_holder.cpp Line 104 in 9471a39 |
|
Hi . I have a new findings. |
Hum... I did not consider that the kill signal could have different sources... Are you using the stable repository package or the AUR package? I do not remember if you have already given this information. It may be worth to install the AUR package if you have not tried that yet. |
|
Did extra debug using PIPEWIRE_DEBUG=3 easyeffects And this is output on journald : |
|
As far as I remember the node missing 1 or 2 wakeup should not cause the system to kill the process. Most installations out there probably also have 1 or 2 missed wakeups from time to time. It depends on the system load and on what pipewire is doing internally. As well as on as heavy the plugin is. The libebur128 library used in the autogain can be very CPU intensive compared to the other libraries we use. |
|
I don't know if related but i also am on Manjaro and in my case, easyeffects is killed when i introduce an equalizer (dependent on lsp-plugins package) and start playing audio. It could be any audio from any source, immediately kills easyeffects. If i remove the equalizer, everything works as expected. I also have "bass enhancer" and "stereo tools" (both provided by calf) in my effects pipeline and they work without issues. EQ (lsp) causes the crash of the whole app. |
@glanduin which parameters have you changed in the equalizer configuration? |
|
I did not manually change anything but instead, i downloaded a "preset" from https://autoeq.app/ This preset is made spesifically for easyeffects and i loaded it as "APO" (as specified). It loaded succesfuly and i can see the eq parameters changed. I am suspecting some kind of clash between the LSP plugin package and pipewire maybe. Because this doesn't happen with CALF plugins. But i honestly did not test any other plugin from the LSP package, so i am probably wrong. |
Most likely the preset changed only the number of bands and the corresponding settings without putting the equalizer into heavier modes of operations. So it should be fine. Sometimes the system kills a process because it took too long to finish operations executed in a realtime thread. This may explain why only this plugin is causing problems for you. Do you see many errors in the output of |
|
I did this configuration : PS. And yes i almost sure that problem with autogain plugin because in pw-top i see most of errors on ee_soe_autogain. PSS: Today got KIlled with following (happened in moment when i pressed pause button on youtube ie playback was good and crashed after i pressed pause) : |
The numbers you are seeing just represent the requested latency. PipeWire may or not switch to them. The line that matters is the one for your soundcard. This is the quantum PipeWire will use.
The main reason why this plugin is heavy is that the library @jpVm5jYYRE1VIKL have you ever installed ananicy or something else that could be messing with EasyEffects threads priorities? Run the command |
|
hi. @wwmm
This action blocked HDMI sound destination . I have multiply monitors but not using monitors output for sound processing. May be it will be good to add faq advice to block extra sound outputs even if it is not used. As i see it indirectly influence on EE even if not used and even if sound never directed to such output. May be nvidia driver ? I ll test more and report. At the moment, the situation with hdmi block is very encouraging. |
Sounds like a bug in the driver or in how PipeWire is handling your devices. Besides my onboard card I also have my monitor audio hdmi device enabled without any side effect. |
|
After couple days of testing i can say that EE still killed but situation dramatically improved. |
The difference is probably the realtime thread EasyEffects uses for the plugins audio processing. Maybe somehow the CPU is not being fast enough to initialize the plugin within the time PipeWire configures for realtime threads. But as far as I remember PipeWire sets a really large timeout. |
EasyEffects Version
7.1.8
What package are you using?
Other (specify below)
Distribution
manjaro
Describe the bug
normally using easyeffects and random moments it just close.
Expected Behavior
must work
Debug Log
Debug Log
Additional Information
in journalctl it show soemthing like this :
The text was updated successfully, but these errors were encountered: