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

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

From: Alan deLespinasse <adelespinasse@gmail.com>
Date: Tue, 12 Aug 2014 21:33:03 -0400
Message-ID: <CAMuhF-LEjwDwOyJnkj+T1Xv6rhKqhK3PSX5vVoxdyw2m5eqWrw@mail.gmail.com>
To: "Srikumar K. S." <srikumarks@gmail.com>
Cc: Chris Wilson <cwilso@google.com>, 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>
What about synchronous graph manipulation? Is there a consensus on that,
and will that be part of the new spec?

That is, the ability to modify the node graph (add/remove nodes or
connections, modify parameters) from the script node callback. Or maybe
from another timed callback that doesn't produce or consume audio samples
(presumably also in the worker thread).

As mentioned in yet another bug:

On Tue, Aug 12, 2014 at 8:56 PM, Srikumar K. S. <srikumarks@gmail.com>

> To me, it would even be acceptable to support *only* 128 since I’m happy
> to build in any
> other buffering I’d need. The buffer length argument of main thread script
> node was, I believe,
> introduced to give some control over potential UI/layout related
> stuttering by increasing latency.
> This would no longer be necessary with worker nodes since they’ll be
> running in the same
> thread.
> Also, if worker nodes are running synchronously in the audio thread, the
> playbackTime field
> in the event can perhaps be removed. It seems to me that playback time
> would be the same as
> currentTime or currentTime+bufferLength/samplingRate in all cases?
Received on Wednesday, 13 August 2014 01:33:32 UTC

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