[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #14 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > ...
> > 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!

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

Received on Saturday, 20 July 2013 03:13:25 UTC