Re: New proposal for fixing race conditions

One more point -

It is not worth worrying about memcpy costs for the input/output 
buffers of script processor nodes since these buffers are small.
These costs can be significant only for buffers created from
pre-generated audio, loaded samples and such.

A possible criterion for examining copy costs and API design might 
be to imagine an implementation of the Web Audio API that uses a 
client-server architecture (like the one SuperCollider has) - where 
all the major audio computation happens not just in a separate 
thread, but in a separate process. Then the objects exposed in JS 
merely *represent* server-side objects. It is certainly possible to
provide a performant audio and synthesis library with this 
architecture. So the API design criterion becomes "minimize the
communication overhead between the client and the server".

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