Re: [web-audio-api] OfflineAudioContext and ScriptProcessorNodes (#69)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723#22) by Chris Rogers on W3C Bugzilla. Tue, 23 Jul 2013 23:31:44 GMT

(In reply to [comment #21](#issuecomment-24244270))
> If we allow the UA to set the ScriptProcessorNode buffer size, we can
> potentially use larger ScriptProcessorNode buffer sizes. For example, if
> there's one ScriptProcessorNode in the graph and it's not in a cycle, we can
> process N blocks for all the nodes before the ScriptProcessorNode, run the
> ScriptProcessorNode with a buffer of N*128 samples, and then process N
> blocks for all the nodes after the ScriptProcessorNode.
> 
> BTW, no matter how we resolve the block size issue, there's a quite severe
> problem we need to address: what happens if the ScriptProcessorNode's event
> handler modifies the audio graph. This isn't a big problem when the event
> handler is running asynchronously (the current situation), but it becomes a
> huge problem when we're effectively running it synchronously.

Yes, you're right there.  One solution is to forbid graph manipulation in that case.

We could still allow graph manipulation with OfflineAudioContext if we're allowed to call startRendering() more than once.  Then we could be allowed to modify the graph each time the .oncomplete handler is called...

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