Effects disabled for a split second when starting/stopping an audio stream

[evanc577]

If an audio stream is playing, and another audio stream is started or stopped, all applied effects are disabled for a split second before being re-enabled again. This is especially noticeable when using effects that change volume, and manifests sudden changes in volume.

I did not have this issue with PulseEffects + Pipewire.

To reproduce:

1. Add an effect in Easyeffects which allows setting gain (such as convolver), set input gain to a low value (< -10 dB).
2. Play an audio stream, such as from a music player. I used MPD, Gnome Music also works.
3. Open a YouTube video without sound in Firefox, such as https://www.youtube.com/watch?v=AjWfY7SnMBI
4. Toggle playing and pausing the YouTube video, observe that the volume changes for a split second.

Having some applications open, such as pavucontrol or OBS, prevent the issue from occuring.

Alternative method:

Get spammed with Discord notifications while listening to music.

Version:

Easyeffects 6.0.3-2 from Arch Linux repo, though this affects all versions of Easyeffects since release

❯ pacman -Qi easyeffects                                                                           
Name            : easyeffects
Version         : 6.0.3-2
Description     : Audio Effects for Pipewire applications
Architecture    : x86_64
URL             : https://github.com/wwmm/easyeffects
Licenses        : GPL3
Groups          : None
Provides        : None
Depends On      : calf  libglibmm-2.68.so=1-64  gtk4  gtkmm-4.0  libebur128  libbs2b.so=0-64
                  librubberband.so=2-64  libsamplerate.so=0-64  libsigc-3.0.so=0-64
                  libsndfile.so=1-64  liblilv-0.so=0-64  lsp-plugins  libpipewire-0.3.so=0-64
                  rnnoise  rubberband  zita-convolver
Optional Deps   : zam-plugins: maximizer [installed]
                  mda.lv2: bass loudness plugin [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : pulseeffects
Installed Size  : 4.16 MiB
Packager        : Frederik Schwan <freswa@archlinux.org>
Build Date      : Tue 03 Aug 2021 11:01:45 AM EDT
Install Date    : Tue 03 Aug 2021 02:10:45 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Platform:

• AMD Ryzen 3700x
• USB DAC
• Arch Linux
• KDE Plasma X11
• Pipewire

Logs:

easyeffects_debug.txt pw-dump.txt

[wwmm]

This sounds like the kind of issue linked to PipeWire's dynamic latency switching. MPD probably requests high latency like Spotify do. Once you open something else that requests low latency the buffer size goes from very big to very small and this is something we can listen to.

In older releases we did not follow the dynamic latency changes. We were forcing PipeWire to always have a small latency value. So when most apps started the latency was already low and this audio buffer size change did not happen. The problem with this approach is that cpu is wasted when only high latency apps are running.

[ctrl-alt-breathe]

This sounds like the kind of issue linked to PipeWire's dynamic latency switching. MPD probably requests high latency like Spotify do. Once you open something else that requests low latency the buffer size goes from very big to very small and this is something we can listen to.

In older releases we did not follow the dynamic latency changes. We were forcing PipeWire to always have a small latency value. So when most apps started the latency was already low and this audio buffer size change did not happen. The problem with this approach is that cpu is wasted when only high latency apps are running.

Is there any way to fix this? Whenever I have Discord running while listening to music, every ping makes it do this and it destroys the music.

[wwmm]

Is there any way to fix this?

Depending on which plugins you use things will be better in the next release 6.2.0. But not entirely fixed. One way to fix this problem is forcing PipeWire to use a fixed latency. Or using environmental variables to force MPD to use a low latency.