Re: New proposal for fixing race conditions

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