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. Jer: 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 far. Cheers, Jussi > > > Cheers, > -- > Ehsan > <http://ehsanakhgari.org/> > >
Received on Friday, 19 July 2013 07:22:59 UTC