wwmm / easyeffects

Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
GNU General Public License v3.0
6.11k stars 263 forks source link

stereo reduced to left ch. #2521

Open atomGit opened 10 months ago

atomGit commented 10 months ago

EasyEffects Version

7.0.6

What package are you using?

Arch (easyeffects)

Distribution

Manjaro

Describe the bug

left channel output only: this happens sometimes when playing remote videos (YouTube/Odysee/etc.) with firefox - i'll start playing a video and it may be left channel only and remain that that way until i cycle the global bypass button which always resolves the issue (left ch. to stereo)

i don't believe i've ever had this happen with local content, regardless of the source, unless i play it with firefox

Expected Behavior

stereo should not be reduced to left ch. only

Debug Log

No response

Additional Information

problem began after a recent Manjaro/pipewire/easyeffects update, roughly a month ago

for a long time i've had what seems to be a somewhat typical problem with several seconds of audio delay (no audio) when starting playback from any source (local or remote, firefox or mpv) - this was finally resolved a few months ago, but now this problem has reappeared as well

the only effect i'm using in easy is the LoudnessEqualizer.json

i'm not using any custom configs for audio

firefox 116.0.2 pipewire 0.3.77 wireplumber 0.4.14 LoudnessEqualizer.json

wwmm commented 10 months ago

left channel output only: this happens sometimes when playing remote videos (YouTube/Odysee/etc.)

I have seen this a few times in the last month. It probably can happen to any player. This is a PipeWire bug that was supposed to be fixed but it is back. I suspect it is related to the use of passive links. This kind of links are necessary for PipeWire's dynamic sampling rate switching to work while EasyEffects is running. Something wrong is happening inside PipeWire when it does this kind of link. But as the bug is super random it is hard to debug it.

The next time it happens run pw-dot. Its output file can be viewed with the command xdot and will show each link state. It would be good to know if any of them is outside of the active state. In any case it is the kind of bug that will require help from PipeWire developers.

wwmm commented 10 months ago

It just happened on my computer again. In pw-dot output I could see that not only all the links are there but they are all active. And EasyEffects level meters show that there is audio data passing through the plugins. It is almost like the node PipeWire creates for the soundcard is ignoring the right channel data. Either that or the link between it and our last plugin is not doing its job.

Durkh commented 10 months ago

Hello, this is also happening to me.

EasyEffects Version

7.0.7

Distribution and Packages

Arch Linux, kernel 6.4.10-arch1-1

pipewire Compiled with libpipewire 0.3.77 Linked with libpipewire 0.3.77

Describe the bug

Left channel output only, it does happen with any audio player, and goes away when cycling global bypass button or continuously enabling and disabling the running audio source in easyeffects players tab (this method is random, sometimes you only need to diable/enable once, sometimes more than 10 times).

Addition info

i noted that it is more prone to happen when changing players, if i'm listening to music on youtube, pause, and open a music player, or play something in other firefox window, the bug is more likely to happen.

Not stopping the audio stream prevents the bug to happen, so, if i keep player A playing, play player B and then pause player A, the bug does not happen.

pw.dot contents https://pastebin.com/tuhZK4VV

i'm using a USB DAC (ifi zen air DAC) and the only change i made to pipewire.conf is: default.clock.allowed-rates = [ 48000 88200 96000 176400 192000 352800 384000]

and current sample rate is: Momentary freq = 88200 Hz

Samk1106 commented 9 months ago

This constantly happens on my system, running Pop_OS! 22.04. Pipewire version 0.3.77 and Easy Effects 7.1.0. It happens all the time when using the Spotify flatpak, but every program is effected.

I am using a USB DAC, a Micca Origain ad250

wwmm commented 9 months ago

This constantly happens on my system, running Pop_OS! 22.04. Pipewire version 0.3.77 and Easy Effects 7.1.0. It happens all the time when using the Spotify flatpak, but every program is effected.

It happens on mine sometimes. It is definitely a PipeWire regression. The question is how to get PipeWire logs that may help them to fix this issue. I suspect that passive links are somehow involved. We do this kind of link so that PipeWire's dynamic sampling rate switching works while EasyEffects is running. But as this bug is very random it is hard to confirm this hypothesis.

atomGit commented 9 months ago

make sure you guys aren't running a custom config

in my case i was running ~/.config/pipewire/pipewire.conf.d/pipewire.conf where i was setting default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]

both my problems disappeared when i eliminated the custom config

wwmm commented 9 months ago

where i was setting default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]

The problem of not setting a sampling rate array is that PipeWire won't even try to change the sound card rate ondemand. Unless there is a new behavior I am not aware of. In any case if this is fixing the problem then PipeWire is doing something wrong to the links when the dynamic sampling rate switching activates.

wwmm commented 8 months ago

I have opened an issue at PipeWire's page about this https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3547.

cjthompson commented 8 months ago

I'm having this issue also with PipeWire 0.3.82. It's not just "left channel" though, each channel seems to bind separately. Each time I toggle the "bypass" button in EasyEffects, each channel can, separately, either output sound, buzzing, or nothing.

kode54 commented 7 months ago

It seems to be exacerbated by the idle timeout suspend feature. If I have audio playing continuously, it keeps working.

wwmm commented 7 months ago

It seems to be exacerbated by the idle timeout suspend feature. If I have audio playing continuously, it keeps working.

EasyEffects uses the timeout to destroy the links between filters. It is the only way to make sure it will not waste cpu power processing silence when there is nothing playing audio. As the PipeWire bug is related to the link creation if we never destroy them the bug does not happen in this case.

kode54 commented 7 months ago

It may be fixed in master now. I'll have to apply the fix to a local build of stable and find out.

nijahplays commented 7 months ago

I'm getting this issue on the Flatpak and Arch's package as well, and is not happening when not using it -Version 7.1.3

Inmoresentum commented 6 months ago

Same issue with flatpak version :(

kode54 commented 5 months ago

I had the issue again today, but it turns out I still had a custom pipewire.conf, but it was just the stock config from distribution, with the only altered settings being to set supported sample rates of 96000 and 44100, and prefer 96000. I decided that was basically a waste now anyway, since I'm using a USB sound device that's limited to 44100 and 48000. Haven't had it since removing the configuration and restarting all the daemons and EasyEffects. Will be sure to check with the above mentioned tools if it happens again.

wwmm commented 5 months ago

I had the issue again today, but it turns out I still had a custom pipewire.conf, but it was just the stock config from distribution, with the only altered settings being to set supported sample rates of 96000 and 44100, and prefer 96000. I decided that was basically a waste now anyway, since I'm using a USB sound device that's limited to 44100 and 48000. Haven't had it since removing the configuration and restarting all the daemons and EasyEffects. Will be sure to check with the above mentioned tools if it happens again.

Interesting. Right now my pipewire.conf is like this

#default.clock.rate          = 48000
default.clock.allowed-rates = [ 44100 48000 88200 96000 192000 ]

I do not remember the last time I disabled the dynamic sampling rate switching. In practice everything I use works either at 48 kHz or 44.1 kHz and is is quite common to see pipewire alternating between them. This may be related indeed.

AdivonSlav commented 4 months ago

Same issue happening on my end with EasyEffects Flatpak, PopOS 22.04 and Pipewire 1.0.2

nijahplays commented 3 months ago

Any news on this issue getting fixed? Still happening to me.

Slater91 commented 3 months ago

I'm not sure if this can help, but here is my pw-dot file (renamed as txt due to GitHub limitations).

pw-dot.txt

wwmm commented 3 months ago

Any news on this issue getting fixed? Still happening to me.

It still happens to me too and unfortunately I have no workaround for it other than enabling/disabling the global bypass when it happens. This forces PipeWire to rebuild the links. As discussed at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3547 the fix has probably to be done in PipeWire. But what was done so far was not enough.

nijahplays commented 3 months ago

Thanks for the quick response!

matsumiya8 commented 4 weeks ago

After struggling with this for a while, I've finally managed to find a workaround that works: disabling node suspension when inactive. You can find instructions on how do this on the arch wiki, for either pipewire media session and wireplumber: https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_delay_or_audible_pop/crack_when_starting_playback

From what I've noticed on my setup, this left channel issue only happens when using EasyEffects + playing media that will result in the sample rating being changed (not resampling) just after the timeout. Naturally, disabling the timeout altogether fixes it for me. I'm using wireplumber by the way, and I didn't have this issue with pipewire media session when I used it.

Slater91 commented 4 weeks ago

Unfortunately the workaround above does not seem to work on my system, as I have just experienced the left channel issue again (after applying the workaround).