Re: Resolution to republish MSP as a note

On Mon, Aug 6, 2012 at 9:59 PM, Chris Wilson <cwilso@google.com> wrote:

> On Mon, Aug 6, 2012 at 11:31 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> I believe that if we strip all the native nodes from the Web Audio API,
>> the MSP API offers a solution to far more problems than the Web Audio API.
>> Not to mention that combined with Marcus' DSP API, even the performance
>> benefits can at least be equaled in many cases.
>>
>
> Obviously, I'm not in favor of this (no surprise, I'm sure).  I would like
> to ask, 1) how does the MSP API offer a solution to far more problems than
> the WA API?  Other than the presumably more scalable latency, I don't see
> how it's really any different; I think the concerns Peter raised were about
> latency in using multiple JS nodes in WA, while still trying to use the
> routing system in significant and interesting ways.  2) Can you elaborate
> on how the performance can be "at least" equaled?  I don't see how you
> expect to get significantly better performance than natively-implemented
> code doing DSP operations on a separate high-priority thread.
>

1) For one (a gargantual one), it offers a solution for video/picture as
well. This would make it less of a problem to drop main thread support for
audio processing as well, as for example in the biggest blocker case
(emulators) the graphics could be manipulated from the same thread as the
audio. [1]
2) Marcus expressed my meaning behind this thought. And no, I didn't mean
that the MSP API would magically have better performing worker processors
(as Chris R pointed out). What I mean is that when you multiplex the nodes
in a graph into a single node, you can optimize it directly as Marcus said,
at which point the performance might be better, or worse to a degree that's
insignificant and becomes less significant over time. At that point, what's
the virtue of Web Audio API vs MSP API & DSP API?

Cheers,
Jussi

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415