Re: Specificity in the Web Audio API spec

On 03/30/2012 09:23 AM, Raymond Toy wrote:
>
>
> On Fri, Mar 30, 2012 at 6:37 AM, Jussi Kalliokoski
> <jussi.kalliokoski@gmail.com <mailto:jussi.kalliokoski@gmail.com>> wrote:
>
>      > I think you raise some interesting points.  What is the goal
>     here?  Are you expecting that independent implementations will
>     always produce *exactly* the same output for the same input?
>
>     Yes, that would be quite ideal. Otherwise if you need that precision
>     (a DAW hardly can afford to sound different on differnet platforms,
>     especially on such a crucial element as a delay node), you're going
>     to have to exclude browsers or resort to a JavaScript implementation
>     for a tool that's supposed to be predefined. Kind of beats the
>     purpose of having predefined nodes, I think. And having these
>     algorithms well defined in the spec is something to push browser
>     vendors to fix their implementations instead of marking them as
>     WontFix because it follows the spec that isn't defined well enough.
>
>
> I definitely agree that having all browsers produce the same output
> would be ideal.  But that requires a *huge* effort  to make the spec
> precise enough.
Other specifications do take huge efforts to specify exactly how the
APIs should work. Why shouldn't the same happen here?


> Even a difference between using floats or doubles in
> the algorithms can make a difference in the results.   Alternatively,
> you could say that the current webkit implementation is the reference.
No. You need to independent implementations before the spec can become a 
recommendation.


>   But that has it's own problems because once the spec is blessed, so is
> the implementation so that it can't be changed for ever after.
>
> We'll probably have to choose some middle ground where, perhaps, the
> algorithms are specified, but the implementation details are left to the
> browser.  That's still a huge effort.
>
> But I definitely agree the spec should be as precise as reasonably possible.
>
> Ray
>

Received on Friday, 30 March 2012 17:21:55 UTC