So after running into this problem suddently and for no ‘apparent’ reason(although it became apparent later) I noticed the complete lack of real support docs online in regards to the ALSA underrun problem.  Hopefully I can rememdy this a little bit and help some people out.

Last week I noticed skype audio was getting really choppy, it was the equivalent of seeing the conversation through a strobe light.  Odd I thought but didn’t pay it too much heed, that was until the end of the week when the audio simply stopped all together and skype refused to close down normally.  I would have to manually kill the process in terminal after the sound cut out.  This problem was exclusive to skype, which made it even more frustrating as I could have youtube and/or music playing in exaile while skype was screwing the pooch.

It occured to me today that something indeed had been changed recently right before this problem started and that was me fiddling with pulse’s daemon.conf and enabling real-time scheduling.  I can’t remember what for but this was part of the problem.  In fact there is even a mention in pulseaudio’s man page in regards to the possibility of real-time scheduling causing problems which I’ll quote here:

Alternatively,  if the risk of locking up the machine is considered too
big to enable real-time scheduling,  high-priority  scheduling  can  be
enabled  instead  (i.e.  negative  nice  level). This can be enabled by
passing –high-priority (see above) when starting  PulseAudio  and  may
also  be  enabled  with  the approriate option in daemon.conf. Negative
nice levels can only be enabled when  the  appropriate  resource  limit

RLIMIT_NICE  is  set  (see setrlimit(2) for more information), possibly
configured in /etc/security/limits.conf. A resource limit of 31 (corre‐
sponding with nice level -11) is recommended.

At this point I got a little excited as the solution seemed within reach.  I hashed out real-time schedule and implemented high-priority scheduling, restarted pulseaudio and loaded up skype.  It started fine but when I made a test call I was once again plagued by ALSA underruns.

They key here was to adjust the nice level.  I incrementally went down from -11 all the way to 3 (as in plus 3 not -3), restarted pulseaudio, loaded skype and viola!  Problem solved.  The nice level might be different for you so maybe experiment with that a little bit.

Summary:

• edit ~/.pulse/daemon.conf (or /etc/pulse/daemon.conf if you run as system)
• Hash out realtime-scheduling and realtime-priority
• Unhash high-priority and nice-level
• set nice level to 3 (not -3 or -11 for that matter)

Update:  Bah, I am still seeing these under runs.  The severity of them has gone down as skype doesn’t completely cut out now and lock up but I am getting audio cutting in and out every 2-3 seconds when making a call via skypeout.

Searching around the skype forums I found this and this actually seems to have done the trick completely:

Edit your ~/.asoundrc file

# Part I directly from ALSA Dmix Wiki

pcm.skype {
type dmix
ipc_key 1024
slave {
pcm “hw:0,0″
period_time 0
period_size 1024
buffer_size 8192
#format “S32_LE”
#periods 128
rate 44100
}
}

pcm.dsp0 {
type plug
slave.pcm “skype”
}

# This following device can fool some applications into using pulseaudio
pcm.dsp1 {
type plug
slave.pcm “pulse”
}

ctl.mixer0 {
type hw
card 0
}

pcm.pulse { type pulse }
ctl.pulse { type pulse }
pcm.!default {
type pulse
}

ctl.!default {
type pulse
}