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.
--
Bad multitasking / responsiveness in Hardy
https://bugs.launchpad.net/bugs/190754
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
