[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #13 from Chris Rogers <crogers@google.com> ---
(In reply to comment #12)
> (In reply to comment #11)
> > The 4ms delay is probably with relation to setTimeout(), right?  That is
> > enforeced artificially by browsers in order to prevent web pages from
> > spamming the main thread in exactly this way, it is not the actual delay of
> > event delivery.  In reality, the event delivery delays really depend on a
> > lot of factors invisible to the web application, such as how busy the event
> > loop is.  But it should be *much* lower than 4ms under most circumstances.
> 
> Not entirely. With the realtime script processor nodes, I've needed a buffer
> size of at least 1024 to avoid glitches due to UI events. Since that amounts
> to 23ms, I thought I was being rather optimistic in picking 4ms :)

There's a difference between a good "safe" buffer size for real-time operation
such as 1024 or 2048 to avoid glitches, since that's based on worst case
performance of any single .onaudioprocess invocation

compared with a non-realtime (perhaps and hopefully often faster than
real-time), we don't have to worry about "safe" sizes, and can do the
synchronization as fast or slow as it needs to be.  Although individual calls
to .onaudioprocess may take longer, the average time it takes to hop from the
real-time to the main thread will be much less than 4ms I believe.  Hopefully,
soon we can get a real-world setup going along with trace points in Chrome to
play with.

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

Received on Friday, 19 July 2013 23:38:44 UTC