easyeffects
easyeffects copied to clipboard
wwmm
Audio becomes crackly when a new application is added
EasyEffects Version
7.0.1
What package are you using?
Arch (easyeffects)
Distribution
Arch Linux
Describe the bug
I'm only using the Convolver plugin. I find I often have to restart easyeffects to fix crackling audio. Typically this is trigger by receiving a notification like from Mailspring. I have also seen this happen when a YouTube video is played whilst listening to Spotify.
Expected Behavior
The audio should not crackle.
Debug Log
Debug Log
Paste your log here
Additional Information
If it's helpful, I'm also using GNOME and the CPU (3950x) should be more than capable of dealing with this.
❯ paru -Q pipewire
pipewire 1:0.3.67-1
Related https://github.com/wwmm/easyeffects/issues/1567.
This seems a clipping issue. Try to use a limiter at the last position of the effects pipeline.
I'm not sure I understand how it's a clipping issue. Typically a notification will come through and then the audio will be crackly indefinitely.
Okay, it just happened without a notification at all. I was listening to spotify, then started playing audio through chrome and now everything is crackly.
During:
(easyeffects:113418): easyeffects-DEBUG: 21:46:51.668: stream_output_effects.cpp:159 No app linked to our device wants to play. Unlinking our filters.
(easyeffects:113418): easyeffects-DEBUG: 21:46:51.668: stream_output_effects.cpp:317 disconnecting the convolver filter from PipeWire
(easyeffects:113418): easyeffects-DEBUG: 21:46:51.669: pipe_manager.cpp:212 117 ee_soe_convolver has been removed
(easyeffects:113418): easyeffects-DEBUG: 21:49:14.183: stream_output_effects.cpp:150 At least one app linked to our device wants to play. Linking our filters.
(easyeffects:113418): easyeffects-DEBUG: 21:49:14.186: plugin_base.cpp:310 soe: convolver successfully connected to PipeWire graph
(easyeffects:113418): easyeffects-DEBUG: 21:49:14.186: pipe_manager.cpp:1206 easyeffects_sink port 70 is connected to ee_soe_convolver port 108
(easyeffects:113418): easyeffects-DEBUG: 21:49:14.186: pipe_manager.cpp:1206 easyeffects_sink port 89 is connected to ee_soe_convolver port 107
'spa_pod_is_array(pod)' failed at /usr/include/spa-0.2/spa/pod/iter.h:339 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /usr/include/spa-0.2/spa/pod/iter.h:339 spa_pod_get_array()
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.601: pipe_manager.cpp:1166 Stream/Output/Audio 134 Chromium with serial 1633 has been added
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.603: pipe_manager.cpp:899 new metadata property: 134, target.node, Spa:Id, 126
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.603: pipe_manager.cpp:899 new metadata property: 134, target.object, Spa:Id, 717
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.609: pipe_manager.cpp:1206 Chromium port 74 is connected to easyeffects_sink port 98
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.609: pipe_manager.cpp:1206 Chromium port 97 is connected to easyeffects_sink port 112
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.641: pipe_manager.cpp:1166 Stream/Output/Audio 127 Chromium with serial 1639 has been added
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.644: pipe_manager.cpp:899 new metadata property: 127, target.node, Spa:Id, 126
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.644: pipe_manager.cpp:899 new metadata property: 127, target.object, Spa:Id, 717
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.653: pipe_manager.cpp:1206 Chromium port 101 is connected to easyeffects_sink port 98
(easyeffects:113418): easyeffects-DEBUG: 21:49:25.653: pipe_manager.cpp:1206 Chromium port 50 is connected to easyeffects_sink port 112
After I paused:
(easyeffects:113418): easyeffects-DEBUG: 21:49:51.030: pipe_manager.cpp:212 Stream/Output/Audio 127 Chromium has been removed
(easyeffects:113418): easyeffects-DEBUG: 21:49:51.030: app_info.cpp:313 Chromium disposed
(easyeffects:113418): easyeffects-DEBUG: 21:49:51.031: app_info.cpp:321 Chromium finalized
(easyeffects:113418): easyeffects-DEBUG: 21:49:51.031: app_info.cpp:28 data struct destroyed
(easyeffects:113418): easyeffects-DEBUG: 21:49:51.031: node_info_holder.cpp:97 127, Chromium finalized
(easyeffects:113418): easyeffects-DEBUG: 21:50:00.659: pipe_manager.cpp:212 Stream/Output/Audio 134 Chromium has been removed
'spa_pod_is_array(pod)' failed at /usr/include/spa-0.2/spa/pod/iter.h:339 spa_pod_get_array()
(easyeffects:113418): easyeffects-DEBUG: 21:50:00.659: app_info.cpp:313 Chromium disposed
(easyeffects:113418): easyeffects-DEBUG: 21:50:00.660: app_info.cpp:321 Chromium finalized
(easyeffects:113418): easyeffects-DEBUG: 21:50:00.660: app_info.cpp:28 data struct destroyed
(easyeffects:113418): easyeffects-DEBUG: 21:50:00.660: node_info_holder.cpp:97 134, Chromium finalized
(easyeffects:113418): easyeffects-DEBUG: 21:50:04.666: stream_output_effects.cpp:159 No app linked to our device wants to play. Unlinking our filters.
(easyeffects:113418): easyeffects-DEBUG: 21:50:04.666: stream_output_effects.cpp:317 disconnecting the convolver filter from PipeWire
(easyeffects:113418): easyeffects-DEBUG: 21:50:04.667: pipe_manager.cpp:212 109 ee_soe_convolver has been removed
Screenshot of easy effects during:
Happened again just now when I got a notification.
(easyeffects:113418): easyeffects-DEBUG: 22:07:38.605: pipe_manager.cpp:1166 Stream/Output/Audio 134 Chromium with serial 1676 has been added
(easyeffects:113418): easyeffects-DEBUG: 22:07:38.606: pipe_manager.cpp:899 new metadata property: 134, target.node, Spa:Id, 126
(easyeffects:113418): easyeffects-DEBUG: 22:07:38.606: pipe_manager.cpp:899 new metadata property: 134, target.object, Spa:Id, 717
(easyeffects:113418): easyeffects-DEBUG: 22:07:38.610: pipe_manager.cpp:1206 Chromium port 103 is connected to easyeffects_sink port 98
(easyeffects:113418): easyeffects-DEBUG: 22:07:38.610: pipe_manager.cpp:1206 Chromium port 74 is connected to easyeffects_sink port 112
Those logs don't seem to help much. Is there anything else I can do to provide information? I deal with this every day and it's really frustrating.
Typically a notification will come through and then the audio will be crackly indefinitely. Okay, it just happened without a notification at all. I was listening to spotify, then started playing audio through chrome and now everything is crackly.
Sounds like PipeWire's automatic latency switching choosing latency values that your system is not being to handle. It is usually the cause of what you are describing. My desktop has no issue with the dynamic latency switching. But my laptop for example just can't handle too low latency values. Depending on what PipeWire chooses there is a lot of crackling that I never see on my desktop.
Typically a notification will come through and then the audio will be crackly indefinitely.
Okay, it just happened without a notification at all. I was listening to spotify, then started playing audio through chrome and now everything is crackly.
Sounds like PipeWire's automatic latency switching choosing latency values that your system is not being to handle. It is usually the cause of what you are describing. My desktop has no issue with the dynamic latency switching. But my laptop for example just can't handle too low latency values. Depending on what PipeWire chooses there is a lot of crackling that I never see on my desktop.
What factors would be involved in whether or not a system can handle it? As mentioned before the CPU isn't slow, a Ryzen 3950x, and there's plenty of memory (64GB). There doesn't appear to be excessive load on the system during this time either. The latency in the screenshot doesn't seem abnormal and it's fine as soon as easy effects is killed.
What factors would be involved in whether or not a system can handle it?
The combination CPU + soundcard hardware + soundcard driver as well as how pipewire is configuring ALSA buffers. Your CPU probably isn't the issue.
There doesn't appear to be excessive load on the system during this time either
High load is not necessary for crackling to appear. As surprising as it may seem.
The latency in the screenshot doesn't seem abnormal and it's fine as soon as easy effects is killed.
The latency in EE window is just an estimation of the extra latency introduced by our plugins. Not the latency PipeWire is using. That one can be seen running pw-top while something is playing. If possible take a print of it without and with crakling.
In any case first we have to make sure the latency switching is the cause. The quantum ranges section from PipeWire's wiki https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#quantum-ranges shows how to temporarily set a fixed latency (quantum size). Try to set a fixed quantum of 1024 or 2048. If cracklings are gone while a fixed value is set then we have to figure out why the switching is causing such a disaster.
Are you using the convolver? If I remember well it and the crystalizer are the only EE plugins that do not handle dynamic latency switching well. But when they are related the crackling comes and goes away very fast. It is not a continuous crackling like the one you seem to be hearing.
Thanks for the info @wwmm. I'll run pw-top and try to capture some data. Then, I'll see if forcing a fixed quantum size helps. I'll let you know soon.
Are you using the convolver? If I remember well it and the crystalizer are the only EE plugins that do not handle dynamic latency switching well. But when they are related the crackling comes and goes away very fast. It is not a continuous crackling like the one you seem to be hearing.
Yeah. I do also sometimes notice there is a sudden and obtuse change in volume when a new application is added too (i.e notification).
Though, it sounds fine here:
The WAIT value is suspicious. 10ms in the last screenshot and 20ms in this one. If I restart easyeffects then this value is like 300us. Again, strange as the 10ms screenshot was awful, but 20ms and 300us are okay. The only other difference I can see is the value of QUANT as 512.
The only other difference I can see is the value of QUANT as 512.
The estimated latency can be calculated as 512 / 48000 = 0.0107 s. So it is about 10 ms. In the ones that were fine the latency was 1024 / 44100 = 0.0232 s. So when things go wrong the latency set by PipeWire is less than half the one that works.
Again if the value is "too low" it depends on the whole system. My laptop struggles with 10 ms but my desktop can handle a lot lower than this.
There are also times where the system is in a state where adding or removing players causes a brief annoying change in volume. I noticed that I can go back and forth between and empty video element in Chromium which changes the global QUANT from 1024 to 512 and back again when removed. I have the minimum QUANT forced at 1024 so honestly not sure how this is happening.
If I close easyeffects, then the weird, brief and sudden change in volume disappears. It seems like there is something in easyeffects or the convolver plugin which needs to handle the change in QUANT better?
It seems like there is something in easyeffects or the convolver plugin which needs to handle the change in QUANT better?
The difficulty that the current convolver code has is related to the need to reinitialize the zita-convolver library if the audio buffer size changes. I do not have a decent solution to this yet.
What is weird is that on some machines it is hard to notice that this problem even exists. On my computer somehow I do not hear the crackling although it should be there.
The really strange thing is that it's not persistent. I do not see this behaviour when the system has just started, only once it's been locked, or put to sleep. Even then it may still be fine.
This seems like it's the same issue I have (#2231), @uhthomas why don't you also try adding this to /etc/pipewire/pipewire-pulse.conf.d/pipewire-pulse.conf and rebooting?
pulse.rules = [
{
matches = [ { application.process.binary = "electron" } ]
actions = {
update-props = {
pulse.min.req = 2048/48000
pulse.min.quantum = 2048/48000
}
}
}
]
This seems like it's the same issue I have (#2231), @uhthomas why don't you also try adding this to
/etc/pipewire/pipewire-pulse.conf.d/pipewire-pulse.confand rebooting?pulse.rules = [ { matches = [ { application.process.binary = "electron" } ] actions = { update-props = { pulse.min.req = 2048/48000 pulse.min.quantum = 2048/48000 } } } ]
Thanks for the suggestion. I'll look at trying this.
Here's another weird / annoying situation. Either the left or right output will stop working (see -100db in the easyeffects screenshot). The only way to fix this is to either restart easyeffects or pause playback and wait for it to drop out of pipewire. I do not believe this has anything to do with the audio source or the application as both spotify and chrome will not play any audio or of one of the channels. This happened when chrome playback started whilst spotify was already playing something.
Either the left or right output will stop working (see -100db in the easyeffects screenshot).
That is #1789. Was this with the latest EasyEffects release? I had some hope that maybe the changes in the last release would help to fix this bug too.
Either the left or right output will stop working (see -100db in the easyeffects screenshot).
That is #1789. Was this with the latest EasyEffects release? I had some hope that maybe the changes in the last release would help to fix this bug too.
I believe so. I'm using Arch Linux and keep everything up to date where possible.
Okay, so I still see this, and a few other issues. The first one is strange artifacts when an application is added or removed. In this instance, I have Spotify playing. It will sound weird for a moment when I open pavucontrol, because the global quant changes from 1024 to 256. The same thing happens when I close it, the quant changes from 256 to 1024.
Secondly, only one channel will play occasionally which is weird.
Hope this is helpful?
❯ paru -Qs pipewire
local/easyeffects 7.1.0-1
Audio Effects for Pipewire applications
local/gst-plugin-pipewire 1:0.3.80-1
Multimedia graph framework - pipewire plugin
local/libpipewire 1:0.3.80-1
Low-latency audio/video router and processor - client library
local/libwireplumber 0.4.14-1
Session / policy manager implementation for PipeWire - client library
local/pipewire 1:0.3.80-1
Low-latency audio/video router and processor
local/pipewire-alsa 1:0.3.80-1
Low-latency audio/video router and processor - ALSA configuration
local/pipewire-audio 1:0.3.80-1
Low-latency audio/video router and processor - Audio support
local/pipewire-jack 1:0.3.80-1
Low-latency audio/video router and processor - JACK replacement
local/pipewire-pulse 1:0.3.80-1
Low-latency audio/video router and processor - PulseAudio replacement
local/wireplumber 0.4.14-1
Session / policy manager implementation for PipeWire
It seems like your earlier comment reflects what I've written.
The difficulty that the current convolver code has is related to the need to reinitialize the zita-convolver library if the audio buffer size changes. I do not have a decent solution to this yet.
So, I guess this issue is blocked until there is a better solution here?
re: channel missing
I don't understand why. It seems like easyeffects thinks both channels are fine, but only the left channel is actually coming through. This is resolved by pausing the media, and letting the application remove itself. It comes back just fine.
The below screenshot doesn't say much. It shows normal operation despite only playing the left channel.
So, I guess this issue is blocked until there is a better solution here?
Yes. I think that I will have to force some kind of minimum latency in the convolver instead of keeping it in zero latency mode as it is now. Dealing with PipeWire's dynamic latency changes without forcing a fixed buffer size on the plugin is a lot harder.
In the meantime what you can do is forcing PipeWire to use a fixed latency value.
I don't understand why. It seems like easyeffects thinks both channels are fine, but only the left channel is actually coming through. This is resolved by pausing the media, and letting the application remove itself. It comes back just fine.
@uhthomas this started to happen on my computer some months ago too. Definitely a PipeWire bug. The challenge is how to debug it in a way that we can provide useful information to its developers. That is why I did not open an issue at their page myself yet.
@wwmm FWIW I think the missing channel thing may be to do with easyeffects? If I uncheck "enable" whilst it's happening for an application, I can hear both channels as normal - and then it's a single channel again if I check the box.
FWIW I think the missing channel thing may be to do with easyeffects?
No. The missing channel is a PipeWire's bug https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3547. It seems they have fixed it but I did not have time to build a package from PipeWire's master branch to test.