EasyEffects audio quality degrades after pausing/resuming playback (convolver-based preset)

[guillermomirandagar]

EasyEffects Version

EasyEffects 8.1.2

What package are you using?

Other (specify below)

Distribution

Kubuntu 26.04 (apt, Origin: Ubuntu) — easyeffects 8.1.2+ds-1

Describe the bug

Environment:

Kubuntu 2604 (KDE Plasma, Wayland)
EasyEffects 8.1.2
PipeWire + WirePlumber 0.5.13
Preset: converted Dolby Atmos profile via speaker-tuning-to-easyeffects (Convolver using a Dolby-Balanced.irs impulse response, plus Equalizer, Multiband Compressor, Limiter in the chain)

Issue:
Audio through the EasyEffects chain sounds correct immediately after login/EasyEffects startup. After pausing audio/video playback (e.g. in Firefox) and resuming, the output becomes noticeably degraded — quieter, more distant/muffled, slightly distorted — without EasyEffects crashing or fully dropping the stream.
What I've ruled out:

Not a PipeWire xrun/CPU bottleneck — pw-top shows 0 ERR and CPU usage is normal during/after the issue.
Not a sample rate mismatch — rate stays consistent (48000) across working and degraded states in pw-top.
Not a routing/bypass issue — confirmed via qpwgraph that the signal path (Firefox → Easy Effects Sink → Convolver → EQ → Multiband Compressor → Limiter → physical speaker) remains fully linked after pause/resume.
Multiple EasyEffects processes was a red herring from manually relaunching the app during testing, not a startup bug.

This preset was generated using https://github.com/antoinecellerier/speaker-tuning-to-easyeffects, which converts a Windows Dolby Atmos APO config into an EasyEffects convolver-based preset.

What I observed:

In pw-top, after a pause/resume cycle, the ee_soe_* filter chain nodes (and easyeffects_sink) sometimes show status I (idle) instead of R (running), even though the graph connections in qpwgraph remain intact and audio is technically still passing through.
This pattern is consistent with PipeWire/WirePlumber's idle-node auto-suspend behavior (node/suspend-node.lua, default 5s idle timeout) suspending the convolver chain on pause, and the chain not fully reinitializing/resyncing on resume — though I was unable to confirm this conclusively, since attempts to disable node suspension via wireplumber.conf.d overrides (node.rules, wireplumber.components.rules) either failed to apply or caused WirePlumber to crash-loop on this version's config schema.
Toggling EasyEffects' own "Inactivity timeout" setting on/off made no difference to the behavior, suggesting the relevant suspend logic is on the WirePlumber/PipeWire side rather than EasyEffects' own auto-suspend feature.

Question for maintainers:
Is this a known interaction between EasyEffects' convolver (or its LV2/filter-chain node) and PipeWire/WirePlumber's node suspend-on-idle behavior? Is there a recommended way to mark EasyEffects' processing nodes as non-suspendable, or does EasyEffects already attempt this and it's failing on newer WirePlumber versions (0.5.13)?
Happy to provide more logs/diagnostics if useful.

Expected Behavior

No response

Debug Log

Debug Log

Paste your log here

Additional Information

No response

[wwmm]

Not a PipeWire xrun/CPU bottleneck — pw-top shows 0 ERR and CPU usage is normal during/after the issue.
Not a sample rate mismatch — rate stays consistent (48000) across working and degraded states in pw-top.

What about the quantum column? Maybe pipewire changed latency and something unusual happened. But usually when changes to latency degrade audio the result is really bad and full of noises.

Is this a known interaction between EasyEffects' convolver (or its LV2/filter-chain node) and PipeWire/WirePlumber's node suspend-on-idle behavior?

Definitely not. The convolver is fine on my computer.

Is there a recommended way to mark EasyEffects' processing nodes as non-suspendable, or does EasyEffects already attempt this and it's failing on newer WirePlumber versions (0.5.13)?

I am not sure if this is possible. PipeWire is in full control of the filters activity. The only thing that is done on our side is creating the filters and their links. PipeWire is the one deciding when the nodes suspend or enter the playback state.

[guillermomirandagar]

I tried to get a controlled before/after comparison using pw-top. Attaching three screenshots: one in a working state, one in a failing state, and one showing an in-between case.

A single pause/resume doesn't reliably reproduce it for me. It seems to take a couple of cycles of pausing, minimizing the browser, and resuming the video before the degradation shows up.

Comparing the working and failing snapshots, the steady-state pw-top values are actually identical — same Quant (3600 for Firefox, 2048 for the sink), same Rate (48000 throughout), same R status on every node. Only the wait/busy microsecond timings differ. So whatever is happening doesn't show up as a persistent state difference in pw-top — it might be something transient during the actual pause/resume transition rather than something visible afterward.

I've also noticed that sometimes after pause/resume, Firefox's active stream shows RATE 44100 instead of 48000, with a leftover idle Firefox node left behind at the other rate (see third screenshot). I initially thought this rate mismatch might explain the degradation, but it doesn't hold up consistently — I've seen both 44100 and 48000 show up in both good and bad audio states. So there does seem to be some rate switching / orphaned node behavior happening on pause/resume, but I can't draw a reliable line from that to the audio degradation itself.

I don't have a way to capture pw-top exactly at the moment of the pause/resume transition — if there's a better way to log this in real time like a continuous PipeWire event logging I would be happy to try it

[wwmm]

Hum... If it isn't the sampling rate and the latency are not changing in a way that could explain the degradation I don't know what could be happening. I see you are using an old easyeffects version. But it is not like the newer ones have got fixes related to audio degradation.

In any case if possible try to use the latest version available on Flathub. But something to have in mind is that at some point we needed to introduce changes to make easyeffects compatible with pipewire 1.6.x. And as result we may not work well with older pipewire releases.

[guillermomirandagar]

Okay, thanks for the information!

[SlothLady]

I am having the same issue on Fedora, when audio is paused for longer than the inactivity timeout it goes bitty/robotic, happens for short bursts of sounds from browser notifications etc too but audio playing from my spotify remains unaffected.