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!
Monday, September 21, 2009
Thursday, September 17, 2009
Limited liability, or how not to develop Karmic using Karmic
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.
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.
Monday, July 27, 2009
"Meanwhile, in real life"...
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.
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.
Monday, June 1, 2009
Action items from UDS Barcelona
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.
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.
Thursday, April 30, 2009
More Karmic plans
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:
General packaging:
Outreach:
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
Saturday, April 18, 2009
Jaunty release party; more Karmic brainstorming
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.)
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.)
Wednesday, April 1, 2009
Further down the rabbit hole
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.
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.
Subscribe to:
Posts (Atom)