Re: Proposal for fixing race conditions

On Thu, Jul 18, 2013 at 2:58 PM, Jer Noble <jer.noble@apple.com> wrote:

>
>
> On Jul 18, 2013, at 1:07 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
> > So how about a JavaScript-based Opus decoder that uses an
> AudioBuffer-backed ring buffer to do memcopy-free decoding and playback by
> decoding directly into a mutable AudioBuffer.
>
> I'm not sure I understood what you're saying here correctly, but you seem
> to be implying that the decoder would run in the main thread which is quite
> suboptimal. What we do in aurora.js (the JS audio decoding framework) is
> that a worker handles the decoding and streaming to avoid clogging the main
> thread + lower the risk of glitches and the worker uses transferable
> ArrayBuffers to avoid copying when juggling between threads. What the main
> thread does is feed that data into a ScriptProcessorNode and IIRC passing
> the ArrayBuffer back to the worker. The worker at no point even knows what
> and AudioBuffer is. So far this seems like the most optimal solution, but
> it already includes a copy of the data.
>
>
> Wherever the decoding occurs, whether on the main thread or in a worker,
> the "immutable ArrayBuffer" option will require two buffers in existence:
> the source ArrayBuffer, and the destination AudioBuffer.  This can result
> in a doubling of memory usage by the decoder.
>

Hmm, the original ArrayBuffer will get GCed if the content code is not
holding on to it, right?  And if they are, that is memory that the content
is keeping alive.  Surely we're not trying to solve the problem of making
it impossible for content to write code which results in an OOM, etc.,
right?  Or am I missing something?

--
Ehsan
<http://ehsanakhgari.org/>