15:33:08 <RRSAgent> RRSAgent has joined #audio
15:33:08 <RRSAgent> logging to http://www.w3.org/2013/09/05-audio-irc
15:33:09 <trackbot> RRSAgent, make logs world
15:33:10 <Zakim> Zakim has joined #audio
15:33:11 <trackbot> Zakim, this will be 28346
15:33:12 <Zakim> ok, trackbot; I see RWC_Audio()12:00PM scheduled to start in 27 minutes
15:33:12 <trackbot> Meeting: Audio Working Group Teleconference
15:33:13 <trackbot> Date: 05 September 2013
15:33:29 <olivier> Agenda: http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0673.html
15:34:04 <olivier> Agenda+ CfC - Audio Buffer Data Races -> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html
15:34:37 <olivier> Agenda+ review of recent draft changes
15:56:35 <chrislowis> ScribeNick: chrislowis
15:58:21 <Zakim> RWC_Audio()12:00PM has now started
15:58:28 <Zakim> + +1.206.395.aaaa
15:58:35 <cwilso> zakim, aaaa is me
15:58:35 <Zakim> +cwilso; got it
15:58:52 <chrislowis> We (chris and olivier) are struggling to get on the call.
15:59:45 <cwilso> that explains why I'm all by myself.  :)
16:00:29 <ehsan> ehsan has joined #audio
16:00:51 <Zakim> +[Mozilla]
16:01:18 <cwilso> zakim, Mozilla has ehsan
16:01:18 <Zakim> +ehsan; got it
16:01:58 <Zakim> +[IPcaller]
16:02:00 <padenot> I'm coming, I have to find a room
16:02:03 <olivier> zakim, IPcaller is me
16:02:03 <Zakim> +olivier; got it
16:02:10 <olivier> zakim, olivier also has chrislowis
16:02:10 <Zakim> +chrislowis; got it
16:02:15 <olivier> Chair: olivier
16:02:18 <olivier> Scribe: chrislowis
16:02:23 <olivier> ScribeNick: chrislowis
16:02:41 <gmandyam> gmandyam has joined #audio
16:03:23 <olivier> zakim, who is here?
16:03:24 <Zakim> On the phone I see cwilso, [Mozilla], olivier
16:03:25 <Zakim> olivier has olivier, chrislowis
16:03:25 <Zakim> [Mozilla] has ehsan
16:03:25 <Zakim> On IRC I see gmandyam, ehsan, Zakim, RRSAgent, colinbdclark, tobie, marcosc, cwilso, paul___irish, shepazu, olivier, trackbot, heath, mdjp, rtoyg, chrislowis, toyoshiAw, padenot
16:03:32 <Zakim> + +1.858.750.aabb
16:03:42 <chrislowis> Zakim, aabb is gmandyam
16:03:42 <Zakim> +gmandyam; got it
16:04:52 <Zakim> +jernoble
16:04:58 <Zakim> +padenot
16:05:12 <olivier> zakim, agenda?
16:05:12 <Zakim> I see 2 items remaining on the agenda:
16:05:13 <Zakim> 1. CfC - Audio Buffer Data Races -> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html [from olivier]
16:05:13 <Zakim> 2. review of recent draft changes [from olivier]
16:05:25 <chrislowis> olivier: let's get started.
16:05:47 <olivier> zakim, take up agendum 1
16:05:47 <Zakim> agendum 1. "CfC - Audio Buffer Data Races -> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html" taken up [from olivier]
16:06:08 <chrislowis> olivier: first item on the agenda is the call for consensus (CfC) on the "data races" issue.
16:06:35 <chrislowis> olivier: I sent an email asking for group members if they object to what we've been calling "roc's proposal"
16:07:02 <chrislowis> olivier: noting that we know there are similiar, related issues, but that this refers to the audio buffer issue only.
16:07:20 <cwilso> I thought Jer objected?
16:07:36 <chrislowis> olivier: there were some issues raised about the syntax and naming of methods, but I haven't seen any objections.
16:08:27 <chrislowis> jernoble: you asked previously what would need to be changed in order for us to live with it.
16:09:11 <chrislowis> jernoble: one thing I'd ask - roc added a method to pull the data out without triggering the neutering, I'd like to request that a method is added for the reverse - for putting data in.
16:09:39 <chrislowis> jernoble: let me clarify, that is something that we'd like to see added before we can say that we "could live" with it.
16:10:01 <cwilso> q+ to ask on #1 - shouldn't we just rename "getAudioChannelData" to something that doesn't use the word "get" then?
16:10:07 <chrislowis> jernoble: also, I don't feel at the moment that there necessarily is consensus yet. I didn't see any discussion of my proposal for example.
16:10:31 <gmandyam> q+
16:10:35 <ehsan> q+
16:10:48 <olivier> ack cw
16:10:48 <Zakim> cwilso, you wanted to ask on #1 - shouldn't we just rename "getAudioChannelData" to something that doesn't use the word "get" then?
16:10:52 <chrislowis> olivier: I guess it was my hunch that there was a consensus growing around rocs proposal, but I'm happy to ask whether there's consensus around alternative proposals.
16:11:44 <chrislowis> cwilso: I think the disagreements I have with Jer's original proposal is that it puts more weight on putting data in and getting data out of the system. I guess it's a disagreement over how much we expect the developer to know about data crossing the boundaries.
16:12:11 <chrislowis> cwilso: if what we're worried about is the use of the word "get" in the method names, maybe we could change it to "access" or something?
16:12:39 <chrislowis> jernoble: there would be a lot of people who object to renaming that function as it would break a lot of websites.
16:13:02 <chrislowis> jernoble: a function exists for pulling data out, but there's not one for putting data in.
16:13:17 <chrislowis> cwilso: are you asking to be able to push data over to the audio copy of that in that case?
16:14:04 <chrislowis> jernoble: exactly. I think the most common case is to get a copy of the data in order to perform an operation on it. If there was a method to push data in too, I think that would be useful.
16:14:24 <chrislowis> jernoble: and it's ok to add it, as it's not going to break existing websites
16:14:32 <olivier> ack gm
16:14:32 <chrislowis> cwilso: ok, I think I understand.
16:15:04 <chrislowis> gmandyam: a question to jernoble: is apple planning to make a contribution to webkit or blink for the proposed approach?
16:15:22 <chrislowis> gmandyam: are you going to try and upstream an implementation?
16:15:52 <chrislowis> jernoble: yes, sure. I don't think apple would do that for blink, we'd probably leave that to google now there's two code bases. But yes, we'd implement it.
16:15:57 <chrislowis> gmandyam: thanks
16:15:59 <olivier> ack ehsan
16:16:01 <chrislowis> jernoble: no problem.
16:16:50 <chrislowis> ehsan: about jer's proposal, I think it's a better API, but it breaks existing content. And I think in this case, that would be significant enough that a lot of existing apps will not work in the implementations.
16:17:15 <chrislowis> ehsan: padenot had a look at existing code out there and found 1 example that would break with roc's proposal.
16:17:46 <chrislowis> ehsan: and a question for cwilso: what's google position about updating their implementation to match what we come up with?
16:18:36 <chrislowis> ehsan: I want to make sure that when we're asking for consensus we're assuming that everyone will actually implement it. To reword: do you think there will be any objections to implementing this in blink?
16:19:59 <chrislowis> cwilso: I'm not sure yet what "this" means here, as we're still only part way through deciding this. But I think I've already stated that although I don't necessarily agree that "fixing" these races is the right thing to do, but if we agree as a group that it's important, then we're committed to having an interoperable api.
16:20:22 <chrislowis> cwilso: I can't commit to timescales at the moment.
16:20:33 <chrislowis> ehsan: that's great, and what I wanted to hear - thank you.
16:21:19 <cwilso> I'd note that we've talked about so many extensions to each proposal that I'm not sure what each proposal consists of anymore.
16:21:35 <ehsan> q+
16:21:39 <cwilso> q+
16:21:52 <olivier> ack ehsan
16:22:01 <chrislowis> olivier: so I'm hearing no objections about either Roc's or jer's proposal although there are concerns. So I'm going to suggest that we look at both, as a straw poll, and see if we can prefer or if we can live with the proposal.
16:22:20 <chrislowis> ehsan: we'd prefer Roc's proposal.
16:22:43 <olivier> ack cwilso
16:22:46 <chrislowis> jernoble: we can live with Roc's
16:23:24 <chrislowis> cwilso: I'd prefer Roc's proposal. My goal is to have the best backwards compat, and the smallest surface area of the api.
16:23:51 <chrislowis> cwilso: and at the moment, I'm not sure what we'll graft on to Roc's proposal to allow for access to the data.
16:24:04 <chrislowis> cwilso: I'd like to discuss the details of how copyChannelData works.
16:24:16 <olivier> Agenda+ discuss the details of how copyChannelData works
16:24:45 <chrislowis> ehsan: discuss here or on the list?
16:24:49 <chrislowis> cwilso: I'd prefer the list.
16:25:31 <chrislowis> jernoble: i'd prefer to do nothing, but I can live with Roc's proposal.
16:25:46 <cwilso> I'd note that if doing nothing is still on the table, I would prefer that too.
16:26:12 <chrislowis> olivier: I'd like to ask, is the main reason you prefer the proposal is for the backwards-compat reasons for it.
16:26:30 <chrislowis> cwilso: just to clarify that was ehsan's comment
16:26:35 <chrislowis> ehsan: yes that's right.
16:27:11 <ehsan> q+
16:27:20 <chrislowis> olivier: I'd like us to spend a little bit of time thinking about the relative risk and reward of going for the quote- "better api" rather than going for backward compat.
16:28:05 <chrislowis> olivier: we've talked about backwards compatibility being important in the past, but we've also spoken about education and outreach as a way moving forwards.
16:28:07 <olivier> ack ehsan
16:28:48 <chrislowis> ehsan: from my stand point, I think if we were designing web audio today from scratch, and there was no existing code out there, we'd probably do some things differently.
16:29:20 <chrislowis> ehsan: I think writing a web audio application today without audiobuffers is quite difficult,
16:29:54 <chrislowis> ehsan: so that's my main reason for not preferring jer's proposal - it will break a lot of content.
16:30:26 <chrislowis> ehsan: I'm not convinced that the goal of the current discussion, which is avoiding data races, requires us to make breaking changes.
16:30:52 <ehsan> q+
16:31:36 <chrislowis> jernoble: the reason my proposal suggested a breaking change is that I understood from Roc and others the data race issue was such a big issue that a breaking change was justified. And that the api may have been designed that way because the author didn't consider the data race issue to be significant.
16:31:57 <olivier> ack ehsan
16:32:09 <chrislowis> jernoble: so would we consider a future API that would be incompatible with today's api that had some extra features?
16:33:16 <chrislowis> ehsan: speaking for myself, I would probably change quite a few things in the existing API -
16:34:53 <cwilso> q+
16:35:05 <chrislowis> ehsan: I think I'd probably have an AudioContext that is responsible for creating everything that an author is likely to use. Which would require a significant amount of thinking.
16:35:35 <olivier> ack cwilso
16:35:49 <chrislowis> ehsan: it's difficult for me to make decisions today in light on what changes we might bring in in the future.
16:37:46 <chrislowis> cwilso: I think backwards compatibility is important enough to not make a breaking change. But the API today is designed such that the developer doesn't need to have deep knowledge of audio in order to take advantage of a glitch-free, low-latency audio thread. And I think I'd keep that design in any future too. It's not just about backwards compatibility in other words, I'd still go in that direction in the future given the choice.
16:39:13 <cwilso> s/deep knowledge of audio/deep understanding of threading/memory sharing
16:39:58 <chrislowis> cwilso: I always try to keep a 5- to 10- year time frame in mind too, and I think if we really believe there will be another API that we will be pushing in the future we should start to work towards that now.
16:40:15 <olivier> RESOLUTION: there is consensus around ROC's proposal. The editors will work on adding it to the spec and the group will refine it wherever there are still concerns
16:41:13 <chrislowis> olivier: well done to everyone for reaching that fairly hefty resolution.
16:42:13 <olivier> zakim, close agendum 1
16:42:13 <Zakim> agendum 1, CfC - Audio Buffer Data Races -> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html, closed
16:42:15 <Zakim> I see 2 items remaining on the agenda; the next one is
16:42:15 <Zakim> 2. review of recent draft changes [from olivier]
16:42:18 <olivier> zakim, take up agendum 2
16:42:18 <Zakim> agendum 2. "review of recent draft changes" taken up [from olivier]
16:42:22 <chrislowis> olivier: I'd like to take a look at changes that have been made since the last call and review those next.
16:42:24 <olivier> https://dvcs.w3.org/hg/audio/
16:43:13 <chrislowis> olivier: padenot can you walk us through the recent changes?
16:43:16 <chrislowis> padenot: sure.
16:43:38 <chrislowis> padenot: I removed the old names section (https://dvcs.w3.org/hg/audio/rev/396c4054ef67)
16:43:59 <chrislowis> olivier: I can't find a corresponding bug.
16:44:05 <chrislowis> olivier: if I do I'd close it.
16:44:17 <olivier> https://dvcs.w3.org/hg/audio/rev/c356109a4006
16:44:20 <olivier> (markup change)
16:44:30 <olivier> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22287
16:44:47 <chrislowis> padenot: this is the change for #22287 (https://dvcs.w3.org/hg/audio/rev/d5abda1da9fc)
16:45:16 <chrislowis> olivier: any objections to this change?
16:45:23 <chrislowis> olivier: hearing none, closing the bug.
16:45:33 <olivier> https://dvcs.w3.org/hg/audio/rev/fbf524d2cc9b
16:45:38 <chrislowis> padenot: next patch ^^
16:46:35 <chrislowis> padenot: it was designed to make it clear how the DelayNode works, making reference to how things work in existing music software (output(t) = input(t - delayTime(t)))
16:46:45 <olivier> https://dvcs.w3.org/hg/audio/rev/92183159c02b
16:46:49 <chrislowis> olivier: then closing that if I hear no objections? ...
16:46:51 <chrislowis> olivier: closed.
16:47:25 <olivier> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21777
16:48:22 <chrislowis> padenot: This one is about generating audio or analysing audio with the script processor node, and that we should allow this node to have zero inputs, or zero outputs in the generating and analysing cases respectively.
16:48:32 <chrislowis> olivier: then closing 2177.
16:49:22 <chrislowis> olivier: A quick question about the next teleconference time. Would you prefer next week, or in two weeks?
16:49:29 <olivier> Topic: Next teleconference
16:49:36 <chrislowis> ehsan: I can't attend next week, but that shouldn't stop you.
16:50:00 <chrislowis> chrislowis: I'd prefer not the 19th, but don't let that stop you.
16:50:25 <chrislowis> olivier: I can not do the 26th.
16:51:04 <olivier> zakim, close agendum 2
16:51:04 <Zakim> agendum 2, review of recent draft changes, closed
16:51:05 <Zakim> I see 1 item remaining on the agenda:
16:51:05 <Zakim> 3. discuss the details of how copyChannelData works [from olivier]
16:51:10 <chrislowis> olivier: the tentative decision then is that we meet in two weeks, the 19th September at the same time.
16:51:25 <ehsan> wfm
16:51:33 <chrislowis> olivier: I think we'll discuss copyChannelData on the list. So let's adjurn for today.
16:51:56 <chrislowis> olivier: thanks everybody for a good meeting. We'll post minutes as usual and talk to you on the 19th, same time.
16:52:03 <Zakim> -jernoble
16:52:04 <Zakim> -gmandyam
16:52:06 <Zakim> -olivier
16:52:09 <Zakim> -cwilso
16:53:29 <chrislowis> RRSAgent, generate minutes
16:53:29 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/05-audio-minutes.html chrislowis
16:53:47 <chrislowis> Zakim, bye
16:53:47 <Zakim> leaving.  As of this point the attendees were +1.206.395.aaaa, cwilso, ehsan, olivier, chrislowis, +1.858.750.aabb, gmandyam, jernoble, padenot
16:53:47 <Zakim> Zakim has left #audio
16:53:54 <olivier> RRSAgent, bye
16:53:54 <RRSAgent> I see no action items