Re: New proposal for fixing race conditions

Hi Jer,


On Mon, Jul 22, 2013 at 5:35 PM, 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?
>

Actually, here's how I figured it should work (not sure if you agree that
it's a fitting solution, or if it will work as I hope it should):

1. The input and output arrays are allocated & maintained by the audio
engine.
2. When the event is fired on the main JS thread, the arrays will be
transfered to the JS thread (i.e. typed array objects are set up pointing
to the audio engine's arrays).
3. The event handler can read the input arrays and write to the output
arrays as it wishes.
4. When the event is finished (returns), the arrays are neutered in JS
land, and the ownership is transfered back to the audio engine.

During 3), the audio engine must obviously not access the arrays.

This would mean zero memcpy:s, and full freedom to modify the output
buffers as you wish.

My guess is that this is very similar to the current solution in gecko
(Ehsan?).

/Marcus



>
> 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
>