- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Jul 2013 23:31:44 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723 --- Comment #23 from Chris Rogers <crogers@google.com> --- (In reply to comment #21) > 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... -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 23 July 2013 23:31:45 UTC