Low-hanging fruit? We have plenty!

Martin asks whether we've exhausted the low-hanging fruit. From my myopic lens, emphatically no. Despite dwindling available resources for Ubuntu (and FOSS, generally) development, I've continued to contribute a spattering of fixes. Doing so is pretty simple, and I'm happy to walk people through the process.

But don't take my word for it.

Fixing a Linux regression defect

This bug is an excellent example of the continual (aka "seemingly endless") process of verifying that hardware works correctly with Ubuntu (and more broadly, current versions of Linux). Briefly, in mid-May 2007, a patch was committed to upstream ALSA adding support for a particular machine. At the time that the patch was merged, support for certain BIOSes was quite suboptimal. Fast forward to late-November 2010, and a user's "sound no longer works," i.e., playback is inaudible through both speakers and headphones jack when using Ubuntu Maverick. In the realm of kernel code, particularly drivers, certain high-profile subsystems move relatively quickly, and given the vast amount of PC hardware, it's nearly impossible to verify that every released version of Ubuntu (much less upstream Linux) doesn't regress some hardware support. It's a difficult and thankless job, but someone has to do it.

Fix the $@%* bug already (aka "the long-overdue mentoring posts")

I meant to post yesterday, but volunteering and cooking for Thanksgiving were higher priorities. Without further ado...

Recently I dove into the Ask Ubuntu pond, and as always it's wonderful seeing so many open source contributors assisting each other with goodwill. I deal in defect (aka "bug") reports mainly, and some of the Ask Ubuntu posts seem to be disguised as such reports. When I come upon these posts, I try to redirect the posters toward the debugging process so that we can resolve the underlying defects. Certain areas in the Ubuntu software stack are notoriously difficult to troubleshoot, and to that end I'm going to document a recent attempt to resolve the user's defect report so that we have some sort of "institutional knowledge transfer." Please feel free to raise pertinent questions and suggestions in the comments.

Here is a common symptom: "my laptop's speakers don't mute when I insert headphones." We call this class of bug "jack sense" ones, and it's nearly always a sound driver defect, so it belongs in the "alsa-driver (Ubuntu)" component in Launchpad. Because the defect has both hardware (sound controller and codec) and software (alsa-driver) portions, we must obtain sufficient information. For new defect reports, we request that the reporter use either the

ubuntu-bug alsa-base

command or follow a more thorough but tedious debugging procedure. For existing bug reports, we request that the reporter use the

apport-collect bugnumber

command or follow the script in the alternate debugging procedure.

Once we've received the requested debugging information, we need to inspect the sound codec slot's state (aka "codec dump"). Conexant parsers live in sound/pci/hda/patch_conexant.c in the [kernel] source code. Note the Vendor ID, because it refers to the specific function in the parser, so in this case we look at the patch_cxt5066() function. Of particular importance is the node ID associated with the headphone jack. This is referred to in the "codec dump" as having "[Jack] HP" in the description string. In this Conexant variant, we're looking thusly at NID 0x19.

Now, a note regarding the current Conexant parsers: there is no automatic BIOS-based setup, and in this way they diverge pretty spectacularly from the Realtek and IDT/Sigmatel ones; emerging Conexant ones are more like Realtek and IDT/Sigmatel. Because there isn't an "auto" model, all entries have to be hard-coded. In the case of patch_cxt5066(), the default model is CXT5066_LAPTOP ("laptop" model quirk) and uses

spec->init_verbs[0] = cxt5066_init_verbs;

to initialize the codec. cxt5066_init_verbs[] has this snippet corresponding to NID 0x19:

 /* not handling these yet */
 {0x19, AC_VERB_SET_UNSOLICITED_ENABLE, 0},

which means that to properly enable jack sense for the reporter's machine we need to add a function to handle intrinsic unsolicited responses, specifically Presence Detect. Luckily, a patch courtesy of David Henningsson landed earlier this summer adding this very functionality, so we only need to check that the proper NIDs are referenced, and upon confirmation then generate a one-line patch to enable jack sense for the bug reporter's machine.

You may notice astutely that I've worded the above process differently from how it appears chronologically in the bug report. The more one works with a particular kernel subsystem (or any software, really) the more readily one is aware how [often] bugs are resolved. In this case, sound driver development moves rapidly, so it's often in the reporter's interest to be using the latest code. Also, patch tagging and reviewing are important.

UDS-Maverick recap

UDS-M is bittersweet. It is the last summit I attend due to additional work commitments that will remove me from Ubuntu development, but more significantly it is the first summit where the future gardeners, maintainers, and developers of the audio infrastructure in Ubuntu and derivatives gathered and discussed how we can drive user experience improvements. In fact, the phenomenal Amber Graner asked me a few questions to that end, and a few things that I neglected to mention are that:

* Canonical has some real rock stars ramping up enablement and proactive quirking efforts on the ALSA front, so Linux distributions will see significant improvement in vendor support for audio in the 12.04 LTS time frame;

* we might see a streamlined method of switching between PulseAudio and JACK via indicator-sound on the Ubuntu desktop;

* Maverick will see the complete removal of native OSS support from our linux packages with OSS proxy being used instead.

As always, we'll continue to apply stable release updates to supported releases (particularly the most current LTS), to address high profile bug reports against the audio stack, and to maintain helpful presences on the varied mailing lists.

It has been one heck of a five-year ride. Thanks for all the fish.

Public service announcement: Read the original bug reporter's summary before adding unrelated comments

I find that I'm wasting considerable time trawling through bug reports where comments not from the original reporter indicate experiences involving very different software configurations. For instance, person A files a bug against pulseaudio on default Ubuntu, and you see very similar symptoms on default Kubuntu and thus proceed to add some comments to the bug report.

File a separate bug.

The bug reporter's symptoms don't involve Phonon at all, but yours do. You've just splattered over an otherwise useful timeline, which generally makes me want to take a long springtime walk instead of fixing the actual bug. Thanks for understanding.

Public service announcement: When in doubt, don't splatter your apport info into an existing ALSA bug report

Folks -

Please, please don't apport-collect -p alsa-base foo (or apport-collect foo in 10.04 LTS) into a bug report that you didn't file unless a member of the audio dev team explicitly requests it. What we end up with are reports that start from the original reporter as "my laptop's internal mic doesn't work" and end with dozens of unrelated comments from other people along the lines of "my laptop's internal speakers are too loud".

Here's the gist: your symptoms may be eerily similar, but your audio hardware often is quite different, which means that resolving the original reporter's bug symptoms should only affect that reporter's hardware. Of course, if you have identical hardware, then your symptoms will be resolved in your own bug report, too. If you didn't file the original bug report, please just file a new one. Thanks for understanding.

2010 Census awareness

Have you mailed your completed 2010 Census form yet?

Pre-Year of the Tiger

Firstly, lots happening on the Ubuntu 10.04 audio front:

* daily builds of stable alsa-driver snapshots (thanks, Brad!);
* massive alsa-lib and alsa-plugins debugging (thanks, David!);
* continued alsa-driver/linux quirking;
* uploads of latest stable alsa*, libsdl1.2 (including direct seeding of the pulse backend in the Ubuntu desktop seed), openal-soft, and pulseaudio source packages;
* re-addition of HDA power down for Sigmatel/IDT in pm-utils-powersave-policy 0.3.

Some very positive Canonical goings-on have occurred, too, but that's the purvey of others. Also importantly, fellow community members are stepping forward to help triage Ubuntu audio bugs. You gals/guys are too numerous to list individually, but rest assured that your efforts (even if you're new to bug triaging!) are much appreciated. Thanks for helping make Lucid rock!

Secondly, John Poelstra recently wrote a fantastic piece on chairing effective meetings. The points are so entirely lucid (bad pun I know) that I can't believe that I hadn't used them!

In fact, the revitalized DistrictOfColumbia LoCo team meetings have begun using them. Brian has been doing a bang-up job posting summaries in lieu of a configured mootbot to keep us accountable. Members of the LoCo team are working on a screencast/video to demonstrate archive-uploadable activities at jams using Bug Hugger, Lernid, and Ground Control. I'll be doing a portion on fixing alsa-driver/linux bugs.