wwmm
Crash on hyprland autostart, but work when launched normally (both in bg)
EasyEffects Version
7.1.8
What package are you using?
Arch (easyeffects)
Distribution
Arch Linux
Describe the bug
on hyprland exec-once(auto launch). i put in easyeffects --gapplication-service for it to launch in bg:
exec-once = easyeffects --gapplication-service
Expected Behavior
it to just launch in bg and not do anything
Debug Log
idk how. but in the sddm wayland-session.log. i see this: (easyeffects:123618): easyeffects-WARNING **: 18:41:57.597: convolver.cpp:342 soe: : irs filename is null. Entering passthrough mode...
Additional Information
No response
idk how. but in the sddm wayland-session.log. i see this: (easyeffects:123618): easyeffects-WARNING **: 18:41:57.597: convolver.cpp:342 soe: : irs filename is null. Entering passthrough mode...
This won't make the app crash. It just means the convolver is in passthrough mode. Considering that it only fails when autostarted my guess is that EasyEffects is being started by hyprland before PipeWire.
idk how. but in the sddm wayland-session.log. i see this: (easyeffects:123618): easyeffects-WARNING **: 18:41:57.597: convolver.cpp:342 soe: : irs filename is null. Entering passthrough mode...
This won't make the app crash. It just means the convolver is in passthrough mode. Considering that it only fails when autostarted my guess is that EasyEffects is being started by hyprland before PipeWire.
hmm. i dont think thats the case. since i have a startup sound(pw-play). And the sound is glitched there(because of the startup of easyeffect & applying effects)
but after that. in btop and pulsemixer, easyeffect is nowhere to be seen
but after that. in btop and pulsemixer, easyeffect is nowhere to be seen
Maybe the system is killing it. What is the output of sudo journalctl -b | grep -i easyeffects right after doing a login?
Sep 16 18:05:07 ArchLinux pipewire[1653]: pw.node: (easyeffects_sink-179) graph xrun not-triggered (0 suppressed)
Sep 16 18:05:07 ArchLinux pipewire[1653]: pw.node: (easyeffects_sink-179) xrun state:0x78696f209008 pending:14/15 s:4140506578123 a:4140506650709 f:4140506671197 waiting:72586 process:20488 status:triggered
Sep 16 18:05:09 ArchLinux pipewire[1653]: pw.node: (easyeffects_sink-179) graph xrun not-triggered (1 suppressed)
Sep 16 18:05:09 ArchLinux pipewire[1653]: pw.node: (easyeffects_sink-179) xrun state:0x78696f209008 pending:5/6 s:4142576817072 a:4142576861765 f:4142576880008 waiting:44693 process:18243 status:triggered
atm, sometimes easyeffects would just randomly quit sometimes.
this is what happens:
i execute easyeffect --gapplication-service
I open spotify, after playing, i quit.
theres a 50% chance that
[1] + 134793 killed easyeffects --gapplication-service
it will get killed???
it seems like easyeffect need some application to keep it busy or else it would get "killed" or quit
sometimes it would survive the launch at autostart, because i open chromium fast enough right before the boot sound quit. and my chrome had yt playing...
any updates?
Not on my side. Here EasyEffects is still fine.
theres a 50% chance that
[1] + 134793 killed easyeffects --gapplication-service
Until some weeks ago several CachyOs users had a similar problem. The system was killing EasyEffects. Eventually an user found out that the reason was that CachyOS had an ananicy rule that was setting all EasyEffects threads to realtime priority. What is something that should never be done. Only the plugins thread needs realtime priority and PipeWire already does that for us automatically.
Maybe something similar is happening on your side. But other factors can make the system kill a process. Like too much memory being used by a process. It is always tough to figure out what causes the system to kill a program.
oh ya i hav ananicy, but i dont have any rules for easyeffects, just for some games and bg processes
oh ya i hav ananicy, but i dont have any rules for easyeffects, just for some games and bg processes
In any case run
chrt -ap
pidof easyeffects
just to be sure only one thread has realtime priority.
u forgot a $() for pidof
but here:
pid 252660's current scheduling policy: SCHED_OTHER
pid 252660's current scheduling priority: 0
pid 252661's current scheduling policy: SCHED_OTHER
pid 252661's current scheduling priority: 0
pid 252662's current scheduling policy: SCHED_OTHER
pid 252662's current scheduling priority: 0
pid 252663's current scheduling policy: SCHED_OTHER
pid 252663's current scheduling priority: 0
pid 252664's current scheduling policy: SCHED_OTHER
pid 252664's current scheduling priority: 0
pid 252665's current scheduling policy: SCHED_OTHER
pid 252665's current scheduling priority: 0
pid 252667's current scheduling policy: SCHED_OTHER
pid 252667's current scheduling priority: 0
pid 252668's current scheduling policy: SCHED_OTHER
pid 252668's current scheduling priority: 0
pid 252669's current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK
pid 252669's current scheduling priority: 20
u forgot a $() for pidof
but here:
pid 252660's current scheduling policy: SCHED_OTHER pid 252660's current scheduling priority: 0 pid 252661's current scheduling policy: SCHED_OTHER pid 252661's current scheduling priority: 0 pid 252662's current scheduling policy: SCHED_OTHER pid 252662's current scheduling priority: 0 pid 252663's current scheduling policy: SCHED_OTHER pid 252663's current scheduling priority: 0 pid 252664's current scheduling policy: SCHED_OTHER pid 252664's current scheduling priority: 0 pid 252665's current scheduling policy: SCHED_OTHER pid 252665's current scheduling priority: 0 pid 252667's current scheduling policy: SCHED_OTHER pid 252667's current scheduling priority: 0 pid 252668's current scheduling policy: SCHED_OTHER pid 252668's current scheduling priority: 0 pid 252669's current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK pid 252669's current scheduling priority: 20
The priorities are fine. So the system should not be killing us because of this. Unless for some unusual reason the plugins thread is taking forever to do its job. Which plugin do you have enabled?
The autogain, the crystalizer and the bass enhancer are among the heaviest plugins provided by EasyEffects. But unless the cpu is very weak the operations done by the plugins in the realtime thread should not last enough for the system to kill us. Hum... Strange...
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
S 29 0 0 --- --- --- --- 0 Dummy-Driver
S 30 0 0 --- --- --- --- 0 Freewheel-Driver
S 47 0 0 --- --- --- --- 0 alsa_output.pci-0000_01_00.1.hdmi-stereo
R 49 2048 48000 5.7ms 62.0us 0.13 0.00 220 S32LE 2 48000 alsa_output.pci-0000_00_1f.3.analog-stereo
R 244 0 0 50.2us 18.1us 0.00 0.00 0 F32P 2 48000 + easyeffects_sink
R 230 0 0 5.2us 32.1us 0.00 0.00 0 + ee_soe_output_level
R 211 0 0 5.7us 33.5us 0.00 0.00 0 + ee_soe_spectrum
R 207 0 0 117.5us 1.7ms 0.00 0.04 9 + ee_soe_autogain
R 169 0 0 7.2us 10.3us 0.00 0.00 0 + ee_soe_convolver
R 134 0 0 3.5us 10.2us 0.00 0.00 0 + ee_soe_crossfeed
R 200 0 0 4.0us 2.6ms 0.00 0.06 1 + ee_soe_crystalizer
R 149 0 0 7.6us 15.6us 0.00 0.00 0 + ee_soe_expander
R 114 0 0 5.3us 13.5us 0.00 0.00 0 + ee_soe_exciter
R 225 0 0 5.8us 13.9us 0.00 0.00 0 + ee_soe_maximizer
R 223 0 0 4.6us 660.3us 0.00 0.02 0 + ee_soe_bass_enhancer
R 218 0 0 5.3us 49.9us 0.00 0.00 0 + ee_soe_bass_loudness
R 270 8192 44100 27.5us 161.8us 0.00 0.00 0 F32LE 2 44100 + spotify
S 50 0 0 --- --- --- --- 0 alsa_input.pci-0000_00_1f.3.analog-stereo
S 51 0 0 --- --- --- --- 0 Midi-Bridge
S 43 0 0 --- --- --- --- 0 bluez_midi.server
S 48 0 0 --- --- --- --- 0 alsa_input.usb-046d_Logitech_BRIO_403C18BA-03.analog-stereo
S 77 0 0 --- --- --- --- 0 v4l2_input.pci-0000_00_14.0-usb-0_3_1.0
S 79 0 0 --- --- --- --- 0 v4l2_input.pci-0000_00_14.0-usb-0_3_1.0
S 254 0 0 --- --- --- --- 0 easyeffects_source
I 127 0 0 0.0us 0.0us ??? ??? 0 ee_sie_output_level
I 242 0 0 0.0us 0.0us ??? ??? 0 ee_sie_spectrum
S 125 0 0 --- --- --- --- 0 ee_test_signals```
Nothing out of the ordinary in the pw-top output. And the target server latency of 2048 / 48000 = 43 ms should be fine. Honestly I have no idea why the system is killing EasyEffects on your computer.
log.txt logs from crash(coredumpctl)
The amount of
Failed to register: Unable to acquire bus name 'com.github.wwmm.easyeffects'
is suspicious. Could it be that hyprland and the dconf service are not playing nice to each other? EasyEffects needs dconf service to already be running before EasyEffects starts. Usually this is done automatically by the desktop environment. Or at least it is in GNOME and KDE.
I think its just becuz i am using a while true; loop to auto restart easyeffect when it crash. and when it crash. it will not unregister it? because the first easyeffects log doesnt have that. im using hyprland
and when it crash. it will not unregister it?
It is still strange. EasyEffects does not do this registration directly. This is gtk or glib job. Something that lower level libraries are trying to do is failing.
I think it's cause of inactivity timeout?
The inactivity timeout in EasyEffects is related to something entirely different. It is used to unlink the filters in the effects pipeline. It won't make the errors in your logs or forbidding the app from starting. Most likely the problem is coming from a lower level library and its interaction with hyprland. EasyEffects is just taking collateral damage.
I do not remember the issue title but in the past users of less popular desktops had similar problems with EasyEffects autostart on login because dconf service was not being started by the desktop before EasyEffects. That is why I suspected about it. But if dconf is being started by hyprland on login before EasyEffects then something else must be going on.
im using xdph and xdp-gtk.
hmm. i dont think thats the case. since i have a startup sound(pw-play). And the sound is glitched there(because of the startup of easyeffect & applying effects)
and if i open spotify and play it before it crash. it wont crash...
its just crashing when no audio is playing
A temporary workaround to write a script to delay launching easyeffects a bit on startup. Something as simple like this seems to allow easyeffects to start up.
sleep 3s
easyeffects --gapplication-service
sleep 1s # wait until it starts to apply eq settings
easyeffects -l eq
I could never have easyeffects trivially startup with Hyprland. I always had to delay it some how.
I could never have easyeffects trivially startup with Hyprland. I always had to delay it some how.
Usually when a delay fixes the problem the reason is the desktop starting EasyEffects before PipeWire. I do not know how KDE and GNOME avoid this. I've never had this kind of issue on them.
Usually when a delay fixes the problem the reason is the desktop starting EasyEffects before PipeWire. I do not know how KDE and GNOME avoid this. I've never had this kind of issue on them.
Well, I suppose pipewire systemd user service should be already started when the desktop system is attempting to launch the autostarting apps. The question is why this does not happen on hyprland.
