I'm not entirely sure what Chris was testing in that mail thread, but yes, there's no inter-thread communication, making this essentially just a JS function call. ROC: yes, it would be safer to move any JS at all out of the main thread, if the JS is non-essential to producing the audio. If the JS is producing audio output, if it's going to cause glitches it's going to cause glitches in or out of the thread. This would only apply to heavy-CPU analysis. On Thu, Aug 14, 2014 at 9:57 AM, Joseph Berkovitz <joe@noteflight.com> wrote: > > On Aug 14, 2014, at 12:36 PM, Srikumar K. S. <srikumarks@gmail.com> wrote: > > Some time ago, Chris Rogers estimated that he can push about 20000 > messages a second max ( > http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0233.html). > The time available to compute a 128 sample block is about 2.5ms. If Chris’s > estimate is indeed the max performance we can get, these message passes are > eating away about 2% of the time available for each script node > instantiated. If you want to leave say 75% of the time available to actual > signal calculations, you can at most instantiate about a dozen script nodes > I think. Since the message passing needed is now synchronous, it seems to > me to be both possible as well as useful to have this overhead taken out. > > > Chris W should confirm, but I don’t think this overhead applies to the new > design at all. There is no “message passing” associated with onaudioprocess > in the new proposal as each event dispatch is a synchronous invocation > within the audio thread. > > …Joe > > . . . . . ...Joe > > *Joe Berkovitz* > President > > *Noteflight LLC* > Boston, Mass. > phone: +1 978 314 6271 > www.noteflight.com > "Your music, everywhere" > >
Received on Thursday, 14 August 2014 20:24:11 UTC