- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Jul 2013 23:22:44 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723
Robert O'Callahan (Mozilla) <roc@ocallahan.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roc@ocallahan.org
--- Comment #21 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> ---
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.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 23 July 2013 23:22:45 UTC