Jamming/stuttering with PipeWire (PulseEffects v5)

[AlexWayfer]

Hello.

Very similar to #222, but with PE v5 and more specific (not random).

Reproducing:

• Play audio from Chromium (I'm using Deezer) — there is no problem.
• Receive a notification with sound from Discord, Telegram, I guess anywhere.
• Listen terrifying crackles.

Sometimes during track switching or something else, but very rare. The case described above gives 100%.

Should I try to record these noises?

Configuration: Arch Linux, pipewire 1:0.3.21-1, pipewire-pulse 1:0.3.21-1, pulseeffects 5.0.0-1.

[wwmm]

Should I try to record these noises?

If it is something easy to do I would like to hear. In some situations I hear some noises when a second audio application is launched and I am suspecting they are being created when PipeWire updates the maximum latency. Try to see if a increased latency value in PulseEffects settings (PipeWire Section) menu changes anything.

[wwmm]

Watching the output of pw-top while you do your tests may help. If a latency change happens at the same time the noises occur pw-top will show it.

[chezbgone]

I believe I am experiencing the same issue. I get these warnings from pulseeffects whenever the static/crackle happens.

[W][000356477.740443][impl-node.c:1040 node_on_fd_events()] (pulseeffects_sie-30) client missed 1 wakeups
[W][000356477.740550][impl-node.c:1040 node_on_fd_events()] (pulseeffects_soe-17) client missed 1 wakeups

I also tried pw-top, but I was not sure how to read the output, in particular what each column meant. I looked around for pw-top documentation, but wasn't able to find it.

[wwmm]

I think that I have seen other applications showing client missed 1 wakeups too in some of the bug reports in PipeWire's page. This may be a PipeWire issue.

[halfrafu]

I'm also experiencing this and by watching pw-top I think it happens when period changes on output device. When I'm just listening to music it stays at 2048 and changes to 256 when Discord starts playing anything then gets back to 2048. Crackling (or more like 50ms of audio getting repeated few times, I guess) occurs on both period changes. Only music is playing through PulseEffects, Discord goes directly to output device.

[wwmm]

When I'm just listening to music it stays at 2048 and changes to 256 when Discord starts playing anything then gets back to 2048

PipeWire adjusts the "global latency" when a new audio application request a smaller latency for its stream. What is a good idea. But I think that something is going wrong somewhere in PipeWire when doing this.This probably the cause of the noises some people have been reporting.

[AlexWayfer]

If it is something easy to do I would like to hear.

Here it is, song playing well, but there is noise on Discord sounds (mute/unmute). The same noise, as I wrote, on notifications from Telegram, maybe something else, it was just easier to demonstrate.

Record: https://drive.google.com/file/d/1yITnaTBXuTX-2bF1fY4aE6-7Carve_vj/view?usp=sharing Credits to song: https://soundcloud.com/gongacid/tamburada-yaz-muzigi

Try to see if a increased latency value in PulseEffects settings (PipeWire Section) menu changes anything.

Increased from the default 50 to 100, 500, 1000 and even 5000 did not change anything, even cracks duration.

Watching the output of pw-top while you do your tests may help. If a latency change happens at the same time the noises occur pw-top will show it.

I don't know what to send you, it's real-time updating, I can record a video if you want, but I've noticed these changes:

1. Chromium already plays a song, I'm starting pw-top, I see this entry:

   S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR  NAME                                                                               
   ...
   304    512  48000  17.1  s   6.5  s  0.00  0.00    0   + Chromium

2. After Discord sound there appears the second Chromium (somewhy) entry:

   308    360  48000  23.6  s   4.3  s  0.00  0.00    2   + Chromium

   With non-integer logarithm of 2 for QUANT. 🤔

3. And QUANT of the sound card entry changes from 512 to 256 for a moment and back:

   56    512  48000 105.4  s  12.4  s  0.01  0.00    0  alsa_output.usb-ASUS_Xonar_U7_MKII-00.analog-stereo

If other entries and order are important, here it is:

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR  NAME                                                                               

!   28      0      0   0.0  s   0.0  s  0.00  0.00    0  Dummy-Driver
!   36      0      0   0.0  s   0.0  s  0.00  0.00    0  Midi-Bridge
!   46      0      0   0.0  s   0.0  s  0.00  0.00    0  v4l2_input.pci-0000_0a_00.3-usb-0_2.1_1.0
    56    512  48000 105.4  s  12.4  s  0.01  0.00    0  alsa_output.usb-ASUS_Xonar_U7_MKII-00.analog-stereo
   100      1     25  15.6  s   4.7  s  0.00  0.00    0   + PulseAudio Volume Control
   122      0      0   7.0  s   9.2  s  0.00  0.00    2   + pulseeffects_sink
   127   1200  48000  18.0  s  14.6  s  0.00  0.00    0   + OBS
   259      1     20  10.4  s  11.6  s  0.00  0.00    2   + pulseeffects_soe
   282      1     20  12.5  s  15.1  s  0.00  0.00    0   + pulseeffects_soe
   134      1     25  22.7  s   8.3  s  0.00  0.00    0   + PulseAudio Volume Control
   304    512  48000  29.6  s  13.5  s  0.00  0.00    0   + Chromium
   296      1     25  17.4  s   4.9  s  0.00  0.00    0   + PulseAudio Volume Control
   308    360  48000  23.6  s   4.3  s  0.00  0.00    2   + Chromium
   272      1     25   6.0  s   1.4  s  0.00  0.00    0   + PulseAudio Volume Control
    57   1024  48000 173.0  s   0.9  s  0.01  0.00    0  alsa_input.usb-ASUS_Xonar_U7_MKII-00.analog-stereo
    89      1     25  12.4  s  13.4  s  0.00  0.00    0   + PulseAudio Volume Control
   140      1     25  23.2  s   7.3  s  0.00  0.00    0   + PulseAudio Volume Control
   141      1     25  31.4  s   7.6  s  0.00  0.00    0   + PulseAudio Volume Control
   144      1     25  38.6  s   6.9  s  0.00  0.00    0   + PulseAudio Volume Control

After some time without outside sounds (and cracks) the second Chromium entry disappears.

[AlexWayfer]

But, I also want to notice, that not only these sounds (notifications) causes cracks lags, but some actions like tab closing can cause too, but a smaller one, that's also why this issue is very similar to #222.

[wwmm]

While investigating other issues I've noticed noises similar to yours. They always happens when PipeWire is updating its latency. When a new audio application starts it may or it may not request a specific latency. If it doesn't or if it asks for a latency that is higher than the one current set PipeWire keeps the current system latency. Usually no noises in this case. But if the application requests a latency that is smaller than the one current set in the system PipeWire will adjust its latency on the fly to meet the new requirement. And this usually leads to noises until "things have settled".

At least with Spotify I was able to workaround these noises by setting PulseEffects latency to a value smaller than the one requested by Spotify. For Spotify pw-top shows 43218 in the column QUANT and 44100 in the column RATE. So the latency requested by Spotify is 43218/44100 = 0.98 seconds. When the latency in PulseEffects menu is 50 ms pw-top will show for our streams 1 in the QUANT column and 20 in the RATE column. 1/20 = 0.05 seconds. In this case the smaller latency request is from PulseEffects so no change is done when spotify streams becomes active.

Maybe setting a latency smaller than 50 ms in PulseEffects menu will help. But I think I will have to open an issue in Pipewire's page about this. It does not seem the kind of problem that can be entirely fixed in the client side.

[AlexWayfer]

But I think I will have to open an issue in Pipewire's page about this.

Thank you. I'd glad to help you, but I'm afraid only as PulseEffects user, I don't understand PipeWire and these latencies very well, and almost have no wish to deep into it. But I can provide requesting information.

Maybe setting a latency smaller than 50 ms in PulseEffects menu will help.

25, 15, even 12 doesn't help. But 10 ms seems do! Thank you. I hope it'll not burn out my computer. 😅 But, but, there are still small random cracks, not on additional sounds like notifications, but, as I wrote, tab closing, keyboard layout switching, windows switching, some else small trivial operations.

[wwmm]

I hope it'll not burn out my computer

hahaha XD. The problem with this workaround is that we kill the good thing about PipeWire's dynamic latency. We are forcing it to be always low. What uses more cpu power =/

But 10 ms seems do! Thank you

Based on your pw-top output the Chrome stream that stays is asking for 512/48000 = 0.01 seconds. So by setting 10 ms in PE menu PipeWire probably did not change its latency as the ones requested are the same now.

there are still small random cracks, not on additional sounds like notifications, but, as I wrote, tab closing, keyboard layout switching, windows switching, some else small trivial operations.

These ones may have a different source. Which priority type are you using in PE menu? If None try to use Real Time.

[AlexWayfer]

I hope it'll not burn out my computer

hahaha XD. The problem with this workaround is that we kill the good thing about PipeWire's dynamic latency. We are forcing it to be always low. What uses more cpu power =/

Yep, that's sad. Fortunately, I have powerful enough CPU and load seems OK.

there are still small random cracks, not on additional sounds like notifications, but, as I wrote, tab closing, keyboard layout switching, windows switching, some else small trivial operations.

These ones may have a different source. Which priority type are you using in PE menu? If None try to use Real Time.

OK, thank you, I'll investigate into it and try your suggestion, maybe I'll post results later here.

[AlexWayfer]

there are still small random cracks, not on additional sounds like notifications, but, as I wrote, tab closing, keyboard layout switching, windows switching, some else small trivial operations.

These ones may have a different source. Which priority type are you using in PE menu? If None try to use Real Time.

OK, thank you, I'll investigate into it and try your suggestion, maybe I'll post results later here.

Fast update: it didn't help. 😔

[rsramkis]

@wwmm @AlexWayfer

Hi Guys,

I have this feeling that I am also experiencing a similar issue to what @AlexWayfer is experiencing. Thought I might try to support the issue by sharing my notes:

When I am playing audio (e.g. streaming audio from Youtube via Tizonia in terminal) the sound works perfectly. But then when I introduce some other audio then I will popping, clicking like clipping sounds.

Examples of other audios sources:

(1) Discord in Firefox, soon as I log into the web client (https://discord.com/login).

• Pulseeffects will show the application "Speech-dispatcher-dummy"

(2) Youtube via Firefox

• Pulseeffects will show the application "Firefox AudioStream"

(3) https://open.spotify.com/ via Firefox

• Pulseeffects will show the application "Firefox AudioStream"

Observations testing with the pipewire delay of 10 - 50 ms:

• Discord via Firefox triggers the static pops continuously soon as you sign in.
• Youtube and Spotify via Firefox do not trigger static and pops most of the time. They close down cleanly (including Firefox audio process) when video is stopped or the web browser tab is closed.
• When Discord "speech-dispatcher-dummy" process is running it stays up even after logging out of Discord and closing the web browser tab.
• Discord process closes when I shut Firefox all the way down.
• Static noise gets worse when I scroll with the mouse.

My Setup:

System:
  Host: sol Kernel: 5.4.100-1-MANJARO x86_64 bits: 64 Desktop: GNOME 3.38.3
  Distro: Manjaro Linux

Machine:
  Type: Laptop System: LENOVO ThinkPad T450s

CPU:
  Info: Dual Core Intel Core i5-5300U [MT MCP] speed: 2337 MHz min/max: 500/2900 MHz
Graphics:
  Device-1: Intel HD Graphics 5500 driver: i915 v: kernel
  Display: wayland server: X.org 1.20.10 driver: loaded: intel
  resolution: <missing: xdpyinfo>
  OpenGL: renderer: Mesa Intel HD Graphics 5500 (BDW GT2) v: 4.6 Mesa 20.3.4

  Processes: 204 Uptime: 2h 07m Memory: 11.58 GiB used: 2.47 GiB (21.3%) Shell: Zsh
  inxi: 3.3.01

pipewire --v: pipewire Compiled with libpipewire 0.3.22 Linked with libpipewire 0.3.22

Example of what I see in the Pulse Effects Console > Applications:

Screen showing the PW_TOP results when reproducing the problem:

[domve]

Is there any progress on this issue? Also experiencing this on Fedora with pulseeffects 5.0.3 and pipewire 0.3.26.

Lowering the latency does seem to fix it for the most part, but then the random crackling becomes very noticable. I used to run my DAC at 96khz, and after lowering the sample rate to 44.1k it does seem to be a bit less frequent, but it's still there.

[wwmm]

Is there any progress on this issue?

Yes and no. At this moment I am working in the gtk4 port. Besides the change in the graphical toolkit version I am also moving from GStreamer to native PipeWire plugins. Hopefully this will fix this and many other issues because the whole effects pipeline will be completely different. The current approach where we take audio away from the server, process in GStreamer and send it back to to the server has had its disadvantages since the first versions in Pulseaudio.

I can already see that these kind of situations are already much better in the gtk4 branch thanks to PipeWire's native filters. But there is still a lot to be done before a release is made. So there isn't a solution you can use right now.

[AlexWayfer]

25, 15, even 12 doesn't help. But 10 ms seems do!

Right now 20 seems OK (25 doesn't), I guess some things have been changed, just a note for followers.

After a hour of usage with 20, there were noises, reduced to 15 — seems better.

[sezanzeb]

For me it was because version 4.8.4 from the ubuntu repos was installed while using pipewire. Switching to version 5.0.4 fixed the issue

[AlexWayfer]

For me it was because version 4.8.4 from the ubuntu repos was installed while using pipewire. Switching to version 5.0.4 fixed the issue

It's not about this issue, because its description contains "with PE v5".

[sezanzeb]

yeah, but I still ended up reading through this because I didn't realize my ubuntu installation doesn't have v5 in its repo, as opposed to a different computer. So if anyone is in my situation it might help. No harm was done with my previous comment, so why bother

[AlexWayfer]

@wwmm Arch Linux finally got an official and stable easyeffects. do I understand correct that now valid command for debugging is G_MESSAGES_DEBUG=easyeffects easyeffects?

[wwmm]

Yes.

[AlexWayfer]

Give me week to test the brand new EE and close or update this issue.

Oh, wait. @wwmm, we found changing latency like a big work-around. I don't see such option for the EE v6. Is it OK? If so — I'm going to close this issue.

Oh, wait. This issue is about PE v5. And this repo is no more about PE v5 and it will not get updates, as I understand. So… it's not an issue of this repository anymore. If you want to make and maintain forks — just be aware. 😁

So, right now, using EE v6, I have no… oh, stop. I've asked my GF to help to test and there is a lag with Telegram notification while YouTube music playing. 😞

Will we update this issue or create a new one, @wwmm ?

For now, attaching logs:

(easyeffects:7569): easyeffects-DEBUG: 01:22:02.166: application: device alsa_card.pci-0000_0a_00.4 has changed profile to: output:iec958-stereo
(easyeffects:7569): easyeffects-DEBUG: 01:22:18.508: presets_manager: saved preset: /home/alex/.config/easyeffects/output/Bass.json
(easyeffects:7569): easyeffects-DEBUG: 01:22:26.126: pipe_manager: Stream/Output/Audio 213 Google Chrome was added
(easyeffects:7569): easyeffects-DEBUG: 01:22:26.126: pipe_manager: new metadata property: 213, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:22:26.127: pipe_manager: Google Chrome port 80 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:22:26.127: pipe_manager: Google Chrome port 79 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:22:26.198: soe: output_level: new PipeWire blocksize: 1024
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.154: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.154: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.155: pipe_manager: Telegram Desktop port 353 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.155: pipe_manager: Telegram Desktop port 355 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.159: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.159: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.160: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.161: pipe_manager: Telegram Desktop port 355 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.161: pipe_manager: Telegram Desktop port 354 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:28:27.179: soe: output_level: new PipeWire blocksize: 512
(easyeffects:7569): easyeffects-DEBUG: 01:28:29.077: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:28:29.078: soe: output_level: new PipeWire blocksize: 1024

[wwmm]

we found changing latency like a big work-around. I don't see such option for the EE v6. Is it OK? If so — I'm going to close this issue.

I gave a long explanation for this in https://github.com/wwmm/easyeffects/issues/1008 but long story short we now follow the latency PipeWire is using. And it adjusts its latency dynamically depending on which value the audio apps are requesting. If you use a plugin that does not add latency there won't be latency to be set on our side. And the few plugins that do add one are already reporting it to PipeWire. At the bottom left side of EasyEffects window there is a number followed by the unit ms that is showing the latency added by the plugins you have enabled.

I've asked my GF to help to test and there is a lag with Telegram notification while YouTube music playing

That is probably PipeWire's dynamic latency in action. I do not remember the name now but PipeWire has an environment variable that allows the latency requested by apps to be overwritten. You can try to launch Telegram with this variable to force it to request a different latency value.

In any case it is better to open a new issue. Things are too different from before.

[wwmm]

Looking at some of the older images in this post I've noticed that speech-dispatcher is running in your computer. When doing new tests make sure that bastard is not running. That thing is really problematic and I removed it from my systems a long time ago. It caused problems in Pulseaudio and stills causes in PipeWire. Once I even saw PipeWire's developer writing "and speech-dispacher strikes again...". Unless you need it it is better to uninstall it.

[AlexWayfer]

Looking at some of the older images in this post I've noticed that speech-dispatcher is running in your computer.

Didn't find such thing in my comments, I guess you're talking about @rsramkis, but I found this thing in my installed packages. It's a dependency of orca from GNOME packages group:

Screen reader for individuals who are blind or visually impaired

But I don't see such launched process for me, but I've uninstalled these packages, let's see.

No, still a sound like click or snap twice: on notification and after around 2 seconds:

(easyeffects:7569): easyeffects-DEBUG: 01:58:31.101: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.102: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.103: pipe_manager: Telegram Desktop port 354 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.103: pipe_manager: Telegram Desktop port 353 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.105: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.106: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.107: pipe_manager: Telegram Desktop port 353 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.107: pipe_manager: Telegram Desktop port 352 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:31.125: soe: output_level: new PipeWire blocksize: 512
(easyeffects:7569): easyeffects-DEBUG: 01:58:33.027: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:33.034: soe: output_level: new PipeWire blocksize: 1024
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.864: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.864: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.865: pipe_manager: Telegram Desktop port 352 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.865: pipe_manager: Telegram Desktop port 355 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.867: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.868: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.868: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.869: pipe_manager: Telegram Desktop port 355 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.869: pipe_manager: Telegram Desktop port 354 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:35.893: soe: output_level: new PipeWire blocksize: 512
(easyeffects:7569): easyeffects-DEBUG: 01:58:37.787: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:37.792: soe: output_level: new PipeWire blocksize: 1024
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.189: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.189: pipe_manager: new metadata property: 351, target.node, Spa:Id, 343
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.190: pipe_manager: Telegram Desktop port 354 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.190: pipe_manager: Telegram Desktop port 353 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.192: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.192: pipe_manager: Stream/Output/Audio 351 Telegram Desktop was added
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.193: pipe_manager: Telegram Desktop port 353 is connected to easyeffects_sink port 345
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.193: pipe_manager: Telegram Desktop port 352 is connected to easyeffects_sink port 74
(easyeffects:7569): easyeffects-DEBUG: 01:58:42.208: soe: output_level: new PipeWire blocksize: 512
(easyeffects:7569): easyeffects-DEBUG: 01:58:44.114: pipe_manager: Stream/Output/Audio Telegram Desktop was removed
(easyeffects:7569): easyeffects-DEBUG: 01:58:44.117: soe: output_level: new PipeWire blocksize: 1024

But I agree: we should create a new issue, and it can be not an EE issue. I'll try to look into this PipeWire ecosystem and env variables.

(for me latency with the single Bass Enhancer plugin is 0.0ms in the left bottom corner)

[rsramkis]

speech-dispatcher

The speech dispatcher process was automatically launching when using the Discord Web application in Firefox.

[amfern]

I had similar issue, disabling speech-dispatcher in firefox solved it https://www.reddit.com/r/firefox/comments/7n5vn6/linux_firefox_and_speechdispatcher_are_making/

[rsramkis]

I had similar issue, disabling speech-dispatcher in firefox solved it https://www.reddit.com/r/firefox/comments/7n5vn6/linux_firefox_and_speechdispatcher_are_making/

This is a good point. Please keep in mind that I believe the speech dispatcher is also used in Accessibility functionality between the web browser and Web Applications so disabling it outright might not server all people.

In Discord (via Firefox) I happen to notice I could just shut it off in the Web Applications in the Settings > Accessibility:

[mempler]

good to know, it's still happening to me but when i close discord, everything works fine. guess i'll use webdiscord for now. i do have TTS disabled

[Compizfox]

I still got this problem with Spotify and Firefox.

Spotify seems to use a quite large latency. Not really a problem, but noticeable when starting/stopping playback (and relevant later on, I think). According to EasyEffects it's 0.19 s.

When I'm playing music from Spotify, and start or stop audio playback in Firefox (e.g. from a video), I hear a jarring glitch in the sound for a fraction of a second. It sounds like the EasyEffects plugins get temporarily disabled. Because I'm using the convolver as an equalizer (with quite a substantial negative pre-amp gain), the sound gets a lot louder with it disabled. I think that's what I'm hearing when Firefox starts/stops playing sound.

As @wwmm suggested, I looked at pw-top when this happens. When only Spotify is playing sound, it reports this:

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR  NAME        
    82   8192  48000 658.3µs  27.9µs  0.00  0.00   10  alsa_output.pci-0000_0b_00.4.analog-stereo
    47      0      0   9.7µs  19.9µs  0.00  0.00   10   + easyeffects_sink
    85      0      0   7.0µs  25.4µs  0.00  0.00   10   + ee_soe_output_level
    90      0      0   7.6µs  74.3µs  0.00  0.00   10   + ee_soe_spectrum
    95      0      0  12.3µs 289.3µs  0.00  0.00   10   + ee_soe_convolver
   103   8192  44100  14.0µs 170.3µs  0.00  0.00   10   + spotify

Then, with Firefox also playing sound:

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR  NAME        
    82   2048  48000 268.8µs  15.9µs  0.01  0.00   10  alsa_output.pci-0000_0b_00.4.analog-stereo
    47      0      0   6.3µs   9.7µs  0.00  0.00   10   + easyeffects_sink
    85      0      0   9.1µs   9.9µs  0.00  0.00   10   + ee_soe_output_level
    90      0      0   4.1µs  45.2µs  0.00  0.00   10   + ee_soe_spectrum
    95      0      0   9.6µs  84.8µs  0.00  0.00   10   + ee_soe_convolver
   103   8192  44100  10.8µs  43.3µs  0.00  0.00   10   + spotify
   194   3600  48000  52.6µs  10.6µs  0.00  0.00   10   + Firefox Developer Edition

So, if I'm interpreting this correctly, Firefox is reducing the quantum from 8192 to 3600.

Any ideas on how to tackle this?

EDIT: Just found #1071, which I think is the same issue.

EDIT: Found out I can fix it by reducing the maximum buffer size of Pipewire to something lower:

/etc/pipewire/pipewire.conf:

default.clock.max-quantum =    2048

This works for me, but in the context of EasyEffects I guess it's more of a workaround than a fix.

[wwmm]

This works for me, but in the context of EasyEffects I guess it's more of a workaround than a fix.

Yes. In our latest release we do not reinitialize LV2 plugins when the latency changes anymore. So for these plugins(that are the majority of the plugins in EasyEffects) things should be better.

[POMATu]

Hello, could someone hint me please what steps to actually implement to have any kind of solution to stop hearing crackles during music playback.

I was using pipewire from ubuntu repos, now upgraded from ppa to pipewire 0.3.51. Still problem persists I tried lowering max-quantum but still I hear crackles in youtube playback in chromium

    default.clock.max-quantum   = 512

You were speaking about tweaking something but i read whole thread havent found what do I need to edit. This issue is so annoying that I would rather quit pipewire and return to pulse-audio just I am also using Noise Cancelling Source which works very well, so I really want to fix this issue in pipewire

[wwmm]

@POMATu it is hard to say because crackles can have many sources. If changing the quantum has no effect maybe the sources of your crackles are in the card driver. At least my card produces noises whenever it enters / exits the suspended mode. Try to disable this in PipeWire. Maybe that is what is happening to you.

[Adiker]

I can confirm this is still an issue on newest PipeWire and happens only when using EasyEffects and when app changes buffer size (quantum) there's a noticeable glitch/crack in the sound. The only workaround I've found to be working is either specifying the same min/default/max quantum value (thus forcing it to stay the same all the time) or turn off EasyEffects. I hope this will be resolved either in PipeWire or EasyEffects (wherever the issue actually is).

[Iheuzio]

The problem you're referring to is audio clipping from what I can see, that is due to the volume being passed through PulseEffect, to fix this you can simply lower the input and output gain levels so you are not getting any errors (Which causes cpu usage to spike and clipping to occur). That's normal for all music software to do, however you just have to be always in the negative Decibels for both in and out volume levels. Hope this helped.

[MrAru]

The same issue presents a long period after I switched from pulseaudio to pipewire. Now I believe this problem should be due to the dynamic quantum changing, just as https://github.com/wwmm/easyeffects/issues/900#issuecomment-1119420249 said. I manually hard-code the min/default/max quantum value, forcefully set this value to 1024 and no more glitch !

The only weird thing, is that even if I set the quantum value to 1024, pw-top says that Chromium has a value of 512. I'm not sure if this is causing some inconsistency.

[wwmm]

The only weird thing, is that even if I set the quantum value to 1024, pw-top says that Chromium has a value of 512. I'm not sure if this is causing some inconsistency.

This is just the value that chromium is requesting. If I remember well the value actually being used by the server is the one shown next to your sound card device name. And as you as forcing a value this should be 1024.

[Compizfox]

The problem you're referring to is audio clipping from what I can see, that is due to the volume being passed through PulseEffect, to fix this you can simply lower the input and output gain levels so you are not getting any errors (Which causes cpu usage to spike and clipping to occur). That's normal for all music software to do, however you just have to be always in the negative Decibels for both in and out volume levels. Hope this helped.

I'm afraid you're misunderstanding the issue. It's not 'just clipping'. The issue is that when Pipewire changes the quantum (because some software that requests a lower quantum starts/stops playback), the EasyEffects plugins momentarily get disabled. This is the source of the glitching sound.

[wwmm]

The issue is that when Pipewire changes the quantum (because some software that requests a lower quantum starts/stops playback), the EasyEffects plugins momentarily get disabled. This is the source of the glitching sound.

Yes. But nowadays this should not be happening to the plugins that are accessed through the LV2 API. In the past I assumed they needed to be reinitialized when the buffer size changed. What is going to happen when latency changes. But according to the LV2 standard author this is not necessary. As almost all of the plugins used in EasyEffects are LV2 plugins this issue should only happen with a few plugins I have written myself. I think that only the crystalizer, noise reduction and the convolver plugins are still restarted when latency changes.

If latency changes are still a problem with the LV2 plugins we use either the plugin is reinitializing data structures internally or the source of the problem is inside PipeWire's null-sink code.

[Compizfox]

I think that only the crystalizer, noise reduction and the convolver plugins are still restarted when latency changes.

Figures; the convolver is the only plugin I'm using... ;)

[pranaypratyush]

Is there any solution to this? It happens every time audio is played/stopped in the browser. Can't we just match the quantum for all the players in my system? I set ~/.config/pipewire/pipewire.conf

context.properties = {
  default.clock.rate          = 96000
    default.clock.allowed-rates = [ 32000 44100 48000 96000 ]
    default.clock.quantum       = 256
    default.clock.min-quantum   = 256
    default.clock.max-quantum   = 256
   }

but it's not doing much. what am I doing wrong?

[Compizfox]

Is there any solution to this? It happens every time audio is played/stopped in the browser. Can't we just match the quantum for all the players in my system? I set ~/.config/pipewire/pipewire.conf

context.properties = {
  default.clock.rate          = 96000
    default.clock.allowed-rates = [ 32000 44100 48000 96000 ]
    default.clock.quantum       = 256
    default.clock.min-quantum   = 256
    default.clock.max-quantum   = 256
   }

but it's not doing much. what am I doing wrong?

What quantum does pw-top report?

[wwmm]

default.clock.allowed-rates = [ 32000 44100 48000 96000 ]

@pranaypratyush Besides checking through pw-top if the correct quantum size is being set by PipeWire also pay attention if the stuttering is happening when the sampling rate changes. As you have a few values in the allowed-rates array it may happen that the quantum size is the same but our filters have to be restarted because the rate has changed. By the way which plugins are you using?

[pranaypratyush]

I am using convolver and bass enhancer

[Adiker]

Still happens to me, for me the problematic plugin is Crystalizer. Removing/turning it off makes the stutter go away.

[hamidr]

I am not sure if this is related but it's worth looking at: https://davejansen.com/disable-wireplumber-pipewire-suspend-on-idle-pops-delays-noise/

[wolf-yuan-6115]

I am not sure if this is related but it's worth looking at: https://davejansen.com/disable-wireplumber-pipewire-suspend-on-idle-pops-delays-noise/

This fixes some issue with Pipewire for me.

[Tyler12970]

I am not sure if this is related but it's worth looking at: https://davejansen.com/disable-wireplumber-pipewire-suspend-on-idle-pops-delays-noise/

The only thing that I did differently with my Tuxedo OS laptop (Ubuntu derivative) was that I temporarily used the superuser command (su) and manually created the folder in the Dolphin file manager since the first command did not copy right away.

Thank you for the link and shout out to Dave for being an absolute legend! These crackling sounds annoyed me for months!

[stvy-silli]

Hello everyone i also had a similar issue. where pop sounds would come most of the time (randomly). It especially came when unpluging my laptop from ac.

it was not because of suspend-on-idle it was because of "level-meter" effect (supposed to calculate peak and stuff) after turning it off, my poping sounds were gone