Re: Aiding early implementations of the web audio API

On Tue, May 22, 2012 at 11:06 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> This is where JS libraries come in. There's already a variety of
> frameworks to make these concepts more easily approachable, all quite
> different with their pros and cons. If you look at web APIs in general, the
> common pattern is that the required features are specified, then different
> frameworks evolve and possibly a later effort is made to standardize some
> APIs that have become used widely enough so that it makes sense to
> standardize them, either to allow the frameworks to tap into performance
> benefits or just define parts of the frameworks that all the frameworks
> share as a standard.
>

What level do you believe we should be codifying, then?  Because if I take
that approach to its logical conclusion, I really do end up thinking you're
looking for something that only defines the input and output streams, and
the developer is on their own for everything in between.  That's certainly
simple enough.  I don't think we're going to see a lot of audio apps being
built if that's all the support they get, though.  And there's nothing
preventing those apps from being built today, then - with the AudioData
API, e.g. - and from the appropriate support libraries being built.  But
they're not.

To go back to something you said earlier - I would point out that leaving
all this audio processing in JavaScript is likely to leave you with LARGER
performance deltas between implementations, unless you somehow get everyone
to optimize their JS runtimes similarly around your audio library - in
which case, you might as well be baking it in.  For anything we put in a
TR, we'll need a test suite, so I presume the variations would be somewhat
dealt with.


> This approach allows for the "cows to pave the path", so that the web
> platform isn't overspecified with APIs that nobody wants to use (I'm not
> saying nobody wants to use Web Audio API, heh, however I think it would be
> better off as a JS library).
>

I'm generally in favor of paving cow paths where they exist.  I'm not as
pleased with turning a bunch of cows out into the forest and seeing what
they come up with as a design methodology, though.

I have actually thought through the API from the perspective of "what do we
really need, anyway?" - I don't want you to think that I'm having a
knee-jerk reaction.  I don't personally have an investment here, other than
wanting to see the same explosion of audio apps on the web platform that
I've seen on, say, my iPad.

-C