Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#86) by Marcus Geelnard (Opera) on W3C Bugzilla. Tue, 31 Jul 2012 05:52:58 GMT

(In reply to [comment #85](#issuecomment-24244774))
> I think there's been a misunderstanding that somehow the JavaScript code
> rendering audio in a JavaScriptAudioNode callback will block the audio thread! 
> This is not the case.  An implementation should use buffering
> (producer/consumer model) where the JS thread produces and the audio thread
> consumes (with no blocking).  This is how it's implemented in WebKit.

How does this work in a subgraph similar to this?:

+------------+      +---------------------+      +------------------+
| SourceNode |----->| JavaScriptAudioNode |----->| BiquadFilterNode |
+------------+      +---------------------+   +->|                  |
                                              |  +------------------+
+------------+      +---------------------+   |
| SourceNode |----->|    AudioGainNode    |---+
+------------+      +---------------------+

(hope this ASCII art works)

I assume that without the input from the SourceNode, the JavaScriptAudioNode will not be able to produce anything (hence its callback will not be fired until enough data is available), and likewise the BiquadFilterNode can not produce any sound until data is available from both the JavaScriptAudioNode and the AudioGainNode.

In other words, if the JavaScriptAudioNode callback in the main thread is delayed by a setInterval event, for instance, i guess that at least the BiquadFilterNode (and all nodes following it?) will need to halt until the JS callback gets fired and finished so that it has produced the necessary data for the graph to continue?

I guess that the lower part of the graph (source + gain) could produce data ahead of time while the JS node is blocking, but I assume that it could be problematic in some cases (e.g. if there are loops or other intra-node dependencies, such as a panner node somewhere controlling the pitch of the source node), so perhaps it's simpler to just let it be blocked too?

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244784