Specificity in the Web Audio API spec

Hello group!

Now that we have already published the second working draft, I think it
might be worthwhile starting to clarify some bits in the spec. This was
ambiguity of a large API like this was already discussed some time ago, but
it's more relevant now, imho, since we're starting to expect prototype
implementations from people other than the author of the spec. Specifying
audio tools is hard, especially if you want to avoid specifying the exact
implementation rather than the algorithm, but this needs to be done for the
implementations to be consistent. We can't trust that browser vendors get
"industry standard" algorithms right, especially if the "standard" is
vague. Even well defined algorithms such as FFT have gone wrong in the past
(IIRC a certain Intel processor had a bug in its FFT implementation, having
severe implications. Sorry I'm stating things without providing any valid
references, maybe James Wei has more specifics on the incident :]). Another
example is that Math.sqrt gives incorrect results on Chrome on Windows, and
they refuse to fix it because "it's according to the spec" [1].

To demonstrate, let's start with the DelayNode (yes, even something as
simple as this has a lot of ambiguity):

1) The time is given in seconds. How is this rounded to samples when
adjusting in terms of the delay buffer? Should it be nearest neighbor?
Floored? Or is the buffer fixed size with an adjustable playback rate,
resampling on the fly? If so, what resampling method should be used?
2) "When the delay time is changed, the implementation must make the
transition smoothly, without introducing noticeable clicks or glitches to
the audio stream." This part is very vague, what does it mean? Basically,
you could have the old buffer fade out and new buffer introduced with a
transition, and it would be according to the spec. Not very desirable. On
the other hand, the browser could be using exactly the algorithm you had
planned for it, but if the source data contains clicks, it could be
interpreted as a bug. So, what should be done to make the transition
smooth? Should the implementation use a fixed size buffer like I explained
in the first point?

Cheers,
Jussi

[1] http://code.google.com/p/chromium/issues/detail?id=117699