Comment 7 for bug 190754

I am confirming the occurence of this problem with current hardy on a IBM ThinkPad T30, 2366-97x. It only shows when using PulseAudio as output as opposed to ALSA. I am deviating from the default PulseAudio configuration only in this way:

--- /tmp/default.pa 2008-02-25 21:41:01.000000000 +0100
+++ /etc/pulse/default.pa 2008-02-25 17:34:25.000000000 +0100
@@ -37,0 +38,4 @@
+#### Kim~* {
+load-module module-alsa-sink device=default
+load-module module-alsa-source device=default
+#### }
@@ -41 +45,2 @@
-load-module module-hal-detect
+#### Kim~*
+#load-module module-hal-detect
@@ -45 +50,2 @@
-load-module module-detect
+#### Kim~*
+#load-module module-detect

This is just to make Skype work with the "raw" ALSA device instead of PulseAudio's emulation; Skype would not work otherwise.

I believe that overly optimistic buffering on PulseAudio's side is to blame here. The buffer is extremely small (on the order of a few dozen milliseconds or so) and thus underruns whenever failed to be fed continuously. Alt-Tab hogs resources for a long enough time to make this happen even without any IOWAIT or significant load. Seeing that my machine neither supports APIC properly nor has a second core, it is plausible that interrupts can unfairly steal CPU time even with a current kernel and its Completely Fair Scheduler. (With just the XT-PIC, any PCI interrupt will cause the system to ask every device on the PCI bus whether it caused the interrupt; also, with just one core, interrupts cannot be handled elsewhere, which might enable PulseAudio to run smoothly.)

Another source of disruption besides Alt-Tab is apt-get update. It will stutter about once for every package list file processed. Who knows, even fork() and/or the associated switches between kernelspace and userspace might be the culprit.

I have not had a look at the PulseAudio source since I would not know where to start.

PulseAudio seems to adapt its behaviour once a sufficient number of Alt-Tabs has been performed. Stuttering does not occur then anymore. It seems that more data is then buffered than under normal conditions. This looks akin to something like TCP slow-start in reverse ;)

Also, having sufficiently advanced hardware (my machine is in its sixth year) would obviously hide all of this.

The correct fix, IMHO, would be to make tweaks to the thresholds, constants, coefficients involved in the buffer size calculation, making it more conservative than it is now. However, I do not know how many buffers exist and where they are. There could be a per-sink buffer, a buffer for the netlink, a buffer in the core. Again, I would not know where to look.

It might also help to use a kernel patched for LatencyTOP and LatencyTOP itself to see whether any kind of priority inversion occurs.

Sorry for being unable to provide patches.

Murat: Simply being under load does not significantly impact responsiveness for me. Load averages of about 10 while playing back MPEG-4 Part 2 ASP video (such as Xvid encoded files) are free of problems - no frames dropped at all.