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

Re: Proposal for fixing race conditions

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Fri, 19 Jul 2013 10:22:32 +0300
Message-ID: <CAJhzemV-t9YXxV6EW-7nij7WeBboMg7vbB_BcB250BTGdWNZfg@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: Jer Noble <jer.noble@apple.com>, "Robert O'Callahan" <robert@ocallahan.org>, Marcus Geelnard <mage@opera.com>, WG <public-audio@w3.org>, "K. Gadd" <kg@luminance.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
On Fri, Jul 19, 2013 at 5:15 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> But Web Audio is part of the Web platform, and its architecture is
> inspired by and built on the same building blocks as other parts of the Web
> platform.
> Also, given the current effort to port WebGL and 2D canvas to Workers,
> there will probably be demand for Web Audio in Workers, soon.  In fact,
> this was recently discussed within Mozilla.  So I don't believe that the
> mention of Workers is inappropriate here.

Especially since in most cases the Web Audio API will most likely be used
in combination with other APIs, and for example for games I believe physics
engines will start offloading to workers which means that in many use cases
of Web Audio the cost of neutering is already sunk (physics engines are
sure to use transferrables). In that sense I find that if you (Jer) resist
neutering specifically in the case of Web Audio a bit odd.


About doubling the memory usage of the decoder... We're using the buffer
size of 4096 for the ScriptProcessorNode in aurora.js, so if an additional
cost of 32KB (4096 * 2 /*channelcount*/ * 32b) doubles the memory usage of
the decoder, I'll be happy man. Even with a different architecture the copy
and keeping a double buffer is unavoidable in most cases anyway, because
the Web Audio API doesn't support live resampling so we have to resample
the audio coming from the decoder. As a side note, copying to the audio
buffer is the least of our memory and CPU concerns, the lack of
controllable XHR binary streaming is our biggest performance sinkhole by


> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
Received on Friday, 19 July 2013 07:22:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC