On Tue, Aug 12, 2014 at 5:47 PM, Srikumar K. S. <srikumarks@gmail.com> wrote: > Parallelism when running offline audio contexts can be nice to have, but > is already available > today even without having to use worker threads. If I'm mixing down 2 > tracks in an offline > context at the end, I can spin off one offline context for each track and > mix down the result. > True enough. > I have another question rgd the new worker node proposal. The script > node’s buffer lengths > declared in the spec are - 256, 512, 1024, 2048, 4096, 8192, 16384. > Whereas the context’s > native chunk length (for k-rate calculations) is 128. If script nodes are > being moved into > the audio thread, then is there any reason to not allow a buffer length of > 128 as well? > No. In fact, as I've started roughing out the AudioWorker spec, I simply removed all the buffering. The group may want it back in, but if we do put it back in we need to add latency exposure. The current partially-done spec proposal is at http://cwilso.github.io/web-audio-api/, BTW - sections 2.11 and 2.12, et al. This > would put script nodes completely on par with native nodes as far as I can > tell and, finally, > let us emulate native nodes using script nodes - which would be a great > way to provide > a reference implementation entirely based on script nodes. > We still need AudioParams to be exposed, but yes, the reference-impl-on-script-nodes possibility is a goal.
Received on Wednesday, 13 August 2014 15:27:51 UTC