In part 1 we saw recommended settings for bit depth and sample rates, why these are recommended, how they work, and how to set them. Here, we’ll talk about glitch-free audio.
If you want to check your configuration, skip ahead to part 3. Or return to part 1.
In Ubuntu you may notice occasional audio glitches. They can be obvious or subtle. For example, here is one I encountered recently that is not quite obvious, but you can definitely hear if you are paying attention:
The higher the resolution of the audio, the increased demand for data flow & processing, the more likely these glitches are to occur. These glitches arise from the way Pulseaudio buffers audio data and schedules interrupts for itself to process and flow that data. Many systems don’t glitch with CD quality and lower, but start to glitch at higher rates. Or they may glitch only when the PC is busy doing other work.
Fortunately, this can be configured so almost any computer can play high resolution audio glitch-free. I’ve experimented with these settings on a 15-year-old PC running Ubuntu 18 that was seriously glitchy even at CD quality, using default settings. By changing settings I got this PC to play local audio files up to 192-24, and stream audio in the browser up to 96-24. Then I applied these settings to a fast modern PC running Ubuntu 16. This PC played CD quality audio just fine with the system defaults, but glitched when playing back high resolution audio. This PC now plays back audio seamlessly at all bit rates.
There are 4 basic settings to configure. You may not need to do them all. Try each individually in turn to see if it fixes the problem.
Pulseaudio Process Priority
The Pulseaudio process normally runs at nice level -11. This gives it priority over normal system processes. But increasing its priority even more can help. That means a numerically smaller number (you’re being “less nice” to the rest of the system).
File: /etc/pulse/daemon.conf
; nice-level = -11 nice-level = -15
Comment out the default nice-level and set it a bit lower. It doesn’t seem like much, but it does make a difference.
Pulseaudio Timer Based Scheduling
A few years ago, Pulseaudio switched to timer based scheduling. This is a better way to reduce audio latency while keeping audio streams running smoothly. But Linux is not a real time operating system; it doesn’t give processes guarantees when they will get CPU time. So timer based scheduling sometimes causes buffer under-runs, which is one cause of audio glitches. The timer based scheduling system is supposed to detect when this happens and increase buffers & latency to compensate. But even if it does, you may still get occasional audio glitches as it detects and compensates.
File /etc/pulse/daemon.conf has settings for audio buffers:
; default-fragments = 4 default-fragments = 4 ; default-fragment-size-msec = 25 default-fragment-size-msec = 50
The total buffer is fragment size * count, so the above example is 4 * 50 = 200 ms of audio buffer, which is 200 ms of latency. This is more than twice the default value.
Note: while the setting says milliseconds, it actually sets the buffer size in bytes. The conversion is based on the default sample rate. So if you set it to 200 ms and the default rate is 44.1 kHz, at 96 kHz it will be about 92 ms, as 200 * (44.1 / 96) = 91.875.
However, if you simply increase these values and restart Pulseaudio, nothing will change. That’s because Pulseaudio by default uses timer based scheduling, which ignores these buffer settings. For these settings to take effect — to increase the buffer size — you must disable timer based scheduling.
Open this file: /etc/pulse/default.pa
Look for this section of the file (around line 50):
### 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
See the line I marked in bold face above? Add a parameter at the end, like this:
load-module module-udev-detect tsched=0
Adding this parameter and setting it to 0 disables timer based scheduling, and makes Pulseaudio use the fragment settings shown above.
Don’t go too crazy with huge audio buffers. Increase it just enough to eliminate audio glitching, and add maybe 50% more to account for system load or high sample rates. Big buffers increase latency which becomes problematic in applications like gaming and video calls.
Resampling
In part 1 we mentioned using the highest quality resampler, soxr-vhq or speex-float-10. You can use a faster, lower quality resampler like speex-float-3.
However, if it becomes necessary to make this change, then there’s no point to high resolution audio because your system is so slow it can’t handle the necessary data & processing. So if you must resort to this, you should also set sample rates back to their defaults (44100 and 48000), and set avoid-resampling to false (its default). This way, Pulseaudio will downsample higher rates to something your system can handle, and it will use a fast lower quality resampling algorithm when doing so.
The benefit is, if your system can’t handle high resolution audio, at least you can configure it to play CD quality audio glitch-free.
CPU Governor
Ubuntu’s default CPU governor is “ondemand”, which sometimes throttles back the CPU when it shouldn’t. For example, playing audio is considered a background task, and it may think the PC is not busy and throttle back the CPU, causing audio glitches.
It’s worth trying the “performance” governor instead. If it doesn’t improve things, you can easily revert back. To try this, first disable the service that always sets the “ondemand” governor, because this will override any other settings you make:
sudo update-rc.d ondemand disable
Next, install package cpufrequtils:
sudo apt install cpufrequtils
Then edit the config file: /etc/init.d/cpufrequtils
Find the commented-out section that looks like this, around line 40
# eg: ENABLE="true" # GOVERNOR="ondemand" # MAX_SPEED=1000 # MIN_SPEED=500
After this section, add a line like this:
ENABLE="true" GOVERNOR="performance
Ensure to comment out or replace any existing lines that set these same settings. Then reboot.
Conclusion
Make sure to restart Pulseaudio after every config change. Use “ps” to ensure only 1 copy of the pulseaudio process is running at a time. When you find settings that work, try them under different conditions of system load to see how robust they are. Sometimes they’ll work when the system is idle then you’ll have problems when it gets busy, as other processes take computing time away from Pulseaudio.
Glitch-free audio is easier to achieve when playing back local files, than when streaming. This is because streaming presents more system load. Thus, you may find settings that work fine for playing back local files but glitch when streaming. If so, try increasing the buffer size.
Note: this method uses bigger audio buffers to ensure smooth playback. This increases latency, which can negatively impact other applications like video calling, movies, and gaming. So, experiment with different buffer sizes and uses the smallest buffers that work reliably. Above I mentioned an alternative approach. Instead of increasing buffering, you can enable the Linux kernel "threadirqs" feature and increase the IRQ priority of the sound card. This may provide glitch-free playback without increasing latency. I have not tried this approach.
Now, we can jump to part 3, where we check how things work while playing audio.