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

[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

From: <bugzilla@jessica.w3.org>
Date: Tue, 23 Jul 2013 23:31:44 +0000
To: public-audio@w3.org
Message-ID: <bug-22723-5429-xi8X37Vpsb@http.www.w3.org/Bugs/Public/>
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

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