21:02:17 <coling> #startmeeting
21:02:17 <pulsator> Meeting started Thu Feb 24 21:02:17 2011 UTC.  The chair is coling. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:17 <pulsator> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:02:33 <coling> #topic PulseAudio Roadmap and Development Meeting Part II
21:02:52 <coling> OK, so let's discuss the UCM stuff with maggie_ :)
21:02:58 <coling> Seeing as that's where we left it.
21:03:09 <coling> Then after we're done there, I have some specific patches and such to discuss too.
21:03:12 <coling> #topic UCM
21:03:28 <coling> mezcalero, have you been following the UCM stuff much at all just out of curiosity?
21:04:36 <mezcalero> nowell, i followed it from the distance
21:04:44 <mezcalero> so it's in alsa merged, right?
21:04:53 <mezcalero> but i haven't looked into the proposed code for pa
21:04:58 <maggie_> yes, it is part of latest release
21:05:30 <coling> I think lasersailor has been looking at it quite a bit of late judging by the interactions on alsa-devel :)
21:05:54 <mezcalero> s/nowell/however
21:06:23 <mezcalero> i cannot really comment on the code for pa
21:06:36 <mezcalero> is this an additional module or directly in the alsa module code?
21:06:37 <lasersailor> I think the code is fine is there's only one ALSA card. Not sure how things work with plugable devices.
21:06:52 <coling> mezcalero, maggie_ has not long started on it yet, and part of what we dicuss today will determine how best to fit it in with PA
21:06:58 <mezcalero> do you switch ucm individually for each sound cards?
21:07:10 <mezcalero> but there were patches, right?
21:07:19 <mezcalero> or am i just awfully badly informed?
21:07:23 <coling> mezcalero, http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module
21:07:24 <pulsator> Title: pulseaudio.git - Pulse Audio (at git.slimlogic.co.uk)
21:07:31 <coling> ^^ maggie_ repo
21:07:38 <maggie_> ok, the current approach is to add a new module
21:08:26 <maggie_> atm it only works only for one ALSA card
21:08:57 <coling> OK, so how I understood it before was that UCM could give information about the sinks/sources available to us, and how they interact with each other for certain use cases.
21:09:06 <maggie_> yes
21:09:12 <mezcalero> btw, if there's doubt, i'd be fine with this is merged into the alsa module
21:09:19 <mezcalero> kinda seems natural to me, but i don't know
21:09:31 <mezcalero> is there something in the ucm stuff we want to expose in the profiles stuff?
21:09:32 <coling> I kinda saw this as a ninja version of our current card profile probing + some extra metadata to aid routing.
21:09:39 <coling> But that's probably a simplistic view of it.
21:09:47 <mezcalero> coling: yes, it is a bit like that, though lower level
21:10:08 <maggie_> there was a discussion about the best place to add the code
21:10:10 <mezcalero> coling: that's why i was suggesting integrating this as a "differing configuration source" for the mixer magic we currently do
21:10:41 <maggie_> and it was decided to add a new module to be able to manage virtual cards
21:10:45 <coling> mezcalero, yeah that was my original thoughts too. I discussed it in such context with Liam and broonie in the pub a while back.
21:11:06 <coling> (but was never sure I was 100% right!)
21:11:09 <mezcalero> maggie_: so, what would make sense to me is that we shortcut this in the alsa module: i.e. if UCM is available for a specific card, use UCM and only UCM for the ports management, and if there isn't use the mixer magic we currently do
21:11:22 <mezcalero> so, i mean, you have to come up with the code
21:11:26 <mezcalero> either way i am happy
21:11:49 <mezcalero> if this is a module of its own, i can definitely live with it, since it is a unit that won't influence my own work
21:11:50 <coling> But is there more to it than that?
21:12:07 <maggie_> yes, that is the idea to avoid the mixer magic when ucm is present
21:12:08 <mezcalero> if this is integrated into the alsa code in pa, that's fine too. Makes sense from my uninformed position
21:12:30 <mezcalero> and you shouldn't be afraid of touching the alsa code really
21:12:45 <mezcalero> but the current mixer code must of course be kept and for us consumer folks
21:12:57 <mezcalero> maggie_: do you expect ucm to be compiled on general purpose distros, too?
21:13:06 <coling> Will we end up creating multiple sinks for the different use cases (e.g. one for audio, one for ringing etc).
21:13:11 <mezcalero> maggie_: i.e. do you expect this to show up in debian or fedora?
21:13:26 <maggie_> maybe what i need to define more are the part of the mixer magic that can be skip when ucm is present
21:13:40 <mezcalero> coling: nah, i'd rather see automatic port/ucm switching based on what is connected
21:13:48 <lasersailor> maggie_: how do we know if UCM is supported for a given card?
21:14:07 * coling assumed UCM would be available on desktops but not many consumer cards would ultimately use it.
21:14:26 <mezcalero> maggie_: well, i thought UCM would completely replace our mixer magic, including hw volume control, or doesn't it?
21:14:45 <maggie_> mezcalero, yes it will
21:15:22 <maggie_> lasersailor, atm the only way it is try to open the ucm for other card when ucm module is loaded
21:16:11 <mezcalero> maggie_: so, yupp, to mit appears most sensible to add this to the alsa modules natively
21:16:16 <maggie_> colin,  even if the ucm is available the ucm needs the configuration files for that given card
21:16:22 <mezcalero> maggie_: but then again i know ucm only very superficially
21:16:47 <coling> maggie_, so if you try and it fails, it's not available, if you try and it works, it is? Seems simple enough (it's how most audio apps probe for PA afterall!)
21:16:54 <mezcalero> but if there's something you take back from this meeting: don't be afraid of changing the alsa module. there's not reason to keep this stuff in its own module
21:16:59 <lasersailor> so we would still use the mixer magic for PCI/USB devices?
21:17:18 <maggie_> colin, yes that's it
21:17:23 <coling> lasersailor, I guess so (unless someone writes the necessary UCM metadata for any given USB/PCI card.
21:17:44 <mezcalero> lasersailor: well, i figure that UCM is really only useful for builtin cards, right? extension cards probably never, right?
21:17:46 <coling> I'm guessing some of the more specialist h/w may have that written (i.e. the ones we write custom profiles for just now maybe)
21:18:20 <maggie_> lasersailor, do you have any suggestion about virtual cards?
21:18:27 <maggie_> I mean how to manage them?
21:19:00 <coling> In what way will you have virtual cards maggie_? Can you explain what they are?
21:19:34 <maggie_> coling, well I was refering to usb devices
21:20:59 <coling> Oh OK, so likely these would just fall through to our existing mixer probing logic I guess.
21:21:01 <lasersailor> you could have one USB device for capture, one for playback, and the two are seen as a virtual card.
21:21:26 <coling> Ahh OK, I see you now. Is this a common scenario?
21:22:38 <coling> And also, how do we deal with the auto-switching of sink/source ports and/or card profiles?
21:22:46 <coling> (depending on use case)
21:23:01 <coling> One of the things tanuk mentioned before he fell asleep was how to deal with policy.
21:23:01 <lasersailor> not really common, but it's a concept that's present in UCM. I really have no idea how this would work
21:23:38 <coling> In an ideal world we'd want to make the policy stuff separate from ucm and "just work" without any UCM support at all (e.g. with our existing mixer probing). Is this a desirable goal?
21:24:09 <maggie_> it is needed a policy to set the use case
21:24:25 <lasersailor> UCM has to work with the policy, so that you set the 'voice' verb only if the policy accepts the call
21:24:29 <maggie_> the initial approach is based on role
21:25:30 <maggie_> but tanuk mentioned that is not nice
21:25:53 <mezcalero> coling: yes, i definitely see automatic profile switching in seperate modules
21:25:58 <coling> I don't think basing it on role was what he disapproved of, more that it should be pluggable.
21:26:13 <mezcalero> coling: i.e. seperate policy and mechanism in seperate modules
21:26:48 <coling> So say for example a UCM based metadata specifies a card profile that defines two, separate profiles, "Music" and "Audio".
21:27:14 <lasersailor> make that Music and Speech :-)
21:27:35 <coling> We are playing a "Music" stream and all is well, but then a "Phone" stream appears. This should trigger a Card Profile change to the "Speech" profile (thanks lasersailor!) and connect the stream to the new sink that appears.
21:28:00 <coling> While this happens the Music stream is likely corked, as it has no sink to connect to....
21:28:24 <coling> When the call is over, the policy modules see that there is a Music stream still waiting and thus switches the Card Profile back to Music again.
21:28:34 <coling> Is that (roughly) how things should work?
21:29:18 <coling> If the UCM defines that Music and Speech can be used at the same time it would create a "Music+Speech" profile that creates both sinks at the same time.
21:29:41 <coling> Thus the routing can connect both streams simultaneously and both get played and no corking is needed.
21:29:49 <coling> Am I on the right track?
21:30:20 <coling> (this may not be done with card profiles of course - it could be done with a single sink and use the Sink Ports)
21:30:25 <coling> Awww
21:30:27 <lasersailor> The policy module should be more explicit and corks/stop the streams. Otherwise you will connect the Music stream to the NULL sink
21:30:33 * coling hopes she comes back :D
21:30:50 <mezcalero> hehe
21:31:24 <mezcalero> coling: but yupp, this kind of seperation between policy and mechanism is how i want to see this implemented too
21:31:51 <Ford_Prefect> (perhaps wait a couple of min, move ahead and then continue when she's back?)
21:32:05 <coling> OK, so it seems we're all on the same page here. I suspect that lasersailor has a much better grasp than me tho' :))
21:32:16 <coling> maggie_, wb!
21:32:19 <Ford_Prefect> \o/
21:32:23 <coling> What was the last line you saw?
21:32:31 <maggie_> thanks, something happened with my node
21:32:48 <maggie_> you mentioning music and phone
21:33:15 <coling> OK, big paste coming up....
21:33:17 <coling> <coling> So say for example a UCM based metadata specifies a card profile that defines two, separate profiles, "Music" and "Audio".
21:33:21 <coling> <lasersailor> make that Music and Speech :-)
21:33:23 <coling> <coling> We are playing a "Music" stream and all is well, but then a "Phone" stream appears. This should trigger a Card Profile change to the "Speech" profile (thanks lasersailor!) and connect the stream to the new sink that appears.
21:33:28 <coling> <coling> While this happens the Music stream is likely corked, as it has no sink to connect to....
21:33:31 <coling> <coling> When the call is over, the policy modules see that there is a Music stream still waiting and thus switches the Card Profile back to Music again.
21:33:35 <coling> <coling> Is that (roughly) how things should work?
21:33:37 <coling> <coling> If the UCM defines that Music and Speech can be used at the same time it would create a "Music+Speech" profile that creates both sinks at the same time.
21:33:41 <coling> <coling> Thus the routing can connect both streams simultaneously and both get played and no corking is needed.
21:33:44 <coling> <coling> Am I on the right track?
21:33:46 <coling> * maggie_ has quit (Ping timeout: 272 seconds)
21:33:49 <coling> <coling> (this may not be done with card profiles of course - it could be done with a single sink and use the Sink Ports)
21:33:52 <coling> <coling> Awww
21:33:55 <coling> <lasersailor> The policy module should be more explicit and corks/stop the streams. Otherwise you will connect the Music stream to the NULL sink
21:33:58 <coling> * coling hopes she comes back :D
21:34:01 <coling> <mezcalero> hehe
21:34:03 <coling> <mezcalero> coling: but yupp, this kind of seperation between policy and mechanism is how i want to see this implemented too
21:34:06 <coling> Will give you a moment to catch up maggie_ :)
21:34:09 <coling> mezcalero, lasersailor do you see this being more of a card-profile thing or a sink/source port thing?
21:34:19 <maggie_> ok
21:34:22 <coling> Or should it really matter?
21:34:24 <mezcalero> coling: ucm? dunno, i don't know ucm enough
21:34:29 <maggie_> a lot of new lines
21:34:32 <mezcalero> coling: but looks like sink/source port think
21:34:35 <mezcalero> thing
21:34:55 <maggie_> ok, ucm basically set a bounch of alsa controls based on the use case
21:34:57 <coling> mezcalero, OK, but I guess sink/source port would only apply if use cases are mutually exclusive right?
21:35:12 <maggie_> e.g it enables all the path to go to the headset
21:35:21 <maggie_> and you can set a device too
21:35:29 <maggie_> e.g a sink or source
21:36:15 <maggie_> the current approach is to set "music" verb when this role is set, then "phone" verb when this role is set
21:36:27 <maggie_> or set hifi verb per default
21:36:38 <coling> I would prefer that the verbs get set indirectly.
21:37:06 <lasersailor> I think that's the part that I am missing. with the current PA approach, you will have a new sink for each profile. But in UCM you can have several outputs per profile
21:37:06 <maggie_> you mean to not link them with verbs?
21:37:07 <coling> e.g. the policy sets the appropriate sink/source port and the UCM module listens for such port changes and sets the verb accordingly.
21:37:41 <coling> So the policy stuff is abstracted from UCM and works on a non-UCM system.
21:38:38 <coling> lasersailor, that's the problem I'm having with a sink/source port based approach. It only works for mutually exclusive case....
21:39:00 <lasersailor> I think it's the other way around. You select the verb and then you will know what sinks are available
21:39:15 <coling> But then with card profile based approach, you can have mutliple sinks and sources, but these all represent (IIUC) one alsa "device" on which you can set a verb?
21:39:22 <maggie_> lasersailor, yes I think so
21:39:33 <coling> Ahh right.
21:40:01 <coling> OK, so some module looks at the streams and decides which is most "important" ($ARBITRARY_ALGORITHM)
21:40:18 <coling> And this module will push the verb to UCM which in turn will update what sinks are actually availbled.
21:40:25 <coling> *available
21:40:47 <maggie_> yes
21:40:54 <lasersailor> #agree
21:40:56 <coling> But isn't this something we kinda "pre-probe" for at startup.
21:40:59 <coling> ?
21:41:12 <coling> e.g. we check all the verbs we care about and then this builds up our list of profiles?
21:41:26 <lasersailor> All the sinks/sources are available in the UCM config file
21:41:27 <maggie_> part of the code it to fill a proplist with that data e.g to list the devices available per use case
21:41:53 <coling> After that initial probe, we just enter into our "non-UCM specific" mode and then the verb is set the other way round (as I suggested originally).
21:42:03 <Ford_Prefect> Possbly a silly question, but I assume that something like jack detection would then become a separate module and do verb-setting based on its own policy?
21:42:35 <coling> Am I making sense?
21:42:51 * coling isn't sure he's describing what's in his head right.
21:43:20 <lasersailor> maggie_: isn't jack detection a modifier in UCM parlance?
21:43:26 <maggie_> colin, yes, in the current code at pa_init all the verbs are set
21:43:41 <maggie_> lasersailor, yes
21:43:50 <maggie_> let me explain more
21:44:21 <maggie_> so, at pa__init, the verbs are set and a proplist per verb is fill
21:44:34 <maggie_> with the modifiers and devices availables
21:45:06 <maggie_> but I have not finish to map that data with the data that PA is already using, eg. the profiles
21:45:14 <coling> maggie_, OK, so does this initial probe result in a list of card profiles?
21:45:24 <coling> maggie_, ahh OK  you just answered :D
21:45:39 <maggie_> list of verbs per card
21:45:48 <coling> So the way I see it, is that the initial UCM probe checks all verbs for the card.
21:45:54 <maggie_> yeap
21:46:02 <coling> This ultimately builds up a list of profiles, which results in various sinks.
21:46:04 <maggie_> to get all the data
21:46:31 <coling> The UCM module will know that a certain card profile will result in a certain verb being "active".
21:46:32 <maggie_> here my confusion, I have proplist, is that a list of profiles?
21:46:51 <coling> maggie_, no the proplist is just a generic key/value storage system
21:47:12 <maggie_> hehe yes, your last sentence describe more
21:47:20 <coling> The card profiles (and sink/source ports) are a kind of defined structure in PA that is the product of our current mixer probing logic
21:47:55 <coling> So without any policy module, if the UCM can create the different card profiles, a user could use e.g. pavucontrol, and change the card profile.
21:48:15 <maggie_> ok, so  with UCM those structures will be replaced
21:48:18 <coling> This would result in the appropriate verb being set via UCM API (e..g when my "Speech" profile is active, I set the speech verb
21:48:44 <maggie_> yes
21:49:07 <coling> maggie_, yeah, I'd say that UCM will bascially generate those structures instead of our current mixer probe. (i.e. if UCM is available it is used and our stuff isn't, but if UCM isn't available then we just fall back to what we do now)
21:49:17 <coling> Either way, the cards and their profiles are filled in.
21:49:19 <lasersailor> Right. But you may need to select which sink you want for this profile
21:49:31 <coling> Indeed lasersailor that's where it gets a bit more complex :D
21:49:57 <maggie_> but, then how to select the verb?  is it ok using the role?
21:50:01 <coling> But I think this illustates my point that the verb is set indirectly of a specific UCM policy module.
21:50:25 <lasersailor> agree
21:50:39 <coling> maggie_, I would propose that each profile has a verb associated with it.
21:50:52 <coling> maggie_, when the profile is active that's the verb that is passed through to UCM.
21:51:20 <coling> This way we can do all the policy stuff in a UCM agnostic way.
21:51:30 <coling> All we do is have policy modules that change card profiles.
21:51:36 <coling> This is done whether UCM is used or not.
21:51:40 <lasersailor> it'd be similar to what's done with BT (HSP or A2DP)
21:51:46 <maggie_> yes
21:52:02 <coling> But when UCM *is* used, then the fact the differetn profiles are activated results in the verb being propigated.
21:52:15 <coling> lasersailor, and this same approach would fit in nicely with the passthrough.
21:52:27 <lasersailor> you saw me coming :-)
21:52:42 <coling> e.g. if someone requests a AC3 format stream, and a card profile that is not active supports HDMI, then it can be activated automagically.
21:52:58 <coling> Excellent.
21:53:02 <coling> :)
21:53:27 <coling> OK, so I think we're all signing from the same page here. The finer details can likely be hashed out in due course :)
21:53:32 <Ford_Prefect> (with jack detection (yes, I'm obsessed!) it'll be awesomer still since then UCM can set the digital out verb and profile when you've got the appropriate connector plugged in)
21:53:42 <coling> Ford_Prefect, yeah
21:53:47 <maggie_> ok, currently if you don't have profile defined PA uses default.conf to generate them, right?
21:54:26 <coling> maggie_, yeah, this is used in pretty much 99% of current PA usage. It's a generic process of probing alsa to work out what it supports.
21:54:57 <coling> But really UCM would avoid the whole thing completely if it's avaialble and implement an alternative way of filling in the card profiles and the subsequent sink/source ports too.
21:55:17 <lasersailor> Ford_Prefect, not really. HDMI outputs on PCs don't care if there's something connected or not (unfortunately)
21:55:17 <maggie_> ok, but that is an issue in some card, I mean the probing breaks them
21:55:38 <Ford_Prefect> lasersailor: is that a hardware limitation or missing support in drivers?
21:55:39 <maggie_> so the idea with UCM is to skip that probing
21:55:51 <coling> maggie_, exactly!
21:55:58 <coling> UCM avoids the need to probe :)
21:56:24 <coling> And we can just skip it completely and bypass that whole process.
21:56:34 <Ford_Prefect> lasersailor: because if it's a h/w limitation, that would be really sad, since we have the opportunity to do things more intelligently with HDMI
21:56:44 <coling> But still end up with the same internal structures (broadly speaking).
21:56:48 <lasersailor> Ford_Prefect,  it's a feature not a bug
21:56:58 <coling> maggie_, but myself and (hopefully) lasersailor can help you with this later if that's OK?
21:57:12 <coling> mezcalero, any comments on this or have you fallen asleep yet?
21:57:25 <maggie_> yeap,  I added an ugly to start selecting some code that can be skip
21:57:26 * coling hopes not as he's about to start bugging mezcalero some more :)
21:57:43 <maggie_> thanks for the help
21:58:00 <coling> maggie_, no worries :)
21:58:53 <coling> OK, so I think we should move on for now. Obviously more discussons of UCM will come in the future :)
21:59:08 <coling> mezcalero, feel free to comment on the above later in the meeting.
21:59:13 <coling> But for now.....
21:59:13 <krtaylor> that was really helpful for me, thanks maggie_
21:59:20 <coling> #topic ORC
21:59:24 * mezcalero reads up
21:59:33 <Ford_Prefect> <grunt>
21:59:39 <coling> Ford_Prefect, you're up!
21:59:53 <Ford_Prefect> What we have is 1- and 2-channel s16ne scaling in Orc
21:59:55 <mezcalero> coling: i am happy
22:00:01 <maggie_> me is going to have lunch
22:00:01 <coling> mezcalero, thx
22:00:03 <Ford_Prefect> It seems to do well on MMX and SSE as I mentioned on list
22:00:11 <coling> Thanks for coming maggie_ :)
22:00:11 <Ford_Prefect> mezcalero said he's fine with Orc as a dep
22:00:22 <mezcalero> yes, i am happy with orc
22:00:24 <Ford_Prefect> (mandatory dep - we already optionally dep on it for module-echo-cancel)
22:00:41 <coling> Ford_Prefect, Cool. I think that's fine. Does Orc as mandatory dep affect any embedded folks?
22:00:51 <mezcalero> coling: i presume they like it
22:00:55 <lasersailor> what is the license for ORC?
22:00:55 <coling> I'm guessing not... It should help...
22:00:57 <Ford_Prefect> coling: the fallback paths are still available
22:01:00 <mezcalero> coling: since less porting work for them
22:01:11 <coling> mezcalero, indeed.
22:01:21 <Ford_Prefect> lasersailor: BSDish
22:01:34 <sjoerd> if they're using gstreamer they're likely to have it already as well
22:01:37 <Ford_Prefect> FWIW, we need some changes in Orc to make the ARM bits fast enough
22:01:48 <coling> OK, so this can go in for 1.0?
22:01:54 <lasersailor> ok. as long as it's not GPL3 no issues
22:02:25 <Ford_Prefect> lasersailor: http://code.entropywave.com/git?p=orc.git;a=blob;f=COPYING;h=2a43304dc69b81ac48f298730930596411d3f699;hb=HEAD
22:02:31 <pulsator> Title: code.entropywave.com Git - orc.git/blob - COPYING (at code.entropywave.com)
22:02:42 <coling> #link http://code.entropywave.com/git?p=orc.git;a=blob;f=COPYING;h=2a43304dc69b81ac48f298730930596411d3f699;hb=HEAD
22:03:11 <coling> (Side note about the meetbot - it will grok links if they are at the start of a post but not if you mention something first like someone's nick)
22:03:32 <coling> Ford_Prefect, so this can be merged for 1.0 yes?
22:03:37 <Ford_Prefect> coling: yes
22:03:41 <coling> cool
22:03:51 <coling> #agreed Orc mandatory dep will be merged for 1.0
22:04:13 <coling> OK, so I'd like to move on ot some specific patches now if that's OK?
22:04:17 <Ford_Prefect> (I'll push out a rebased tree for you to pull tomorrow)
22:04:25 <coling> Ford_Prefect, nice thanks
22:04:31 <coling> #topic Win32
22:04:38 * mezcalero loves gpl3
22:04:51 <coling> OK, so mkbosmans has done some awesome work of late (lots of patches and tidy ups)
22:05:06 <mezcalero> is the git repo somewhere?
22:05:09 <coling> It's very much appreciated, so thank you Maarten :)
22:06:10 <mkbosmans> https://github.com/mkbosmans/pulseaudio/compare/mingw32-build
22:06:11 <pulsator> Title: Comparing master...mingw32-build for mkbosmans's pulseaudio - GitHub (at github.com)
22:06:47 <coling> mezcalero, I've reviewed most of it already and most seems pretty fine, but the one thing I'm not sure about is the wrapping up of EINTR at various places
22:07:03 <coling> mezcalero, specifically this: https://github.com/mkbosmans/pulseaudio/commit/821562b9bc8d1a9033daaae0fd5373498a085054
22:07:04 <pulsator> Title: Commit 821562b9bc8d1a9033daaae0fd5373498a085054 to mkbosmans's pulseaudio - GitHub (at github.com)
22:07:08 <mkbosmans> the last commit of the series
22:07:19 <mkbosmans> yup, thats it
22:07:22 <coling> I'm not sure if the silent swallowing of EINTR is safe or not.
22:07:59 <mezcalero> hmm?
22:08:04 <mezcalero> does it swallow EINTR on that patch?
22:08:27 <coling> No, but pa_read does already, and this changes read() -> pa_read()
22:08:29 <mkbosmans> no, pa_read does that
22:08:48 <mezcalero> ah, i see what you mean
22:08:49 <coling> ditto for pa_write and (IIRC) pa_poll
22:08:56 <mkbosmans> This is necessary, because on windows the code in pipe.c makes a pipe
22:08:56 <mkbosmans> out of two sockets instead of file descriptors. That means that a bare
22:08:56 <mkbosmans> read/write won't work, because it expects an fd. pa_read/pa_write
22:08:56 <mkbosmans> provides a nice wrapper that uses recv/send in case of Windows
22:08:56 <mkbosmans> sockets. But as pa_read/pa_write also does a loop to cover up EINTR,
22:08:57 <mkbosmans> I'm not sure whether the code is still correct on Linux. (Limited
22:08:59 <mkbosmans> testing of this code on Linux reveals no problems though)
22:09:14 <mkbosmans> (copied from an earlier mail to the list)
22:09:22 <mezcalero> windows is such a broken system
22:09:29 <mkbosmans> tell me about it
22:09:41 <mezcalero> i think it is probably good to eat it here too
22:09:50 <coling> mezcalero, nice.
22:09:52 <mezcalero> let's merge this and fix what breaks ;-)
22:09:54 <mkbosmans> i've given up building _on_ windows, not yet given up building _for_ windows
22:09:59 <coling> I like the thinking :)
22:10:07 <coling> mkbosmans, :D
22:10:23 <mezcalero> mkbosmans: are they paying you for this, or do you do this for "fun"?
22:10:28 <mkbosmans> for the windows part (module-waveout) there is the regression that the source does not work anymore
22:10:39 <mkbosmans> but that will come with time
22:10:47 <mkbosmans> for the fun, can you believe it?
22:11:06 <coling> OK, so I'll just merge your branch then I mkbosmans. mezcalero will be reviewing git master this week so if there is anything myself and the others have not yet spotted, he can question it then.
22:11:08 <mezcalero> everybody their thrills
22:11:16 <mkbosmans> but I want to deploy it on some windows boxes I'm administrating
22:11:25 <coling> #action coling to merge mkbosmans' win32 build branch \o/
22:11:57 <coling> #topic Log Targets
22:12:26 <coling> mezcalero, OK this one relates to a relatively small set of patches posted by vinio (who sadly has now left for the night)
22:12:57 <coling> mezcalero, the only reason I've not really merged this is because I wasn't sure if you'd have some objections to logging to something other than $syslog.
22:13:34 <mezcalero> hmm
22:13:42 <mezcalero> so regarding this patch:
22:13:43 <coling> mezcalero, but in principle, are there any objections. Latest patches are here: <http://permalink.gmane.org/gmane.comp.audio.pulseaudio.general/8695> and <http://permalink.gmane.org/gmane.comp.audio.pulseaudio.general/8696>
22:13:44 <pulsator> Title: [PATCH 1/2] Add a target to the PA log feature (at permalink.gmane.org)
22:13:45 <mezcalero> https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110224/4e0435a0/attachment-0002.obj
22:13:54 <mezcalero> people won't like long --help texts like that
22:14:14 <mezcalero> the patch should just write the comment for the switch in question in one line down
22:14:21 <mezcalero> no reindenting of the table please
22:14:37 <coling> mezcalero, yeah I'll deal with the style and such like.
22:14:42 <mkbosmans> I already said that on the list, together with some bikeshedding about PA_LOG_FILED => PA_LOG_FD
22:14:44 <mezcalero> we don't do s-o-b btw
22:14:53 <coling> mezcalero, just wondering if the general principle is OK?
22:15:06 <coling> mezcalero, yeah I know but stripping s-o-b out is more hassle than just leaving them in.
22:15:12 <mezcalero> i am not entirely sure what the use case is
22:15:29 <mezcalero> and yeah, FILED is weird
22:15:32 <mezcalero> should bw FD
22:15:44 <mezcalero> s/bw/be
22:16:04 <coling> mezcalero, his use case was on an embedded system, but for debugging it could also prove useful if it can be changed at runtime, e.g. pactl set-log-target ~/.palog.txt
22:16:11 <coling> I could use that at times when helping users etc.
22:16:18 <lasersailor> I can explain this one: we use tracing capabilities to check when the audio becomes corrupted...
22:16:20 <coling> So I can see use cases for it got general usage.
22:16:46 <coling> Ahh of course I presume you work with vinio lasersailor?
22:17:06 <mezcalero> hmm, is this about connecting things to /dev/kmsg?, that would be cool..
22:17:12 <lasersailor> yes.
22:17:31 * Ford_Prefect finds the rotation logic being in our code odd
22:17:34 <mezcalero> +    if (log_fd >= 0)
22:17:34 <mezcalero> +        pa_close(log_fd);
22:17:34 <mezcalero> +
22:17:35 <mezcalero> +    pa_close(log_fd);
22:17:37 <mezcalero> uh?
22:17:54 * mezcalero agrees with Ford_Prefect
22:18:16 <mezcalero> i'd rather not see the rot logic in pa
22:18:24 <lasersailor> mezalero: not really. we can trace multiple data channels at the same time, audio being one of them.
22:18:29 <mezcalero> i don't want pa to become a new logrotate implementation
22:19:10 <coling> OK, so after the patch is physically cleaned up and weirdness removed, the general principle is OK mezcalero? i.e. FD logging is OK to add.
22:19:21 <mezcalero> so, i am not against this, except i don't like the rotation in our code, and the naming needs to be fixed. and some of the dirty things like "else if (strchr(string, '/')) {" i don't like
22:19:27 <mezcalero> error checking
22:19:48 <coling> Cool, that's fine, myself or mkbosmans can take care of that I believe.
22:20:02 <mezcalero> and insert_substr looks weird, too
22:20:13 <mezcalero> if this is really useful it should be in util.[ch] or so
22:20:31 <mezcalero> but i kinda getthe feeling pa_sprintf_malloc() is a better choice here?
22:20:31 <mkbosmans> how about the other change that vinio separated in the second patch?
22:20:34 <mezcalero> dunno
22:20:35 <Ford_Prefect> I'd suggest use file:<path> as the target instead of searching for '/'
22:20:50 <mezcalero> Ford_Prefect: agree
22:20:55 <coling> #agreed vinio's logging patches will be applied once tidied up (FD, not FILED, no log rotation, indentation in help text, string handling and other stuff)
22:21:24 <coling> #agreed vinio's patch to use file:<path> prefix rather than searching for /
22:22:01 <mezcalero> i cannot parse the description of the second patch
22:22:22 <coling> mkbosmans, can you describe it a bit better?
22:22:33 <mkbosmans> no, as I didn't understand it either
22:22:37 <coling> :)
22:22:48 <mkbosmans> that's why I asked for vinio to separate it from the PA_LOG_FD introduction
22:23:12 <coling> OK, we'll try and work that out with vinio later and decide what to do with that, unless lasersailor can enlighten us?
22:23:21 <mkbosmans> as vinio described on the list:
22:23:22 <mkbosmans> the algorithms around 'char *t' have been reordered in order to optimize memory use. This could be useful when traces are big. The trace buffer "char text" has been set to 16*1024Kb which allocates already 16Kb on the stack. This buffer is then copied into t, in the for loop that checks for carriage returns. What needed to be optimized is that extra memory is allocated in case of metadata (location and timestamp) is prep
22:23:22 <mkbosmans> ended to t, by creating dynamically a new buffer. The idea is to prepend the data directly into t (and append if it's the case) before we affect the value of 'text'. It avoids one dynamic memory allocation, at least in the case of the new target PA_LOG_FILED.
22:23:23 <mkbosmans> Therefore, a 'metadata' buffer is created and prepended in t whatever the target. One switch/case is actually added to build this metadata buffer and we keep the other one just for write the actual log (text+metadata) in the target.
22:23:58 <mkbosmans> but I guess, this is better suited for normal review, not for the meeting now?
22:24:07 <coling> Yeah I think so.
22:24:29 <coling> The principle is fine tho' and uncontroversial
22:24:33 <coling> OK, so next
22:24:39 <coling> #topic Infinite Loop
22:24:49 <coling> This is just a patch posted on Jan 1st (someone was keen).
22:24:59 <mezcalero> OS/2
22:25:00 <mezcalero> yikes
22:25:00 <coling> Not sure I really understood it so I waited for a further reviews
22:25:36 <coling> mezcalero, indeed :)
22:25:52 * mezcalero doesn't understand it either
22:25:59 <mezcalero> looks like a workaround, not a fix though?
22:26:10 <Ford_Prefect> Erf, no context even
22:26:24 <coling> OK, so NAK on that one until more infor is given then?
22:26:45 <mezcalero> yeo
22:26:47 <mezcalero> yep
22:26:50 <coling> #agreed NAK on the Infinite Loop
22:26:59 <coling> #action coling to follow up and ask for more context and info.
22:27:12 <coling> #topic LADSPA
22:27:26 <coling> OK, so there are now a few LADSPA related patches waiting.
22:27:36 <Ford_Prefect> (perhaps that thing can go in as an OS/2-specific workaround with an ifdef)
22:27:36 <coling> Some are quite large and useful (e.g. multichannel support)
22:27:56 <coling> Ford_Prefect, yeah maybe.
22:28:32 <coling> I don't personally know jack about LADSPA, so I'm not overly confident merging one or the other (not even looked at how one compares to the other)
22:28:52 <coling> But as two people have done this now, I'd like to get at least one of them merged sooner rather than later (e.g. for 1.0)
22:29:07 <coling> Is anyone educated in LADSAP at all that could help review?
22:29:46 <coling> One of the bits I'm particularly uncertain about is the removal of a silence memblock... not really sure why it was needed before and isn't needed now.
22:30:15 <mezcalero> uh, the ladspa stuff is difficult
22:30:20 <coling> If no-one is able, I'll just merge the one I know has been tested a fair bit (I helped the author learn git)
22:30:36 <coling> It was in turn adapted from an older patch posted to trac.
22:31:18 <mezcalero> hmm, yeah, merge it into master and i'll review it then
22:31:28 <coling> OK, I'll do that.
22:31:39 <coling> #action coling to merge the LADSAP stuff.
22:32:02 <coling> Ok, so now a couple of specific problems without patches
22:32:08 <coling> #topic Sound gone weird.
22:32:13 <mezcalero> uh
22:32:23 <coling> THis is something that I pesonally suffer from and know others have reported also....
22:32:36 <coling> This happens to me about ~10 times a day at least
22:32:54 <coling> It's happened about four times during this meeting so far.
22:33:12 <mezcalero> sounds as if the samples are a bit off
22:33:14 <mezcalero> no clue
22:33:17 <coling> Basically the audio goes all out of kilter and stays out. I'm not sure if this is something in PA or something in HDA
22:33:24 <coling> Does anyone else get this?
22:33:32 <mezcalero> i have had it before that stuff like this is a driver problem, but i wouldn't rule it out that it is pa
22:34:00 <coling> I'm not sure if it's "triggered" by e.g. skype (I've started running it more often recently and it seems to correspond to triggereing this more frequently, but it's not the primary cause)
22:34:25 <coling> OK, so no real clues. That's OK, but I certianly want to get to the bottom of the problem before 1.0
22:34:44 <Ford_Prefect> Too many rewinds?
22:34:47 <coling> #info No real clue if it's PA or ALSA. More investigation needed.
22:34:54 <coling> Ford_Prefect, don't think so.
22:34:59 <lasersailor> coling: I can't download your files, no permissions.
22:35:05 <coling> Crap
22:35:09 <Ford_Prefect> (the wav files are 403, oga worked for me)
22:35:36 <coling> lasersailor, fixed
22:35:39 <coling> oga are smaller :)
22:35:51 <coling> but gst didn't write the perms very openly.
22:35:59 <coling> Safer that way I sps
22:36:17 <coling> The monitor records correctly, but the mic shows what I actually hear.
22:36:21 <lasersailor> is this on the capture or playback path?
22:36:31 <coling> lasersailor, playback.
22:36:43 <coling> I record what's playing via the montior source and via the mic.
22:36:59 <coling> The monitor recording is fine, but the mic obviously records what I hear which is not fine.
22:37:18 <coling> So I think the "recording" process in both cases is working fine :)
22:37:36 <coling> And PA thinks everything is OK due to monitor being correct.
22:37:55 <coling> I'm not sure if that indicates a problem in the driver is more likely.
22:38:11 <Ford_Prefect> How do you make it go away? PA restart?
22:38:55 <coling> Ford_Prefect, pasuspender echo
22:38:59 <coling> That's the simplest.
22:39:06 <coling> Just closing and reopening the device "fixes" it.
22:39:17 <lasersailor> if you want 5s the drive closes, does this solve your problem?
22:39:20 <lasersailor> wait
22:39:25 <coling> Yeah that too
22:40:24 <coling> But generally our old friend "ALSA plug-in [plugin-container]" (aka Flash Plugin) generally prevents this from working by itself automagically
22:40:43 <Ford_Prefect> 3v!l
22:40:53 <coling> But anyway, if no-one happens to "just know" we can move on, and I'll try and debug more.
22:41:08 <lasersailor> do you know if there's any resampling?
22:41:43 <mezcalero> btw, one thing we need to the add to the list of things to talk about: tx is dead
22:41:59 <sreeves1> coling: does this happen on one specific type of card ?
22:42:14 <coling> lasersailor, hmm, not 100% sure to be honest... possibly. But all things played form then on is messed up regardless.
22:42:23 <mezcalero> coling: if the monitor is OK, i'd guess the driver is weird
22:42:26 <coling> lasersailor, I'll try with trivial to see if it prevents it happening.
22:42:35 <mezcalero> coling: and then things are hard to debug
22:42:39 <coling> sreeves1, I think on HDA, but not 100% sure.
22:42:46 <Ford_Prefect> mezcalero: tx?
22:42:53 <coling> Ford_Prefect, i18n
22:42:57 <Ford_Prefect> Ah
22:42:59 <coling> I presume
22:43:04 <mezcalero> Ford_Prefect: transifex
22:43:38 <coling> #info Issue likely to be related to driver, but more testing needed. Try with trivial resampler to see if it occurs less
22:43:38 <mezcalero> Ford_Prefect: you know, support for weird languages, like katakana, or hindi, or tamil... ;-)
22:43:50 <Ford_Prefect> mezcalero: what?! nobody speaks those anyway :p
22:44:05 <coling> Ok, lets discuss this now
22:44:06 <coling> #topic Translations
22:44:10 <mezcalero> Ford_Prefect: or kannada of course
22:44:12 <coling> So what do we do?
22:44:27 <mezcalero> coling: so, dimitris change how tx works
22:44:42 <mezcalero> i.e. since a while tx doesn't commit into our tree anymore
22:44:52 <mezcalero> i tried to convince him that that was the biggest feature
22:44:58 <mezcalero> but, uh, he wasn't convinced
22:45:08 <mezcalero> he planned to add something to make our life easier
22:45:20 <mezcalero> one of the great things of Tx was that i never had to bother really
22:45:29 <mezcalero> since my own interest in i18n is rather low
22:45:38 <mezcalero> but uh, we probably need to do something about this sometime
22:45:44 <mezcalero> and adopt the new he does things
22:45:50 <mezcalero> but it's low prio
22:46:04 <coling> mezcalero, I'd be happy to do that
22:46:04 <Saviq> well, pulling the new translations from tx is a `tx pull` away
22:46:08 <mezcalero> but if somebody cares, he's welcome to figure how we can make things work
22:46:19 <mezcalero> Saviq: you have experience with that?
22:46:22 <coling> I did try to work out how it was done a while ago, but never sussed it.
22:46:26 <mezcalero> Saviq: but what i want is independent commits
22:46:34 <mezcalero> Saviq: that was the big issue
22:46:34 <coling> I'd be happy to pull tx's in and push our changes out etc.
22:46:47 <Saviq> mezcalero: independent as in per-change? per-language?
22:46:53 <mezcalero> Saviq: per change
22:47:09 <mezcalero> Saviq: we don't do that in the git world: commit a huge bunch of changes in one go
22:47:16 <mezcalero> Saviq: we commit all changes individually
22:47:37 <Saviq> mezcalero: yeah I know
22:48:03 <coling> mezcalero, so would the pulls cause this one big commit problem?
22:48:04 <Saviq> I'd have to think about what can be done, we could probably pull a patchset from tx
22:48:09 <Saviq> coling: yes
22:48:13 <coling> Ahh bummer
22:48:27 <Saviq> 'cause you'd get all the changes between `tx pull` in one go
22:48:52 <coling> So can you look into this issue Saviq ?
22:49:04 <Saviq> I can take a look at that, have a chat with dimitris about what's possible
22:49:15 <coling> Awesome
22:49:20 <Saviq> please someone tell meetbot to sign that in for me :)
22:49:42 <coling> #action Saviq to discuss i18n with dimitris about the ability to get per-change txn merges
22:49:46 <mezcalero> Saviq: i had a long chat with dimitris about this
22:49:48 <Ford_Prefect> I'd add the PA_VOLUME_MAX decrease to the list, but it /is/ getting late and I'd bump some concrete release planning first
22:49:59 <mezcalero> Saviq: and he was open to provide us with some kind of stream we can convert into commits
22:50:11 <mezcalero> but as long as we cannot do this tx is a complete no-go for me
22:50:13 <coling> Ford_Prefect, I actually meant to mention it earlier when mezcalero said not to re-define it for UI_MAX ;)
22:50:30 <coling> but me first
22:50:35 <coling> #topic DBUS Reconnection
22:50:45 <Saviq> mezcalero: ok, I'll ping him back on this, do you have a log maybe or was this the weird analogue thing called a face-to-face conversation?
22:50:45 <mezcalero> Ford_Prefect: yes, please keep PA_VOLUME_MAX as is, and introduce PA_VOLUME_UI_MAX
22:50:54 <coling> Myself and several users have experience a problem connecting to dbus after suspend.
22:51:06 <mezcalero> Saviq: "over-a-beer conversation"
22:51:06 <coling> mezcalero, it's slightly different tho'
22:51:21 <coling> The MAX thing I mean.
22:51:26 <coling> For different reasons.
22:51:40 <coling> OK, let's discuss this now...
22:51:44 <mezcalero> tbh i didn't fully grok Ford_Prefect's proposal
22:51:46 <coling> #topic MAX volume
22:51:52 <coling> Ford_Prefect, go!
22:51:59 <mezcalero> Saviq: if you talk to him, tell i am wearing the tx shirt right now.
22:52:02 <Ford_Prefect> Okay, so basically our current max is 289 dB of gain
22:52:16 <Ford_Prefect> It is possible (and I've done this) to damage your hearing by mistake while toying with pacmd or such to set volume
22:52:39 * elmarco likes the tx-shirt
22:52:46 <Ford_Prefect> Which is why I think it's good to bring it down to ~50 dB
22:53:22 <Ford_Prefect> Well, admittedly, setting the volume too high is stupid
22:53:36 <coling> mezcalero, WDYT? ACK/NAK?
22:53:44 * coling cuts to the chase
22:53:45 <mezcalero> uh, are you sure this is a real problem?
22:53:47 <elmarco> Ford_Prefect: you are assuming input volume is normalized?
22:53:52 <mezcalero> i mean, the hw sets limits anyway
22:53:57 <Ford_Prefect> Simple way to do this:
22:54:00 <Ford_Prefect> Hook up speakers
22:54:02 <Ford_Prefect> Play music
22:54:11 <Ford_Prefect> pacmd and set the volume to 1 million or so
22:54:19 <mezcalero> what we can do digitally is not more than any evildoer coudl do to you by sending you a prepared wave file
22:54:19 <Ford_Prefect> Have you ears ring for about a month
22:54:39 <Ford_Prefect> mezcalero: true, it's not a global solution
22:54:47 <Ford_Prefect> mezcalero: but it does prevent user stupidity
22:54:50 <mezcalero> the range that is accessible via the sw amp is the same as is available to the wave files themselves
22:54:59 <mezcalero> Ford_Prefect: well, but pacmd is a low level tool
22:55:17 <mezcalero> Ford_Prefect: i am kinda convinced that user stupidity like this should be worked against in the UI
22:55:20 <mezcalero> not in the lowest level
22:55:28 <lasersailor> Do you mean that the amplification results in clipping? that could happen with a +1dB gain...
22:55:49 <coling> Ford_Prefect, do you drop your request?
22:55:53 <sjoerd> mezcalero:  i discovered a bug in the gnome volume media key handling not too long ago that caused the volume level to overflow when you kept pressing volume down
22:55:56 <sjoerd> that was bad
22:56:04 <sjoerd> having pulse make that not possible would be better :)
22:56:05 <coling> sjoerd, ouch.
22:56:13 <Ford_Prefect> coling: I'm happy to discuss this later, since it requires discussion
22:56:22 <sjoerd> (well make it loud but not maxint)
22:56:29 <mezcalero> sjoerd: PA trying to fix bastien's bugs? ;-)
22:56:47 <sjoerd> it's fixed now ;)
22:57:04 <sjoerd> but i first hit this when my laptop was playing movies at a movie night we had
22:57:10 <sjoerd> which wasn't pleasant
22:57:33 <coling> I can imagine
22:57:54 <sjoerd> so some safety for software stupidity as well as user error would be good is all i'm saying :)
22:57:59 <Ford_Prefect> mezcalero: we can't solve the problem for all cases
22:58:01 <coling> I don't really see why you'd want to go above e.g. +50dB anyway... that's massively loud
22:58:10 <Ford_Prefect> mezcalero: but I don't see a practical value for the amount of gain we allow
22:58:19 <mezcalero> coling: hey, mine goes up to twelve ;-)
22:58:28 <Ford_Prefect> And if someone needs it that badly, they can recompile for it
22:58:34 <mezcalero> Ford_Prefect: the limit sounds so arbitrary though
22:58:58 <coling> How about +48dB... ti's a power of 2 and thus not arbitrary :D
22:59:01 <elmarco> Ford_Prefect: why not just in a configuration file?
22:59:13 <Ford_Prefect> elmarco: mostly because we have it as a define which is part of the API
22:59:18 <mezcalero> Ford_Prefect: putting good user limit on top of things makes sense, but the 11dB suggested for the PA_VOLUME_UI_MAX probably only make sense for consumer UI as we know it... i wouldn't add artificial limits to the core that enforce that
22:59:24 <mkbosmans> power of two is not really relevant on a dB scale
22:59:37 <coling> Yeah I know, I was jk/ing
22:59:39 <Ford_Prefect> mezcalero: even if the artificial limit has a potential benefit and no limit has none?
22:59:52 <mezcalero> Ford_Prefect: hmm, can we implement this as a module?
22:59:57 <mezcalero> if so, this might be an option
23:00:06 <mkbosmans> well, what would be the use case for a serious amplification factor?
23:00:26 <mkbosmans> for me that would be a stupidly silent movie/recording or something
23:00:27 <coling> I guess the define can be left as is, but the server side can do additional sanity checks?
23:00:52 <mezcalero> i am not convinced we can change the #define without breaking abi
23:00:52 <elmarco> mkbosmans: somehow, this happens to me nearly every day..
23:01:08 <Ford_Prefect> elmarco: how much gain do you need to add, usually?
23:01:10 <elmarco> mkbosmans: not movies, but crappy podcast/radio
23:01:13 <mkbosmans> in that case 20-30dB amplification would suffice, I'd say
23:01:23 <Ford_Prefect> mezcalero: I don't think any client uses PA_VOLUME_MAX
23:01:24 <mkbosmans> elmarco, ah, yes, indeed
23:01:43 <coling> Ford_Prefect, yeah I doubt it.
23:01:43 <mezcalero> so, yupp, it'd be happy if we have an option or so, and even better a module to just enforce limits optionally, but not in the core in a #define compile-time way
23:02:01 <coling> OK, so that's pretty much that decided then?
23:02:05 <lasersailor> what you really want is called a limiter.
23:02:17 <coling> Ford_Prefect, you happy to move on?
23:02:24 <Ford_Prefect> I don't think it's doable compile-time. Is preventing setting it in the UI acceptable?
23:02:31 <Ford_Prefect> As in for pactl/pacmd
23:02:40 <Saviq> lasersailor: I'd say a compressor would be better
23:02:47 <Ford_Prefect> s/compile-time/in a module/
23:02:52 <krtaylor> I like configurable, except leave PA_VOLUME_MAX as is and have a configurable override
23:02:58 <lasersailor> limiter is an extreme form of compression
23:03:05 <mezcalero> Ford_Prefect: well, i mean, we can add a config option option in daemon.conf for it
23:03:05 <lasersailor> same DRC processing
23:03:10 <coling> Ford_Prefect, I don't think it's possible as module, but probably from daemon.conf
23:03:17 <mezcalero> Ford_Prefect: and if it is set to 0 no enforcement is done
23:03:22 <mezcalero> Ford_Prefect: and then distros can ship that
23:03:28 <coling> WFM.
23:03:28 <Ford_Prefect> Okay
23:03:34 <mezcalero> Ford_Prefect: and i probably would even ship that on fedora probably
23:03:34 <krtaylor> +1
23:03:40 <coling> #agree We wont change PA_VOLUME_MAX, but add a limiting factor in daemon.conf
23:03:45 <coling> OK, next
23:03:50 <elmarco> mezcalero: f15 feature!
23:04:03 <coling> #topic DBUS Reconnection
23:04:21 <mezcalero> coling: daemon.conf option is one choice, a module for it another, if that is feasible. but given how simple this is a daemon.conf option might be the better choice than yet-another-module
23:04:24 <coling> OK, so this is a problem I experience from time-time and others do too (someone mentioned it today)
23:04:32 <mezcalero> elmarco: f16 if at all ;-)
23:04:55 <coling> When resuming from suspend, dbus connection is sometimes not re-established.
23:04:58 <mezcalero> coling: if the rate limit burns you then recompile pa with pa_rate_limit shortcut to true
23:05:07 <mezcalero> coling: but i don't really follow
23:05:09 <mezcalero> coling: dbus?
23:05:30 <coling> mezcalero, rate limit?? Not sure what you mean.
23:05:47 <coling> Anyway, the problem with the dbus reconnection failure is that all hotplug breaks (e.g. USB)
23:06:09 <coling> This is due to the reserve-wrap stuff not working as it's not able to check that we can use the device.
23:06:22 <mezcalero> in the mail you linked from the wiki you mentioned something about "events suppressed" ← that's the ratelimiter
23:06:47 <coling> Oh right sorry
23:06:52 <coling> ignore that tho
23:06:59 * mezcalero doesn't really see the connection between suspending and dbus reservation
23:07:19 <coling> That's not actually the best mail to have posted.
23:07:23 <coling> But regardless
23:07:39 <coling> I mean STR (i.e. laptop suspending)
23:07:57 <coling> When I resume, sometimes the dbus connection is lost.
23:08:05 <mezcalero> the dbus connection?
23:08:07 <coling> And then everything stops working.
23:08:12 <mezcalero> between pa and dbus-daemon?
23:08:15 <coling> Yup
23:08:16 <mezcalero> the AF_UNIX socket is gone?
23:08:24 <mezcalero> that's weird
23:08:29 <coling> Yeah.
23:08:35 <mezcalero> which side closes it, any idea?
23:08:37 <Ford_Prefect> #action Ford_Prefect to redo PA_VOLUME_MAX patches to be daemon.conf configurable
23:08:45 <coling> But I'm certainly not alone
23:09:02 <coling> I sadly don't know which side closes it.
23:10:06 <coling> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-December/008330.html
23:10:07 <pulsator> Title: [pulseaudio-discuss] Card sometimes doesn't create sinks/sources (at tango.0pointer.de)
23:10:09 <coling> Better link
23:10:38 <mezcalero> coling: hmm, no clue at all about this
23:10:41 <coling> mezcalero, basically when inspecting the session bus, org.pulseaudio.Server is not on  it.
23:10:52 <mezcalero> coling: hmm, weird
23:10:52 <coling> It's annoyingly hard to reproduce.
23:10:59 <mezcalero> so it's only sometimes?
23:11:03 <coling> Yup
23:11:08 <mezcalero> hmm, no clue
23:11:10 <coling> I don't remember it happening for a while.
23:11:38 <coling> It's possibly something that started with dbus 1.4 but someone mentioned it happening with 1.2.x too, alhtouhg it could be an unrelated problem)
23:11:49 <coling> I guess I'll just have to leave it but keep my eyes open for a reoccurance.
23:11:58 <mezcalero> yupp
23:12:00 <coling> Is there anything you could advise debugging wise?
23:12:07 * mezcalero smells a race
23:12:36 <mezcalero> coling: try setting a breakpoint on the function of libdbus that closes the socket fd
23:12:45 <mezcalero> and run pa in gdb while you suspend
23:13:13 <coling> OK, thanks
23:13:35 <coling> Will try that. I'll see if I can get it to reproduce again first then if I can get it to happen at all, I'll try that.
23:13:41 <coling> #action coling to try and debug more.
23:13:56 <coling> OK, on to the final topic I think \o/
23:14:05 <coling> #topic 1.0 Release Schedule
23:14:13 <Ford_Prefect> \o/
23:14:21 <coling> OK, when do we want it!?
23:14:34 <coling> I think the various patches can go in shortly.
23:14:44 <coling> Some unwritten stuff will come in the next month or so.
23:15:07 <coling> I think we should aim for a beta in ~2 months and final by ~3-4 months.
23:15:16 <coling> But that's relatively arbitrary
23:15:30 <krtaylor> coling, how about that blog on running pa in gdb ;-)
23:15:32 <coling> There can of course be further 0.9.x releases in the meantime too.
23:15:47 <Ford_Prefect> krtaylor: http://pulseaudio.org/wiki/Community#BugsPatchesTranslations
23:15:49 <mezcalero> beta? let's just call that 0.10 or so
23:15:50 <pulsator> Title: Community – PulseAudio (at pulseaudio.org)
23:15:51 <coling> krtaylor, yeah I'll have to work out how to do that properly first :D
23:16:14 <mezcalero> coling: what was the versioning scheme we agreed on btw for >= 1.0?
23:16:17 <mezcalero> 1.0, 1.1, 1.2?
23:16:32 <mezcalero> 1.47, 1.67, 1.88?
23:16:45 <coling> mezcalero, yeah, 1.0 then 1.1 and 1.2 etc. for bug fix releases and new majors for other releases.
23:16:48 <mezcalero> and then 1.107, 1.454, 1.997?
23:16:51 <mezcalero> ok
23:17:05 <coling> So 2.0 wont be *that* far behind in theory.
23:17:08 * mezcalero doesn't really believe to much in "major" releases...
23:17:23 <mezcalero> but anyway
23:17:34 <coling> Essentially if it's from git master it's a new major if it's from the $MAJOR.x-stable branch it's a Minor bump
23:17:48 <sjoerd> having smaller releases more often would be great even for development branches
23:17:57 <mezcalero> so, if this stuff is merged then i'll go through git master and review it next week
23:18:09 <coling> Cool.
23:18:22 <mezcalero> sjoerd: what? you don't like our 1y release cycle? and you are the debian guy here ;-)
23:18:27 * Ford_Prefect thinks a pre-release in a month (maybe another 2 weeks after) and schedule final release in 2 could work
23:18:36 <sjoerd> mezcalero: i use unstable on everything but servers :)
23:18:46 <Ford_Prefect> In that case, I should suggest rolling releases :p
23:19:09 <mezcalero> Ford_Prefect: go and play with your http://funroll-loops.info/ !
23:19:10 <pulsator> Title: Welcome to Gentoo is Rice, the Volume goes to 11 here. (at funroll-loops.info)
23:19:17 <coling> I'm pretty certain I've got all patches committed to stable-queue into master but it might be useful if someone else checks git cherry output
23:19:49 <coling> (as it has been ~2 years since git master deviated from stable-queue!)
23:20:05 <coling> I will warn that there are some false positives in the git cherry output
23:20:23 <coling> But I digress... like I say I *think* I've stayed on top of that.
23:20:56 <Ford_Prefect> I'll take up watchummy-item to verify
23:21:07 <coling> So Ford_Prefect's schedule is more optimistic than mine, mezcalero what do you think? I suppose you'll be doing some work next week and then some more before the release.
23:21:16 <krtaylor> maybe this is the time to bring up Continuous Integration?
23:21:38 <coling> Oh yeah forgot about that topic.
23:21:47 <krtaylor> it was a late addition
23:21:49 <coling> But lets decide on our schedule first
23:21:49 <mezcalero> that sounds so modern. so xp. so uml. makes me feel old.
23:21:58 <krtaylor> lol
23:22:08 <Ford_Prefect> mezcalero: you *are* old :p
23:22:19 <krtaylor> ouch
23:22:31 <mezcalero> coling: well, we can aim for this, but schedules are hard... the fedora cycle is already enough deadlines for me ;-)
23:22:44 <mezcalero> Ford_Prefect: your mom is old
23:22:52 <Ford_Prefect> Yes ...
23:22:58 <Ford_Prefect> :p
23:23:01 <coling> So will we say, beta in ~1month (after passthrough stuff is final). With release no later than ~3months, ideally in 2?
23:23:18 <coling> That's still quite lose but within a reasonable timescale.
23:23:20 <mkbosmans> no 0.
23:23:23 <mezcalero> yeah
23:23:27 <mkbosmans> no 0.9 releases anymore?
23:23:47 <coling> mkbosmans, I think doing a final one from stable-queue makes sense, yes
23:23:50 <coling> It should be simple tho'
23:24:15 <mkbosmans> may be my rtp-stuff should go into stable-queue after all then
23:24:23 <coling> mezcalero, do you still want to be in charge of that too or delegate to me?
23:24:28 <mkbosmans> as there was an ubuntu bug about it just last week
23:25:03 <coling> mkbosmans, OK, if you send me the sha1s (or even a branch to pull) that's cool.
23:25:14 <mezcalero> coling: let me have a look, and as long as the stuff is not on fdo yet it probably makes sense that i upload releases and stuff
23:25:30 <coling> mezcalero, yeah that makes sense.
23:25:43 <mezcalero> coling: let's revisit things when things are on fdo, then the release process becomes a lot simpler to do for people who don't happen to be "Lennart Poettering"
23:25:58 <coling> OK, so is the schedule for 1.0 OK for you Ford_Prefect?
23:26:06 <Ford_Prefect> ++!
23:26:12 <coling> OK, so...
23:26:53 <coling> #agreed We will release a 1.0 beta in ~1month (after passthrough stuff is finalised) with the final release coming preferably in ~2months but no later than ~3 months time.
23:27:09 <coling> #agreed We will do a (final?) 0.9.x release from stable-queue
23:27:18 <coling> #undo
23:27:18 <pulsator> Removing item from minutes: <MeetBot.items.Agreed object at 0x8caf4cc>
23:27:36 <coling> #agreed We will do a (final?) 0.9.x release from stable-queue before 1.0 final release.
23:28:01 <coling> Although that doesn't preclude doing more later if needed/desired by downstream
23:28:08 <coling> (from 0.9.x I mean)
23:28:20 <coling> OK, so krtaylor's CI
23:28:20 <mkbosmans> which downstreams are using stable-queue?
23:28:22 <mkbosmans> all of them?
23:28:29 <coling> mkbosmans, pretty much I think.
23:28:40 <coling> tho' fedora is likely behind as usual.... :p
23:28:52 <sreeves1> before we move to CI - as we drive to 1.0 release would it be beneficial to review what modules and options are set by default
23:29:04 <coling> sreeves1, Oh yeah that was one thing.
23:29:15 <sreeves1> I ask because I know some distros patch out things like module-x11-cork and the default sampler
23:29:23 <coling> Can we agree to  not load module-x11-cork-request by default?
23:29:24 <mkbosmans> I think, e.g., fedora, debian and gentoo are all using 0.9.22 with hardly a single patch
23:31:02 <Ford_Prefect> Gentoo only adds an arm build patch on top of 0.9.22
23:31:05 <coling> mkbosmans, you could be right. We should recommend they follow better s-q I guess.
23:31:15 <coling> Or get the release out.
23:31:27 <coling> But anyway, can we agree on x11-cork?
23:31:34 <mkbosmans> the largest list of patches I found with Ubuntu, but let's not get into that ;-)
23:31:48 <coling> It's not stateful and generally causes problems with unpausing things when phone calls come in etc.
23:31:50 <mkbosmans> (still without flat volumes on the upcoming 11.04)
23:32:11 <coling> Really? Still no FV?
23:32:18 <coling> Shame :(
23:32:42 * coling is most annoyed about the libcanberra patch they did tho'.....
23:32:53 <coling> breaking the spec and wasting hours of my time :(
23:33:01 <mezcalero> coling: can you explain what the issues with x11-cork are?
23:33:17 <mezcalero> and what's wrong with the default resampler? i.e. speex?
23:33:27 <mkbosmans> I did see quite some patches from the BSDs, some of them where similar between netbsd and freebsd
23:33:36 <coling> mezcalero, well when skype gets a call, and you happen to have your music player paused, then the call will result in your music being unpaused.
23:33:36 <mkbosmans> I guess they should be upstreamed somehow
23:33:43 <mkbosmans> (sorry for hijacking the topic)
23:33:53 <Ford_Prefect> The same problem happens on the N900, btw
23:34:02 <mezcalero> coling: hmm, i guess somebody should look into the new mpris for that
23:34:27 <Ford_Prefect> (cork-music-on-phone can't differentiate between user-paused streams and streams it corks)
23:34:43 <coling> mezcalero, well once 1.0 is out I can fix in KDE easily. But with Gnome I'm not sure.
23:34:56 <coling> Ford_Prefect, how about a magic property in the proplist?
23:35:24 <coling> But that's different from the actual x11 keysym generation hack.
23:35:33 <Ford_Prefect> coling: I suspect to do it right, the module needs to track stream corking/uncorking intelligently
23:36:02 <coling> Yeah, that's what I meant... the module could put in a property to aid that tracking.
23:36:23 <coling> e.g. module-cork-on-phone.corked = true
23:36:34 <Ford_Prefect> But then you might unpause-pause manually after
23:36:41 <Ford_Prefect> And something needs to track when that happens
23:36:46 <coling> True...
23:36:53 <coling> Ah well, simple = not good enough
23:36:59 <coling> Can be done tho' obviously.
23:37:23 <coling> Anyway, can x11-cork module be not loaded by default?
23:37:45 <coling> Generally speaking it causes more problems (i.e. unexpected behaviour) than it solves.
23:37:52 <coling> (from my experience)
23:38:10 <coling> (and the bug reports I dealt with and still deal with for other distros)
23:38:18 <coling> We've commented it out for ~2 releases now.
23:38:32 <coling> So I'd like to make this official
23:38:39 <coling> mezcalero, what says you?
23:38:50 * coling is getting sleepy so would like to wrap this up
23:39:05 <mezcalero> coling: "your distro" is that mandriva or mageia?
23:39:22 <coling> bit of both but likely more mageia
23:39:36 <mezcalero> well, dunno, if ik am not too opinionated on that
23:39:41 <mezcalero> i know that some embedded folks use it
23:39:53 <mezcalero> maybe this is something to keep in as a showcase by default?
23:39:53 <coling> But if I talk about past, we == mandriva, and future we == mageia (and maybe mandriva too)
23:39:58 <mezcalero> even if distros disable it?
23:39:59 <coling> :p
23:40:22 <mezcalero> but, do as you wish, if you have a strong opinion
23:40:36 <mezcalero> much more appreciated of course would be to hook this up to mpris instead ;-)
23:40:50 <coling> I'm not overly opinionated, but I've had to advice suse and ubuntu about the problems it causes, so I'd rather it was "official" advice.
23:41:20 <coling> mezcalero, yeah, I'm hoping someone from ubuntu (e.g. ronoc or diwic) will do that seeing as their sound menu stuff is based on that...
23:41:20 <mkbosmans> make it commented out in default.pa then
23:41:40 <coling> mkbosmans, it's in start-pulseaudio-x11 so harder to find for distros/those not familiar.
23:42:19 <coling> OK
23:42:26 <mezcalero> btw, i am prepping a new lc release as we speak
23:42:31 <mezcalero> it's all gnome3 now
23:42:41 <coling> mezcalero, can you put some comments next ot the FALLBACK_THEME define?
23:42:48 <Saviq> oh so I won't have to remove the .so anymore? ;)
23:42:50 <coling> Just to make the ubuntu patch fail....
23:42:54 <coling> :p
23:42:58 <coling> And to stop them doing it again.
23:43:02 <mezcalero> if somebody cares about an updated version that works with gnome2 as well, that is doable, but i am too lazy
23:43:14 <mezcalero> Saviq: remove?
23:43:24 <mezcalero> coling: ubuntu patch?
23:43:36 <coling> mezcalero, see my mail on libcanberra-devel
23:43:44 <mezcalero> there was an ubuntu patch?
23:43:48 <mezcalero> to lc or to the theme?
23:43:50 <Saviq> mezcalero: for some time now (jhbuilding gnome-shell) I've had to drop the canberra .so file due to some broken symbols
23:44:02 <mezcalero> Saviq: that's already fixed in .27
23:44:03 <Ford_Prefect> mezcalero: gnome2 version would be nice, imo, because there's a large likelihood that people might want to stay with it for a while
23:44:04 <coling> mezcalero, they redefined FALLBACK_THEME and thus broke the implementation of the Sound Theme Spec.
23:44:04 <mezcalero> or not fixed
23:44:07 <mezcalero> just worked around
23:44:15 <mezcalero> Saviq: but i am pushing out .28 now
23:44:15 <Saviq> cool
23:44:31 <mezcalero> Ford_Prefect: yupp, welcome to do the patch then... ;-)
23:44:35 <mezcalero> Ford_Prefect: it's not much work
23:44:39 <mezcalero> story goes like this:
23:44:50 <mezcalero> the login and gdm ready sounds are generated via .desktop files
23:44:52 <coling> mezcalero, a comment above the FALLBACK_THEME that reads: /* Please do not redefine the FALLBACK_THEME define, it's part of the spec */
23:44:55 <coling> Or similar
23:45:04 <mezcalero> that are autostarted when the respective session begins
23:45:20 * nirbheek would like to point out that there is no problem with libcanberra built with ./configure --enable-gtk --enable-gtk3 reported by anyone in Gentoo
23:45:26 <mezcalero> now, those .desktop autostart files have some magic in it so that g-s skips them if some gsettings key isn*t set
23:45:36 <mezcalero> this used to be a gconf key
23:45:43 <mezcalero> i dropped the gconf key check
23:45:48 <mezcalero> replaced it by a gsettings key
23:46:00 <mezcalero> since only one rule can be added to the .desktop files
23:46:11 <coling> #agreed coling to decide on the x11-cork request stuff
23:46:15 <mezcalero> so, if people do care about gnome2 a thinkable fix is to always ship two versions of the .desktop files
23:46:26 <mezcalero> and somehow ensure that one is used in gnome2 only and the other in gnome3
23:46:44 <mezcalero> and then the gnome2 version would check the gconf key and the gnome3 version would check gsettings
23:47:03 <mezcalero> but i am too lazy to test that and do the work, as for fedora gnome3 is the only thing we care about
23:47:20 <mezcalero> nirbheek: hmm?
23:47:37 <nirbheek> mezcalero, replying to Saviq's datapoint about having to delete the gtk module manually
23:47:45 <Ford_Prefect> mezcalero: okay, I should be on gnome2 for another month or so, so if I can get to it by then or prod nirbheek into doing it, it'll be done :)
23:48:00 <nirbheek> That was a problem caused by local installations, aiui
23:48:00 <mezcalero> coling: have a link to that patch?
23:48:09 <coling> It's an all in one type thing...
23:48:12 <mezcalero> coling: this is moronic
23:48:18 <coling> mezcalero, yes.
23:48:24 <coling> mezcalero, I was rather annoyed when I found it.
23:48:27 <nirbheek> i.e., users doing make DESTDIR=something install, and an update leaving the old one around
23:48:53 <coling> (had spent ages debugging why the "Front Left" test sounds were not working for a Kubuntu user in my Speaker Setup thing)
23:49:03 <coling> (and eventually traced it to this)
23:50:15 <coling> http://archive.ubuntu.com/ubuntu/pool/main/libc/libcanberra/libcanberra_0.26-1ubuntu10.diff.gz
23:50:38 <nirbheek> mezcalero, fwiw, I don't think the gnome2 vs gnome3 thing will be a runtime problem in libcanberra since it's currently not possible to have both GNOME 2.32 and GNOME 3.0 installed at the same time.
23:50:39 <coling> Just search for FALLBACK_THEME in there.
23:51:16 <mezcalero> fuck, this ubuntu patch is full of fuck
23:51:37 <mezcalero> and zero comunication with upstream about this
23:52:18 <coling> I wouldn't expect comms with upstream as it's customisation for Ubuntu... just that it's *invalid* customisation that I object to.
23:52:39 <mezcalero> the g_atexit() madness is upsetting me much more
23:52:49 <mezcalero> yeah, and i'll get the blame
23:52:53 <mezcalero> i asked them not to add that
23:53:00 <mezcalero> that it won't work
23:53:02 <coling> Anyway, have we got time to discuss CI or shall I just end the meeting now?
23:53:14 <mezcalero> CI?
23:53:17 <mezcalero> ah, uh
23:53:20 <mezcalero> what's planned?
23:53:35 <mkbosmans> coling, aside: perhaps you can add an # action for yourself about adding a roadmap/todo/GSoC/help wanted page to the wiki. (you mentioned it some hours ago in the source output per-stream volume control topic)
23:53:43 <krtaylor> Iwas thinking like bamboo, buildbot or the like - I dont have a preference for the tool, but a build and sniff test after a checkin is a really good idea
23:53:53 <mezcalero> is anybody from ubuntu still around?
23:53:56 <coling> #topic Continuous Automated Build and Integration
23:53:57 <sjoerd> coling: for seperate patch for ubuntu see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/libcanberra/natty/files/head:/debian/patches/ (much easier then the one big one)
23:53:59 <pulsator> Title: ~ubuntu-branches/ubuntu/natty/libcanberra/natty : files for revision 40 (at bazaar.launchpad.net)
23:54:19 <coling> #action coling to add a roadmap/todo/GSoC/help wanted page to the wiki
23:54:22 <coling> :)
23:54:30 <coling> sjoerd, ahh nice
23:54:52 <coling> mezcalero, I think diwic sadly left, but I already discussed with him and he's not to blame :D
23:55:09 <coling> I belive the relevant parties have been poked (I asked a few different people)
23:55:22 <coling> But that's only about the theme, not your other issues.
23:55:25 <mezcalero> coling: that g_atexit must go
23:55:28 * sjoerd should really update canberra in debian
23:55:44 <Ford_Prefect> krtaylor: what do you need for setting this up?
23:56:03 <mezcalero> coling: 2 patches they did are fucked, the 3rd one should go upstream
23:56:31 <mezcalero> krtaylor: i have no clue about CI
23:56:34 <krtaylor> Ford_Prefect, I have used bamboo in other project, but I have never set it up - I don't have a feel for how hard it would be
23:56:38 <mezcalero> what is this really about?
23:56:48 <mkbosmans> I'm planning on using the OpenSuse BuildService (its not just for suse) for the Windows build. Currently I have only one pulse package there (from my github branch), after 1.0 it will have a separate package for the latest stable release, latest unstable/beta release and perhaps git master.
23:56:54 <mezcalero> just running tests on each commit?
23:56:55 <mkbosmans> thats not really CI though
23:56:56 <Ford_Prefect> mezcalero: basically make sure that build and all tests pass with every commit
23:56:59 <mkbosmans> just automated builds
23:57:08 <mezcalero> Ford_Prefect: and what happens if it doesn't?
23:57:26 <mezcalero> and, why wouldn't one want this?
23:57:28 <Ford_Prefect> (I assume that's it, krtaylor can correct me if I missed something, maybe build images?)
23:57:40 <Ford_Prefect> mezcalero: lots of loud noises and notification
23:57:48 <krtaylor> different tools do different things, but basically it automatically builds with each checkin and runs some basic sniff test
23:57:50 <Ford_Prefect> mezcalero: presumably it's a question of time and infrastructure
23:57:56 <mezcalero> Ford_Prefect: well, i think i have shown, that i have no trouble ignoring mails ;-)
23:58:01 <Ford_Prefect> I assume krtaylor is volunteering the time :D
23:58:13 <Ford_Prefect> mezcalero: :p
23:58:15 <mezcalero> krtaylor: so, yupp, go ahead, i figure you need some hook in the git repo?
23:58:26 <krtaylor> I would be able to help, the prob is equipment
23:58:33 <mezcalero> krtaylor: to get a notification when things change?
23:58:48 <sjoerd> with recent buildbots you don't even need hooks in the git repo
23:58:53 <mezcalero> krtaylor: uh, my server is already constantly under > 1.0 load
23:59:04 <sjoerd> it can just poll the git tree every 15 minutes or so
23:59:10 <Ford_Prefect> I wonder if fd.o folks can help with that?
23:59:18 <sjoerd> Ford_Prefect: we can ask
23:59:21 <coling> Indeed.
23:59:37 <coling> OK so if anyone sets up CI we'll do what we can to support it.
23:59:39 <Ford_Prefect> If not, we can potentially hammer my Linode :D
23:59:41 <sjoerd> i wouldn't have an issue of having come of the buildslaves ccu has also build pulseaudio
23:59:50 <coling> Cool.
23:59:52 <sjoerd> we already are buildslaves for telepathy and webkit so
23:59:58 <sjoerd> just needs a build master somewhere
00:00:04 <sjoerd> which could run on fd.o i guess?
00:00:19 <Ford_Prefect> What's a build master?
00:00:22 <sjoerd> i can check with Mithrandir/daniels to see what they think of it
00:00:39 <krtaylor> I'll look into it, I have friends that have set it up - I'll summarize and send email to the list
00:00:41 <elmarco> Ford_Prefect: the thing that control the salves, ofc!
00:00:45 <sjoerd> Ford_Prefect: basically it's the thing the keeps an eye on the repos and pokes the slaves
00:00:56 <sjoerd> and usually has the overview web interface et c
00:01:07 <Ford_Prefect> elmarco: it's 0530, cut me some slack :p
00:01:07 <coling> #agreed  if anyone (e.g. krtaylor or sjoerd) sets up CI we'll do what we can to support it (i.e. with git hooks etc.)
00:01:23 <coling> Jeeze Ford_Prefect I didn't realise it was *that* late :D
00:01:29 <coling> I think it's time to end....
00:01:38 <coling> #endmeeting