20070315
Bug triaging best practices (crimsun)
- kernel
- symptoms such as "sound not working", "sound muted", and anything else falling under "not being able to hear sound under Ubuntu but being able to under $another_os" should be triaged against linux-source-2.6.x, where x is the kernel version for that Ubuntu release
- i.e., use linux-source-2.6.x instead of alsa-driver, generally, because we don't actively patch the alsa-source binary package (against which alsa-driver, which is in universe, is responsible), whereas we do take care of the kernel
- if alsa-source provides the driver, do not assign to linux-source-*.
in previous Ubuntu releases, this was constrained to drivers like the EchoAudio ones
- if modinfo on the driver returns nothing, then instead of using linux-source-2.6.x as the triaged package, we can use alsa-driver
- u-audio subscribes to alsa-driver but not the former, because bugs against linux-source-2.6.x aren't necessarily audio bugs
- perfectly acceptable to manually subscribe ubuntu-audio.
- also acceptable to assign bugs to alsa-driver, which will be reassigned.
- bugs that mention volume problems like "regression from Ubuntu X: volume too low" would be linux-source-2.6.x issues, not alsa-utils
- there are two classes of drivers that will have these types of regressions, the first far more common than the second: HDA- and AC97-based ones, respectively
the HDA ones are easier to triage, because we can narrow them to a specific file: the file that is the culprit is based on the HDA codec used, which one can get on an Ubuntu install from tail -2 /proc/asound/oss/sndstat
- there are two classes of drivers that will have these types of regressions, the first far more common than the second: HDA- and AC97-based ones, respectively
- symptoms such as "sound not working", "sound muted", and anything else falling under "not being able to hear sound under Ubuntu but being able to under $another_os" should be triaged against linux-source-2.6.x, where x is the kernel version for that Ubuntu release
- userspace
- anything dealing with "volume not being restored properly on (reboot)" or the like falls under alsa-utils
- anything dealing with "resampling sounds very bad" falls under alsa-lib
Spoke about DebuggingSoundProblems information - separate attachments are good
http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh grabs similar info and will find its way into the upstream project #upstream/Freenode, which should help us
Items remaining for the Feisty release (crimsun)
- regressions
- AC97 and Intel diff only showed one regression against Edgy; tsmithe will merge kernel-team@ patches that were not applied.
These tend to show up as headphone quirks, particularly with the multimedia hotkeys (eg, VolUp)
Often must bind Headphone and Master channels to fix, best documentation in the source: http://hg.alsa-project.org/alsa-kernel/file/f8284261b2be/Documentation/ALSA-Configuration.txt
- Tag these bugs in Launchpad as "headphone quirk".
Malone bug 88332 in linux-source-2.6.20 "low volume through headphones on HP Pavilion ZT3000 (ICH4) [edgy regression]" [Medium,Needs info] https://launchpad.net/bugs/88332
we've established that it's an actual kernel<->hardware issue, and since edgy works where feisty doesn't, we'll need to look specifically at sound/{core/,pci/ac97/,pci/intel8x0.c} differences in the git trees
- in feisty, the header files were shuffled, so we can ignore those changes in sound/pci/ac97/
- crimsun will manage this bug.
- Influx of bugs
- Monitor IRC
- Forum Ambassadors
Launchpad<->Forums link
- ALSA support would involve recompiling alsa-plugins to enable the jack plugin. This isn't enabled currently as jack-audio-connection-kit is in universe whilst alsa-plugins is in main
Looking ahead to Feisty+1 (crimsun)
the first issue here is integrating the DebuggingSoundProblems request info and the alsa-info.sh script into hwdb-client
- well, the first step is to write up a specification so it can be considered for the next development summit in Sevilla
- one of audio team to be at UDS-Sevilla to champion the spec
- integrating a script into hwdb-client shouldn't be difficult. Keep in mind we need to deal with at least three classes of devices: ISA, PCI, USB
- pci and usb are fairly straightforward (with the latter substituting lsusb -vv in place of lspci -vvn)
- isa's a bit more hairy, so I'll need to ask Scott and others about that
- so, start throwing around ideas for hwdb-client integration, and hopefully by our next meeting we have a better idea of how things should piece together
- well, the first step is to write up a specification so it can be considered for the next development summit in Sevilla
- Pro audio
UbuntuStudio is going to drive a different set of requirements focused on much lower latency, jack integration, and so on; ALSA itself needs to be prepared for that
- the most invasive change would be a "realtime"ish kernel
- it was discussed that the best approach to get any patches in would be a Launchpad spec and convincing of BenC.
- it was decided that the patches are in fact too invasive, and that we should let them filter into the mainline kernel piecemeal so as to get proper support and testing.
- variable timer
- more likely than not already merged and thus will be in Feisty+1
- is seeded for Edubuntu, and we can install it, but whether it becomes the default is something that would be a good discussion topic at UDS/Sevilla
- not yet GNOME default
- Does GNOME want a sound server, rather than not just using GStreamer?
- not yet ready for GNOME
- Work on collapsing deltas
- Merge changes with upstream; send patches to alsa@
PortAudio v19 stability?
- Backend for both wired and audacity in Feisty
Next meeting is 27 March 2007, 1800 UTC.
UbuntuAudio/Meetings/Minutes/20070315 (last edited 2008-08-06 16:41:30 by localhost)