Re: New proposal for fixing race conditions

On Jul 19, 2013, at 11:54 AM, Chris Rogers <crogers@google.com> wrote:

> Jer, thanks for sharing the proposal.
> 
> I can't support a solution like this because it:
> 
> 1. Forces the need for copies both for setting and reading data.  PCM data is large and it's inefficient to be required to copy.
> 2. It needlessly complicates the API, where we now have a simple solution.
> 3. The "problem" it is supposed to solve is effectively a non-issue.


I agree with 3, as I’ve stated before repeatedly.  Even so, it is not unhelpful to propose a concrete ‘solution’, if only to have something concrete to discuss performance tradeoffs.

I disagree with 2; it simplifies the API by re-using existing method names (set(), slice(), etc.) from similar classes.

I (partially) disagree with 1.  For the standard playback model, there are precisely 0 extra memcpys and mallocs: decodeAudioData will continue to emit AudioBuffer objects which can be passed directly to an AudioBufferSourceNode.  It is only generated audio which requires an additional memcpy, and only for upfront data creation. ScriptProcessorNode playback requires the same number of copies as before.

Readback of decoded data will require extra copies.  This is necessary achieve the intended outcome.  For certain use cases, such as permutation of decoded data, OfflineAudioContext can be used to efficiently read and write AudioBuffers.

-Jer