<trackbot> Date: 05 September 2013

<scribe> ScribeNick: chrislowis

We (chris and olivier) are struggling to get on the call.

<cwilso> that explains why I'm all by myself. :)

<padenot> I'm coming, I have to find a room

<olivier> Scribe: chrislowis

<olivier> ScribeNick: chrislowis

olivier: let's get started.

CfC - Audio Buffer Data Races -> http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html

olivier: first item on the agenda is the call for consensus (CfC) on the "data races" issue.
... I sent an email asking for group members if they object to what we've been calling "roc's proposal"
... noting that we know there are similiar, related issues, but that this refers to the audio buffer issue only.

<cwilso> I thought Jer objected?

olivier: there were some issues raised about the syntax and naming of methods, but I haven't seen any objections.

jernoble: you asked previously what would need to be changed in order for us to live with it.
... 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.
... let me clarify, that is something that we'd like to see added before we can say that we "could live" with it.
... 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.

<Zakim> cwilso, you wanted to ask on #1 - shouldn't we just rename "getAudioChannelData" to something that doesn't use the word "get" then?

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.

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.
... 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?

jernoble: there would be a lot of people who object to renaming that function as it would break a lot of websites.
... a function exists for pulling data out, but there's not one for putting data in.

cwilso: are you asking to be able to push data over to the audio copy of that in that case?

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.
... and it's ok to add it, as it's not going to break existing websites

cwilso: ok, I think I understand.

gmandyam: a question to jernoble: is apple planning to make a contribution to webkit or blink for the proposed approach?
... are you going to try and upstream an implementation?

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.

gmandyam: thanks

jernoble: no problem.

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.
... padenot had a look at existing code out there and found 1 example that would break with roc's proposal.
... and a question for cwilso: what's google position about updating their implementation to match what we come up with?
... 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?

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.
... I can't commit to timescales at the moment.

ehsan: that's great, and what I wanted to hear - thank you.

<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.

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.

ehsan: we'd prefer Roc's proposal.

jernoble: we can live with Roc's

cwilso: I'd prefer Roc's proposal. My goal is to have the best backwards compat, and the smallest surface area of the api.
... and at the moment, I'm not sure what we'll graft on to Roc's proposal to allow for access to the data.
... I'd like to discuss the details of how copyChannelData works.

ehsan: discuss here or on the list?

cwilso: I'd prefer the list.

jernoble: i'd prefer to do nothing, but I can live with Roc's proposal.

<cwilso> I'd note that if doing nothing is still on the table, I would prefer that too.

olivier: I'd like to ask, is the main reason you prefer the proposal is for the backwards-compat reasons for it.

cwilso: just to clarify that was ehsan's comment

ehsan: yes that's right.

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.
... 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.

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.
... I think writing a web audio application today without audiobuffers is quite difficult,
... so that's my main reason for not preferring jer's proposal - it will break a lot of content.
... I'm not convinced that the goal of the current discussion, which is avoiding data races, requires us to make breaking changes.

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.
... so would we consider a future API that would be incompatible with today's api that had some extra features?

ehsan: speaking for myself, I would probably change quite a few things in the existing API -
... 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.
... it's difficult for me to make decisions today in light on what changes we might bring in in the future.

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.

<cwilso> s/deep knowledge of audio/deep understanding of threading/memory sharing

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.

<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

olivier: well done to everyone for reaching that fairly hefty resolution.

review of recent draft changes

olivier: I'd like to take a look at changes that have been made since the last call and review those next.

<olivier> https://dvcs.w3.org/hg/audio/

olivier: padenot can you walk us through the recent changes?

padenot: sure.
... I removed the old names section (https://dvcs.w3.org/hg/audio/rev/396c4054ef67)

olivier: I can't find a corresponding bug.
... if I do I'd close it.

<olivier> https://dvcs.w3.org/hg/audio/rev/c356109a4006

<olivier> (markup change)

<olivier> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22287

padenot: this is the change for #22287 (https://dvcs.w3.org/hg/audio/rev/d5abda1da9fc)

olivier: any objections to this change?
... hearing none, closing the bug.

<olivier> https://dvcs.w3.org/hg/audio/rev/fbf524d2cc9b

padenot: next patch ^^
... 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)))

<olivier> https://dvcs.w3.org/hg/audio/rev/92183159c02b

olivier: then closing that if I hear no objections? ...
... closed.

<olivier> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21777

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.

olivier: then closing 2177.
... A quick question about the next teleconference time. Would you prefer next week, or in two weeks?

Next teleconference

ehsan: I can't attend next week, but that shouldn't stop you.

chrislowis: I'd prefer not the 19th, but don't let that stop you.

olivier: I can not do the 26th.
... the tentative decision then is that we meet in two weeks, the 19th September at the same time.

<ehsan> wfm

olivier: I think we'll discuss copyChannelData on the list. So let's adjurn for today.
... thanks everybody for a good meeting. We'll post minutes as usual and talk to you on the 19th, same time.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/deep knowledge of audio/deep understanding of threading/memory sharing
Found ScribeNick: chrislowis
Found Scribe: chrislowis
Found ScribeNick: chrislowis

WARNING: No "Present: ... " found!
Possibly Present: IPcaller Mozilla ScribeNick aaaa aabb audio chrislowis colinbdclark cwilso ehsan gmandyam heath https inserted jernoble joined marcosc mdjp olivier padenot paul___irish rtoyg shepazu tobie toyoshiAw trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0673.html
Found Date: 05 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/05-audio-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.