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

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

From: Srikumar K. S. <srikumarks@gmail.com>
Date: Wed, 13 Aug 2014 07:37:28 +0530
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>
Message-Id: <31279333-40F3-410E-AFEF-F5CAF06D331D@gmail.com>
To: adelespinasse@gmail.com
Great point! 

For the realtime case, I believe passing back messages from an audio worker node to the main thread would be enough. For offline audio context, it won’t suffice and we will need a sync mechanism. In fact, I just realized that to even access “currentTime”, we’d need access to the audio context within a worker node .. which the current proposal doesn’t provide and therefore playbackTime is not redundant as the proposal stands.

-Kumar

> On 13 Aug 2014, at 7:03 am, Alan deLespinasse <adelespinasse@gmail.com> wrote:
> 
> 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: https://github.com/WebAudio/web-audio-api/issues/69#issuecomment-24244290
> 
> 
> On Tue, Aug 12, 2014 at 8:56 PM, Srikumar K. S. <srikumarks@gmail.com> wrote:
>> 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 02:08:04 UTC

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