Re: Call for Consensus: retire current ScriptProcessorNode design & AudioWorker proposal

> I don't know how much the overhead is, but that's probably a bit excessive optimization. Say with a buffer size of 128 @ 48kHz sample rate the overhead will be there 375 times a second. It would probably be in the same category of optimizations as using a shorter name for onaudioprocess. :)

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.

-Kumar

> On 14 Aug 2014, at 8:22 pm, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
> 
> On Thu, Aug 14, 2014 at 6:59 AM, Srikumar K. S. <srikumarks@gmail.com> wrote:
>> Also I imagine there'll be some overhead to running JS on the audio thread that would be nice to avoid.
> 
> 
> With JS running in the audio thread, the most exciting possibility performance-wise (imho) is to have 
> the worker code use asm.js to limit/avoid GC and have much better performance than normal JS. 
> (I’ve seen up to 5x gain relative to normal JS.)
> 
> If no external JS interactions are done, there is no reason for such code to behave any 
> differently than the native nodes themselves. JS itself becomes the “shader lanaguge” here.
> 
> Agreed, and WRT the shader language for audio, I think the discussion should finally be put to rest. asm.js already provides us a (poorly compressed) "byte code" into which you can compile whatever audio shading language you come up with. And actually, if at some point WebGL lands in workers, it means you can also compile that nice shader language into GLSL and have your audio running on the GPU just in case of those high parallel operations. ;) The nice thing is, WebGL is synchronous so you can use it seamlessly with the synchronous API.
>  
> The only remaining unavoidable non-native overhead perhaps is message passing for 
> onaudioprocess, perhaps? Likely even that can be optimized away.
> 
> I don't know how much the overhead is, but that's probably a bit excessive optimization. Say with a buffer size of 128 @ 48kHz sample rate the overhead will be there 375 times a second. It would probably be in the same category of optimizations as using a shorter name for onaudioprocess. :)
> 
> - Jussi
>  
> 
> -Kumar
> 
>> On 14 Aug 2014, at 8:50 am, Robert O'Callahan <robert@ocallahan.org> wrote:
>> 
>> On Thu, Aug 14, 2014 at 3:22 AM, Chris Wilson <cwilso@google.com> wrote:
>> On Tue, Aug 12, 2014 at 5:32 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> Running JS sync in the audio thread is also suboptimal: it means that JS misbehavior can cripple audio processing. I find it easy to imagine cases where I'd rather have all my JS analysis code running on the main thread to minimize the possibly of breaking my audio output, even though there's a small latency penalty.
>> 
>> True enough.  But in that case, you can simply transfer the data over to another thread to do the processing there, yes?
>> 
>> You can, but it's simpler and safer to be able to avoid running any JS on the audio thread in the first place.
>> 
>> Also I imagine there'll be some overhead to running JS on the audio thread that would be nice to avoid.
>> 
>> Rob
>> -- 
>> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
>> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
>> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
>> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
>> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
>> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
>> otohoeo ofoioroeo ooofo ohoeololo.
> 
>