jamesdsp shuts down by itself

[boranity]

For example, I turn off the song, I start watching the video, then when I alt-tab, when I look at it, jamesdsp is closed.

[FZXizzbKv7jg]

Hi,

confirm.

[1] 367091 killed jamesdsp

After playing a song has finished.

Further, the audio pipeline always has to be reloaded after starting JamesDSP again.

[hydrocat]

this happens to me too.
This is the initial log messages when I start if from the terminal:

[16:50:48.233] [INF] main::main: Application version:  (Pipewire flavor)
[16:50:48.233] [INF] main::main: Qt library version: 5.15.10
[16:50:48.233] [INF] main::main: Using language: en_US
[16:50:48.233] [DBG] main::main: Launched by system session manager: no
[16:50:48.234] [INF] SingleInstanceMonitor::isServiceReady: Service registration successful
[16:50:48.341] [INF] MainWindow::MainWindow$ctor: ============ Initializing audio service ============
[16:50:48.341] [INF] MainWindow::MainWindow$ctor: Compiled with PipeWire support.

and before being killed:

16:51:25.297] [DBG] PwPipelineManager::on_registry_global: Stream/Output/Audio 78 Firefox with serial 5590 has been added
[16:51:25.300] [DBG] AppConfig::isAppBlocked: Firefox is not blocked
[16:51:25.302] [DBG] PwPipelineManager::on_metadata_property: new metadata property: 78, target.node, Spa:Id, 154
[16:51:25.302] [DBG] PwPipelineManager::on_metadata_property: new metadata property: 78, target.object, Spa:Id, 5556
[16:51:25.312] [DBG] PwPipelineManager::on_registry_global: Firefox port 148 is connected to jamesdsp_sink port 152
[16:51:25.312] [DBG] PwPipelineManager::on_registry_global: Firefox port 150 is connected to jamesdsp_sink port 213
[16:51:25.314] [DBG] FilterContainer::on_link_changed: At least one app linked to our device wants to play. Linking our filters.
[16:51:25.317] [DBG] PwBasePlugin::connect_to_pw: @PwJamesDspPlugin: JamesDsp successfully connected to PipeWire graph
[16:51:25.352] [KNL] Log::kernel: EffectDSPMain: Buffer size changed, update convolution object to maximize performance
[16:51:27.012] [DBG] PwPipelineManager::on_destroy_node_proxy: Stream/Output/Audio 78 Firefox has been removed
[16:51:35.632] [DBG] FilterContainer::on_link_changed::<lambda>: No app linked to our device wants to play. Unlinking our filters.
[16:51:35.632] [DBG] FilterContainer::disconnect_filters: disconnecting the JamesDsp filter from PipeWire
[16:51:38.623] [KNL] Log::kernel: EffectDSPMain: Benchmark done
[16:51:47.538] [DBG] PwPipelineManager::on_registry_global: Stream/Output/Audio 166 Firefox with serial 5604 has been added
[16:51:47.540] [DBG] AppConfig::isAppBlocked: Firefox is not blocked
[16:51:47.544] [DBG] PwPipelineManager::on_metadata_property: new metadata property: 166, target.node, Spa:Id, 154
[16:51:47.544] [DBG] PwPipelineManager::on_metadata_property: new metadata property: 166, target.object, Spa:Id, 5556
[16:51:47.552] [DBG] PwPipelineManager::on_registry_global: Firefox port 128 is connected to jamesdsp_sink port 152
[16:51:47.552] [DBG] PwPipelineManager::on_registry_global: Firefox port 87 is connected to jamesdsp_sink port 213
[16:51:47.555] [DBG] FilterContainer::on_link_changed: At least one app linked to our device wants to play. Linking our filters.
[16:51:47.558] [DBG] PwBasePlugin::connect_to_pw: @PwJamesDspPlugin: JamesDsp successfully connected to PipeWire graph
[16:51:47.599] [KNL] Log::kernel: EffectDSPMain: Benchmark flag == 1, refreshing convolutions
[16:51:47.599] [KNL] Log::kernel: EffectDSPMain: Buffer size changed, update convolution object to maximize performance
Killed

[nix-shell:~/git/llm-poc]$ 

I wonder if it is breaking beacuse of firefox or the constant connect-disconenct of pipewire clients.

[BxDev]

Have the same bug.

[FZXizzbKv7jg]

With echo "1" > /proc/sys/kernel/print-fatal-signals

I found RT Watchdog Timeout (hard)

Solved by installing realtime-privileges and adding the user to the group realtime.

[medmedin2014]

@ThePBone It's not a problem of priority or privilege, other apps like EasyEffects works fine without any crash and without giving them any kind of privilege, only JamesDSP closes itself, even a simple clicking on next video on YouTube crashes the whole app.

Playing with privilege can cause serious issues of performance for other running desktop apps, especially on medium laptops.

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.114.0
Qt Version: 5.15.12
Kernel Version: 6.7.2-1-MANJARO (64-bit)
Graphics Platform: Wayland

[timschneeb]

other apps like EasyEffects works fine without any crash and without giving them any kind of privilege, only JamesDSP closes itself, even a simple clicking on next video on YouTube crashes the whole app.

EasyEffects is also affected by the same issue: wwmm/easyeffects#2407
The problem isn't a crash, the apps are receiving a kill signal from another place.

I'm still unable to reproduce this issue on my devices, so I don't know how to fix this at the moment properly.

[senjacob]

For me the Flatpak app automatically closed each time spotify song changed in Firefox on Kubuntu 23.10 (X11, QT5.15.10, Kernel 5.5.0.21-generic 64-bit)

Editing the below desktop file and changing Terminal=true fixed the issue for me.

/var/lib/flatpak/app/me.timschneeberger.jdsp4linux/current/active/export/share/applications/me.timschneeberger.jdsp4linux.desktop

[gilcn]

Don't know if it's related or not but I had the same problem until yesterday.
My distro (Arch) updated pipewire from 1.0.3 to 1.0.4 and it seems the issue is gone now.

[medmedin2014]

For me even with pipewire 1.0.4, the crash is always present with JamesDSP while EasyEffects is not getting at all killed.

[gilcn]

For me even with pipewire 1.0.4, the crash is always present with JamesDSP while EasyEffects is not getting at all killed.

I thought the problem was fixed but I just had jamesdsp killed right now.
Sorry about the noise.

[Exordio]

Hi all, jamesdsp works stably for me - until I turn on xscreensaver. As soon as I turn it on, jamesdsp catches kill, but I can’t figure out from whom. Can anyone tell me what to do in such a situation?