I don’t usually have a case to go off on a Linux or an open source project. But in the case of PulseAudio — I do. Let me set this stage.

One of my other, many jobs, is recording audio books. For this job I use Audacity — it’s a perfect solution for the task. I use Audacity on Ubuntu 12.10. Since purchasing a new computer (one with an Intel i5 chip), I’ve had nothing but issues with skipping sound (which caused ‘hiccups’ in the system and in my recordings). And I have gone through a long list of troubleshooting steps:

  • Replaced motherboard
  • Ran memtest86
  • Replaced hard drive
  • Tested CPU
  • Installed three flavors of Linux (Ubuntu Studio, Linux Mint, Ubuntu 12.10)
  • Installed three different kernels (3.7, 3.8, and low-latency)
  • Tried various multimedia players
  • Tweaked PulseAudio settings
  • Read more about sound than I thought I ever would

Turns out — the issue has been around for some time and is still a problem. Now, before I lay blame on a single project, I understand it’s a challenge. The PulseAudio developers have to deal with multiple hardware, many distributions, desktops, and applications. It would be a daunting task for anyone. But —  and here’s where the sympathy leaves the building for me — prior to PulseAudio, this wasn’t an issue (and the developers of Esound, OSS, and Alsa had the same pressures on their shoulders).

I should also say that some of my tweaking had better results (I’ll share what I did in a moment); but, in the end, the skipping persists. I have to say this: Get it together PulseAudio! I’ve scoured countless forums to find posts dating back to 2008, posts complaining of the same problem. Countless bugs have been filed, but the pleas for help seem to fall on deaf ears.

Understandably, this issue is more of a show stopper for me. I happen to depend upon sound for income — and the more I have to re-record sections of a book, the longer it takes me to complete a project. Or, even worse, I miss one of the skips and the book goes to finalization with a flaw — not good (of course I listen very closely, so I rarely miss them). But this problem has got to be addressed.

Here’s the problem: When PulseAudio works well, it’s a dream. But when it starts causing problems, it’s a nightmare. Removing PulseAudio isn’t the solution — as too many distributions are now in deep with this sound system. Ultimately, the solution is for the skipping audio to be fully, and completely, addressed.

My optimizations

I’ve managed to get my skipping down to a bare minimum. I’ve tried quite a lot of tweaks and changes, but ultimately, what has worked the best for me, is the following:

  • kernel 3.8.1 – generic
  • using Audacious to listen to sound (making sure to choose PulseAudio for the output settings)

The following tweaks need to be made in the /etc/pulse/daemon.conf file:

Uncomment the following lines:

  • realtime-scheduling = yes
  • realtime-priority = 5
Uncomment the following lines:
  • default-sample-format = s16le
  • default-sample-rate = 44100
  • default-sample-channels = 2
Set the following*:
  • default-fragment-size-msec = 125
  • default-fragments = 2
* The above numbers were derived from the following steps (done from a terminal window):
  1. echo autospawn = no >> ~/.pulse/client.conf
  2. killall pulseaudio
  3. LANG=C pulseaudio -vvvv > ~/pulseverbose.log 2>&1
Hit Ctrl-c to return to your prompt. Now run the following commands:
  • rm ~/.pulse/client.conf
  • grep device.buffering -m2 ~/pulseverbose.log
The second command should present to you something like:
: sink.c:     device.buffering.buffer_size = “352800”
: sink.c:     device.buffering.fragment_size = “176400”
The calculations for the settings are:
  • 352800/1411200 = 0,25s = 250 msecs
  • 176400/1411200 = 0,125s = 125 msecs

Once you’ve added those settings to /etc/pulse/daemon.conf, restart PulseAudio with the command pulseaudio -k. You should now enjoy less (but not zero) skipping.

This PulseAudio issue has had me climbing the walls over the last couple of months. I sincerely hope someone will take note and push for a concerted effort to resolve a problem that has plagued the system for nearly half a decade. And should the developers not be capable of solving this issue, I would ask the major distributions (those that depend upon PA) to find an alternative! This problem is going to only become worse as more and more people start playing games on Steam. How shameful would that be if Linux begins to start gaining serious momentum on the desktop, only to have it shot down because of a faulty sound server?