17:08:25 <coling> #startmeeting
17:08:25 <pulsator> Meeting started Thu Feb 24 17:08:25 2011 UTC.  The chair is coling. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:08:25 <pulsator> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:08:47 <coling> #topic PulseAudio Development and Roadmap Meeting
17:08:58 <coling> OK
17:08:59 <KevinB> #help
17:09:06 <coling> Hello everyone
17:09:11 <diwic> Hi there!
17:09:19 * Ford_Prefect waves to all :)
17:09:31 <vinio> Hi, nice to talk to you Col
17:09:38 <coling> In case you didn't spot the previous topic, there is a meeting agenda here: http://pulseaudio.org/wiki/Meetings/2011-02-24
17:09:39 <pulsator> Title: Meetings/2011-02-24 – PulseAudio (at pulseaudio.org)
17:09:44 <maggie_> hi :)
17:10:17 <coling> I'll be using the meetbot to take notes and chair the discussions. After we're done, there will be notes automatically posted online.
17:10:23 <tanuk> KevinB: Check out http://wiki.debian.org/MeetBot - #help doesn't provide help on the bot.
17:10:24 <pulsator> Title: MeetBot - Debian Wiki (at wiki.debian.org)
17:10:43 <coling> Generally speaking you wont need to worry too much about the bot.
17:10:44 <mezcalero> i for one welcome or new irc bot overlords
17:11:03 <coling> #agree we all welcome our irc bot overlord
17:11:18 <coling> :)
17:11:26 <diwic> coling, thats "agreed"
17:11:37 <coling> diwic, should be a synonym
17:12:07 <coling> but didn't give me any feedback, so will use agreed
17:12:08 <coling> ANyway
17:12:15 <coling> On with the discussion.
17:12:24 <coling> Lets start at the top :)
17:12:28 <urkle> according to manual.. agree is synonym to agreed :)
17:12:56 <coling> So, git master is pretending to be something approaching v1.0
17:13:07 <coling> But it's been bumbling along like that for some time now.
17:13:21 <coling> We need to discuss what features will go into 1.0 and the approximate release schedule.
17:13:51 <mezcalero> the volume ramping tsuff in git master needs fixing before it can be relased
17:14:00 <coling> With regards to the passthrough stuff Pierre and Ford_Prefect have worked on, I think it's on track to be usable pretty soon, is that correct.
17:14:07 <mezcalero> so this needs to be backed out or i need to get off my ass
17:14:19 <coling> mezcalero, how much work do you think is needed there?
17:14:40 <Ford_Prefect> I expect passthrough to be done (coded, tested, reviewed) in about a month
17:15:10 <coling> #info passthrough to be done (coded, tested, reviewed) in about a month
17:15:18 <mezcalero> coling: well, the vol ramp stuff was the last major thing i wroked on before disappearing into systemd land
17:15:23 <mezcalero> coling: and it was hard
17:15:48 <mezcalero> coling: so hard that this new systemd thing was so much shinier and simpler to hack on...
17:16:08 <mezcalero> coling: i'd probably back it out for now
17:16:16 <Ford_Prefect> It would be nice to have that since we need it for crossfading
17:16:21 <coling> mezcalero, you will have to be reassimilated at some point :p
17:16:23 <mezcalero> well, but not the current code
17:16:46 <mezcalero> the current code is not wirtten in a way that it actually knows in which context it is run
17:17:01 <mezcalero> i.e. there's RT code touching non-RT data
17:17:04 <mezcalero> and vice versa
17:17:14 <mezcalero> the seperation is not clear, and this will blow up in our faces
17:17:24 <mezcalero> the reason it was so hard
17:17:38 <coling> OK, so the 1.0 plan will see it removed/disabled.
17:17:39 <mezcalero> is mostly that i tried to fix a much bigger project, i.e. filters you can plug into sinks and streams
17:17:58 <mezcalero> of which the ramping should have been one of
17:18:14 <mezcalero> but i got lost in trying to get rewinding work in a somewhat sensible way in those filters
17:18:45 <mezcalero> because filters tend to have block sizes
17:18:48 <mezcalero> and yupp
17:19:00 <mezcalero> anyway, i think the only sensible thing to do is  back those patches out for now
17:19:12 <mezcalero> fork of something from master, and remove these patches
17:19:13 <coling> mezcalero, sounds like there simply wont be enough time to deal with anything positive related to that in any short-term scale, so back them out it will be
17:19:44 <coling> mezcalero, OK, so will you be able to do that do you think? Or would you prefer someone else to do it?
17:20:11 <coling> I would personally rather the patches are removed from master and reapplied in a separate branch that can be merged again later.
17:20:14 <mezcalero> coling: well, basically F15 is dictating my time
17:20:25 <coling> (the current mess in git for the 0.9.x branch stems from not doing this)
17:21:11 <tanuk> I agree. I'd like to keep unreleasable code outside master.
17:21:18 <mezcalero> coling: http://cgit.freedesktop.org/systemd/tree/TODO ← that's my todo list for F15, when I am done with all that work I will do more on PA than I have been doing the past months
17:21:20 <pulsator> Title: systemd - System and Session Manager (at cgit.freedesktop.org)
17:21:29 <mezcalero> but then again i promised something like that a couple of times already
17:21:35 <mezcalero> and never really held it
17:21:41 * mezcalero hides ashamed
17:21:48 <sjoerd> Having git master in a constantly basically releasable state would be great indeed
17:21:57 <coling> #agreed Volume ramping will be removed from git master and reapplied in a feature-branch
17:22:12 <mezcalero> ok
17:22:33 <coling> OK, but someone needs to do that work. Any takers? Ford_Prefect tanuk perhaps?
17:22:41 <mezcalero> from my perspective the ramping is the only blocking thing for master
17:22:49 * Ford_Prefect is okay with taking it up
17:22:51 <mezcalero> but i need to have a closer look
17:23:05 <mezcalero> yupp, would be cool if Ford_Prefect would do that
17:23:16 <mezcalero> but what i really want to do is go through master
17:23:25 <mezcalero> and figure out if there are any other major problems
17:23:30 <coling> #action Ford_Prefect will look to remove the volume ramping stuff (remporarily) from git master and move it to a feature branch
17:23:37 <mezcalero> and i will do that, you can count on that, in the coming week
17:23:42 <coling> mezcalero, that would be nice.
17:23:57 <coling> #action mezcalero to give an assessment of git master stability
17:24:01 <coling> #undo
17:24:01 <pulsator> Removing item from minutes: <MeetBot.items.Action object at 0x8e163ec>
17:24:07 <coling> #action mezcalero to give an assessment of git master stability in the coming week
17:24:17 <coling> Just to tie you to that :D
17:24:23 <Ford_Prefect> >:)
17:24:43 <coling> OK, so lets move on.
17:24:47 <coling> #topic DBUS support
17:24:53 <coling> tanuk are you here?
17:25:03 <tanuk> Yes, I'm here.
17:25:12 <coling> What is the current state of the DBus Support in g-m? Is there any major blocker to releaseing it as 1.0?
17:25:59 <tanuk> I don't have anything against releasing 1.0 with the current stuff in.
17:26:03 <coling> (diwic you're next on topics just so you're ready!)
17:26:27 <tanuk> But I have a lot against making the D-Bus interface official.
17:26:58 <coling> tanuk, awesome. I think that's acceptable - we can ensure that this is emphasised in the release notes.
17:27:07 <coling> Is anyone against this?
17:27:12 <diwic> Can we ship it as disabled by default?
17:27:13 <mezcalero> nope
17:27:29 <coling> i.e. version 1.0 will ship with a "preview" of dbus protocol support (subject to change)
17:27:31 <diwic> Or rather /should/ we disable it by default?
17:27:32 <mezcalero> i can live with releasing it and declaring it unofficial
17:27:57 <mezcalero> btw, one of the biggest issues i had with the dbus stuff, was the weirdness regarding dbus per-session and pa per-user
17:28:10 <mezcalero> but that's most likely going to be fixed on the dbus side soonishly
17:28:15 <mezcalero> there's going to be a user bus
17:28:25 <mezcalero> maintained by systemd automatically
17:28:32 <coling> mezcalero, yeah figured that would be something that would bubble up to PA. Nice work.
17:28:42 <mezcalero> hence the weirdness will go away, and we have little to fix in PA
17:29:23 <mezcalero> it's only going to be fixed for systemd users however. Sorry ubuntu ;-)
17:29:41 <coling> OK good. Re diwic's comments, I think that dbus protocol can be disabled right? The decision about whether it should be can be left for later I think :)
17:29:45 <tanuk> So we'll just use the session bus. Until everyone uses the "single user session" model, multiple simultaneous logins won't work well, but I guess that's not a big deal.
17:30:08 <coling> #agreed DBus support will be included in 1.0. It will be clearly labelled as a preview and not finalised/subject to change etc.
17:30:15 <mezcalero> tanuk: the session bus will be redirected to the user bus by default on fedora, and we ask others to do that too
17:30:38 <mezcalero> tanuk: so we officially break multiple logins that way, unless people disable this redirection, but then they are on their own
17:30:58 <coling> OK, next...
17:30:59 <coling> #topic Mixer Rewrite
17:31:09 <coling> diwic has some patches available for review.
17:31:26 <mezcalero> hmm, in the wiki there was a link to a mail with a link to some .debs
17:31:27 <diwic> They are in ubuntu 11.04 since a week back.
17:31:37 <coling> I don't think it's overly controvertial, so it should be in 1.0 without any problem.
17:31:39 <mezcalero> but i want to see the code
17:31:43 <mezcalero> hmm
17:31:46 <mezcalero> not so quick ;-)
17:31:52 <coling> Hmm, I guess I didn't like the patches.
17:31:53 <diwic> mezcalero, patches have been posted as well
17:32:02 <mezcalero> diwic: link?
17:32:10 <Ford_Prefect> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-January/008716.html
17:32:11 <pulsator> Title: [pulseaudio-discuss] [PATCH] Pulseaudio input mixer rewrite (at tango.0pointer.de)
17:32:24 <mezcalero> i think you mentioned something regarding renaming "mic 1" to "mic front"
17:32:29 <mezcalero> i actually did that on purpose
17:32:44 <diwic> I'm hoping to get the mixer rewrite into stable-queue even
17:32:54 <mezcalero> because on more drivers than not things are not wired up as the mixer suggests
17:32:58 <coling> I think the archive kills the patches :s
17:33:25 <mezcalero> hence just calling things "mic 1" and "mic 2" instead of "mic front" takes away the pressure from us to fix those drivers
17:33:31 <diwic> mezcalero, but then I've been committing kernel patches for 2.6.38 to fix some of that up, and for the rest my mileage varies from yours.
17:33:38 <coling> mezcalero, diwic has also been on an alsa fixing quest, getting h/w labelled properly etc.
17:34:02 <mezcalero> diwic: but, uh, it really depends on a laptop manufacturer to wire things up
17:34:19 <mezcalero> diwic: i.e. you often would need DMI information to be able to know whether something is front or back
17:34:37 <mezcalero> and that kinda of quirk db is nothing we really want to maintain, or do we?
17:34:38 <diwic> mezcalero, on HDA, that's present on the default pin config register, not DMI
17:35:00 <mezcalero> diwic: will, but the information in HDA is information by the chip manufacturer, and usually not correct
17:35:07 <diwic> mezcalero, and yes, there are quite a bit of quirks in the driver for those pin configs
17:35:22 <diwic> mezcalero, it's being set by BIOS usually
17:35:30 <mezcalero> well, "usually"
17:35:38 <mezcalero> but often enough by the .inf data on windows
17:35:41 <mezcalero> or not at all
17:35:48 <diwic> mezcalero, and unusually, we quirk the pins in the HDA driver.
17:35:59 <mezcalero> the question is: do we want to maintain these quirks really?
17:36:19 <mezcalero> i mean, i decided not to bother, and named it "mic 1" and "mic 2" to avoid this maintainence burden
17:36:29 <mezcalero> but then again, if you are willing to maintain this i am fine with this
17:36:39 <coling> Well it would be nicer to users to get them labelled properly
17:36:44 <mezcalero> but you should be aware that this is probably a lot of work
17:36:57 <diwic> mezcalero, I see your point and the only thing I can say is that from what I've seen they are usually correct
17:37:05 <mezcalero> diwic: ok, if you say so
17:37:15 <coling> I think we should go with it.
17:37:25 <coling> If it turns out we get a lot of complaints we can just switch back.
17:37:33 <mezcalero> that's probably true
17:37:43 <diwic> or maintain the rewrite and just change the aliases
17:37:46 <mezcalero> hmm, but i would love to see the patches..
17:37:48 <coling> But like jack-detection (more on that later), this will perhaps provide the push needed to do those fixes.
17:38:01 <coling> mezcalero, they are on the list.
17:38:04 <diwic> mezcalero, I'll post a new link after the meeting
17:38:06 <mezcalero> that mail doesn't include patches
17:38:22 <coling> Hmm, OK, well there are there somewhere.
17:38:22 <mezcalero> diwic: what else does the mixer rewrite change?
17:38:58 <coling> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/8317
17:39:00 <pulsator> Title: Gmane Loom (at thread.gmane.org)
17:39:11 <diwic> mezcalero, well, hopefully it should actually move things such as "Front Mic Boost" e g
17:39:20 <diwic> which current code doesn't
17:39:23 <mezcalero> diwic: btw, i do appreciate your work on this quirk stuff a lot. It's the kind of stuff i never wanted to do, and I know how much work that is
17:40:11 <diwic> mezcalero, thanks. And yeah, you'll have the patches at coling's link there
17:40:39 <coling> mezcalero, that mail does have patches, but not on the archive link as mailman strips them... not very handy fwiw... we can discuss that later when we get to infrastructure :D
17:41:07 <mezcalero> ok, the patches look pretty ok, otherwise, but i just had a rough browse through it
17:41:27 <mezcalero> coling: yeah, i kinda would like to move PA to fdo anyway... ;-)
17:41:38 <coling> mezcalero, wait for the topic :D
17:41:44 <mezcalero> sure
17:41:48 <coling> hehe
17:41:50 <coling> OK, so
17:41:53 <mezcalero> anyway, yeah, i guess this mixer stuff is good for master
17:42:01 <coling> #agreed we'll push the mixer stuff for 1.0
17:42:08 <coling> #action coling to merge the patches in
17:42:14 <coling> #undo
17:42:14 <pulsator> Removing item from minutes: <MeetBot.items.Action object at 0x8e148ec>
17:42:27 <coling> #action coling to merge diwic's mixer rewrite
17:42:43 <coling> #topic AEC
17:42:48 <coling> OK, so echo cancellation
17:42:53 <mezcalero> coling: i'll review master after the mixer stuff is merged
17:42:55 <coling> Not sure there is much to discuss here really
17:43:08 <coling> mezcalero, OK, I'll do that over the w/e or tonight then.
17:43:21 <Ford_Prefect> AEC status: I think it's good to ship, though we need more testing and potential tweaking
17:43:38 <coling> Am I right in saying that AEC is used magically for "phone" streams?
17:43:45 <Ford_Prefect> On a local network it works well, recently tried it on a proper call over the internet and it was not so good
17:43:46 <coling> (or was that just something someone suggested?)
17:43:51 <Ford_Prefect> coling: correct
17:44:30 <coling> Ford_Prefect, so at present the likes of Skype do not enable their own built in AEC, so this is OK, but what if they were to enable it? Should we define a way to disable it? Like a magic property?
17:44:58 <Ford_Prefect> coling: can do, and makes sense
17:44:59 <mezcalero> i think AEC should be merged, and then i'll have a look at it later on when reviewing master
17:45:10 <Ford_Prefect> mezcalero: it's in master already :)
17:45:11 <coling> AEC is alreayd in master so it's all good.
17:45:28 <coling> #agreed AEC will make it into 1.0
17:46:06 <coling> #action Ford_Prefect and coling to investigate a way to disable magical AEC enabling for "phone" streams
17:46:11 <sreeves1> Ford_Prefect: when you say "it was not so good" over the internet what do you mean
17:46:43 <Ford_Prefect> sreeves1: the echo wasn't cancelled well enough until I tweaked some params, at which point it just got attenuated sufficiently to not be too annoying (but introduced more lag)
17:47:01 <coling> #topic Volumes go up to +11dB
17:47:06 <coling> OK, moving on.
17:47:07 <mezcalero> up to 11? haha
17:47:16 <coling> This is just me being lazy.
17:47:35 <mezcalero> oh shit i closed the wiki page, what was the url again?
17:47:46 <coling> I meant to do this a while ago but will put in the +11dB "overdrive" define to allow us to push the "150%" overdrive out to clients so we get more standard support.
17:47:48 <Ford_Prefect> mezcalero: http://pulseaudio.org/wiki/Meetings/2011-02-24
17:47:50 <pulsator> Title: Meetings/2011-02-24 – PulseAudio (at pulseaudio.org)
17:47:55 <mezcalero> thanks
17:48:26 <coling> mezcalero, we agreed on this a while ago so shoulnd't be an issue. I'll just define a PA_VOLUME_OVERDRIVE being +11dB which is pretty near to the current g-v-c of 150%.
17:48:50 <coling> Is everyone happy with the define name? "Overdrive" is maybe not the best term?
17:48:51 <mezcalero> yupp, i am fine with adding this, but please do not redefine PA_VOLUME_MAX
17:48:58 <mezcalero> is "overdrive" the right name for this btw?
17:49:05 <mezcalero> i am not a native speaker
17:49:07 <coling> exactly :)
17:49:16 <diwic> softvol_max?
17:49:33 <mezcalero> but it sounds so "cpu clock overdriver" SUPER DUPER FAST YAY UBUNTU
17:49:35 <mezcalero> oops
17:49:38 <mezcalero> YAY GENTOO i meant
17:49:49 <coling> :p
17:49:50 <coling> how aobut PA_COLUME_RECOMMENDED_MAX?
17:50:02 <mezcalero> http://funroll-loops.info/ ;-)
17:50:03 <pulsator> Title: Welcome to Gentoo is Rice, the Volume goes to 11 here. (at funroll-loops.info)
17:50:09 <coling> except maybe spell volume correctly....
17:50:28 <mezcalero> coling: yep, sounds good, or maybe call it UI_MAX?
17:50:36 <mezcalero> coling: PA_VOLUME_UI_MAX?
17:50:44 <coling> Is everyone happy enough with that?
17:50:49 <diwic> +1 for ui_max
17:50:49 <mezcalero> after all this is simply and only to show in the UI
17:50:52 <tanuk> I vote for UI_MAX.
17:50:58 <coling> OK
17:51:05 <mezcalero> nice
17:51:13 <coling> #agreed Software volume define will be PA_VOLUME_UI_MAX
17:51:27 <coling> #action coling to add defines and such like for PA_VOLUME_UI_MAX
17:51:42 <coling> #topic Dealing with Profiles, Ports and Virtual Sinks (in GUIs)
17:51:49 <coling> OK, so let me explain this one.
17:51:57 <coling> We are now getting a fair few "filter sinks"
17:51:57 <mezcalero> coling: and make sure to explain that PA_VOLUME_UI_MAX is no technical limit, just a recommendation for UIs
17:52:05 <coling> mezcalero, noted
17:52:26 <coling> #action coling to make sure to explain that PA_VOLUME_UI_MAX is no technical limit, just a recommendation for UIs
17:52:45 <mezcalero> coling: that wiki page about writing mixes probably needs some minor updating then, too
17:53:04 <coling> #action coling to update wiki page about volume control uis
17:53:24 <coling> With all these filter sinks, UIs can become rather clumsy and confusing.
17:53:38 <coling> E.g. for the equalizer sink and for aec etc.
17:53:59 <mezcalero> coling: well, my plan for that was the filter stuff i worked on and i mentioned in context of the vol ramp stuff
17:54:05 <mezcalero> coling: but i never finished it
17:54:13 <mezcalero> it's a bit disappointing, i know
17:54:15 <coling> In many ways we almost want to hide these sinks and present the UI with "stream options" that relate to the sinks they are currently attached to.
17:54:32 <coling> These stream options are really just a wrapper around moving the stream to the appropriate sink.
17:54:55 <coling> But the GUIs could be presented to the user the mask this internal function.
17:55:24 <coling> e.g. show a sink and find all the filter sinks attached to it. Hide these filter sinks, but show them as "stream options" in the GUI for streams working with the sink.
17:55:34 <coling> Not sure I'm describing this properly, but I think this would work rather well.
17:55:41 <mezcalero> coling: hmm, i think this is already doable
17:55:46 <coling> Indeed.
17:56:01 <mezcalero> coling: we have a prop for sinks that inform the clients that something is just a sink on top of another sink
17:56:06 <mezcalero> coling: uis could follows this
17:56:07 <coling> It's more to just discuss if this is an appropriate "solution"
17:56:14 <mezcalero> well, i guess it is
17:56:23 <mezcalero> i mean, in the long run when i finish the filter stuff
17:56:24 <coling> OK, so there is a little more.
17:56:28 <mezcalero> then we can plug in stuff into streams
17:56:30 <mezcalero> not only sinks
17:56:31 <mezcalero> but
17:56:47 <coling> mezcalero, in that case would it be worth defining an API for this?
17:56:48 <mezcalero> often enough it is a good idea to still keep around a seperate sink that sits on top of another and adds a filter
17:57:01 <mezcalero> simply to minimize cpu load
17:57:14 <mezcalero> since applying a filter once, in a sink, is hceaper than twice in two streams
17:57:18 <mezcalero> if you follow what i mean
17:57:22 <coling> mezcalero, and then we could impelement it behind the API as I suggest just now, and move it across to the "cleaner" future internal workings without chaging things at the client side?
17:57:36 <mezcalero> so, even if the filter stuff comes one day, i think doing what you suggest in the UI will continue to be useful
17:57:47 <coling> OK, that's fine then :)
17:57:59 <coling> The next point on this topic is somewhat related.
17:58:11 <mezcalero> well, i am not sure we should discuss the APIs of stuff that is mostly vaporware right now, which my filter stuff is
17:58:29 <coling> With card profiles and sink/source ports, it's sometimes useful to know ahead of time what will be possible if the profile/port is activated.
17:58:35 <mezcalero> coling: so, yepp, sounds good if this property is used how ou suggested in the mixer clients
17:58:59 <mezcalero> urks
17:59:03 <mezcalero> that's a big topic ;-)
17:59:21 <coling> I'd like to extend the info returned from card profiles particularly, to give the names, icons and descriptions of the sinks/sources that would be made available if they were activated.
17:59:54 <coling> This is based on the work I did with module-device-manager which keeps track of devices it's seen but may not currently be active.
17:59:58 <mezcalero> coling: how would you encode that?
18:00:25 <coling> not sure about the code, but probably in the card-info in some capacity.
18:00:35 <mezcalero> coling: the reason this is currently not really done is that i was afraid about thinking about an encoding for all of this
18:00:38 <coling> (e.g. extend available profiles)
18:00:49 <mezcalero> coling: but the data structures for that are complex
18:01:13 <coling> All I'd really expect is that for each card profile it would list the sinks and sources it enables.
18:01:41 <mezcalero> well, you probably want props with that, right?
18:01:46 <mezcalero> and sometimes it is really hard to get those
18:01:54 <mezcalero> it's a reall difficult problem
18:02:02 <coling> Well in an ideal world yes, but really all I need for UI's is name, description and icon.
18:02:04 <mezcalero> and adds a lot of complexity, just for one drop down box ;-)
18:02:24 <mezcalero> but yupp, i won't stop you from working on that
18:02:32 <mezcalero> it's the kind of work i just pussied our from doing ;-)
18:02:36 <mezcalero> s/our/out
18:02:46 <coling> This is all the info module-device-manager captures just now anyway.
18:02:58 <coling> And it's all that's really needed to produce a nice UI.
18:03:03 <coling> OK, cool.
18:03:29 <coling> #agreed coling can extend card info to include name, description and icon of sinks/sources enabled in that profile.
18:03:36 <coling> I'll leave it there then.
18:03:51 <coling> I could talk about this some more but I think this is enough for now :)
18:04:00 <coling> #topic Priority Lists
18:04:09 <coling> OK so we agreed before mezcalero that these would go into core.
18:04:17 <coling> I'm happy to do that work with your blessing.
18:04:35 <coling> But I may need to pester you about exactly how you want it implemented should I run into issues.
18:04:52 * mezcalero is getting hungry
18:04:52 <coling> You did say you'd do it but I suspect it's not worth my while waiting? :p
18:05:13 <mezcalero> coling: yupp, i suck ;-)
18:05:23 <coling> :)
18:05:32 <mezcalero> coling: well, yupp, i can write something up
18:05:42 <mezcalero> coling: pester me a couple of times the coming week
18:05:49 <coling> OK
18:05:51 <mezcalero> coling: and when i have enough i'll write it ;-)
18:06:08 <tanuk> coling: Did I understand it correctly that the only thing that goes into the core is the priority list structure, and manipulating is pushed entirely to modules (well, there's probably some simple fallback policy, but usually that wouldn't be used)?
18:06:29 <coling> #action mezcalero to write up a "recommendation" as to how he'd like the priority lists done in core (will take some pestering)
18:06:43 <coling> tanuk, I'd say there is still scope for flexibility there.
18:06:59 <mezcalero> tanuk: what i want to emphasize this is that normally things are done automatically, and thjings are just a stack where the uppermost matching rule is used. on KDE this stack would then be accessible to apps too
18:07:19 <mezcalero> tanuk: and kde apps could fiddle and rearrange the stack
18:07:46 <coling> tanuk, IMO I'd like to see some "policy" modules - like module-intended-roles, only maniupulate the lists and let the core routing do it's job (e.g. they'd be responsible for initially inserting the devices at the right end of the prio list, but let users override this if so desired)
18:08:07 <mezcalero> that fiddling api could be in the general api even, but it's something that normal (i.e. gnome clients) will never use and would never have to use
18:08:49 <coling> But I wouldnt' want to prevent other modules from doing the routing too if absolutely needed. I'll leave scope for that.
18:09:23 <coling> #action coling to implement prio lists after getting mezcalero recommended approach from him (likely post 1.0 tho')
18:09:32 <coling> Right next!
18:09:41 <coling> #topic per-stream vol control for source outputs
18:09:53 <coling> Do we all agree this is desirable now that flat volumes are implemented?
18:10:29 <coling> If so does anyone want to do that? I did make a start on it (have a branch somewhere) but the volume ramping stuff confused me.
18:10:43 <coling> I can perhaps look to rebase it after the ramping stuff is ripped out?
18:11:16 <Ford_Prefect> IIRC there was agreement that per-source volumes would be good to have at some point
18:11:20 <tanuk> I'd like to add "volume readable" and "volume readable" bits to everything: sinks, sources, sink inputs and source outputs.
18:11:39 <coling> #agreed We all want per-stream volumes on source outputs.
18:11:47 <coling> OK, so we can work on this after 1.0
18:11:57 <coling> Perhaps good as a GSoC even....?
18:12:00 <tanuk> From API point of view that would cover per-stream volumes too.
18:12:04 <coling> Maybe not enough meat in it tho'
18:12:06 <mezcalero> yupp, this is a good feature and has long been on my todo list
18:12:26 <tanuk> *per-capture-stream volumes
18:12:33 <coling> OK, well no controversy there.
18:12:40 <coling> Just need someone to do it :)
18:12:42 <diwic> As for GSoC, the formal part of that, I know we can run them at Canonical, but how would that rhyme in with everything else?
18:13:15 <coling> (I'm planning on advertising the "what we want" stuff a bit better so that people can do it, whether for GSoC or otherwise)
18:13:25 <coling> diwic, I'm not sure, perhaps we can discuss this after?
18:13:28 <diwic> ok
18:13:49 <coling> (I've said I'd be mentor for a couple projects but really have no clue about the GSOC admin :p)
18:14:01 <coling> #topic Headphone Jack Detection
18:14:15 <diwic> yeah, that's what I'm currently missing the most
18:14:23 <coling> OK, so this is another thing we probably need to enable to unearth some alsa deficiencies
18:14:31 <diwic> very very likely yes
18:14:42 <coling> The question is, how do we do this.
18:15:07 <coling> I guess the basic premise is make the h/p jack change the sink port right?
18:15:23 <diwic> maybe also hide things
18:15:53 <coling> But if that's the case how do we differentiate between manual port changes and automagic ones? And how would we be able to know what can be hidden?
18:16:28 <mezcalero> so
18:16:39 <diwic> e g just hide HDMI sink if nothing is plugged in the HDMI port
18:16:52 <maggie_> I need hp jack detection for ucm
18:16:52 <mezcalero> last time i talked to takashi about this he wasn't even sure hew wanted to keep the current input system based appraoch
18:17:07 <mezcalero> and wanted to move that into the control api of alsa
18:17:12 <coling> hi maggie_ I was just wondering what nick would be yours :) (I guessed correctly :D)
18:17:12 <mezcalero> what's the newest on that?
18:17:25 <diwic> hide "analog headphones" if there are no hp plugged in etc
18:17:26 <mezcalero> is there now a clear roadmap how jack sensing is supposed to work on the kernel side?
18:17:40 <coling> diwic, do you know about the kernel side much?
18:17:42 <mezcalero> and how matching things up with individual volume controls is supposed to twork?
18:17:53 <mezcalero> this all stands and falls with the kernel side
18:17:56 <diwic> I haven't had that discussion with Takashi but I'm thinking even if it would change, that shouldn't stop us
18:18:17 <maggie_> there are a couple of alsa calls like snd_soc_jack_new
18:18:29 <mezcalero> diwic: i'd prefer to do things the future-proof way though, not some kludge that will day soon anyway
18:18:44 <mezcalero> diwic: i.e. we really should know whether the input stuff or the alsa control stuff is going to be future
18:19:01 <diwic> mezcalero, so make the "kernel detect" mechanism pluggable and leave the rest of the code intact
18:19:22 <mezcalero> diwic: well, but how would you do the match up?
18:19:29 <diwic> maggie_, so the soc has its own jack detection?
18:19:40 <mezcalero> diwic: if the events come in from the alsa control layer matching things up is probably a lot more natural
18:19:51 <maggie_> it reports jack insertion as event
18:20:12 <mezcalero> diwic: but if we need to somehow find to which set of mixer control a specific /dev/input device belongs this is going to be difficult
18:20:43 <diwic> mezcalero, I don't have all the answers at this point. This is something I'd like in Ubuntu 11.10 though
18:21:00 <mezcalero> well, i am fine if somebody works on this
18:21:14 <mezcalero> and if that someone wants to support both mechanisms and this is feasible then he's welcome
18:21:24 <maggie_> I was thinking that in module-udev-detecadd a function t that listens for dev/input device changes
18:21:28 <mezcalero> it's however something that I myself always wanted to wait for ALSA first
18:21:32 <coling> OK, so diwic do you want to try and do some research on this when you have time. maggie_ can perhaps give some input to where it relates to ucm support.
18:21:39 <mezcalero> maggie_: but how do the matching up?
18:21:45 <mezcalero> maggie_: in the general, i.e. desktop case?
18:22:00 <diwic> Have we done our research as of which half-baked implementations are already available?
18:22:31 * coling doesn't really know anything about it - he's too high level :p
18:22:43 <mezcalero> to me it appears as this is something to be supported in the alsa modules themselves, not in a glued on module on top
18:23:16 <mezcalero> i mean, in an ideal case
18:23:18 <diwic> mezcalero, sounds reasonable to put it in module-alsa-card
18:23:28 <mezcalero> the one looking into this would port all drivers to the same interface first
18:23:35 <diwic> or something called by that, yes
18:23:51 * coling spies some wishful thinking from mezcalero ;p
18:23:51 <mezcalero> but i do understand that porting all drivers first is not fun
18:24:12 <mezcalero> so i do think it is acceptible if we tape over this problem for a while by supporting both apis
18:24:19 <Ford_Prefect> Would at least be good to try to get agreement with ALSA folks on the winning solution
18:24:35 <coling> I suspect it'll be a little similar to tsched... we have to implement it, people have to realise it's broken and report their errors and then it has to be fixed in alsa!
18:24:41 <mezcalero> after all the entire mixer definition file stuff in pa is mostly a nice way to hide the fact that we tape over broken drivers ;-)
18:25:08 <diwic> my narrow world is HDA, there I know the three most common codecs use the same method. The same one implemented for HDMI and we're not far from being there.
18:25:25 <mezcalero> coling: well, in tsched however, we know how the drivers should work. in the alsa case it's not clear to me at least in which way the trip will go
18:25:36 <coling> diwic, yeah this does cover a lot of bases even if it is a "narrow" view :)
18:25:43 <mezcalero> to me it appears the input subsystem is the wrong answer though. THis should be done in the alsa ctl layer
18:26:04 <mezcalero> and i think that is what takashi was saying to
18:26:05 <mezcalero> too
18:26:17 <coling> OK, so diwic are you happy enough to discuss this a bit with takashi and see if we can get a consensus?
18:26:49 <coling> If so we can at least start to get things going in the right direction.
18:26:54 <diwic> I'm happy for someone else to do it as I'm going to have 11.04 to think about for a two or three months now
18:27:12 <diwic> But after that...it's something I'd *like* to look into
18:27:29 <coling> Hmm, OK, I'm not really all that clued up on what's needed if I'm honest, so I'm not really ideal for this.
18:27:33 <coling> Any other takers?
18:27:55 <coling> broonie, I presume this doesn't really affect you all that much?
18:27:56 <mezcalero> diwic: btw, the jack sensing stuff probably does interfere a bit with the prio list stuff of coling's. because we probably want to keep a history of profiles used, and when somebody plugs something in that is not available in the current profile we should automatically switch profile to the profile that was used and works
18:28:18 <mezcalero> diwic: that said i am not sure coling actually wants to do his priolist stuff for the profile logic, too
18:28:25 <Ford_Prefect> It's something I'm interested, but also won't be able to look at for a couple of months (and I'm starting from scratch, to boot, so don't count on me)
18:28:41 <coling> mezcalero, I'm not 100% decided on it to be honest.
18:28:52 <maggie_> I have to look at it, the idea is to call ucm jack handler when it is detected
18:29:23 <coling> mezcalero, I was thinking it might be needed for some stuff but not others (e.g. current stream-restore saves device+vol, but prio lists would probably just save device as vols will have to be saved separately for different ports)
18:30:25 <mezcalero> man i am hungry. let's speed this up, otherwise i'll die of starvation on this very keyboard
18:30:27 <krtaylor> I could probably look at it as well
18:30:48 <coling> maggie_, how does the UCM jack handler work? Is it tied to something totally new or works with existing jack stuff in alsa?
18:30:52 <coling> mezcalero, agreed...
18:30:53 <diwic> maggie_, krtaylor, is this jack detection something that's planned for Ubuntu 11.04 and/or Linaro 11.05?
18:30:59 <broonie> mezcalero: What is the this you were asking me to comment on?
18:31:08 <coling> broonie, it was me.
18:31:21 <coling> broonie, headphone jack detection mainly.
18:31:27 <broonie> The tie up with individual volume controls is something the PC audio guys need to figure out.
18:31:34 <coling> but we probably need to move on.
18:31:40 <krtaylor> diwic, not to my knowledge
18:31:43 <maggie_> ucm basically set the alsa controls that are needed to get an use case working
18:32:06 <coling> OK, so in the interests of speeding things up let's move on to UCM
18:32:19 <maggie_> hehe ok
18:32:40 <maggie_> I haven an initial version of module-alsa-ucm module
18:32:44 <coling> #agreed Jack Detection is hard... We need to discuss how it will work for PC audio with takashi and get that sorted before we move on to PA support, but lets try and push it.
18:32:49 <broonie> For the embedded case the problem is totally different; there's way more system state tied in with the jacks and PA can't do anything..
18:32:52 <coling> #topic UCM
18:33:34 <coling> maggie_, That's cool. I'm sorry I've not been able to review stuff as actively as I would have liked. Been a bit busy of late.
18:33:47 <coling> maggie_, that and I'll need help really understanding the UCM stuff.
18:34:13 <maggie_> ok, no problem
18:34:36 <maggie_> I can help with ucm understanding
18:35:24 <maggie_> the idea about ucm is to provide an easy way to set the alsa control that are needed to get working some audio scenarios
18:36:25 <maggie_> you can alsa get info like default devices for playback and capture and volumen info
18:36:43 <coling> Cool. We can probably discuss this later, but mezcalero's input would probably be invaluable with regards to how to fit everything in. As this is something people (and various companies) really want NOW, I suggest we arrange a second meeting about this topic particularly as I suspect we could discuss it for a while just now?
18:37:06 <maggie_> yeap
18:37:18 <coling> mezcalero, Can you carry on for a little while longer or would you prefer a more specific discussion time?
18:37:55 <coling> If so we should get an approx time now and then hopefully maggie_ broonie and Liam and Pierre can attend too?
18:38:33 <coling> but I'd love it if we could chat before that maggie_ so I get a good understanding.
18:38:43 <coling> Hi mkbosmans glad you could make it :) We're still going :D
18:38:45 <maggie_> yeap, other time sounds better
18:38:52 <mezcalero> coling: i think a second meeting would be good
18:38:55 <Ford_Prefect> If mezcalero can stay for it, I suggest jumping to Participation/Infrastructure and then doing the rest after, based on how people feel about time
18:38:58 <coling> Sorry if that's a fobb off maggie_ :)
18:39:20 <coling> Especially as you've waited patiently!
18:39:35 <maggie_> :) no problem
18:39:39 <coling> Ford_Prefect, yeah, the rest of the topics should pre pretty quick.
18:39:58 <coling> mezcalero, do you have a suggested time for a more UCM-centric chat?
18:40:08 <mezcalero> dunno, could do tonight
18:40:10 <coling> maggie_, what timezone are you btw? Is this kind of time good for you?
18:40:25 <maggie_> me GT+6
18:40:26 <mezcalero> there was another slot in the meeting scheduler everybody would be free iirc
18:40:52 <coling> maggie_, so it's getting kinda late for you now I guess.
18:41:28 <mezcalero> oh, hmm, i guess later tonight woduln't really work then...
18:41:33 <maggie_> sorry, no It is 12:41 pm, it is GMT-6
18:41:42 <coling> Ahh, not so bad then :)
18:41:47 <broonie> Oh, good - I had thought that was the case :)
18:41:50 <maggie_> nope
18:41:54 <Ford_Prefect> That's GMT+6 :)
18:42:08 <coling> OH so it's me that can't do sums...
18:42:18 * coling is confused by timezones...
18:42:21 <coling> Anyway, all is good
18:42:28 <maggie_> hehe I'm in México
18:42:32 <mrc3> Ford_Prefect, or gmt-06, no?
18:42:50 <coling> So mezcalero what time for UCM chats? +2h from now?
18:42:55 <coling> mezcalero, or +3h?
18:42:58 <mezcalero> ijust say 6 hours west
18:43:14 <maggie_> but maybe Liam can not join
18:43:17 <Ford_Prefect> mrc3: gmt-6 would be 0043 on 25th feb
18:43:40 <mezcalero> hmm?
18:43:46 <mezcalero> i need 2h
18:43:58 <mezcalero> if that works for people, we can meet then again
18:44:01 <mezcalero> or 3h would work too
18:44:17 <coling> OK, so is 21 UTC OK for you maggie? (2h 15m from now)
18:44:17 <Ford_Prefect> 2 == fine by me, 3 == late
18:44:38 <maggie_> yeap, it's ok
18:44:39 <coling> mezcalero, if you could stay 10mins more can we cover a few quick points?
18:44:45 <coling> cool :)
18:45:05 <coling> #agreed Further chat re-UCM at 21 UTC
18:45:17 <coling> Ford_Prefect, I'm going to ignore Orc for now.
18:45:21 <mezcalero> coling: sure, but my strength is fading, i am so hungry i can barely press down the buttons on my kbd anymore ;-)
18:45:33 <coling> mezcalero, You can manage
18:45:58 <coling> I'll just skip the remaining code related stuff for now, but if we can discuss after UCM later that would be good - they should be fairly quick
18:46:07 <coling> #topic participation
18:46:26 <mezcalero> currently only you and me have git access?
18:46:35 <mezcalero> i kinda like having few committers only
18:46:38 <coling> OK, this relates to infrastructure too, but I'd very much like at least Ford_Prefect and tanuk to get git commit access if they approve
18:46:41 <mezcalero> but i am open to hand out more
18:47:06 <tanuk> I approve :)
18:47:08 <Ford_Prefect> Would be nice  :)
18:47:14 <mezcalero> np, ping me later
18:47:14 <coling> It would take the burden off of me a little as basically I'm the only once committing stuff for the last >1year which isn't ideal for patch reviews.
18:47:30 <coling> That and I don't really feel qualified to push all the patches I do sometimes!
18:47:36 <mezcalero> coling: let me do the next release, after i reviewed the patches
18:47:37 <coling> Good glad we agree :)
18:47:47 <mezcalero> coling: hey, i think i did at least one commit ;-)
18:48:03 <coling> Yeah you did a few, but you know what I mean.
18:48:05 <coling> :)
18:48:22 <mezcalero> coling: the lennart resource itme allocation follows a pester me enough protocol
18:48:33 <mezcalero> keep annoying me and i will do something
18:49:04 <coling> mezcalero, OK, can we have some sort of semi-regular meetings like this perhaps where we agree a time and then tick off issues and discussion topics there?
18:49:09 <mezcalero> (or kill you to make you shut up, but so far i have not killed anybody, and i don't think i am the killer type)
18:49:25 <coling> I think that would work quite well and lets you concentrate on the stuff you need to do with out constant interuptions.
18:49:46 <mezcalero> coling: i am in too many "regular" meetings already. me no likey regular. me prefer when there is enough to talk about that
18:49:47 * coling knows Muay Thai and is bigger than you....
18:50:05 <coling> mezcalero, that's kinda what I meant by "regular" so that's OK.
18:50:30 <coling> mezcalero, can I take over pavucontrol tho'?
18:50:43 <coling> I'd like to do some releases there. I think you offered a while ago and I should have said yes then....
18:51:02 <mezcalero> coling: you are welcome to
18:51:19 <coling> #agreed we can arrange meetings on an as-needed basis to discuss specific topics
18:51:21 <mezcalero> you get a free beer with that ;-)
18:51:34 <coling> #agreed coling will take over pavucontrol releases
18:51:42 <coling> #action mezcalero to give coling a beer
18:51:47 <mezcalero> coling: btw, we might be able todo a pa meetup during desktop summit
18:52:06 <mezcalero> ok, can i get myself some food now?
18:52:06 <coling> #action mezcalero to do what's needed to let coling take over pavucontrol
18:52:21 <coling> mezcalero, just 2mins more.
18:52:27 <coling> #topic infrastructure
18:52:30 * sreeves1 seconds the idea of a PA meeting during the desktop summit
18:52:50 <Ford_Prefect> ++ from me too, but back to topic
18:53:04 <coling> mezcalero, can you contact freenode as the project lead to get #pulseaudio channel registered.
18:53:25 <coling> mezcalero, it has to come from the project lead. Either that or put up something somewhere syaing that I can represent the project.
18:53:40 <coling> It's not a big deal, but it would allow us to change topic etc. which is nice.
18:53:49 <coling> (I had to get freenode admin to do it for 0.9.220
18:53:51 <mezcalero> ok, pester me about it later
18:54:06 <coling> #action mezcalero to do somthing about IRC channel
18:54:14 <coling> mezcalero, re FDO... what's your plan there?
18:54:25 <mezcalero> coling: well, no real plan
18:54:31 <mezcalero> but it would be cool if this was on fdo
18:54:31 <coling> Should we migrate bugs and git hosting to them?
18:54:34 * Ford_Prefect suggests moving bugs and git there
18:54:36 <mezcalero> i just don't want to do the work
18:54:55 <mezcalero> and the migration sounds like a lot of work
18:54:56 <coling> mezcalero, I can do what's needed if I have the rights to do so.
18:55:08 <diwic> sorry, what's FDO?
18:55:17 <mezcalero> freedesktop.org
18:55:21 <diwic> ok
18:55:25 <coling> mezcalero, I'm happy to rip out the PA website and bugs db and setup a new wikie and such like.
18:55:31 <Ford_Prefect> (I looked up trac->moinmoin migration, and there isn't a ready solution to migrate history, so we need to keep the wiki up)
18:55:40 <coling> but may need your help for some bits of course.
18:55:44 <mezcalero> coling: maybe this is a chance to clean up the bug db
18:55:50 <mezcalero> coling: i.e. keep the old stuff around fo a while
18:55:59 <mezcalero> coling: but ask people to submit on fdo from now on
18:56:00 <coling> Well I'm happy to do that too.
18:56:12 <mezcalero> and not copy anything over
18:56:14 <Ford_Prefect> coling: I can pitch in with that process if you need help
18:56:25 <coling> mezcalero, can you send me details of who I'd need to contact about that?
18:56:29 <coling> Ford_Prefect, ace.
18:56:33 <mezcalero> coling: hmm?
18:56:39 <mezcalero> coling: to get something set up on fdo?
18:56:48 <mezcalero> coling: just file a bugzilla request for a project
18:56:48 <coling> mezcalero, if you don't know I'll just go through the fdo lists and ask :)
18:56:54 <coling> Cool
18:57:00 <mezcalero> coling: and that you need bz, and web, and stuff
18:57:10 <mezcalero> coling: and then it will probably be ignored
18:57:13 <mezcalero> coling: and then ping me
18:57:20 <mezcalero> coling: and i'll pull some strings
18:57:27 <coling> #action coling and Ford_Prefect to look at moving our infra to fd.o
18:57:35 <coling> mezcalero, OK, that's cool.
18:57:53 <coling> Right, I think you should get some food... the typing seems awfully weak now.
18:57:59 <coling> :)
18:58:02 <coling> Thanks for sticking with it.
18:58:15 <coling> We'll have a two hour break and start back with UCM discussion.
18:58:16 <mezcalero> yupp, all my letters are gray now, not crispy white anymore
18:58:24 <krtaylor> CI part of move?
18:58:24 <coling> #endmeeting