Re: New proposal for fixing race conditions

The upside to ownership passing is that you can do the initial computation
on a web worker, then transfer the complete buffer to the main thread
(without a copy), and then transfer the buffer again when the
AudioProcessingEvent arrives, I think...


On Mon, Jul 22, 2013 at 8:35 AM, Jer Noble <jer.noble@apple.com> wrote:

>
> On Jul 21, 2013, at 2:56 AM, Marcus Geelnard <mage@opera.com> wrote:
>
> ...actually, after doing some more thinking, I figured that the
> AudioProcessingEvent does not have to provide AudioBuffers for the
> input/output. The information provided by the AudioBuffer is already known
> (sampleRate must be the same as AudioContext.sampleRate, and duration -
> well, you know the size of the buffer to process).
>
> Instead of using AudioBuffers, we could use typed arrays directly, like
> this:
>
> interface AudioProcessingEvent : Event {
>
>     readonly attribute double playbackTime;
>     readonly attribute sequence<Float32Array> input;
>     readonly attribute sequence<Float32Array> output;
>
> };
>
>
> Then I think that it would be possible to define the event based on
> ownership transfer, i.e. the input/output arrays are valid only during the
> event, and once the event handler finishes the arrays are neutered. That
> would eliminate the need for memcpy and provide performance that should be
> on par with the current (racy) solution.
>
>
> If the only thing your ScriptProcessorNode is doing is ownership-passing
> pre-rendered buffers, why aren't you using an AudioBufferSourceNode?
>
> Basically, if your event handler is doing any computation, the results of
> that computation will need to be copied into an output buffer. There should
> be no benefit to memcpy'ing to a local buffer then ownership passing over
> memcpy'ing directly to the ouput buffer.
>
> -Jer
>