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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723#12) by Chris Rogers on W3C Bugzilla. Fri, 19 Jul 2013 23:38:43 GMT

(In reply to [comment #12](#issuecomment-24244205))
> (In reply to [comment #11](#issuecomment-24244200))
> > 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.

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