[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #10 from Chris Rogers <crogers@google.com> ---
(In reply to comment #9)
> Another point I wondered about is whether the "back and forth" between the
> audio processing thread and the main thread to process a script node will
> force sub-realtime rendering for offline audio contexts in current browser
> architectures. 
> 
> Currently, it is not unreasonable to expect a delay of 4ms between event
> firing and callback invocation. That limits the number of calls that can be
> made to a script node to 250 calls per second. If a block size of 128 is
> used, that might limit the rate of generating audio samples to 32KHz. The
> longer the event->callback delay, the worse this gets.

Yes, it's true that running the ScriptProcessorNode at size 128 is a
performance penalty, so it's probably best to not force the ScriptProcessorNode
to process using a buffer size of 128.  I was just saying that *if* we would
like the ScriptProcessorNode to have zero in/out latency, then we'll need 128
buffer size.

I"m fairly sure the dire prediction of delay of 4ms is not something we would
normally see, based on my experience of the WebKit/Blink code.  I haven't yet
had a chance to determine the exact performance hit, but we have nice tracing
features in Chrome to get quite a detailed picture.  I'll try some experiments
here...

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

Received on Friday, 19 July 2013 22:18:40 UTC