The future and direction of web audio

Hello guys,

Hope you're all having a nice summer! (Get well, Al!) I feel a bit like a
broken record for going on with this again, but bare with me.

I think there's an important point we need to think about when we're
designing this API. If we do this wrong, so many people are going to be
really mad at us. Audio APIs have the problem that if you can't do much with
the core, you can't do much with the rest either. That's why I've been
touting "freedom, freedom..." for some time now. At first, I think it's of
utmost importance that we stop premature optimization with this API, it is
going to shoot us in our backs, there's no question of it. So next time
we're suggesting taking away a freedom – such as the programmer being able
to decide the sample rate – think of the justifications. If it's
performance, think again, not good enough, not future-proof. Computers are
going to get faster, that's inevitable. (Once the graphene sheets hit the
market, the processing power of consumer computers is forecast to be
300-3000x the current) Twenty years from now, if people are still using this
API, they won't be damning it because it isn't fast enough, but because they
can't do what they want with it.

I'm not saying we shouldn't keep performance in mind, it's an important
thing, but I think no compromises should be made in the name of performance.
Same goes a bit for implementation difficulty, but of course, some of us are
going to be the ones writing the implementations as well, so I understand
you guys disagreeing on such points. This means I have nothing against the
idea of pre-defined standard purpose processing nodes, to serve as the basis
for games, etc, and to provide extra performance, they're not hurting any
freedoms I'm seeing. However, Chris mentioned earlier something about adding
a reasonable maximum value for the sample rate and unless there's a good
reason for it, I'm not convinced that such a thing should exist.

So, what I'm saying here is... We're making specs, and we've been given
relatively free hands at that, making us a very unique standards working
group indeed (wouldn't you agree, Doug? ;) ), so let's be idealistic! Let's
make this thing future-proof, and think more of the spec than the
implementation. Like Philip said on Twitter "we only get one chance at
designing this API".

Cheers!
Jussi

P.S. Doug, Al, what's happening with adding Amos Wenger (the guy behind
JSMad) as an invited expert to the group?