Re: Web Audio API Spec

Hi Jussi, thanks for the points.

On Mon, Jun 20, 2011 at 1:06 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> Hello guys,
>
> I've finally had the time to properly discuss this with people and to
> really think about it, so I have a few concerns of the current spec:
>
> First of all, the spec is way too non-specific. For example, if the spec
> says "a more advanced implementation could", that just gives too much
> freedom to implementations, and can result in serious pain to web
> developers. Say, some implementation decides not to implement a delay node,
> so if your application requires that behaviour, you have to have a pure js
> implementation and feature detection in place to counter that, and that just
> beats the purpose of having a higher level API.
>

I agree.  There are a small number of examples of this in the specification
that need to be made much more specific.  I'd like to work with you to help
fix the text in those places.


>
> The next thing is somewhat the same thing, this is also something that I've
> confirmed in my discussions with people. Currently the spec doesn't specify
> the exact algorithms to use with the processing of the nodes. That basically
> means that you'll never know what you get, making it impossible to write
> unit tests, and more importantly, for a DAW it's simply unacceptable that a
> musical piece would sound different on a different platform. Also beats the
> purpose of web as a "consistent" platform.
>

The specification can be made very specific with the exact mathematical
specification in all of the nodes.  This is clearly the case with the gain,
delay, panner, convolver, splitter, merger, analyser, and biquad-filter
nodes.  I put special consideration into designing a reverberation model
(convolution) that *can* be precisely defined by its algorithm.  Because
there is no standard and precise definition of a dynamics compressor
(although it's one of the most commonly used audio effects in games and
music), it's a little more difficult.  But we can specifiy its general
parameters of behavior such as attack, release, threshhold, ratio, etc. as
is generally accepted.


>
> Also, the current spec is very much wrong in a way that... It let's the
> implementation mandate the spec and not vice versa, and that is just not
> acceptable from my point of view, and that is also confirmed in my
> discussions. An example of this is that when you create a pure javascript
> processing thingy, as far as I know, you can't know for sure that you would
> get the buffer size and sample rate that you asked for. I think this is also
> not a very good idea, if we have a higher level API like this, it should be
> able to do the resampling for you, otherwise you may have to do it in JS,
> which is a performance hit and often a nasty hack. I think that the spec
> should state that IFF the sample rate and buffer size aren't specified, the
> implementation tries to find the optimal values for them.
>

Currently the API does not allow for specifying the sample-rate of
JavaScriptAudioNode (and never did).  It runs at the sample-rate of the
AudioContext.  Grant Galitz has made a feature request to specify the
context's sample-rate and there's an open bug for it:
http://code.google.com/p/chromium/issues/detail?id=73062&q=owner%3Acrogers%40google.com&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS

It's certainly feasible to do...

We've been discussing various strategies for dealing with buffer size on the
list and also the tele-conferences for JavaScriptAudioNode.  All good ideas
are welcome for trying to address scalability issues when running on
different hardware, glitching, and getting exactly the buffer size you ask
for.  One of the issues we're looking at is when the JS developer asks for a
specific buffer size and it runs fine on his particular machine, but then in
a different browser, different OS, or different hardware, that same buffer
size results in complete audio breakup.  It's a difficult problem to solve
and we should keep talking about possible solutions to it.


>
> I hope that we can raise a good discussion regarding these problems.
>
> Jussi
>

Chris