On Jul 30, 2013, at 4:45 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> The AudioBuffer constructor that takes an array (or sequence) of Float32Arrays needs to specify that it copies the contents of those arrays (I believe that's your intent?).
>
> Yes, as Ehsan pointed out, this should be a sequence, which requires that the contents are passed by value[2], not by reference.
>
> Yes, but you still need to specify that the contents of the Float32Arrays are copied.
Reasonable enough.
>
>> Are they fresh AudioBuffers every time an event fires, or do values get reused?
>
> Implementation detail.
>
> I don't think so. Scripts can observe whether the AudioBuffer passed in an event is the same as AudioBuffers previously passed to the event, by storing a reference to the previous AudioBuffers and comparing references. Even worse, someone might do something like
> scriptProcessorNode.onprocess = function (event) { bufferList.push(event.inputBuffer); };
> in which case it definitely matters whether AudioBuffers are being reused!
Well, this isn’t a change from the existing spec. So if you believe this is underspecified, we should fix it regardless of the outcome of the data race issue.
>
>> And what is the state of the initial outputBuffer object?
>
> What is the state now?
>
> Not super well specified. I think you want to say it's an empty (zero) buffer with numberOfOutputChannels channels each of length bufferSize (both values taken from createScriptProcessor), ...
Ditto about the underspecification in the existing spec.
> and "not currently in use". (Does it go into the NO_MODIFICATION_ALLOWED_ERR state when the event handler returns?)
This, however, is new, and should be clarified in my proposal.
-Jer
Received on Tuesday, 30 July 2013 23:50:19 UTC