Your comments keep generating more questions. So use of pipewire or pulseaudio is application specific. How do you find out what audio an app is trying to use? What does youtube use for audio?
I suppose I should find that out as to whether youtube uses pipewire or pulseaudio as that is the source of my primary cracking issue.
I will look this up if you don’t have any immediate info.
oh no. cracking started again. Real bad: can’t comprehend an audio.
I did a pipewire restart and it cleared up while the same video was still running.
If a restart of pipewire corrects the problem with unchanged pipewire.conf parameters, I would say the problem source resides outside of the pipewire system and it’s config file.
I get sporadic interruptions on bluetooth, though they are relatively minor. I can stop them by disabling WiFi. But then I am mainly using a wired connection. If I were using WiFi for my networking, I would expect the interference to be more severe.
My temporary fix now is to restart pipewire. I made an alias to run that.
Not the best solution but I will use it until it stops working.
Shouldn’t need to do this.
While the app is actively playing audio, open a terminal and issue:
systemctl --user stop pipewire-pulse
If the sound stops the app is using the pipewire-pulse interface.
Anyway, afterwards you may issue systemctl --user restart pipewire-pulse to restore the default system setup and the app might need restarting to output sound again.
BTW, Firefox playing YouTube appears to be using pipewire-pulse here on Tumbleweed.
(base) tom@mydesktop: ~ $ systemctl --user stop pipewire-pulse
Stopping 'pipewire-pulse.service', but its triggering units are still active:
pipewire-pulse.socket
youtube briefly interrupted but continued to run audio with no manual intervention.
Then restarted pipewire-pulse. youtube did another short interruption but kept going with no intervention.
Guess youtube was running pipewire-pulse but fell back to just pipewire.
So, pipewire-pulse config needs to be adjusted to affect youtube cracking, I believe.
That is a step to a fix.
I have cracking restarted. It is so bad you can’t listen and comprehend the audio on a youtube video. Pipewire restarts do not work as I thought they had been doing. I have tinkered again with some of the parameters in pipewire.conf that have been suggested by others. I think all I have tried is for naught.
I have seen crackling get worse over time. Others have made similar comments. From my computer experience, it is not normal computer behavior for something to change over time. It is like some buffer is filling up and generating problems until it is cleared out. I don’t know what this could mean in audio processing.
I am back to my solution from 2024, i.e., a system reboot. This just worked to clear my bad cracking.
This problem is a long way from being under control for me.
There are too many things that can go the wrong way playing youtube videos, so that is not a good way to try and troubleshoot the issue. BTW, we still don’t know how you are playing youtube videos (which browser for instance or whatever).
To test whether it is a pipewire issue or not, I recommend playing a simple audio file, no exotic format (mp3 or flac will do) using a simple player (even the command line ffplayin extreme cases). While that is playing, pw-topshould clearly show where, if any, buffer underrun occurs in the ERR column.
Your current pipewire settings seem sound for a recent system, so maybe the problem is somewhere else?
Yes, check bug 1237419: is your current user a member of the “pipewire” group? (Hint: you may have to manually add that group to the system).
The pipewire chain has several buffers of varying length (check the “QUANT” column in pw-top) and cracklings are usually an effect of a “buffer underrun” which happens when a buffer in the chain is emptied faster than it is filled up by the preceding stage, or possibly a “buffer overrun” when the buffer is not emptied fast enough and even when it is full the feeding stage or app doesn’t stop sending data.
That is very often seen with bluetooth, so if you are using BT anywhere in the chain look there.
I have not seen anything that requires a full system restart here, so maybe your problem is not strictly related to pipewire and tweaking its config might not give the expected result.
I listen to youtube continuously. My crackling complaints have all been based upon youtube videos that I run in valvaldi (chromium based) browser. I too have thought that youtube and vivaldi could be culprits. When cracking was severe, I did test restarting youtube which did not stop the cracking. I did also test restarting vivaldi that also did not stop the cracking. So I have discarded them as causations at the present time.
I have not run other audio like vlc for extended period to test for initiation of cracking. I am planning to do that. I do not recall ever having observed cracking in vlc but I don’t use that heavily.
After system reboot with no other changes, audio has been perfect after about 10 hours continual use.
That smells of memory leak or something like that; if that is the case, tweaking pipewire config will do nothing.
When crackling occurs, is the system using the swap space (if the system has any swap at all…)?
There is zero swap use. I have never seen any swap use in System Monitor after 6 or so years use. Has 32gb memory. Usage has never challenged this number and I do do some number intensive fluid dynamics parallel processing tuff. Has 4tb disk about 30% full. . System Monitor says 0.6% swap use.
I installed vivaldi (the rpm from their website) and after one hour or so of listening to internet radios and watching a few YouTube musical videos my first impressions are that:
it looks like a memory hog (and to an extent also a cpu hog): only one tab, listening to a radio, minimal quasi static graphics, I see 13 related processes, 2 eating some 50% cpu core each, 4 of them with a 75-150 MB memory footprint;
what is worse, while watching YouTube (with even more load on cpu and RAM), there is at least one related process using some 400 MB of RAM and apparently ever increasing: cannot say if it is a memory leak at this stage, but something worth noting;
sound wise, it uses pipewire-pulse;
it looks somewhat conservative about sound buffers, IMHO you don’t need to increase the “quantum” values in your current pipewire (and pipewire-pulse) setup.
All in all, vivaldi does not seem very efficient on resources and I would keep an eye on its use of memory (and possibly cpu) after 10 hours of continuous operation especially when audio crackling appears; the possibility of a memory leak seems a real one.
For a thorough troubleshooting I would try also another browser and some tests with files on disk played with a simple player to exclude network, bluetooth and similar effects.
At this point I am not sure that your problem is with pipewire or even that it can be solved by tweaking pipewire beyond what you have already done.
Good Luck (and keep us updated… )
35 hours after the reboot, cracking started again. youtube audio was running probably half that period.
Another reboot this morning cleared the problem. I’ll see how long it takes to deteriorate again.
I do use bluetooth headphones primarily but also have wired headphones that I can easily switch to. I have verified in the past that the cracking is also in place when I switch to wired headphones while the system is in a cracking state. I should verify that again though.
I only use ethernet wired internet connections. Wireless is in place but not used.
This machine is about 6 years old. Pretty high end when I assembled it; i7 cpu, 32gb harddisk. Do not recollect getting audio cracking until the last year or so. Perhaps it is an equipment deterioration issue.
I have seen cracking issues raised in forums of other distros.
Still pretty high end IMHO. I cannot see cracklings on a 10 yrs old laptop (i74720, 16 GB RAM) with default settings and I would rule out equipment deterioration other than loose or oxidized connectors. More likely that some SW update (or bloating) in the last year or so introduced a bug or exposed a system bottleneck somewhere.
If the problem shows again, record RAM and CPU usage (or anything odd on system monitor) and try ffplay <path to an audio file on your disk>and see how it goes.
And FWIW I fired up a Leap 15.6 test install on the same HW and found that pipewire is still in better shape there than it is currently on Tumbleweed, no bug 1237419 and I could go as low as default.clock.quantum = 64without cracklings (remember you currently have default.clock.quantum = 1024, or 16x my test setting, so you should be pretty safe on that side).