Imposible to set lattency offset for bluetooth speakers with pavucontrol when Easyeffects are active.

[magillos]

EasyEffects Version

7.1.4

What package are you using?

AUR (easyeffects-git)

Distribution

Arch

Describe the bug

With bluetooth devices, audio/video are not in sync. When Easyeffects are bypassed or not on, there in no problem with sync.
The issue itself is that pavucontrol 'latency offset' has no effect on audio/video sync when Easyeffets are active but it works fine when Easyeffect are off.

Expected Behavior

Setting pavucontrol 'latency offset' working also when Easyeffects are active.

Debug Log

Debug Log

``` Paste your log here ```

Additional Information

No response

[wwmm]

The issue itself is that pavucontrol 'latency offset' has no effect on audio/video sync when Easyeffets are active but it works fine when Easyeffect are off.

This feels like something to report to PipeWire developers. There is nothing that can be done about this on our side. Which plugins are you using? How much extra latency is EasyEffects reporting in its bottom panel?

The latency setting you are applying through pavucontrol is handled entirely by PipeWire. EasyEffects has no access to whatever pipewire is doing to it. And even if it had PipeWire is the one managing each filter state as well as the the minimum latency. The most that can be done in EasyEffects is not using plugins that add higher latency or changing their settings in a way that the extra latency is smaller.

[magillos]

Thanks for reply. I have 123ms reported in Easyeffects but this latency is undetectable if wired speakers or or headphones are used. I'm only using equalizer with some APO profile loaded. I'll try to ask on pipewire's gitlab, they have been very helpful there in the past so fingers crossed.

[wwmm]

I have 123ms reported in Easyeffects but this latency is undetectable if wired speakers or or headphones are used. I'm only using equalizer with some APO profile loaded.

Are you using the equalizer in a mode different from IIR? Something like FIR or FFT for example? Usually its latency is not so high in IIR mode.

It may be interesting to see what is show by pw-top while EasyEffects is running. Maybe with your bluetooth devices and EasyEffects running at the same time PipeWire is selecting a minimum latency that is very high. You can estimate its value by dividing the Quantum by the Rate shown in pw-top columns for the soundcard line.

[magillos]

Not sure why, but I had FIR selected and audio/video seems bit better with IIR but still can't be corrected further with pavucontrol.

And here is my pw-top with Firefox playing video: Do you think that Firefox and bluetooth speaker using different quantum could be cause of the issue?

I'll have to browse all the piepewire and wireplumber configs but I don't think I set 256 buffer anywhere myself.

[EDIT] I forced the same quantum for everything but it doesn't seem to impact anything (I tried 1024 and 256). I noticed something else though. Bypassing equalizer or even Easyeffects with global bypass toggle still blocks pavucontrol from applying latency offset. Easyeffects has to be killed for that to take effect.

[wwmm]

Do you think that Firefox and bluetooth speaker using different quantum could be cause of the issue?

This is just their requested latency. The actual value set by pipewire is shown in the soundcard line. Based on the image it is using 256 / 48000 = 0.005 seconds for the bluetooth device. A low value that should not be causing video and audio to be out of synchronization by a noticeable margin.

I'll have to browse all the piepewire and wireplumber configs but I don't think I set 256 buffer anywhere myself.

Probably not. PipeWire decided to use this value on its own.

Bypassing equalizer or even Easyeffects with global bypass toggle still blocks pavucontrol from applying latency offset. Easyeffects has to be killed for that to take effect.

I have never used Pauvcontrol's latency offset. I wonder how this actually works. The only thing that come to my mind as a possible explanation for it to be failing is the fact that the audio player is not playing directly to the hardware device but to EasyEffects virtual device. Maybe whatever it is the mechanism Pavucontrol is using it is not supposed to be used with a "man in the middle". I imagine PipeWire developers will be able to explain if this is the case.

[wwmm]

When the global bypass is enabled the pipeline becomes quite simple:

audio player -> null sink -> spectrum plugin -> level meter -> soundcard

If this breaks the latency offset I see only two possibilities. Either null-sinks are not compatible with it or there is some information about the latency that should be going through our filters and we are doing something wrong. But as far as I am aware we already do what is supposed to be done to send the latency information ahead https://github.com/wwmm/easyeffects/blob/5c6bcaf0cba97ddeef0882b690701bb5d3912dfd/src/plugin_base.cpp#L118. Unless something changed on PipeWire's side that I am not aware of... It happened in the past...

[wwmm]

Unless something changed on PipeWire's side that I am not aware of... It happened in the past...

But even if this is the case only plugins that actually add latency would be affected. The spectrum and the output level meter do not add latency. And the null-sink also shouldn't...

[magillos]

Thanks for explanations. One more observation I made is, that if an app (Firefox in this case) is disabled or excluded from Easyeffects processing, pavucontrol can offset lattency. It's not needed then, as Pipewire seems to take care of latency, but it can do it.

I created a ticket on Pipewire gitlab. Maybe they will reply there.

[magillos]

With recent changes in Pipewire and EasyEffects, the issue is now fixed. Audio and video seem to be in sync and it can still be adjusted with pavucontrol. Thank you.