Lessons learned at Jaunty Beta

Jaunty Beta has been incredible in countably infinite ways:

Good:

• iotop has pinpointed gconf doing silly things after distribution upgrades;
• linux is queued for upload with backported patches to resolve the "OMG PULSEAUDIO SUCKS" bugs;
• VirtualBox has proven to be invaluable for testing;

Bad:

• The audio stack has been in constant flux since Jaunty opened for development. Apologies for not having been able to provide a smoother, better engineered experience, and thanks for sticking with me through the stuttering, clicking, popping, and crashing...
  
• I have been reminded constantly that we, as a community, are failing to support our upstreams and volunteers. During last December's UDS in Mountain View, I took a moment to thank Graham Binns for his thankless work on the Launchpad bug tracker. There have been scattered attempts of "thank a developer" a day. Really, we need to be doing that every chance we have! So - thank you, fellow volunteers and developers. I really couldn't keep plugging away at FOSS without you gals and guys.
• It is fashionable to hate on Ubuntu and Canonical. I am not an apologist for either, but I do choose to spend my time primarily in Ubuntu. Practically, I do not have enough cycles to treat all upstreams equally. That sucks. Apologies to Debian, PulseAudio, and Linux, to name a few.
  

Call for testers

If you're as annoyed as I am with Jaunty's PulseAudio instability, behold, there is light at the end of the tunnel. If you're running 64-bit, please test the kernel at http://kernel.ubuntu.com/~dtchen/ and let me know how the stability of PulseAudio fares. If there is enough interest, I'll work on building 32-bit.

Edit: 32-bit is now available.

Triaging bugs in Ubuntu, or How Not To Tee Off The Most Important Person: Yourself

Colin Watson and numerous others have written about the seemingly sad state of bug triaging in Ubuntu. Many of the criticisms are spot-on. For the protocol (whatever that is) to be effective in actually resolving the issues reported in bugs, we need a technically competent swarm. How might a community-ordered distribution like Ubuntu go about growing such ranks? After all, the topic of resource constraints is by no means unique to Ubuntu tasks. I remember discussing it in the inaugural MOTU Council, and mentoring was incorporated as part of the new developer protocol.

Mentoring seems to be an underused feature in Launchpad for Ubuntu bugs. I propose that prospective members of the Bug Control team participate as mentees. (I do not wish to quantify a metric for determining whether such mentees would then be "fit" to join the team.)

Consider this post a call to fellow developers to offer mentorship: go ahead and choose the "Offer Mentorship" link at the trailing vertical edge of any bug report in Launchpad. For what it's worth, consider me a mentor for any audio-related bug. (And yes, that next post about Linux is forthcoming.)

Fainting and the Linux audio stack, or Know Your Enemy

I've been working off and on to draft a Linux audio overview in the vein of Bryce's excellent X Window System architecture docs. Lennart, the brains behind Avahi and PulseAudio, already has a quite-good writeup on the different APIs with well thought-out reasons for choosing whichever one(s) for a task. Given that I've been knee-deep in triaging audio bugs, it has been amusing to watch various (developer) parties argue the merits of their wheels.

Nonetheless, in Linux, it's still a jungle [PNG].

Any user, power or novice, generally approaches bugs in an identical fashion: stuff needs to work now. Without further ado, here is part one of rationale behind guidelines for troubleshooting audio anomalies in Ubuntu (some of which is documented).

My sound is broken. Well, not quite. Generally when one's sound is inaudible, it can be caused by numerous culprits. Prior to Intrepid, one's user had to be in the "audio" group to use sound devices. PulseAudio's use of PolicyKit obviates that requirement, so one's user no longer has to be in that group. However, users experimenting with multiple desktop environments like Xfce, KDE, and GNOME - some of which don't use PulseAudio with a PolicyKit backend - need to be in that group. What am I driving at?

• The user has to know too much about traditional discretionary access control.

Thanks to PulseAudio's integration with PolicyKit - and here, classic abstraction at work - we no longer have to concern ourselves with questions regarding incorrect ownership and/or permissions on /dev/dsp*, /dev/snd/*, etc. Yet that is a common culprit for inaudible applications that we catch repeatedly using a community-maintained troubleshooting script.

Next time, we look at how Linux speaks to our audio hardware.

PulseAudio

If it seems fashionable to post about PulseAudio experiences, I'll refrain from spouting my own mishaps and instead focus on fixing and maintaining the audio stack in Ubuntu (a rather thankless job in any Linux distribution).

Firstly, people claim that PulseAudio brings a lot of fail to the Linux desktop environment. As with many maturing architectures, there are massive growing pains. David F is not the first to note that Jaunty's packages have thrown many desktop users for a loop. It should come as no surprise that there is more breakage on the horizon, and in fact, I documented it twice to, well, near silence on the ubuntu-devel-discuss mailing list. Much more importantly, however, PulseAudio has been instrumental in exposing numerous alsa-kernel (which in Ubuntu affects the linux source package, not the alsa-driver source package) and alsa-lib bugs. We all owe Takashi, Jaroslav, Lennart, and myriad others a round of $beverage for making things bearable^Waudible.

I'll take this opportunity to state again [OpenOffice.org Impress file] (as during my 2008 Ohio LinuxFest presentation) that Linux audio can be hairy, and if it has worked for us directly via ALSA, OSS (including v4.x), etc., we should be pleased but mindful that there is always room for improvement.

Secondly, Jaunty is in development. While it is reasonable to expect that filesystem-munching bugs don't hit us daily, it is also reasonable to expect that running a development branch brings experimental configurations that could munch our filesystems. The PulseAudio configuration currently in Jaunty was delivered precisely to trigger alsa-kernel and alsa-lib bugs so that they can be fixed. Surely we don't want another instance of Hardy's PulseAudio configuration to bite us!

Finally, it is much more productive to Ubuntu developers and maintainers for the Jaunty testing community to file bugs. In the case of Jaunty's PulseAudio, there already exists one "master" bug tracking the most common complaints of:

• my sound is inaudible on GNOME session login
• my sound disappears randomly while using GNOME
• music and/or video applications seem to hang or crash while using GNOME

Rest assured that we are working diligently to resolve the bug (which affects linux, alsa-lib, and pulseaudio).