Fw: Re: Notable Changes to Jaunty's PulseAudio

[Daniel T Chen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 4 Mar 2009, Steve Langasek wrote:

> 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
> still race
> conditions outstanding that pose a risk to the stability of
> the jaunty
> release?

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 
module-alsa-source);
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.

- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJrzkPe9GwFciKvaMRAoIZAJ9ogfgDu3lWQbljAzN+T9OdHexCzwCfcuRz
4ZxnxAa2MeR8RqQaC9cErq4=
=Z0vk
-----END PGP SIGNATURE-----