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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723#13) by Srikumar Subramanian (Kumar) on W3C Bugzilla. Sat, 20 Jul 2013 03:13:23 GMT

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

Sure. Understood. I just did a quick-n-dirty estimate of what this rate can be. It looks like the average time can be 0.5ms in Chrome. Gist here - https://gist.github.com/srikumarks/6043702

Btw the offline processing doesn't need to be in a real-time thread and probably shouldn't be, since it is running "as fast as it can". It should perhaps be in the same class as the threads used by web workers.

> Hopefully, soon we can get a real-world setup going along with trace points
> in Chrome to play with.

Looking forward to it!

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