Re: New proposal for fixing race conditions

I agree, I don't actually see any benefit in ScriptProcessorNode operating
on AudioBuffers, since all you really care about is the data in them.

Cheers,
Jussi


On Sun, Jul 21, 2013 at 6:24 PM, Srikumar Karaikudi Subramanian <
srikumarks@gmail.com> wrote:

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