Hi, I switched to openSUSE Tumbleweed half a year ago, and have been mostly satisfied, however I have a few nagging issues. Some are quite minor, including this one, but it does make the experience noticeably less polished.
So, whenever I start a game or something else demanding I get audio stutters while starting it. Strangely enough, that often includes when just having Steam open and I turn my main screen on (I have two). My computer has the following:
I also used to have video stuttering while playing a game if e.g. Spotify changed track, but managed to work around that by turning off the Plasma notification that pops up, so there seems to be some wider system prioritization issues.
First suggestion: Change from Pulseaudio to Pipewire. There is a lot of info about how to do it. If you are not able to find how, tell me.
Second: A recent Steam update disabled main interface hardware acceleration on Linux. So, if you launch a game from Steam and let main Steam application open, you will have performance issues , cause in background, Steam continues playing “Library” animations and taking CPU.
Third: Usually, audio stuttering is result of a heavy load of I/O in hard disk (HD not usually with SSD).
I’m using Leap 15.4 here – Tumbleweed may well be different:
The “pipewire” and “wireplumber” packages are installed by default but, the following packages may also need to also be installed:
“wireplumber-lang” and “wireplumber-audio”
“pipewire-libjack-0_3” and “pipewire-pulseaudio”
“gstreamer-plugin-pipewire”
On Tumbleweed, the Pulse audio packages should not have been installed – the systemd user service “pipewire.service” should be executing by default.
Yes I am already using Pipewire, as it is default in Tumbleweed. And from what I’ve heard, real-time kernel is not really necessary anymore since real-time patches are already in the mainline kernel. Pipewire uses rtkit to make the system prioritize itself, according to https://docs.pipewire.org/page_module_rt.html. From checking the Pipewire config file and the system monitor Pipewire has a nice value of -11, which means it should get rather high priority I’d think, so it’s strange that a game launched from Steam makes sound stutter. Apparently Steam has a nice value of -10, which is lower, and any game process launched has the value 0, so even lower priority.
Heavy I/O should not be the cause either, since my system is running on a fast NVME SSD.
If you are using Pipewire and you have this stuttering problem, I’m afraid the problem is related to your CPU power. Have you seen the CPU and GPU load when this happens? I’m sure the CPU will have all threads at 100%, can you look at it?
That is unfortunately not the case. I’ve used both btop and the Plasma system monitor to see if it spiked to 100%, but no, a Ryzen 5 5600X, while not the newest and beefiest, should tackle a fair amount of desktop multitasking fine, including starting a game without audio dropouts.
However, I’m sure you will all be glad to know, I found something that has alleviated the issue a lot. It hasn’t solved it completely, but now it’s only on very rare occasions that audio dropouts happens while starting some other program. Thanks a lot to @deano_ferrari as the thread he linked to, while not directly related, helped me notice the
#link.max-buffers = 64
link.max-buffers = 16 # version < 3 clients can't handle more
block in the pipewire.conf file. Simply swapping which one was commented out, so link.max-buffers = 64 instead of 16, seemed to do wonders for avoiding the consistent audio dropouts when starting a program. As said, it still can happen, but it’s no longer consistently easy to reproduce, so I think I am satisfied with that.
Now, if only the proprietary NVIDIA driver would behave properly… but that would be for another day and another thread, plus I’m not sure there’s a lot that could be done about that with the proprietary driver anyway.
Thanks to everyone for participating in this thread, even if you didn’t directly help it’s always good to have people ask questions because it helps me to check more things and troubleshoot further. Glad to see the openSUSE community is alive and well and ready to help.
Good to read of your success after changing the link.max-buffers value. A similar post here discussing that and the default/min quantum clock settings to optimize sound processing for a given system environment…
I’m glad it worked for you. However, there is one thing that should be carefully considered before changing this value. On PipeWire’s own page it clearly says about the “link.max-buffers” parameter: “More buffers is almost always worse than less, latency and memory wise”.
You can use “pw-top” and “pw-profile” to guess what was happening while playing that game and try to fix issue.
Thanks for the warning. I also set default.clock.min-quantum = 256 because I also do some music production and I need low latency when using a MIDI keyboard, and from testing in my DAW 256 is a nice sweet spot where it doesn’t tend to lead to crackling but also has acceptable latency (even though less would always be desirable). But most programs don’t ask for less than 256 anyway, so I don’t think it’ll really change much in practice.
pw-top is what I’ve used indeed, to confirm it wasn’t just my head lagging but the actual audio too. Haven’t tried pw-profiler before now, and ran it while getting some audio crackling, but I am not quite sure how to interpret the graphs. Here they are, in case they tell you anything I could change to make it even less likely to happen:
The most complete article about is this one. In fact, it explains too another CLI tools.
Also, I don’t know if you know UMFA’s YouTube channel. It has very interesting videos about everything related to pro audio on Linux. I leave you here a very interesting video of his, but you will find many more on his channel.
