W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

From: <bugzilla@jessica.w3.org>
Date: Sat, 20 Jul 2013 03:13:23 +0000
To: public-audio@w3.org
Message-ID: <bug-22723-5429-cCGhG8NJIg@http.www.w3.org/Bugs/Public/>

--- 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 -

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC