Residual audio when playing muted media in Firefox

[ceiphr]

EasyEffects Version

6.2.4

What package are you using?

Flatpak (Flathub)

Distribution

Fedora 35

Describe the bug

Hello! I love this project so much, it's the only way to make audio sound good on my Framework laptop!

Here are some steps to reproduce this odd bug I'm having:

1. Open Spotify or YouTube in any browser.
2. Play something with audio.
3. Pause the media playing audio.
4. Open Firefox.
5. Play something new with no audio in Firefox.

For the first half second, the audio from the old media will play before cutting out.

This is most obvious when "Loudness" plugin is used. With "Loudness" bypassed, there's usually just a pop noise instead of residual audio.

Please let me know if you need any further details!

Expected Behavior

Play something new with no audio in Firefox should result in no residual audio being played.

Debug Log

Debug Log

Paste your log here

Additional Information

Firefox v98.0 (64-bit)
My EasyEffects preset: https://github.com/ceiphr/dotfiles/blob/master/.var/app/com.github.wwmm.easyeffects/config/easyeffects/output/Framework%20EQ.json

[wwmm]

This is the kind of problem that is tough to solve. Specially when using third party plugins. There reason why it gets more noticeable with the Loudness plugin is because depending on the situation it may have high latency. And high latency in its case will be tied to accumulated data inside the plugin.

Something you may try is increasing the Inactivity Timout setting in our preferences window. The larger the value the longer EasyEffects will stay processing silence after it detects that there is no audio player active. The downside is that CPU power will be wasted for a longer time when there is nothing that needs to be processed. But it should drain old data stored inside high latency plugins.

[wwmm]

Have in mind that this workaround will only help if you wait for some time before trying to play something else on another player. All players are redirected to the same processing pipeline.

[ceiphr]

Thanks for getting back to me so quickly!

I increased Inactivity Timout from the initial 10s to 30s. I waited a few minutes between playing Spotify and playing something muted in Firefox. The issue persists.

Something interesting that I just noticed: This is only occurring with Firefox. Following the reproduction steps with Chrome instead of Firefox, results in the expected behavior.

Could this be an issue with Firefox, or is it an issue with how EasyEffects interacts with Firefox audio?

[Digitalone1]

The pulseaudio implementation in Firefox has been always bad. I remember this bug which was quite annoying, reported years ago and never resolved.

[wwmm]

Diferent audio applications deal with the server in different ways. The same thin happens when you compare mpv with other videio players. But I still do not understand what is happening differently in this case when Firefox runs... I wonder if the difference is on the requested latency. If that is the case pw-top should show different values for Firefox and Chrome in the QUANT column.

[ceiphr]

Sorry for the delay. There are different values for Firefox and Chrome in the QUANT column:

[wwmm]

There are different values for Firefox and Chrome in the QUANT column:

Chrome request a latency that is 3 times smaller than the one requested by Firefox. Depending on how PipeWire adjusts its latency more data may be accumulated inside the plugins when Firefox is running. So maybe that is the reason why different things happen when only Firefox is running.

[wwmm]

But thinking about it again it does not make sense considering that nowadays PipeWire uses quantum sizes of 1024 by default... It may not be allowing the buffer size to go above this value...

[ceiphr]

I don't know if this helps, but I found these stats inside about:support in Firefox:

The audio backend is called pulse-rust which I assume means it's a rust implementation of a library intended for working with PulseAudio. Could this be relevant to the quantum size being three times larger than Chrome's?

[wwmm]

The audio backend is called pulse-rust which I assume means it's a rust implementation of a library intended for working with PulseAudio. Could this be relevant to the quantum size being three times larger than Chrome's?

Probably not. Each application has its own needs when it comes to latency. And it is just what is requested to the audio server. In the PipeWire will choose the value it considers more appropriate.

At this moment I am out of ideas. Something different happens when Firefox used. No doubt about it. But it is not clear exactly what.

[ceiphr]

No worries! I hope we can figure this out at some point. I'll try to investigate further in any way I can. Thank you!