Next Session: TBD |
1 19:06 < dtchen_> welp, Friday night seems as good a night as any to have an impromptu session: 1) on triaging Karmic sound bugs; 2) on the way forward in Lucid
2 19:06 < dtchen_> (so, as I don't suspect anyone's really lurking, this will just be a braindump to go on the bugsquad/debugging wiki)
3 19:06 < dtchen_> ** So, firstly, triaging Karmic sound bugs **
4 19:07 < dtchen_> Probably the most important page anyone can reference is https://wiki.ubuntu.com/DebuggingSoundProblems/KarmicCaveats
5 19:07 -!- playya__ [n=playya@unaffiliated/playya] has joined #ubuntu-classroom
6 19:07 -!- IoFran [n=IoFran@189.231.26.50] has joined #ubuntu-classroom
7 19:08 < dtchen_> Just about anyone experiencing sound problems in Karmic should be directed to read that page first, then seek assistance using either the #ubuntu-bugs irc channel here on Freenode or by using https://answers.launchpad.net
8 19:08 < dtchen_> Very briefly, I'll summarise some of the points that I first mentioned in my blog post and which were later nicely written up by David H
9 19:09 < dtchen_> A) By far the most common problem in dist-upgrades from Jaunty to Karmic has been "the case of the missing Karmic kernel in the grub boot menu"
10 19:10 < dtchen_> There are ongoing efforts to diagnose precisely what's causing this symptom. What's complicating matters is that some people appear to have manually modified their grub configuration file (grub.cfg/menu.lst), so there isn't one approach to catch all culprits.
11 19:11 < dtchen_> If, however, as a triager or reporter, you see that the bug report mentions that you're running 9.10 (Karmic) but running a non-2.6.31-based kernel, and you *know* that you dist-upgraded from 9.04 (Jaunty) without having messed with grub or kernels, then go ahead and file the bug, then triage the bug to affect the grub source package.
12 19:13 < dtchen_> B) A lesser severity (but no less annoying) issue lies in how Ubuntu Karmic's PulseAudio handles softmodem and softMIDI applications.
13 19:14 -!- virtuald [n=virtuald@unaffiliated/virtuald] has joined #ubuntu-classroom
14 19:14 < dtchen_> I need to emphasize that usually the bug reporter is not at fault in choosing to install the packages sl-modem-daemon or timidity.
15 19:14 < dtchen_> (Normally System > Administration > Hardware Drivers, better known as Jockey, offers/suggests to install the modem driver if the hardware is discovered.)
16 19:15 -!- joaopinto [n=janito@ubuntu/member/joaopinto] has quit ["Wan't new software for Ubuntu ? Check www.getdeb.net ."]
17 19:16 < dtchen_> What usually happens is that the user has one or more of the sl-modem-daemon or timidity packages installed, and as both of these are not natively-PulseAudio aware (but instead speak directly to ALSA), the user encounters the classic race of "who can grab the sound device first?"
18 19:17 < dtchen_> The culprit is actually PulseAudio's module-udev-detect module, which skips an entire ALSA hw: device once it encounters a softmodem. This is a bug in the pulseaudio source package, but it has not been resolved upstream yet. We're discussing ways to work around this symptom properly, but it touches more than just PA -- alsa-driver/linux is also involved.
19 19:19 < dtchen_> C) Yet another bug people are encountering is the "omg volume too loud/distorted/kills kittens" symptom, which boils down to one of two sources:
20 19:20 < dtchen_> --> alsa-driver/linux is misreporting the sound device's dB range, so PA either happily accepts this absurdity or flails and uses its own calculated range
21 19:20 -!- Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-classroom
22 19:20 < dtchen_> --> your sound hardware is good and truly fscked
23 19:20 -!- Burgundavia [n=corey@ubuntu/member/burgundavia] has quit [Remote closed the connection]
24 19:21 < dtchen_> (That isn't to say that both can't be applicable simultaneously...)
25 19:22 < dtchen_> D) Some people with higher-end (non-HDA; ICE17xx-driven) sound cards are encountering an alsa-lib bug where the "front:" virtual definition incorrectly lacks the proper number of channels.
26 19:22 < dtchen_> As a result, when PA queries alsa-lib, it gets nonsense back and simply skips the sound device.
27 19:23 -!- playya_ [n=playya@unaffiliated/playya] has quit [Read error: 101 (Network is unreachable)]
28 19:23 < dtchen_> So, right above I've summarised the four major (A, B, C, D) bug classes I've been triaging in these weeks since Karmic released.
29 19:24 < dtchen_> A question that ultimately is raised is "How can we automate this triaging? Bug patterns? etc."
30 19:24 < dtchen_> That's a very good question, and a few of us (Brad, Luke, David H, and I) are discussing how to best hook these processes into apport and checkbox.
31 19:25 < dtchen_> ** Next, the way forward in Lucid **
32 19:25 < dtchen_> Since I will not be attending UDS-L, we've already been discussing what to do about the massive volume of user experience snafus when it comes to audio in Ubuntu.
33 19:27 < dtchen_> A) Firstly, on the hardware enablement (alsa-driver/linux) front, we will be rolling either weekly or daily builds of the stable alsa-driver snapshots from upstream ALSA.
34 19:28 < dtchen_> For Karmic, we're having quite good experiences with linux-backports-modules-alsa-karmic-generic [for desktops], because this package (well, linux-backports-modules-alsa-2.6.31-xx-generic) contains a much newer alsa-driver from 20091012.
35 19:29 < dtchen_> (The real grunt work was done by Tim (rtg) and Andy (apw), so buy them beers!)
36 19:30 < dtchen_> Since much of my hardware enablement efforts will be upstream this cycle, having these weekly/daily builds will allow early Lucid testers with *extremely* new HDA hardware to be able to help track and fix regressions.
37 19:32 < dtchen_> B) Secondly, similar to the USB testing images that were used during Karmic's development cycle at Linux conferences, the kernel team will be doing something similar with the above weekly/daily snapshots. In this fashion, we'll have checkbox run on a lot of bare metal, which always helps.
38 19:33 < dtchen_> C) Luke and I have agreed to freeze as much of the sound stack as early as possible, which probably means that we won't be shipping anything newer than ALSA* 1.0.22 (presuming it is released soon enough).
39 19:33 < dtchen_> Now, this point is actually up for discussion at UDS-L, so my words above need to be taken with a grain of salt.
40 19:34 < dtchen_> D) We're still a long way from getting everything properly integrated with PulseAudio. Even applications such as timidity should be configured to use libao instead of ALSA directly, because it's much easier to tell /etc/libao.conf to use pulse as its backend.
41 19:34 < dtchen_> (And that's just one application)
42 19:35 < dtchen_> E) Jack Audio Connection Kit will be in main for Lucid, which should finally lay to rest some w(e)ariness.
43 19:35 < dtchen_> ** End notes **