You’ve installed Steam in Linux, then some games from your library, and went on to enjoy the games. You launched your favorite game, turned on your speakers or put on your headphones, and then rushed to mute them because of the annoying cracking sound. Is that your experience with Steam games for Windows playing under Linux?
The source of the problem is an incorrectly-configured parameter in Pulseaudio and can show up in any Linux distributions. Thankfully, there’s an easy fix. Read on to find how you can fix the Steam games cracking sound issue in Linux with a simple tweak.
Also read: How to Record System Sound on Linux
Tweak the PulseAudio Daemon
The fix to our problem is a two-part process, with the possibility of some troubleshooting afterward for good measure. Let’s start by tweaking PulseAudio’s daemon.
Fire up your favorite terminal, and enter:
sudo nano /etc/pulse/daemon.conf
Search for the parameters “default-fragments” and “default-fragment-size-msec.” Both should already exist, but if they don’t, feel free to add them yourself. Set their values to 2 and 4, respectively. They should look something like this:
default-fragments = 2 default-fragment-size-msec = 4
Save the updated file and restart PulseAudio to apply the changes. You can do that with:
pulseaudio -kThat concludes the first part of our tweaks. Don’t worry, as the one that follows is even easier!
Tweak the Sound Server
Relaunch your favorite text editor, but this time edit the file that defines how the PulseAudio sound server should start, with:
sudo nano /etc/pulse/default.pa
Locate the section which tells PulseAudio to load driver modules using udev. It will look like this:
### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect .else ### Use the static hardware detection module (for systems that lack udev support) load-module module-detect .endif
Update it by adding tsched=0 at the end of “load-module module-udev-detect”, so that the new version reads like:
### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect tsched=0 .else ### Use the static hardware detection module (for systems that lack udev support) load-module module-detect .endif
Save the changes and restart PulseAudio once more with:
pulseaudio -k
And that’s it – hopefully, the problem will be gone.
Troubleshoot
If the tweaks above improved your situation, but it’s still not fully fixed, re-edit the first file and increase the values of the “default-fragments” and “default-fragment-size-msec” parameters. Try values like “3” and “5” or “4” and “8,” respectively. Don’t go crazy from the get-go, but increase the values progressively until the problem’s eliminated.
On the other hand, if those tweaks made the problem worse, it’s worth going the other way around. Decrease the values for those two parameters, then go back to the second file and modify your tweak to tsched=1.
Restart PulseAudio once more and check whether your problem is fixed this time. If it’s not, go back to both files and undo any changes. Unfortunately, in this case, the source of the problem lies elsewhere.
It’s worth trying different drivers for your audio subsystem, but since those tend to be included in the kernel, that would mean swapping your distribution’s kernel for a different one. Check if there’s a newer one available. If not, either revert to a previous one or install an alternative kernel, like Liquorix.
Drivers, Buffers, Scheduling
You may wonder why those parameters (possibly) fixed your problem. It all has to do with your audio subsystem’s hardware, its drivers, and how PulseAudio uses it.
The first two parameters we changed split the audio device’s buffer into fragments. Depending on your audio subsystem, this may help the operating system stream data to your audio subsystem, which is then turned into sound.
The second parameter changes PulseAudio’s scheduling approach. Since version 0.9.11, PulseAudio uses a system-timer-based model. However, this demands your hardware and driver return accurate timing information. Some do, like Intel’s solutions. This is considered the modern and better approach. Some, like many soundcards by Creative, don’t. Depending on your hardware and drivers, turning the timer scheduler (the tsched parameter we introduced) on or off (values 1 or 0) can make a world of difference.
If instead you have the no-sound issue in Ubuntu, here is how to fix it.
Our latest tutorials delivered straight to your inbox
