Audiobuffer Race Conditions #66
Comments
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:
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": The proposal: 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. |
ghost
assigned
|
Paul, I'm assigning this to you. Implementing the decision into the spec should, IMHO, be near the top of your list of changes for the webaudio spec. Holler if you need clarifications or need help from the WG on details. |
|
This has been done in padenot@cded12c, waiting for the merge of the refactoring. |
|
Paul, I don't see the interface definition for copyChannelDataTo in the latest spec (nor in the padenot/web-audio-api@cded12c diff), does this mean that there is still some text to be added to the spec to fully implement ROC's proposal at https://wiki.mozilla.org/User:Roc/AudioBufferProposal ? |
|
On 19/02/2014 12:14, Olivier Thereaux wrote:
This page is not up to date, the spec text as committed represents the That said, I just noticed I failed to remove all the mentions of the old |
|
Pushed 5deadb3 |
This bugzilla entry tracks the Audio WG discussion about “Fixing Race Conditions”.
The initial proposal was by ROC on 21 June 2013:
http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0644.html
Discussion thread so far:
http://lists.w3.org/Archives/Public/public-audio/2013AprJun/thread.html#msg644
followed by...
http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg10
The text was updated successfully, but these errors were encountered: