Musings on maintaining Ubuntu

Cabals and membership boards

2011-08-04T09:38:00.005-04:00

It both heartens and saddens me that Chase's proposal to amend the Developer Membership Board's approval process has met with seeming vehemence and accusations. The participants in the discussion have all contributed invaluable resources to Free Software, and it is wonderful that this dialog is taking place, because any vibrant community will continually evaluate its relevance and efficacy. Unfortunately, some of the responses have become accusatory and detract from the thrust of the conversation. Please, let's continuously - and gratefully - give and accept constructive criticism.

Patch Pilot report: 2011-08-03 (approximate)

2011-08-03T16:57:00.014-04:00

Reviewed and uploaded to Oneiric:
acpi 1.5-3ubuntu1
smbldap-tools 0.9.5-1ubuntu1
multimon 1.0-5ubuntu1
monobristol 0.60.3-1ubuntu1
djbdns 1:1.05-8ubuntu1

Triaged and marked not relevant for Oneiric:
muttprint
ladcca
pdumpfs
mpc
dvi2dvi

Patch Pilot report: 2011-07-30 (approximate)

2011-07-30T13:32:00.010-04:00

Reviewed and uploaded to Oneiric:
wmii 3.9.2+debian-3ubuntu1
psycopg2 2.2.1-1ubuntu3
libmatthew-java 0.7.3-1ubuntu1
daemontools 0.76-3ubuntu3
scanbuttond 0.2.3.cvs20090713-5ubuntu1
mtr 0.80-1ubuntu1
fail2ban 0.8.4+svn20110323-1ubuntu1
java2html 0.9.2-4ubuntu1
gogoc 1.2-4ubuntu1
coherence 0.6.6.2-5ubuntu1
uw-imap 2007e~dfsg-3.1ubuntu3
tcc 0.9.25-9ubuntu1
nethogs 0.7.0-3ubuntu1
multicd 1.7.3-1ubuntu1
eyed3 0.6.17-1ubuntu1

Triaged and marked not relevant for Oneiric:
libwibble
gdal
lua-xmlrpc
prototypejs
mt-daapd
kdiff3

Patch Pilot report: 2011-07-26 (approximate)

2011-07-27T00:10:00.004-04:00

Reviewed and uploaded to Oneiric:
base-files 6.4ubuntu3
bibus 1.5.1-3ubuntu1
cricket 1.0.5-13ubuntu1
icecc 0.9.6-1ubuntu1
lashwrap 1.0.2-0ubuntu7
lomoco 1.0beta1+1.0-5ubuntu4
rp-pppoe 3.8-3ubuntu1
tig 0.17-1ubuntu1

Reviewed and marked not relevant for Oneiric:
tclxml
soci

Patch Pilot report: 2011-07-20

2011-07-20T14:42:00.008-04:00

Reviewed and uploaded to Oneiric:
tictactoe 0.8.1-5ubuntu1
pct-scanner-scripts 0.0.4-3ubuntu1
gpredict 1.3-1ubuntu1
coolkey 1.1.0-8.1ubuntu1
sbackup 0.11.4-0ubuntu4
bcfg2 1.1.1-3ubuntu3

Reviewed, updated SRU information and uploaded to -proposed:
w-scan 20091230-1ubuntu0.1, 20100316-3ubuntu0.1 and 20101001-1ubuntu0.1
wackamole 2.1.1-3.1ubuntu0.10.04.0, 2.1.1-3.1ubuntu0.10.10.0 and 2.1.1-3.1ubuntu0.11.04.0
lash 0.6.0~rc2-5ubuntu0.1

Reviewed and closed as not-applicable in Oneiric:
fusion-icon
tigr-glimmer

Patch Pilot report: 2011-07-19 (approximate)

2011-07-19T08:03:00.005-04:00

Reviewed and uploaded to Oneiric:
pm-utils 1.4.1-8ubuntu1
base-files 6.4ubuntu2
acoustid-fingerprinter 0.3~20110715-0ubuntu1
distcc 3.1-4ubuntu2
tesseract 2.04-2.1ubuntu1
vim-addon-manager 0.4.3ubuntu1
fusecompress 2.6.git913897f4-1ubuntu1
sweep 0.9.3-4ubuntu1

Please support the Ada Initiative

2011-06-06T14:00:00.005-04:00

Donate to the Ada Initiative’s Seed 100 campaign to support women in open tech and culture!

Low-hanging fruit? We have plenty!

2010-12-02T14:51:00.005-05:00

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

2010-11-27T14:14:00.003-05:00

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")

2010-11-26T13:39:00.006-05:00

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

2010-05-15T04:35:00.009-04:00

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

2010-04-06T14:18:00.008-04:00

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

2010-04-02T03:32:00.010-04:00

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

2010-03-21T00:04:00.002-04:00

Have you mailed your completed 2010 Census form yet?

Pre-Year of the Tiger

2010-02-07T17:50:00.015-05:00

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.

Heads up: powerdown changes to alsa-base in Lucid/10.04

2009-12-31T01:05:00.005-05:00

If you don't normally follow the Ubuntu development lists, it's a good time to begin. Yesterday I uploaded alsa-driver 1.0.22.1 to Lucid which, among other things, contains my extensions to power down various parts of the HDA controller and codec after a configurable idle period. Work is far from complete, and I could use your help to make sure your sound hardware is well-supported in 10.10.

In summary:
"Just to clarify in case it's not already obvious: my having uploaded alsa-driver 1.0.22.1 in no way affects the default Lucid install of the kernelspace ALSA driver (aka alsa-kernel). It remains 1.0.21. Anyone wishing to build modules of 1.0.22.1 can do so using module-assistant and alsa-source. And, until Takashi returns, that approach will be more current than using the daily snap from the 27 Dec.

So, the current state of Lucid contains:
alsa-kernel 1.0.21 (as shipped in linux 2.6.32-9.13-generic)
alsa-lib 1.0.22 + Fix-S24_3LE-softvol-distortion.patch (bdf80)
alsa-plugins 1.0.22"

Lucid development: audio for Alpha 1

2009-12-07T23:22:00.002-05:00

Things that won't land for Lucid Alpha 1:

Steady progress on Analog Devices HDA suspend/resume additions/fixes in pursuit of powerdown objectives;

Fix for PulseAudio bailing on HDA softmodems.

On the other hand, they will land sometime soonish. In fact, the latter fix is available for testing in Karmic from the ubuntu-audio-dev PPA.

(As always, thanks for understanding that I have a limited amount of free time to do this stuff.)

How not to configure default settings for sound applications

2009-11-19T06:33:00.004-05:00

You're absolutely right, Martin: recordmydesktop did the wrong thing and screwed your sound experience in Ubuntu. Fortunately, it's really straightforward to fix:

--- recordmydesktop-0.3.8.1.orig/src/rmd_types.h
+++ recordmydesktop-0.3.8.1/src/rmd_types.h
@@ -39,7 +39,7 @@
#ifdef HAVE_LIBASOUND
#include

- #define DEFAULT_AUDIO_DEVICE "hw:0,0"
+ #define DEFAULT_AUDIO_DEVICE "default"
#else
#include
#include

Flailing against the light, or why bad things happen to good users

2009-11-18T11:55:00.008-05:00

Seriously, Craig, I'm a bit disappointed that you didn't stop to ask members of this perceived conspiracy how to disable PulseAudio before flaming away, but as you say, it is most definitely your "right" to flame away. And, as Jordan mentioned in your blog post's comments, it was (and is) hardly MOTU's decision to tie PulseAudio more tightly into the GNOME desktop. That decision was upstream GNOME's. Not Ubuntu's. Not Fedora's. Not openSUSE's. Not Gentoo's. Not Debian's. Not Mandriva's.

In other words, it would take a non-trivial amount of work to remove the PulseAudio dependency from GNOME, and then Ubuntu would get to carry the delta *and* respond to defect reports.

Let's put this in perspective: there are two people working on audio in Ubuntu. One of them is employed by Canonical, and he isn't 100% time on audio. The other one cares enough to trawl through vitriol and drivel to respond to requests, demands, rants, and apathy -- on his lunch breaks and spare time -- to unbreak a resounding mess. If it's insufficiently clear, you're preaching to the choir, and your ultimatum is pathetically misdirected.

Now let's be constructive:

Firstly, PulseAudio *can* be made to go away in Karmic. I've written about it before, but I guess the naysayers are too busy flailing about how much PA sucks. Some caveats with the approach given: you'll need to use one of alsamixer, amixer (both command line tools shipped by default in the alsa-utils package), alsamixer-gui, aumix, and so on. You'll lose live per-application (per-stream) migration. You'll lose per-application volumes. And you'll lose other things, but they're hardly consequential enough to list here.

Secondly, the loss of system sounds is not a PulseAudio issue. It's a window manager issue. There's even a defect report about it.

Thirdly, PulseAudio *has* to use ALSA. PulseAudio is not a replacement for ALSA and never will be, because one of ALSA's primary functions is enable hardware. It's a sound driver. PulseAudio is not a sound driver; it's a program that uses sound drivers. If you're expecting PulseAudio to replace ALSA, go ahead and throw that idea out the window.

Fourthly, where are your defect reports for PulseAudio and ALSA in Karmic?

Lastly, no one is forcing you to upgrade to the latest Ubuntu hotness. Some people still use Dapper; others, Hardy. A great many people don't use Ubuntu at all. If you don't enjoy Ubuntu's direction, why not attend the Lucid developer summit and work with people there to resolve some issues?

Caveats for audio in 9.10

2009-10-29T19:37:00.010-04:00

Here follows an update for 9.10 to this month's earlier caveats:

If you use Ubuntu:

Use Karmic's kernel, not Jaunty's. A lot of you with Realtek and IDT/Sigmatel HDA codecs are being bitten by /boot/grub/grub.cfg not being updated properly, resulting in Jaunty's 2.6.28 kernel being used instead of Karmic's 2.6.31. Jaunty's kernel has pretty subpar performance for PulseAudio, and you should not incorrectly blame PulseAudio.
Check that slmodemd is not running if you're seeing a dummy/null sink in the volume control applet. Arguably PulseAudio's module-udev-detect should allow the device instead of bailing when detecting it, and an approach is under discussion for future versions. In the meantime, you can either instead load module-detect in /etc/pulse/default.pa (or ~/.pulse/default.pa) or kill slmodemd.
Install linux-backports-modules-alsa-karmic (then reboot) if you have a very new computer, because that package enables audio on quite a few very new laptop models and contains much improved support for microphone auto-switching.
Use a temporary alternate channel mapping for PulseAudio if you have an ice17xx-based sound card. Please be aware that the fault lies with alsa-lib not PulseAudio and will be addressed in 10.04 LTS.
Configure PulseAudio to ignore your sound driver's misreported dB information if you experience "overdriven" sound.
Attach a verbose PulseAudio runtime log to your PulseAudio bug report.
Attach an ALSA codec dump to your linux bug report if jack sense (e.g., connecting headphones mutes internal laptop speakers) does not seem to function properly.

As always, thank you for helping improve Ubuntu!

The perils of saving sound card state; and why apologizing is good.

2009-10-13T23:50:00.008-04:00

Bad news: I broke alsa-utils in Karmic.

Good news: I fixed it tonight. Please report your results.

Honestly, I tested the previous upload on Ubuntu, Kubuntu, and Xubuntu before committing to bzr -- even on different hardware! It just goes to show that I make dumb mistakes, so, sorry about that.

Mo' bett' news: many thanks to the awesome Tim Gardner, who imported alsa-driver stable (snapshot from 20091012) into ubuntu-karmic-lbm.git, which means that all you poor saps with eeePCs and HP dvs and Dell Studios will finally have less suck for audio. Granted, it will require installing linux-backports-modules-karmic in a week or so...

In other news (what?! there're more kinds?!), it really is decent to apologize when I make mistakes. This guy is a real gem, that is all.

Caveats for audio in Ubuntu Karmic Beta

2009-10-01T20:42:00.008-04:00

In the wake of the Ubuntu Karmic Beta release, here are some audio gotchas on my radar:

* Volumes being erroneously set to 0 and/or muted upon reboot/shutdown
** We'll address this in Lucid by altering how alsactl store is called. For Ubuntu, there's arguably no need to actually call alsactl restore; PulseAudio handles volume state on its own. Granted, the approach will take some fleshing out, as we need to handle Kubuntu, Xubuntu, Ubuntu Studio, ...

* Default PulseAudio behaviour causes overdriven audio due to hardware inanity
** Thanks to some wonderful (sarcasm) hardware integration, we can work around this issue by using the patch mentioned in the comment. Please note that this patch will not be turned on for Karmic, because doing so will result in a very poor user experience for many more HDA users whose hardware are not quite so craptastic.

* Internal/External microphone selection is broken for many HDA users
** Well-known upstream, being addressed for Lucid, patches too invasive for Karmic, etc.

* Extremely high CPU usage by PulseAudio with third-party applications (Skype, I'm looking at you)
** Use the PulseAudio-aware beta of Skype

Finally, last post I described populating the alsactl init database. There are a few things of which one should be aware:

* Too quiet or too loud is usually a driver (i.e., linux) bug
** We can work around this in alsa-kernel/linux, so the first place we check is linux, not alsa-utils. In the rare case it is not a driver bug, we resort to alsactl init patches.

* You can clone the upstream alsa-utils git tree and submit patches directly
** (Next post, I'll cover how to do it.)

Atlanta Linux Fest 2009 and Crowdsourcing

2009-09-21T09:52:00.012-04:00

A couple months ago, upon reading the tentative speaker schedule for Atlanta Linux Fest 2009, I was surprised at the Canonical omnipresence. There was personal trepidation regarding how such a presence may be interpreted, and sure enough, I wasn't alone. Certainly in my talk, I kept the vast majority of the physical speech focused on current FOSS and mentioned Ubuntu only in the confines of what we've done poorly and how we're resolving those shortcomings.

For instance, one of the most difficult things to "get right" in a default (clean) install is configuring various audio settings. A great analogous post by Ed Felten really made me reconsider the command line as the preferable interface for troubleshooting.

Many parts of Ubuntu are contributed by volunteers (thank you!) like myself. There seems to be a considerable amount of bad blood in the Linux community regarding what Canonical "doesn't do". We all need to do a better job of thanking our fellow volunteers and remembering that corporate overlords do not drive everything.

That said, I enjoyed the brief moments spent at this year's ALF (had to leave early to return to work), particularly the thoughtfulness of all the organizers (please thank them!) and attendees.

See you this weekend at Ohio LinuxFest!

Limited liability, or how not to develop Karmic using Karmic

2009-09-17T07:37:00.005-04:00

Karmic has been wonderfully jumpy these past few days. I must have some sick fascination with broken systems, as my presentation at this year's Ohio LinuxFest will focus on developing Karmic while running Karmic. Not just that, but this Saturday I'll briefly discuss Linux audio at Atlanta Linux Fest.

Now for the real meat in this post. For Karmic+1, I want Ubuntu to lead the charge in populating alsa-utils's init db.

Currently we do some pretty braindead things in alsa-utils's initscript, namely forcibly iterate over an entire set of static mixer element strings and values and attempt to set all detected audio devices to a specific state. Well, it's rather unlikely that my Logitech USB headset will have a Creative Audigy-specific "Audigy Analog/Digital Output Jack", yes?

Of course, that's just one badness, but the driving factor is to be able to conditionally set volumes on system start (for non-PulseAudio configurations) based on the machine's SSID. This approach largely resolves the "Gee, I have an Audigy X that requires the jack toggle to be muted to get audible analog output but person Y with an Audigy Z requires it to be unmuted" debacle.

So where do you come in? With current HDA codecs, using a static setting of 80% for PCM is pretty fragile. Some hardware sounds really overdriven at that setting, and others are barely audible. We need your SSID (lspci -nv|grep -A1 040[13]) and your preferred volumes! More in the following weeks.

"Meanwhile, in real life"...

2009-07-27T22:21:00.013-04:00

Firstly, I have been neglecting my Ubuntu Karmic objectives due to a sudden fit of productivity in $dayjob. I expect this lapse to be completed after the Black Hat USA briefings. (That said, if you're headed to that Sin City and have Ubuntu sound problems, find me, and we can eliminate the debugging roundtrips.)

Secondly, I am working through the powerdown issues for the remaining HDA (controllers and) codecs besides Sigmatel/IDT. The Analog Devices and Realtek ones are pains in my rear.

Lastly, some words on respect. I tend toward forcefulness - sometimes misled but mostly well-intentioned - and note that, rather than blow much hot air about the (emotional) fitness of Mono or the blatant sexism in many environments (not just FOSS), to frame the issues as obstinate juvenile mutterings reduces them to the bottom line: I (we) disrespect other people. I (we) should stop being an idiot(s). But rather than argue who needs to stop what, I am going to eradicate the tomfoolery and shenanigans that I have internalised. It's really simple: people notice when I (we) take time to help them with Ubuntu. People notice when I (we) take time to note that I (we) don't agree with sexism in presentations. For me, Ubuntu is about leading through maturity.

Action items from UDS Barcelona

2009-06-01T01:24:00.007-04:00

As usual, the Ubuntu Developers Summit was a whirlwind, and I returned to the States enthusiastic about making Karmic a better user experience.

On the audio front, a slew of bugs have been resolved in Karmic simply by upgrading the entire stack. I led a plenary session during UDS focused on the travails of audio in Linux [OpenOffice.org presentation] with emphasis on how they affect Ubuntu and its remixes. Soon Luke and I will be offering snapshot builds in a dedicated audio PPA of alsa-driver-stable (daily), alsa-driver-unstable (daily), and pulseaudio (weekly). These pristine builds will contain only minimal packaging bits to facilitate debugging with respective upstreams. The availability of test builds of PulseAudio will make it easier to ship the most recent stable version in Karmic.

Roderick Greening and I will be testing GStreamer with PulseAudio on Kubuntu as part of the effort to streamline the audio stack. There will be a separate PPA for these packages.

Glitch-free PulseAudio likely will not be enabled in Karmic. There is insufficient traction in changing kernel configuration options, and we will all need to evaluate how those configurations affect other objectives (e.g., improved battery life).

As part of an improved battery life objective, powering down HDA controller amps when no sound is being played has already been enabled. The mailing list post covers possible regressions and how to track development with your experiences.

On the community front, something that has plagued the distribution process-wise is the heavyweight handling of patches from contributors. Patches, even URLs to them, often languish in Launchpad despite being tagged as containing patches. Both drive-by contributions and fully Debianised/Ubuntuised debdiffs suffer this same fate. I've taken on the task of making sure the process for people not immersed in the Ubuntu development model is more akin to a front office or reception similar to MOTU mentorship. Instead of expecting new contributors to follow the distribution's development model, a new Launchpad group, ubuntu-reviewers, with an associated mailing list, will be responsible for taking posted references to git changesets, patch URLs, etc., converting them into usable debdiffs for the appropriate Ubuntu release(s), and subscribing the appropriate component sponsor group. For example, if you find a bugfix for a package, you could send an e-mail to the mailing list for said review group. You could also file a bug using ubuntu-bug/Launchpad, clearly state the URL to the patch, and subscribe the review group.

While the administrative work is in progress (e.g., name of the Launchpad group), the goal is straightforward: involve as many contributors as possible without bogging them down in, well, administrivia.

More Karmic plans

2009-04-30T19:13:00.003-04:00

The Jaunty development cycle was a hectic, pulsating (no pun intended) ride, and Karmic's looks to be just as vigourous! Here are my objectives for 9.10:

Audio:

Enable power-saving by default for HDA controllers - after fifteen seconds, power down the HDA controller to squeeze some juice for those transpacific flights. I'll be calling for testers shortly, but I'm most interested in resolving anomalies after the controller powers back up. You can already test this today if you're using karmic's kernel or a git snapshot of alsa-driver:
echo options snd-hda-intel power_save=15|sudo tee -a /etc/modprobe.d/test_power_save.conf

Offer snapshots of ALSA drivers - transition alsa-driver stable and unstable snapshots to use DKMS, and build daily debs in an audio-specific PPA (to be established)

Offer snapshots of PulseAudio - transition to weekly snapshots of git HEAD of upstream master, and build debs in above PPA

Streamline troubleshooting - offer GUI method for resetting stream volume and sink

General packaging:

Resume mentoring - already held two classroom tutorials. We need to use #ubuntu-classroom more effectively

Set periodic runs of piuparts/autopkgtest - determine which subset(s) of main and universe and make sense; enhance any existing build harnesses. See also where LDTP fits

Outreach:

Engage middle-schoolers, high-schoolers, itinerant workers in FOSS

Jaunty release party; more Karmic brainstorming

2009-04-18T21:50:00.003-04:00

We're having a Jaunty release party in Washington, DC.

I'd also like thoughts on how to make resolving bugs like this one more transparent, err, easier, to the casual user. (Sure, I could have picked any one from thousands on Launchpad.) Matt Z has already contributed apport hooks to facilitate the process, but we have a long way to go still. (Please don't castigate or indulge in overzealousness in the comments.)

Further down the rabbit hole

2009-04-01T11:32:00.003-04:00

Craig, emotional bug reporting inevitably does a disservice to bug reporters and the people working to fix bugs alike. Reporters tend to omit necessary information; triagers and developers tend to ignore vitriolic (and often misled and/or uninformed) rants. Neither helps advance the state of FOSS. While I empathize with your (and nearly everyone else's) frustration with audio in Jaunty, there's no easy solution to the mess [PDF]. Many people blame Hardy's poor PulseAudio integration, and they are well placed to decry the missing changes to /etc/pulse/default.pa to allow most non-Free applications to play nicely. You specifically call out "functional" testing in the QA process, but are you actively involved in said QA process?

There are a shedload of shortcomings in Ubuntu related to audio. E.g., ubuntu-bug/apport could be taught to use alsa-info.sh (which isn't in Ubuntu Jaunty's alsa-driver source for various reasons but will be in Karmic's) behind the scenes; a standing FeatureFreeze exception similar to the GNOME desktop's could be requested and granted for ALSA-Lib and PulseAudio; linux's generic configuration could be "better" tweaked for desktop interactivity - and those are by no means comprehensive. However, each comes with an opportunity cost. Every single one of us needs to do a better job of working upstream, because throwing a tantrum in front of volunteers accomplishes little.

Lessons learned at Jaunty Beta

2009-03-26T23:57:00.006-04:00

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

2009-03-19T23:18:00.006-04:00

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

2009-03-04T00:11:00.003-05:00

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

2009-02-27T00:36:00.005-05:00

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

2009-02-25T18:02:00.006-05:00

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).