Re: New proposal for fixing race conditions

> Instead of using AudioBuffers, we could use typed arrays directly, like this:

I prefer this as a developer for its simplicity. In fact, I have a wrapper for
script nodes [1] that adds support for a few extras, including
scheduling script nodes, cleaning them up and a-rate AudioParam 
inputs. In this wrapper the input and output buffers are passed
directly as Float32Arrays close to your suggested interface.

-Kumar

[1] https://github.com/srikumarks/steller/blob/master/src/models/jsnode.js

On 21 Jul, 2013, at 5:56 PM, 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.
> 
> Any thoughts?
> 
> /Marcus
> 
> 
> 
> 
> 
> On Sun, Jul 21, 2013 at 12:56 AM, Marcus Geelnard <mage@opera.com> wrote:
> Hi Russel,
> 
> I'm also a big fan of the ScriptProcessorNode (in fact, it's the one I use the most), so I'm quite concerned with it's performance too.
> 
> 
> On Saturday, July 20, 2013, Russell McClellan <russell@motu.com> wrote:
> > I'm not sure I fully understand this new proposal by Jer, but it seems like it requires a new allocation of an audio buffer every time a ScriptProcessorNode processes an event.  If I'm right about this, my intuition is that this will degrade the performance characteristics of the ScriptProcessorNode.  I could be wrong about either of these propositions - please correct me if I am.
> >
> 
> Yes, but with Jussis proposal of adding an in-place get operation there's no need for creating new objects. You'd still have to do two memcpy:s per event for a signal processing script node (only one memcpy for a signal generator). In general I don't think that it is a big performance hit (the memcpy will likely be much cheaper than any JS processing going on in the event handler), but this might be one use case that would benefit from ownership transfer (i.e. neutering).
> 
> At this point I'm not all that concerned though. Any performance enhancing API additions could be added later.
> 
> /Marcus
> 
> 
> > This situation is sort of unfortunate from my perspective (i.e. a potential user of the API), as we already have a thread-safe proposal on the table that doesn't significantly degrade the performance of ScriptProcessorNode (i.e., Robert's initial proposal).  As a user, I would prefer as much performance as possible from the ScriptProcessorNodes.
> >
> > Thanks,
> > -Russell
> >
>