[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #6 from Chris Rogers <crogers@google.com> ---
(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.

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

Received on Friday, 19 July 2013 19:28:30 UTC