[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723

--- Comment #7 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > I accidentally hit "save changes" before I got a chance to read what I'd
> > typed. Apologies for the duplication. Here it is, edited -
> > 
> > --
> > I agree with Ehsan here. The only reason it is convenient to have a buffer
> > size specifiable for a script processor node is to tweak it to avoid audio
> > glitching, since (as Ehsan pointed out) we can always code up any delays we
> > require for an application in the onaudioprocess callback. This is not
> > useful for offline processing.
> > --
> 
> I'm just trying to get clarification and more detail on what you mean here,
> since I'm working on a prototype right now.  Maybe this is already clear to
> you, but just wanted to make sure...
> 
> In the general case, a ScriptProcessorNode has *both* input and output data
> and acts as a signal processor.  In order to achieve zero latency, the
> buffer size has to be 128, the same as the rest of the native nodes.  If
> this were not the case, then the .onaudioprocess handler could not be called
> until enough input samples (>128) were buffered (for the .inputBuffer
> attribute of the AudioProcessingEvent), thus introducing a latency.

Understood. To restate in more concrete terms what I said, it would be
acceptable, I think, if script processor nodes created on offline audio
contexts supported *only* buffer durations of 128 and threw an exception for
other values. It would also be acceptable if implementations simply ignore the
requested buffer size in this case and always used 128. 

The notion of "latency" in this context may need some clarification and it is
perhaps better to just translate this term as "delay in a signal path". If the
script node's output is piped through some processing that gets fed back into
the script node, then it won't (obviously) see the effect of its output until
it actually generates it. There would therefore be a (minimum) delay of
BUFFER_LENGTH samples before it gets to see its output signal on its input pin.
In the absence of feedback, there need be no "latency" at all.

Consider this simple graph: 

    source ----> script-node --------> destination
       |                                   ^
       |                                   |
       \----> some filter node ------------/

Suppose the script node has a buffer size of 1024 set (= 128*8). The script
node will produce output only once every 8 blocks. If for any block the
destination node does not receive audio on one or more of its inputs, it
*could* buffer the others until it has some audio from all of its inputs before
proceeding to mix them (partial mix downs would be an optimization). If this
were the destination's behaviour, then there would be no *audible* signal delay
in the script node's path and this graph would effectively behave as though its
block size was set to 1024 and not 128 (except for k-rate animated parameters
which will update more frequently for the native nodes).

If every node used this "wait for all inputs before running" logic, then script
nodes with buffer sizes greater than 128 need not impose a delay in their
signal paths. However, such a script node now imposes a memory cost
proportional to its buffer length (minus 128) on all multi-input nodes
immediately dependent on its output (ex: a channel muxer will have to buffer
all other inputs until it gets some from a script node connected to one of its
inputs). 

A simple way to avoid such additional "invisible" memory costs and the
additional buffering logic is to only support the native block size of 128 for
script nodes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 19 July 2013 21:24:51 UTC