RE: Specificity in the Web Audio API spec

(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 :])

I don't know any FFT bug in Intel processor. There was a fdiv bug in Pentium long long ago (http://en.wikipedia.org/wiki/Pentium_FDIV_bug ), but it is a bug, not something with standard

Best Regards

James


From: Jussi Kalliokoski [mailto:jussi.kalliokoski@gmail.com]
Sent: Thursday, March 29, 2012 6:33 PM
To: public-audio@w3.org
Subject: 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