Comment 124 for bug 345627

Revision history for this message
Conn O Griofa (psyke83) wrote :

Luke & Daniel,

I've been experimenting with PulseAudio in Karmic and Fedora 11, and I'm making some observations/suggestions relevant to this bug report, and PulseAudio as a whole.

My basic codec identifier, for reference:
conn@inspiron:~/.pulse$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In Fedora 11 (which uses kernel 2.6.29 and PulseAudio 0.9.15 with glitch-free playback enabled and no resampler/fragment customizations, unlike Ubuntu), audio works perfectly without any stutters, and bug #374002 is not triggered on my system.

With Karmic using the default PulseAudio settings, I'm experiencing what I would call micro-stutters, where the sound appears to skip an extremely short duration (milliseconds) every 20 seconds or so - this never occurred on Intrepid or Hardy with PulseAudio, is 100% reproducible in Totem and other applications, and is definitely not due CPU starvation. Bug #374002 [1] is not triggered, but only because glitch-free playback is disabled.

On Karmic with kernel 2.6.30-10-generic, I modified PulseAudio's configuration to use a vanilla PulseAudio configuration that's equal to Fedora (tsched=1, and no customizations to the resampler or default-fragment* values). This eliminated the microstutters entirely, but it triggers bug #374002 on my laptop after some minutes of audio playback. Even Skype appears to work correctly for a short time, but the aforementioned bug always kicks in within a few minutes, which requires PulseAudio to be restarted manually.

Tonight I upgraded to kernel 2.6.31-1-generic and with the same vanilla configuration, microstutters are eliminated entirely *and* bug #374002 is no longer triggered on my system. Even the most troublesome application, Skype, works absolutely flawlessly with PulseAudio (when configured to use the "pulse" device). There are no stutters at all, and Skype maintains a single client connection to the PulseAudio server (I'm sure you've noticed the problem where Skype connects and disconnects to the server dozens or sometimes hundreds of times in the space of a few minutes, causing stuttering - this no longer occurs).

First, a question: why did kernel 2.6.30-10-generic trigger bug #374002, when it was supposed to be fixed since kernel 2.6.29 according to Fedora's bug report related to my particular codec [2]? As I said earlier, this bug did not occur when I tested Fedora 11 on my laptop.

Second, a proposal: let's enable glitch-free playback and revert the modifications to the default-resampler, default-fragments and default-fragment-size-msec parameters.

I understand that this will trigger the snd_pcm_delay/snd_pcm_avail errors in buggy drivers (even though my particular codec appears fixed), but we need to face facts:
a) interrupt-based playback in PulseAudio really is "glitchy", and audio quality is suffering for everyone on Karmic as a result;
b) the resampler/fragment modifications we use in Ubuntu are poor workarounds [3] for the erratic buffering behaviour in certain applications (Skype) and CPU usage caused by interrupt-based playback in PulseAudio;
c) There is no guarantee that we can resolve the current stuttering/buffering issues with interrupt-based playback, as it seems pretty obvious that the majority of development is focused on glitch-free playback in PulseAudio;
d) We are depriving ourselves of the opportunity to co-operate with the PulseAudio, Fedora, ALSA and upstream kernel developers in squashing the remaining bugs in PulseAudio and the ALSA kernel drivers that glitch-free playback exposes.

I am aware that some sound cards may never work correctly with glitch-free (due to poor hardware documentation), but perhaps we can consider a method to blacklist cards later on - let's cross that bridge when we come to it.

Luke, it seems like an excellent idea to implement these changes in your PPA (if you feel it's it's too risky to test in the official repository), what do you think? We have ample opportunity to begin wider testing of glitch-free playback, and our testing in Ubuntu can potentially improve the ALSA kernel drivers in the final 2.6.31 kernel. I'd like to help in any way possible.

Regards,
Conn

[1] https://bugs.launchpad.net/bugs/374002
[2] https://bugzilla.redhat.com/show_bug.cgi?id=472339
[3] https://launchpad.net/bugs/190754