Re: [web-audio-api] OfflineAudioContext and ScriptProcessorNodes (#69)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723#6) by Srikumar Subramanian (Kumar) on W3C Bugzilla. Fri, 19 Jul 2013 21:24:50 GMT

(In reply to [comment #6](#issuecomment-24244170))
> (In reply to [comment #5](#issuecomment-24244160))
> > 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.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/69#issuecomment-24244176