Ubuntu Wiki

Log

08:02 < crimsun> all right, let's get started
08:02 < TheMuso> Is it just us three?
08:03 < tsmithe> looks like it... does it really matter?
08:03 < crimsun> Bug triaging best practices (crimsun)
08:03 < bdmurray> me too!
08:03 < TheMuso> oh right
08:04 < crimsun> first, to many people there's some confusion regarding alsa
08:04 < TheMuso> Re bugs, I have seen what bdmurray, crimsun, and Andrew Ash have been doing in responding to bugs.
08:04  * tsmithe too
08:04 < crimsun> here we'll lay out guidelines to make triaging a bit less painful
08:05 < tsmithe> (*smiles*)
08:06 < crimsun> 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
08:07 < tsmithe> yep
08:08 < crimsun> 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
08:08 < bdmurray> Is ubuntu-audio a subscriber to thse bugs?
08:08  * tsmithe restrains from answering in angst of getting it wrong
08:09 < crimsun> u-audio subscribes to alsa-driver but not the former, because bugs against linux-source-2.6.x aren't necessarily audio bugs
08:09 < bdmurray> right, so would it be appropriate to manually subscribe them?
08:09 < crimsun> yes, that is perfectly acceptable
08:10 < crimsun> alternately, you can, as you've been doing, triage the bug against alsa-driver, and we'll reassign as appropriate
08:10 < crimsun> this brings up another subtle point
08:11 < crimsun> there is one corner case (in terms of actual kernel sound drivers) in which one should triage bugs against alsa-driver instead of linux-source-2.6.x, and that is if alsa-source provides the actual driver instead of linux-source
08:12 < tsmithe> that's understandable
08:12 < tsmithe> how do we know that that is the case?
08:12 < crimsun> in previous Ubuntu releases, this was constrained to drivers like the EchoAudio ones
08:12 < tsmithe> (just learn?)
08:12 < TheMuso> crimsun: I guess to check that we need to check what package a driver belongs to?
08:13 < crimsun> TheMuso: because it's a corner case, modinfo on a default Ubuntu install will help there
08:13 < TheMuso> crimsun: I still don't quite understand.
08:14 < crimsun> for instance, if we can see from the bug report that the reporter is using snd-foo, then we can run ``modinfo snd-foo''
08:14 < crimsun> if nothing is returned, then instead of using linux-source-2.6.x as the triaged package, we can use alsa-driver
08:14 < TheMuso> crimsun: Right.
08:14 < tsmithe> ah clever
08:15 < crimsun> ok, that covers the kernel side ["sound inaudible"]
08:15 < crimsun> now, the userspace portion is more mundane
08:16 < crimsun> generally speaking these bugs are pretty easy to classify: anything dealing with "volume not being restored properly on (reboot)" or the like falls under alsa-utils
08:17 < crimsun> anything dealing with "resampling sounds very bad" falls under alsa-lib
08:17 < tsmithe> right
08:19 < crimsun> now, take for example, bugs that mention volume problems like "regression from Ubuntu X: volume too low" would be linux-source-2.6.x issues, not alsa-utils
08:19 -!- j_ack_ is now known as j_ack
08:19 < tsmithe> uhuh... why so?
08:19 < tsmithe> does alsa-utils not regress?
08:20 < TheMuso> Alsa-utils would generally know about the mixer values already I'm guessing.
08:20 < TheMuso> So it can usually set them.
08:20 < crimsun> right, Luke's got the idea
08:20 < tsmithe> hmm ok
08:20 < crimsun> there are two classes of drivers that will have these types of regressions, the first far more common than the second
08:21 < crimsun> HDA- and AC97-based ones, respectively
08:21 < TheMuso> crimsun: Does hda stand for anything?
08:21 < tsmithe> high-definition audio
08:21 < tsmithe> :S
08:21 < crimsun> high definition audio, interestingly enough
08:21 < TheMuso> right
08:22 < crimsun> HDA regressions and fixes can be expected for quite some time; we're only beginning to get better support for these newest models
08:22 < TheMuso> Lovely
08:22 < crimsun> and as you can tell just by browsing the linux-source-2.6.20 and alsa-driver bugs, most of the audio issues have to do with HDA-based chips
08:23 < tsmithe> TheMuso, remember, cynicism is not a good path
08:23 < crimsun> the HDA ones are easier to triage, because we can narrow them to a specific file
08:23 < TheMuso> tsmithe: Cynicism was furthest from my mind.
08:24 < tsmithe> :)
08:24 < crimsun> 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''
08:25 < tsmithe> ok
08:25 < crimsun> [the proper location for HDA is /proc/asound/card0/codec*, but it's different for AC97-based ones, which use /proc/asound/cardX/*codec*/* . Because /proc/asound/oss/sndstat abstracts that difference, and because we load snd-pcm-oss by default in Ubuntu, we use /proc/asound/oss/sndstat]
08:26 < TheMuso> Makes sense.
08:27 < crimsun> one of the more important pages that we use is https://help.ubuntu.com/community/DebuggingSoundProblems
08:27 < crimsun> this generally gathers enough info for us to triage correctly
08:27 < TheMuso> I've seen that be requested many a time.
08:27 < tsmithe> yeah
08:27 < tsmithe> and people always do it wrong...
08:28 < TheMuso> tsmithe: ?
08:28 < crimsun> yeah, some people will dump it all into one comment inline, which can be painful
08:28 < tsmithe> what he said ^^
08:29 < crimsun> separate attachments are good
08:29 < TheMuso> Oh right.
08:29 < TheMuso> I thought tsmithe meant something different.
08:29 < tsmithe> no :)
08:30 < crimsun> a few of us in #alsa are working on a script to grab similar info, http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh
08:30 < crimsun> this script will find its way into the upstream project [#upstream/Freenode], which should help us
08:31 < crimsun> the long-term intent (jumping ahead momentarily) is to tie this functionality into the hwdb-client
08:31 < TheMuso> Right.
08:31 < tsmithe> that would be very nice :)
08:31 < crimsun> therefore making it transparent to the user.
08:32 < crimsun> ok, are there any questions on triaging practices, then?
08:32 < TheMuso> Not from me, everything makes sense.
08:32 < tsmithe> yea
08:33 < aouaou> how about the professional audio devices?
08:33 < crimsun> aouaou: with respect to triaging, can you be more specific?
08:34 < aouaou> is something going to change in those devices? (sorry i am not an expert just audio professional)
08:35 < crimsun> aouaou: the scope of your question is fairly broad
08:35 < aouaou> yes u are probably right.. i should probably let you carry on
08:36 < crimsun> aouaou: if alsa already supports said pro audio device, then we can work to get it into linux-source-2.6.x if it's not already there
08:36 < aouaou> ok
08:37 < crimsun> aouaou: if there are issues other than getting support, like actually adding a driver, that's better addressed upstream [to alsa-devel@ ]
08:37 < aouaou> from end-user's scope i think there are some problems with the audio latency
08:37 < tsmithe> if that's supposed to be @ sourceforge, then they really need to get that subscribers only
08:37 < aouaou> is there anything that can change that?
08:38 < _MMA_> aouaou: Latency where?
08:38 < crimsun> aouaou: on feisty, there're two workarounds of sorts: -lowlatency kernel and the PAM realtime access. Both of these are documented.
08:38 < aouaou> ok thank you very much. i will check them out
08:39 < crimsun> aouaou: check in #ubuntustudio
08:39 < _MMA_> crimsun: There is also a script that addresses some PCI latency issues but thats another topic.
08:39 < _MMA_> las mentioned it.
08:39 < crimsun> _MMA_: right, remind me when we get to "Looking ahead to Feisty+1"
08:39 < TheMuso> I would think that would only be a problem if your hardware was causing latency issues.
08:39 < _MMA_> k
08:40 < crimsun> ok, moving on
08:40  * TheMuso notes that he has his cards all set on a good IRQ.
08:40 < crimsun> Items remaining for the Feisty release (crimsun)
08:41 < crimsun> the first issue we have is to make sure we don't regress from Dapper and Edgy for linux-source-2.6.20
08:41 < crimsun> one area in which I know there are regressions is in the AC97-based quirks
08:41 < tsmithe> well, my diff for ac97 and intel showed only one regression
08:42 < tsmithe> but then, there are - i'm sure - unapplied patches from kernel-team@
08:42 < tsmithe> i'm going to go through and put them all (together?) this weekend some time
08:42 < crimsun> ok, great
08:43 < crimsun> for the benefit of others, these AC97-based quirks tend to show up as headphone quirks
08:43 < TheMuso> Right.
08:43 < crimsun> particularly with multimedia hotkeys, like VolUp/VolDown/Mute
08:44 < crimsun> on many of these types of laptops, you often have to bind the 'Headphone' and 'Master' elements together so that the hotkeys work properly
08:45 < TheMuso> oh fun
08:45 < tsmithe> right - how does this happen? is there a doc somewhere?
08:45 < crimsun> Brian and I started working through some of these types of bug reports, tagging them "jack sense" on Launchpad
08:46 < crimsun> (which is a bit more broad than just that issue, but it narrows things down a bit)
08:46 < tsmithe> excellent
08:46 < crimsun> we should actually make those distinct, now that I think about it
08:46 < crimsun> let's use the "headphone quirk" tag for that
08:47 < tsmithe> right - this ominously suggests that there are other jack quirks
08:47 < crimsun> tsmithe: the best documentation would be the source, (un)fortunately
08:48 < tsmithe> i'm fine with that - any particular areas?
08:48 < crimsun> http://hg.alsa-project.org/alsa-kernel/file/f8284261b2be/Documentation/
08:49 < crimsun> generally speaking, ALSA-Configuration.txt is the relevant file
08:49 < tsmithe> thanks
08:49 < crimsun> note that f8284261b2be, the changeset hash, is continually updated, so to get the latest using the Web, you'll want to follow tip
08:50 < tsmithe> "tip"? is that like "head" or "trunk"?
08:50 < crimsun> (or you can just hg clone alsa-kernel, see instructions on http://www.alsa-project.org/download.php)
08:50 < tsmithe> i think i must just do that :)
08:50 < crimsun> yes, tip is the Mercurial equivalent of head/trunk
08:51 < tsmithe> excellent. makes me wonder why there need be so many names
08:51 < crimsun> there are so many systems :)
08:52 < tsmithe> that's not an excuse  ;)
08:52 < crimsun> ok, speaking of regressions, there's a rather serious one in bug 88332
08:52 < Ubugtu> 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
08:53 < tsmithe> that wouldn't happen to be a "Fujitsu Lifebook C1211D", would it?
08:53 < crimsun> this one's subtle and may require considerable git bisecting
08:53 < TheMuso> heh. I got 403 when attempting to check out alsa-driver from hg.
08:54 < crimsun> TheMuso: make sure you use hg.alsa-project instead of hg-mirror.alsa-project
08:54 < TheMuso> crimsun: right
08:54 < TheMuso> yep that works
08:55 < crimsun> with James's issue, we need to cover three areas, core, ac97, and intel8x0
08:55 < tsmithe> blimey
08:56 < crimsun> off the top of my head, I can't see why it would have regressed. It doesn't seem to be a power management issue, and there aren't many changes on top of that to those three areas
08:57 < tsmithe> ok - so how would you go about finding out?
08:58 < crimsun> via the initial steps, 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
08:58 < tsmithe> that's an awfully broad file set
08:59 < crimsun> thankfully it's smaller than it seems
08:59 < tsmithe> ah ok
08:59 < crimsun> in feisty, the header files were shuffled, so we can ignore those changes in sound/pci/ac97/
09:00 < tsmithe> mmhmm
09:00 < crimsun> I'll spend some time this evening looking at it, and we'll need to ask James to test 2.6.20-11.18
09:01 < tsmithe> who are "we"?
09:02 < crimsun> we -> ubuntu-audio
09:02 < crimsun> I'll take care of that part
09:02 < tsmithe> right :)
09:03 < crimsun> ok, second issue is to keep up with the seemingly endless flood of quirks
09:03 < crimsun> I try - and I admit I used to be much better about this - to peek into #ubuntu periodically to help with audio issues
09:04 < tsmithe> yea
09:04 < tsmithe> i try and catch them as well
09:04 < crimsun> quite a bit of the quirks gathered in previous Ubuntu releases were from #ubuntu and #alsa
09:04 < tsmithe> makes triaging much easier, when the reporter is alive
09:04 < TheMuso> Forgive me if I decide not to go in there again. That channel moves way too quickly for me to follow
09:05 < crimsun> TheMuso: sure, it's a bear
09:05 < tsmithe> well, to be honest, i try and catch them outside of there
09:06 < crimsun> there are many sources besides those two IRC channels in which to get quirks
09:06 < crimsun> I've neglected crawling through other distributions' bug databases
09:06 < crimsun> (a glaring error, really)
09:06 < tsmithe> grgh
09:07 < _MMA_> Maybe something could be done through the Ubuntu Forums. I know some feedback will come from Ubuntu Studio forums once they open.
09:07 < tsmithe> well, there has been discussion on -devel-discuss about (or maybe launchpad-users) about that kind of thing
09:07 < crimsun> _MMA_: I know quite a few sound issues are reported on the forums, but we need a mechanism for transferring those reports into Launchpad
09:08 < _MMA_> Didnt tsmithe have that covered somewhat with "Forum Ambassadors"?
09:08 < _MMA_> Thats another subject though.
09:08 < tsmithe> what was suggested was rather linking of old bugs to new posts. i think the f-a should cover vice versa
09:09 < _MMA_> Both seem good.
09:09 < crimsun> ok, that seems reasonable
09:10 < crimsun> anything else that seems critical for Feisty?
09:10 < tsmithe> not that i am aware of, certainly
09:10 < TheMuso> Not that I am aware of.
09:10 < crimsun> Cory, anything from ubuntustudio's perspective?
09:11 < _MMA_> I want to ask about freebob and firewire but they might not directly relate to whet the topic here is.
09:11 < _MMA_> I know we're going to get support questions for firewire devices.
09:12 < _MMA_> So Im guessing that if Freebob supports it the divice is good.
09:12 < crimsun> right, and likely freebob + jack alsa-plugin will be the way to go
09:12 < _MMA_> Ok.
09:12 < TheMuso> Does freebob support alsa in any way?
09:12 < _MMA_> So we will have to place an importance on the Freebob project.
09:12 < tsmithe> would it not have to?
09:12 < crimsun> currently this means that the user has to download and recompile alsa-plugins (enable the jack alsa-plugin, which is currently disabled)
09:13 < crimsun> TheMuso: not directly last I looked
09:13 < tsmithe> so it's directly a jack-only thing?
09:13 < _MMA_> And why is it disabled?
09:14 < tsmithe> i was just in the middle of typing "hmm - what's the rationale for that" :)
09:14 < crimsun> _MMA_: promotion of alsa-plugins to main for the pulseaudio plugin (for Edubuntu)
09:14 < crimsun> (jack-audio-connection-kit is in universe, which would cause the build to fail)
09:14 < TheMuso> ah yes
09:14 < tsmithe> ahh
09:15 < _MMA_> I see.
09:15 < TheMuso> If I understand correctly, this plugin makes alsa apps appear as jack apps right?
09:15 < TheMuso> If so, I've tried to use it before, with poor results.
09:16 < crimsun> it routes native alsa apps to jack
09:16 < _MMA_> So whats the way around this for a user?  Recompile alsa-plugins?
09:16 < crimsun> _MMA_: yes, as noted above
09:16 < TheMuso> And not all alsa apps allow you to easily change which device they use, especially custom asoundrc setups.
09:17 < TheMuso> So I guess we ort to move to feisty+1.
09:17 < tsmithe> yes
09:17 < tsmithe> i'm trying to find the agenda page... where was it again?
09:17 < _MMA_> Having a pre-built package for Ubuntu Studio users might have to happen somehow.
09:17 < crimsun> tsmithe: https://wiki.ubuntu.com/UbuntuAudio/Meetings
09:17 < tsmithe> thank you
09:18 < crimsun> _MMA_: we can discuss this post-meeting/offband in us-devel
09:18 < _MMA_> Ok.
09:18 < crimsun> ok, moving on to Looking ahead to Feisty+1
09:19 < crimsun> the first issue here is integrating the DebuggingSoundProblems request info and the alsa-info.sh script into hwdb-client
09:19 < tsmithe> yup
09:19 < tsmithe> what can we do to help with this process?
09:20 < crimsun> well, the first step is to write up a specification so it can be considered for the next development summit in Sevilla
09:20 < TheMuso> Who will be there to champion it?
09:20 < crimsun> one of you, hopefully :)
09:21 < tsmithe> hmm
09:21 < crimsun> I'm travelling during that month, so I won't be able to attend, unfortunately
09:22 < _MMA_> joejaxx and I have applied for sponsorship.
09:22 < tsmithe> hmm
09:22  * TheMuso never saw the call for it.
09:22 < TheMuso> applying for sponsorship.
09:22 < _MMA_> Whould be great if tsmight or TheMuso could be there.
09:22  * tsmithe neither
09:22 < tsmithe> _MMA_, *ahem*
09:22 < _MMA_> https://wiki.ubuntu.com/UDS-Sevilla/Attendees
09:23  * tsmithe ganders over
09:23 < _MMA_> Jane said they will look over that list.
09:23 < TheMuso> Nothing about sponsorship there.
09:23 < crimsun> 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
09:24 < TheMuso> yeah
09:24 < tsmithe> isa... awh
09:24 < crimsun> pci and usb are fairly straightforward (with the latter substituting lsusb -vv in place of lspci -vvn)
09:25 < crimsun> isa's a bit more hairy, so I'll need to ask Scott and others about that
09:25 < tsmithe> do people actually want those cards supported?
09:26 < crimsun> yes
09:26 < TheMuso> Well some mobos have MIDI controllers that are ISA.
09:26 < crimsun> (and Mark would probably argue yes, too)
09:26 < TheMuso> Mine included.
09:26 < _MMA_> crimsun: Ill also get the specific script from las to see if its useful or it might be the same one. :)
09:26 < crimsun> _MMA_: different issue, but we'll get to it in a second
09:28 < crimsun> 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
09:28 < tsmithe> i guess i'll need to get these sources then
09:29 < tsmithe> is an apt-get source enough, or is there somewhere else i should be looking?
09:29 < crimsun> https://launchpad.net/products/hwdb-client
09:29 < tsmithe> excellent
09:30 < tsmithe> (i'm pretty sure i should be looking by myself)
09:31 < crimsun> ok, next issue for Feisty+1 is the pro audio bent
09:31 < crimsun> UbuntuStudio is going to drive a different set of requirements focused on much lower latency, jack integration, and so on
09:31 < crimsun> ALSA itself needs to be prepared for that
09:31 < tsmithe> what are the other requirements?
09:32 < crimsun> _MMA_: is there movement on realtime?
09:32 < tsmithe> (those that are different to the UbuntuStudio ones?)
09:33 < TheMuso> crimsun: What needs doing alsa wise?
09:33 < crimsun> TheMuso: the most invasive change would be a "realtime"ish kernel
09:33 < TheMuso> right
09:33 < crimsun> I have not inspected those additional changes; I know some of them are in .20
09:34 < crimsun> again, this would need a specification on Launchpad, but more importantly, it's going to require convincing BenC
09:34 < TheMuso> As far as I know, the realtime patches are for ever changing.
09:34 < TheMuso> From release to release./
09:35 < crimsun> it's going to be a hard sell, honestly, because it's so invasive and because it changes
09:35 < crimsun> right
09:35 < TheMuso> crimsun: I don't believe we will get it in.
09:35 < _MMA_> Sorry. Kids. :)
09:35 < TheMuso> When I ran Gentoo, the rt kernel did just totally crap out on me when I least expected it at times.
09:36 < _MMA_> The most we can hope for are the things Ben has enabled.
09:36 < crimsun> this is a place where UbuntuStudio can drive, since US will likely be the sole use case
09:36 < TheMuso> -lowlatency seems to work fine here, although I haven't tested it with a lot of apps at once.
09:36 < tsmithe> well, surely he's the guy that knows best?
09:36 < _MMA_> Like has been said, things like Ingos patches are simple too invasive.
09:36 < TheMuso> I believe RT will be integrated in the mainline kernel over time.
09:37 < TheMuso> And thereby stabalised.
09:37 < crimsun> I'm happy to defer it even further (or strike it completely)
09:37 < TheMuso> Me too.
09:37 < _MMA_> Ben has also mentioned that Ingo's patches are slowly making it into mainline.
09:37 < _MMA_> :)
09:37 < crimsun> right, piece-wise, as verifiable through testing
09:37 < TheMuso> Yep.
09:38 < TheMuso> SO eventually everybody will gain.
09:38 < tsmithe> that would certainly be the best approach
09:38 < _MMA_> Also some things are changing that make the patched unneeded.
09:38 < TheMuso> I'm willing to wait for that, as long as we keep -lowlatency around.
09:38 < tsmithe> i'm not for going for everything to please some people
09:38 < _MMA_> Ben mentioned a variable timer.
09:38 < pochu> hey thekorn!
09:38 < crimsun> _MMA_: likely to be default in Feisty+1, since it has already been merged
09:38 < thekorn> hi pochu !
09:38 < crimsun> unless I misparsed linux-kernel@ and LWN
09:39 < _MMA_> crimsun: Nice. Ill chat with you later about that.
09:39 < _MMA_> :)
09:39 < crimsun> (which is entirely possible, since I've been running around)
09:39 < TheMuso> So what else is there/
09:39 < crimsun> for Feisty+1, we should work on collaping deltas
09:39 < TheMuso> Where does pulseaudio stand? As far as I can see, its not enabled in feisty.
09:40 < TheMuso> crimsun: ?
09:40 < crimsun> pulseaudio's not default [yet] in gnome
09:40 < TheMuso> Right.
09:40 < _MMA_> I was wondering about PS as well.
09:40 < _MMA_> gah
09:40 < tsmithe> will it be?
09:40 < _MMA_> *PA
09:40 < crimsun> it's 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
09:41 < crimsun> http://live.gnome.org/PulseAudio
09:41 < _MMA_> I would love to be in on the spec but theres no way I can impliment it. :)
09:42 < crimsun> _MMA_: likely there will be little to implement if upstream (gnome) pulls it in
09:42 < _MMA_> True.
09:43 < crimsun> ok, back to collapsing deltas. We need to ensure our changes get merged back to upstream [ALSA@]
09:43 < TheMuso> One thing I would like to have a look at for feisty+1, is the state of portaudio 19.
09:43 < TheMuso> Yes.
09:43 < TheMuso> Mainly to work out how stable it is.
09:43 < TheMuso> I know I'm kinda scratching my own itch here, but anyway.
09:43 < crimsun> I have been woefully slack about pushing changes back, and that will change.
09:44 < _MMA_> crimsun: Kinda related. When will you be leaving us?
09:44 < crimsun> As for portaudio19, I know it's the backend for feisty's Audacity. Does anyone have experience with its stability?
09:44 < tsmithe> wired is also using portaudio19
09:44 < ogra> for usage in a default ginem you will need a bunch of patches from the old esd package
09:44 < ogra> *gnome
09:44 < ogra> i worked with the pulse package nearly the whole release for ltsp
09:44 < ogra> its great there, but not ready for gnome as is
09:44 < tsmithe> (when it gets in)
09:44 < TheMuso> crimsun: Not really. I am investigating it for espeak.
09:44 < ogra> imho gnome should be fixed to not require a sound daemon
09:44 < ogra> afaik there is even a patch to switch everyting to gstreamer
09:45 < ogra> (for events etc)
09:45 < tsmithe> ogra, but then there's the issue with initialising that. i'd prefer a simple library to do that
09:45 < crimsun> _MMA_: (I'm gradually cutting back, but I'm unlikely to disappear completely simply due to the sheer enormity of audio issues)
09:45 < ogra> tsmithe, but gstreamer is used everywhere else ...
09:45 < ogra> its silly to dupicate backends
09:46 < _MMA_> crimsun: So we need to make sure you have a good team in place with a good system to take more pressure of you.
09:46 < ogra> *duplicate
09:46 < tsmithe> yes -  but on lower end systems; at login?
09:46 < _MMA_> *off
09:46 < crimsun> _MMA_: (what we're doing here)
09:46 < _MMA_> ;)
09:47 < crimsun> anyhow, we're perilously close to the devteam meeting, so let's go ahead and close off
09:47 < tsmithe> ah yes ok
09:47 < tsmithe> next meeting?
09:47 < TheMuso> crimsun: Quickly, do we want some wiki pages?
09:47 < crimsun> TheMuso: yes, that would be useful
09:47 < tsmithe> i think we should start chucking ideas together for hwdb-client
09:47 < tsmithe> and minutes?
09:47 < ogra> tsmithe, well, a cut down gstreamer-minimal ? i'd really not just replace one sounddaemon with another ... but hey i'm not a gnome dev who decides such things :)
09:48 < tsmithe> ogra, well - i'm with you on that :)
09:48 < TheMuso> crimsun: As for next meeting, well hows every couple of weeks to make sure we're on target with bugs?
09:48 < ogra> i just worked with pulse the last months and wanted to throw in my 2cent
09:48 < tsmithe> great
09:48 < TheMuso> I'm happy to rotate times to suit other people, given enough notice.
09:49 < crimsun> if same time on the 29th works, let's shoot for it
09:49 < TheMuso> Fine by me
09:49 < tsmithe> not for me
09:50 < tsmithe> i'm going away to germany the day before, unfortunately
09:50 < crimsun> ok, how does the 27th look?
09:50 < crimsun> at possibly 1800?
09:50 < TheMuso> Fine once again.
09:50 < tsmithe> 27 is good
09:50 < TheMuso> The notice is good for me to make it
09:51 < tsmithe> if i find i have other things planned, i'll email you both
09:51 < crimsun> ok, let's set it for March 27th 1800 UTC
09:51 < crimsun> I'll work on these minutes this evening
09:51 < crimsun> thanks, everyone
09:51 < TheMuso> crimsun: You sure?
09:52  * tsmithe was gonna suggest doing it
09:52 < crimsun> oh, if someone else wants to, feel free :)
09:52 < tsmithe> i'm fine with someone else doing it, tough :P
09:52 < TheMuso> tsmithe: If you're happy to do so.
09:52 < tsmithe> *though
09:52 < tsmithe> ok - i will
09:52 < tsmithe> where shall i email
09:52 < tsmithe> ?
09:52 < tsmithe> (it'll help get things straight in my mind)
09:52 < crimsun> thanks, tsmithe. See https://wiki.ubuntu.com/UbuntuAudio/Meetings/Minutes  (which you'll have to create)
09:53 < tsmithe> ok - that's great
09:53 < tsmithe> @schedule
09:53 < tsmithe> looks like ubuntu dev is soon
09:53 < tsmithe> nothing more?
09:53 < crimsun> I recommend following https://wiki.ubuntu.com/MOTU/Council/Meetings/Minutes as a template
09:53 < TheMuso> nope
09:54 < crimsun> nope, we're all up :) Thanks again!