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

Re: Call for Consensus: retire current ScriptProcessorNode design & AudioWorker proposal

From: Chris Wilson <cwilso@google.com>
Date: Wed, 13 Aug 2014 08:27:23 -0700
Message-ID: <CAJK2wqVRK7G4-iRTE2+Ph+-D6W+U9b6+RmAxXJ3kHJ48qjdCDg@mail.gmail.com>
To: "Srikumar K. S." <srikumarks@gmail.com>
Cc: Joseph Berkovitz <joe@noteflight.com>, Raymond Toy <rtoy@google.com>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <olivier.thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>
On Tue, Aug 12, 2014 at 5:47 PM, Srikumar K. S. <srikumarks@gmail.com>

> 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.

> 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

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