Re: [web-audio-api] Visible Data Races (#254)

Now that the most problematic race is fixed (`AudioBuffer`), we still have to address the remaining problems, outlined in this [email](

Points (3) and (4) in the email has been solved by roc's proposal.

Those remaining races are:
- When calling `AudioContext.createPeriodicWave(Float32Array real, Float32Array imag)`, on both arguments ;
- `AudioParam.setValueCurveAtTime(Float32Array values, double startTime, double duration)`, on the `values` argument ;
- `AudioProcessingEvent.inputBuffer`, `AudioProcessingEvent.outputBuffer`: clarify the current spec text further ;
- `OfflineAudioCompletionEvent.renderedBuffer`.

Here is a proposal, taking into account some feedback from the thread at the time:
- Because `PeriodicWave`s maintain their own, internal, representation of the `real` and `imag` argument, specify that any modifications of these argument _after_ the call are not reflected in the `PeriodicWave`s.
- `setValueCurveAtTime`: we could simply copy the data. [Concerns]( have been expressed about performances on some specific use cases, however, no testcase/benchmark has been provided.
- `AudioProcessingEvent.(inputBuffer|outputbBuffer)`: we could simply drop the sentences:
> This AudioBuffer is only valid while in the scope of the onaudioprocess
> function. Its values will be meaningless outside of this scope. 

> Any script modifications to this AudioBuffer outside of this scope will not 
> produce any audible effects. 

  and simply state that different buffers should be used each time, making quite clear that modification of the buffer outside of the callback will not have any effect. (The `outputBuffer` case has been solved by adopting roc's proposal). Additionally fresh buffers should be used each time for the `outputBuffer` as well.

- `OfflineAudioCompletionEvent.renderedBuffer`, a new `AudioBuffer`
 should be used each time. 


Reply to this email directly or view it on GitHub:

Received on Friday, 18 October 2013 12:08:13 UTC