The issue will be put to a vote. 

Proposed voting procedure and links to relevant rules in the W3C process have been announced on the mailing-list by the chairs. Archived at: http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0283.html

I think that the phrasing that Olivier proposed is a bit too close to agreeing on a final solution, but none of the proposed solutions are really ready yet (need more decisions and discussion).

I would like the phrasing to be slightly more more abstract, so that we can agree on a common mind-set for which we will solve the problems, for instance:

1. Keep the current API, with the shared memory solution. Specify the exact behavior in the Web Audio specification, and work together with other parties to work out what other specifications need to be updated/written, etc.

2. Based on RoC's proposal: Try to keep the current API, but remove any shared memory problems by using neutering as much as possible, and copying where necessary.

3. Based on Jer's proposal: Update the API in order to remove shared memory problems and make the interface more akin to existing Web interfaces.

Not sure if this is the best formulation - suggestions are welcome.

Yeah, I actually think that whether we go with ROC's proposal or Jer's proposal is not the important question, the important question is whether we're going to fix the problem in our own API or someone else's API. If we decide to fix this in our own API, we can then decide the details after that choice, from my point of view ideally by combining the best parts of the two proposals.

Hmm, if we're going to try to be more precise about these proposals, then the proponents of option 1 should have a specification of what the shared memory model is going to look like.  We should also have a list of all of the modifications to other specs in hand, and have at least initial buy-in from the editors of those specifications since without that we cannot be sure that we can adopt option 1 in practice.

Indeed, I think the first of any votes should be "keep a shared memory solution between the main thread and audio thread, or make changes to the API such that it does not use shared memory".

If we use ranked voting as Olivier suggested, it seems possible to distinguish between ballots that place #1 first (shared memory OK) and those that don't (shared memory not OK).

Being able to make this distinction in the responses does seem like the primary thing to resolve here. If we do wind up concluding that shared memory isn't OK, then regardless of the ballots I would expect we'll be looking at the alternatives and having further discussions about their merits.

Call for Consensus around the "ROC proposal":
http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0635.html

The proposal:
https://wiki.mozilla.org/User:Roc/AudioBufferProposal

Results expected on 2013-09-05

Based on the CfC on 2013-08-30 and the group teleconference on 2013-09-05 (http://www.w3.org/2013/09/05-audio-minutes.html#item01) the group has resolved that there was consensus around "ROC's proposal". From now on the group will work on fixing remaining issues with this proposal.

Web Audio API issues have been migrated to Github. 
See https://github.com/WebAudio/web-audio-api/issues

Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.