W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: New proposal for fixing race conditions

From: K. Gadd <kg@luminance.org>
Date: Mon, 22 Jul 2013 10:19:08 -0700
Message-ID: <CAPJwq3XRDESJ6X1LhBVkZu3xwZ1J6s4_865DcnuqZA9Cwfr_Mg@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Marcus Geelnard <mage@opera.com>, Russell McClellan <russell@motu.com>, WG <public-audio@w3.org>
The upside to ownership passing is that you can do the initial computation
on a web worker, then transfer the complete buffer to the main thread
(without a copy), and then transfer the buffer again when the
AudioProcessingEvent arrives, I think...


On Mon, Jul 22, 2013 at 8:35 AM, 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?
>
> 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
>
Received on Monday, 22 July 2013 17:20:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC