What has been the outcome of this testing?* The
upgrade was fairly painless
for me, but I know that may not be indicative; are there
conditions outstanding that pose a risk to the stability of
Given the kernel team's decision to not enable the PREEMPT kernel config
option for -generic in jaunty, the change in pulseaudio 0.9.14-0ubuntu10
will be reverted, which will restore the configuration to that shipped in
Alpha 5 (glitch-free disabled). This change is being tested by community
members using the package in my PPA.
Two significant issues have plagued PA even with glitch-free disabled:
1) bogus data from alsa-kernel via alsa-lib caused crashes, mostly notably
in PulseAudio's module-alsa-sink (but also triggerable in
2) certain ALSA mixer elements needed to be set to non-zero and unmuted,
mostly notably 'Front' and 'PCM'.
(1) is actually caused by two components - snd_pcm_update_avail() in
PulseAudio was improperly handling a signed underflow from alsa-lib, but
upstream discussion has led to the drivers being identified as unstable.
I've corrected this bug using a portion of logic from upstream, so PA no
longer crashes in snd_pcm_update_avail() due to the underflow. There was
also an adjustment to the delay handling, so the CPU no longer spins in
the case that the driver returns such a large positive value.
The remaining component that needs to be resolved is the case where the
driver improperly sets POLL* status but doesn't actually return any usable
data. In this context, the CPU will also spin, and due to the default PA
configuration where no-cpu-limit defaults to yes in /etc/pulse/daemon.conf
(being commented), the daemon will abort. I'm addressing this bug (330814)
this week (as time off from $dayjob permits) and hope to have it squashed
for Alpha 6.
(2) requires digging deeper into the alsa-utils.c code in PA - it is not
immediately obvious under what conditions such an adjustment to available
ALSA mixer elements should be made. I have a sinking feeling that I'll
have to hard-code logic to detect whether a volume-/stream-/sink-restore
has occurred, but this approach, too, warrants investigation. I'm
addressing this bug (315971) for Beta.