19:13:41 <RRSAgent> RRSAgent has joined #audio
19:13:41 <RRSAgent> logging to http://www.w3.org/2011/10/18-audio-irc
19:13:55 <chris> anybody know the callin number and passcode?
19:14:09 <quinnirill> zakim, +??P7 is quinnirill
19:14:09 <Zakim> sorry, quinnirill, I do not recognize a party named '+??P7'
19:14:17 <quinnirill> zakim, ??P7 is quinnirill
19:14:17 <Zakim> +quinnirill; got it
19:14:26 <kinetik> Zakim: IPcaller.a is kinetik
19:14:42 <quinnirill> case sensitive :)
19:14:57 <kinetik> zakim: IPcaller.a is kinetik
19:15:12 <chris> phone number?
19:15:18 <chrislo> zakim, list attendees
19:15:18 <Zakim> As of this point the attendees have been [IPcaller], +1.978.314.aaaa, chrislo, quinnirill
19:15:20 <Zakim> -[IPcaller.aa]
19:15:33 <tmichel> *Bridge US:* +1-617-761-6200 (Zakim)
19:15:33 <quinnirill> zakim, IPcaller.a is kinetik
19:15:33 <Zakim> +kinetik; got it
19:15:44 <kinetik> thanks
19:15:45 <Zakim> +[IPcaller.a]
19:15:48 <quinnirill> np
19:15:54 <chris> tmichel: thanks - and the code?
19:16:20 <tmichel> the passcode is 26631#
19:16:24 <chrislo> Al is talking about the different APIs we have and asking to open up discussion. 
19:16:30 <chris> thanks :)
19:16:45 <chrislo> Jo suggests a useful starting point might be to ask a question about implementation.
19:17:07 <Zakim> + +1.650.253.aabb
19:17:18 <tmichel> chris has joined ?
19:17:25 <chris> yes
19:17:38 <chrislo> Jo suggests we need to consider the use cases - streaming and synthesis.
19:18:05 <chrislo> Chris Rogers joins and asks for a brief summary. 
19:18:15 <tmichel> zakim, who is here?
19:18:15 <Zakim> On the phone I see chrislo, ??P1, +1.978.314.aaaa, [IPcaller], kinetik, ??P6, quinnirill, [IPcaller.a], +1.650.253.aabb
19:18:17 <Zakim> On IRC I see RRSAgent, quinnirill, chris, Hoene, Zakim, JoeB, tmichel, roc, MikeSmith, chrislo, colinbdclark, smaug, foolip, Alistair, kinetik, trackbot
19:19:22 <chrislo> Jo asks whether a specific concrete implementation could serve the two different use cases.
19:19:52 <chrislo> Jo thinks the APIs can be made to coincide. But can an implementation work in both worlds.
19:20:53 <chrislo> Chris Rogers says, I recently posted some example code integrating the audio API with the streaming API / Web RTC implementation. 
19:21:17 <chrislo> Chris R says there has to be some point of integration between these different APIs.
19:22:09 <chrislo> The public web rtc implementation looks good to Chris for setting up p2p connections and dealing with them at a high level, and he's given some examples in the last couple of days showing how the web audio API could work with it. 
19:22:36 <chrislo> He thinks the implementation would be possible in the next couple of months in Chrome.
19:22:45 <chrislo> The distinction is the objects don't have to be the same. 
19:22:56 <chrislo> zakim, who's talking?
19:23:11 <Zakim> chrislo, listening for 10 seconds I heard sound from the following: [IPcaller] (5%)
19:23:47 <chrislo> Joe asks what the arguments are for for unification.
19:25:02 <chrislo> Chris Rogers says that a unified API would be difficult to develop the larger it gets (adding audio event scheduling to the p2p api for example) 
19:25:49 <chrislo> Namespace collision, fragile base class problem and so on. 
19:25:54 <chrislo> Al asks roc for his ideas. 
19:26:25 <chrislo> roc says he's addressed quite a lot of issues by email, asks whether to recap.
19:26:53 <chrislo> Joe would like roc to talk a little about Chris's suggestions. 
19:26:56 <quinnirill> zakim, who is speaking?
19:27:06 <chrislo> quinnirill: I think that's JoeB 
19:27:11 <Zakim> quinnirill, listening for 10 seconds I heard sound from the following: chrislo (20%), [IPcaller] (5%), ??P6 (35%)
19:27:13 <Alistair> that was JoeB 
19:27:35 <quinnirill> yeah, just trying to identify who is echoing :)
19:27:52 <chrislo> roc says we don't yet have a concrete namespace collision problem.
19:28:38 <quinnirill> ty :)
19:28:53 <chrislo> roc can't remember an occasion when we've split objects on the web to make them simpler
19:29:06 <chrislo> roc, but it's hard to be sure of how things will evolve. 
19:29:18 <chrislo> Al says it seems that we have different apis for different use cases
19:29:25 <chrislo> Audio API for games, synthesis and so on. 
19:29:34 <chrislo> And RTC for streaming. 
19:29:54 <chrislo> It seems to make sense for RTC to have some audio features, and it would make sense to see if we could share some core features. 
19:30:26 <chrislo> Maybe a basic audio spec for mixing and panning that we could share, then pass the output of that to a seperate mixing level. 
19:30:37 <chrislo> But that might lead to redundency 
19:31:28 <chrislo> Chris is talking about Al's questions about controlling the audio of each tab. 
19:31:42 <chrislo> For mixing and panning Chris says that's the bread-and-butter of the Audio API. 
19:32:06 <chrislo> It's able to take and mix / change the volume and pan from a number of sources, including the web rtc apis/ 
19:32:40 <chrislo> Al is asking whether it would make sense to split the API into two differnent APIs, while recognising that that runs contrary to roc's opinion. 
19:32:56 <chrislo> He says it would make sense to share functionality at some level. 
19:33:33 <chrislo> JoeB is asking that if the mixing part of the API is simple, why can't it just be spliced in to the audio path at the point where it's needed
19:34:25 <chrislo> Al understands the argument, clarifies that the split might not be in code necessarily but a split in the standardisation effort. 
19:34:57 <chrislo> Al has talked to musicians and they would like the synthesis/effects pinned down to the sample accuracy. 
19:35:34 <chrislo> But because we have the push from RTC for communications in the browser, and could use things like compression and noise reduction, it seems like we could take the set of most-used features and put that in one deliverable
19:35:42 <chrislo> and the more complicated features a bit further out. 
19:36:05 <chrislo> Chris Rogers(?) thinks that phasing the support levels of APIs in general is a great idea. 
19:36:53 <chrislo> Chris doesn't think we need to standardise to the sample level when we role out, just as web graphics specs don't specify rendering down to the pixel level. 
19:37:31 <chrislo> roc - authors don't generally care about graphics anti-aliasing in general, whereas musicians maybe do care as Al points out. 
19:37:55 <chrislo> If we're producing things that sound the same we'll be ok, but if they're different then not. 
19:38:57 <chrislo> Chris thinks we can produce something that sounds the same across implementations. Most things are specified to the sample level in the Web Audio API (except perhaps the compression stuff which is however following established principles. There's no agreed 'standard' for compressors) 
19:39:32 <chrislo> Al thinks the point about starting out without full precision is good one.
19:40:02 <chrislo> Chris says that the impulse response of the convolution filters exactly defines how those effects work. 
19:40:44 <chrislo> And mixing and panning, and filters can all be specified precisely in a mathematical sense
19:41:05 <chrislo> Al asks roc how far he's thought about rendering audio and what the signal path would be. 
19:41:29 <chrislo> roc - wants to integrate the framework with media elements, that's what he's working on now. 
19:42:16 <chrislo> Then he wants to test it with hundreds of streams at the same time and see what kind of performance he can get.
19:42:23 <chrislo> Al - that would be interesting to see. 
19:43:02 <chrislo> Al asks roc to talk about pulling the audio api into the streaming api. 
19:43:31 <chrislo> roc doesn't have a lot of experience with effects, and would like to see the effects made available in a common proposal. 
19:43:54 <chrislo> roc's looking at a simple mixing effect at the moment. 
19:44:24 <chrislo> Al asks Chris Rogers about copyright issues around his API
19:44:30 <chrislo> Chris says it's all open source. 
19:45:16 <chrislo> Chris would like to see some more agreement with roc to take the Web Audio code as is and move it into the Gecko code base to integrate it there. 
19:45:27 <chrislo> As an alternative to roc working to reimplement from scratch. 
19:45:48 <chrislo> roc says most of the effort so far has been on syncronisation issues, blocking issues and so on. 
19:46:25 <chrislo> And they'll remain issues even if we take a bridging approach. 
19:46:37 <chrislo> Roc - does Web Audio have the ability to notice that streams have stopped? 
19:47:13 <chrislo> Chris - is the issue around syncronising audio elements in the case of buffer underruns. 
19:47:37 <chrislo> Roc - it's also about syncing filters and mixers and so on, so you don't filter silence while you're waiting for rebuffering. 
19:48:03 <chrislo> Chris - if it's only going to pause for a second or so you can keep running the filter even with silence going through it. 
19:48:23 <chrislo> Roc - but that might not work if there's an element that you're waiting for. 
19:49:05 <chrislo> Al asks if we can add handlers for these things and let developers worry about it. 
19:49:29 <chrislo> Roc - you have to handle it in real time which is very tricky, and is better handled by the browser. 
19:50:03 <chrislo> Chris thinks that that kind of work needs to be done in the browser, is not sure about the syncing of effects though. Would like to discuss that further later. 
19:51:23 <chrislo> Chris - we're talking about streaming html element streams, a kind of stream that can be blocked and we could work on the html media element apis to allow syncronisation of streams. 
19:51:34 <chrislo> Roc mentions the media controller proposal which does some of that. 
19:53:20 <chrislo> JoeB - by bridging the audio graph to the rtc api then the developer would have control of how granular they wanted to handle the blocking and syncronisation issues. 
19:54:02 <chrislo> Chris agrees. In the audio context there is no "blocking" everything is a continuos stream, which may be silent for periods. 
19:54:41 <chrislo> Chris thinks the syncing should be in the HTML element or the controller proposal (with which he's not so familiar)
19:55:16 <roc> http://www.whatwg.org/specs/web-apps/current-work/#mediacontroller
19:55:51 <chrislo> (the proposal roc mentioned at 20:51)
19:58:07 <chrislo> Joe is talking about treating the whole graph as something that blocks. 
19:59:07 <chrislo> Chris proposes that if the blocking and syncing is handled externally, and if something is blocked it just inputs silence into the audio API graph, with no notion of transmitting blocking information to the audio api. 
19:59:20 <chrislo> The audio api doesn't need to care about it.
20:00:12 <chrislo> Roc mentions that if you want audio to be in sync with video that's not what you want. 
20:00:19 <Zakim> -??P6
20:00:26 <roc> oops dropped off
20:00:41 <Zakim> +[IPcaller.aa]
20:00:56 <chrislo> Chris disagrees - it doesn't mean that we'd lose syncronisation, it would just process silence. 
20:01:09 <tmichel> RRSagent, draft minutes
20:01:09 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/18-audio-minutes.html tmichel
20:01:31 <quinnirill> zakim, [IPcaller.aa] is roc
20:01:31 <Zakim> +roc; got it
20:01:43 <tmichel> RRSagent, make minutes public
20:01:43 <RRSAgent> I'm logging. I don't understand 'make minutes public', tmichel.  Try /msg RRSAgent help
20:01:51 <roc> yeah I'm back
20:02:13 <tmichel> RRSagent help
20:02:37 <quinnirill> tmichel: publish minutes maybe?
20:03:38 <chrislo> RRSAgent, make logs world-visible
20:04:13 <chrislo> tmichel: is that what you wanted to do? 
20:04:17 <quinnirill> haha, that's an interesting command
20:05:02 <chrislo> Chris - imagine you have a video tag with transport controlls. The audio is going through a reverb. If the video freezes the audio stops but the tail of the reverb carries on. 
20:05:22 <chrislo> Chris - when you hit play again, the audio would go back through the reverb.
20:05:34 <tmichel> right I wanted to make the minutes public. thanks.
20:06:01 <chrislo> If you didn't want the reverb tail to sound, you could use javascript to turn off the reverb at the point that "pause" was pressed. 
20:06:10 <chrislo> tmichel: I'll publish them at the end of the call. 
20:06:16 <tmichel> rrsagent, draft minutes
20:06:16 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/18-audio-minutes.html tmichel
20:06:31 <tmichel> THey are already been published ...
20:06:59 <chrislo> tmichel: yeah, I think we need to add some metadata at the end. 
20:07:40 <chrislo> roc so the latency of the filter isn't an issue?
20:07:58 <chrislo> chris - for the most part no, the effects built in the audio api don't have a latency. 
20:08:22 <chrislo> chris sometimes with a delay you'd mix wet and dry, that's not latency as such - it's part of the effect. 
20:09:07 <chrislo> Al closes the meeting for today. Let's keep the discussion going on the thread. 
20:09:21 <chrislo> Meeting: Audio WG
20:09:31 <chrislo> Chair: Al MacDonald
20:09:40 <chrislo> Scribe: Chris Lowis
20:09:46 <chrislo> ScribeNick: chrislo
20:09:53 <chrislo> rrsagent, draft minutes
20:09:53 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/18-audio-minutes.html chrislo
20:10:06 <Zakim> -roc
20:10:09 <Zakim> - +1.978.314.aaaa
20:10:10 <Zakim> -kinetik
20:10:10 <Zakim> - +1.650.253.aabb
20:10:12 <Zakim> -[IPcaller.a]
20:10:13 <Zakim> -[IPcaller]
20:10:15 <Zakim> -quinnirill
20:10:52 <chrislo> Alistair: still there? 
20:11:00 <Zakim> -chrislo
20:11:55 <Alistair> yes
20:12:18 <Alistair> chrislo: thanks so much for scribing, i really appreciated itr
20:12:27 <chrislo> RRSAgent, create the minutes
20:12:27 <RRSAgent> I have made the request to generate http://www.w3.org/2011/10/18-audio-minutes.html chrislo
20:12:29 <Alistair> looks like everything went up ok
20:12:46 <chrislo> RRSAgent, bye
20:12:46 <RRSAgent> I see no action items