Re: Questioning the current direction of the Web Audio API

> To the extent that it is a problem today, it's partly because present-day
implementations are running the JS in these nodes in the main thread.

Let's suppose ScriptProcessorNode is optimized and runs in the audio
thread? (Therefore minimizing IPC). And let's suppose 2 benchmarks, which
for me summarize the important questions.

1)
Test1.1 is N ScriptProcessorNodes, each of them running an algorithm A.
Test1.2 is one ScriptProcessorNode running N times the algorithm A.

2)
You have a really big graph. Test2.1 connects together native AudioNodes
and/or ScriptProcessorNodes. Test2.2 implements the exact same dsp graph as
a highly optimized dsp function using asm.js, running in a single
ScriptProcessorNode.

In 1) do you think it is possible to bring the execution time of Test1
close to the execution time of Test2 by improving ScriptProcessorNode?
In 2) do you think the Test2.1 will always be faster than Test2.2?

In fact ... the Test2 could already be done! I should try ...



2013/10/19 Joseph Berkovitz <joe@noteflight.com>

>
> On Oct 19, 2013, at 12:02 PM, s p <sebpiq@gmail.com> wrote:
>
>
> And no matter if there is more nodes in the futures, there is just no way
> all the basic building blocks for all the algorithms humans can ever
> conceive can be provided as AudioNodes (and that sucks. Because on
> basically every other plateform, there is no limitation).
>
>
> Of course AudioNodes can't be provided for everything. That is why
> extensibility is important, and ScriptProcessorNode is at present the
> vehicle for doing so.
>
> Second, if you understand that professionals need things that can't be
> built with basic AudioNodes, you understand that ScriptProcessorNode will
> be more than just an escape valve.
>
>
> "Escape valve" was an understatement on my part. I completely agree that
> ScriptProcessorNode is essential to any professional, wide-ranging use of
> the API.
>
> Now the big problem with that is : you will need to instantiate multiple
> ScriptProcessorNodes in your graph, connect them with native AudioNodes,
> and because of the sum of the overheads of using ScriptProcessorNodes, you
> will end-up in a situation where it is actually more performant to just put
> the whole dsp function into ONE single ScriptProcessorNode, re-implementing
> oscillators, convolutions, and the whole thing ... making native AudioNodes
> useless. That's what I mean by "this architecture is impossible to extend".
>
>
> I don't think your analysis is correct about ScriptProcessorNodes *for all
> time*. To the extent that it is a problem today, it's partly because
> present-day implementations are running the JS in these nodes in the main
> thread. This can impose inter-thread communication overhead that is highly
> implementation-dependent. To address this issue does not (to my mind) mean
> changing the entire direction of the Web Audio API. It means the overhead
> of ScriptProcessorNodes -- or whatever succeeds them in later API versions
> -- must be minimized through various means.
>
> The WG has received similar feedback regarding ScriptProcessorNodes from
> other parties as well including internal W3C reviewers. These reviewers
> have not concluded that AudioNodes are "useless"; rather, they have
> requested that Web Audio address its present shortcomings and made some
> positive proposals on how to do so.
>
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>
>


-- 
*Sébastien Piquemal
*
*
** *-----* @sebpiq*
 -----* *http://github.com/sebpiq*
*
 ----- http://funktion.fm