- From: <bugzilla@jessica.w3.org>
- Date: Tue, 31 Jul 2012 05:52:58 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415
--- Comment #87 from Marcus Geelnard (Opera) <mage@opera.com> 2012-07-31 05:52:58 UTC ---
(In reply to comment #85)
> 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?
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 31 July 2012 05:53:01 UTC