wwmm
Attaching something (ie. OBS) to EasyEffect's sink's monitor output, causes choppy audio
EasyEffects Version
7.2.3
What package are you using?
NixOS
Distribution
NixOS unstable
Describe the bug
Attaching OBS-studio to the sink's monitor output (to get a stable connection to un-equalized audio), causes the recorded audio to stutter.
A workaround is to manually disconnect obs-studio from easyeffects and link up all it's inputs via helvum.
Expected Behavior
Audio should be fine, and sound like would be expected when listening to a regular hardware output monitor, minus easyeffects' modifications.
Debug Log
No response
Additional Information
No response
Attaching OBS-studio to the sink's monitor output (to get a stable connection to un-equalized audio), causes the recorded audio to stutter.
This feels like an issue that is coming from PipeWire or maybe WirePlumber considering it is the one doing the links between OBS and our null-sink monitor ports. Sturrenting in a situation like makes me think about PipeWire's dynamic latency switching. When OBS was linked to our null-sink PipeWire may have switched to a lower latency that your system is having difficulties to handle. What is the output of pw-top when the stuttering happens? Maybe the QUANTUM value show at your soundcard line is too low for your system.
Worth noting that both the HDMI output (alsa_output.pci-0000_29_00.1.hdmi-stereo) and OBS have choppy audio, while the defined output in easyeffects (alsa_output.pci-0000_2b_00.4.analog-stereo) has no issues whatsoever, despite having the lowest QUANTIUM and highest WAIT values.
From monitoring via the HDMI output I also noticed that the monitor output of the sink is affected by the effects applied by Easyeffects, which I was trying to avoid. Additionally, using the bypass button makes the choppiness go away on the HDMI output.
From monitoring via the HDMI output I also noticed that the monitor output of the sink is affected by the effects applied by Easyeffects
This really feels like WirePlumber doing something it shouldn't. EasyEffects only asks WirePlumber to move to our virtual devices playback or recording streams. But the monitor of the soundcard devices isn't a stream.
And even when EasyEffects asks for a stream to be moved to our device the link would not be done to our virtual sink monitors. The stream is supposed to play to it and not recording from it.
In any case the fact that the global bypass fixes the problem is a sign that something is not right in PipeWire. Rebuilding the links should not be necessary.
I have also been experiencing this issue. It seems like the equalizer causes issues with listening to the sink before it. A workaround is to put an effect before the equalizer and configure it to do nothing, for example adding the delay effect and setting the delay to 0. This way the equalizer isn't the first effect after the Easy Effects Sink and listening to the sink (using for example OBS) works fine.
Clear audio when listening to the Easy Effects Sink:
Choppy audio when listening to the Easy Effects Sink:
I have also been experiencing this issue. It seems like the equalizer causes issues with listening to the sink before it. A workaround is to put an effect before the equalizer and configure it to do nothing, for example adding the delay effect and setting the delay to 0. This way the equalizer isn't the first effect after the Easy Effects Sink and listening to the sink (using for example OBS) works fine.
That is weird. EasyEffects code for these two plugins is essentially the same as far as "wrapping them in PipeWire's API" is concerned. @SKBotNL try to run pw-top for both cases. Is there any difference in the QUANTUM value shown at your soundcard line? Or a difference in error count?
A workaround is to put an effect before the equalizer and configure it to do nothing, for example adding the delay effect and setting the delay to 0.
I'm having the same issue here but I only have Deep Noise Remover enabled. Adding Delay after DNR solves the choppiness. Now I removed Delay to capture some difference, but the choppiness is still gone.
One unrelated issue is that I can only capture audio in OBS with PulseAudio, not native PipeWire input.
Edit: nevermind it's back when I remove and add the input in OBS.
Also, the choppiness sounds really like sample rate conversion error, and I just happen to have 44.1K (the game I want to OBS to capture) as well as 48K (everything else) running at the same time. That might be why I cannot reproduce it with other cases.
Also, the choppiness sounds really like sample rate conversion error, and I just happen to have 44.1K (the game I want to OBS to capture) as well as 48K (everything else) running at the same time. That might be why I cannot reproduce it with other cases.
Hum... The deep noise plugin needs resampling to 48 kHz as this is the sampling rate it was trained to use. The plugin based on RNNoise has the same restriction. But a bug in the resampling for these plugins would not explain people seeing this issue with the equalizer because the equalizer does not need resampling on EasyEffects side.
I have also been experiencing this issue. It seems like the equalizer causes issues with listening to the sink before it. A workaround is to put an effect before the equalizer and configure it to do nothing, for example adding the delay effect and setting the delay to 0. This way the equalizer isn't the first effect after the Easy Effects Sink and listening to the sink (using for example OBS) works fine.
That is weird. EasyEffects code for these two plugins is essentially the same as far as "wrapping them in PipeWire's API" is concerned. @SKBotNL try to run
pw-topfor both cases. Is there any difference in the QUANTUM value shown at your soundcard line? Or a difference in error count?
The QUANTs do not change between the cases, but here you have the output of pw-top:
I don't know where the errors came from, however I do not see them increasing when I switch between having an effect before the equalizer or not.
I don't know where the errors came from, however I do not see them increasing when I switch between having an effect before the equalizer or not.
In the cases where they are concerning you will see hundreds or maybe thousands of errors. Not only in the soundcard line but also in the filters lines.
I had the issue again today.
- Adding Delay does not actually matters.
- Settiing Attenuation Limit to 0 dB "fixes" the issue (probably similar to disable the effect, except this does not remove it from the processing chain?)
- Disable input monitoring also fixes the issue, but with DNR still working as intended.
After some tinkering I lost the environment where changing input monitoring will have an effect, so no more detailed log today. Now it just works regardless if I adjust this setting,
I have a feeling we’re not all experiencing the same issue, but rather multiple issues that lead to the same result. In my situation having the delay filter in front of my equalizer has consistently fixed the choppiness in OBS recordings.
Hi, I am also using the EasyEffect sink as OBS audio device and have this issue. Adding a 0ms delay before the EQ fixes it though.
(EasyEffect ver 8.0.0, on Fedora 42 KDE)
Seems noticeably less choppy than it did for me, but I also dont know what it's supposed to sound like - my current workaround is to use desktop audio capture source and explicitly exclude easyeffects (though i dont think easyeffect itself emits audio?).