Re: TPAC F2F and Spec Proposals

On 10/18/2011 11:47 AM, Anthony Bowyer-Lowe wrote:
> On 18 October 2011 09:19, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>
>           They have very mathematically precise algorithms.
>
>     I don't see them in the spec.
>
>     Even simple thing like DelayNode doesn't say in which way
>     "implementation must make the transition smoothly".
>     And if implementations don't provide the exactly the same
>     output, using the API in music production would be pretty unreliable.
>     One couldn't play the same audio data the same way in different
>     browser.
>
>
> Indeed. Even something as conceptually simple as the GainNode can have
> audibly different results according to how implementations deal with
> numeric accuracy, unity overflow and order of operations.
>
> [Which tangentially reminds me, I'd love the GainNode to handle negative
> gains in order to provide signal phase inversion without requiring an
> expensive JavaScript processing node. But that's just the modular
> synthesist in me.]
>
> And whilst biquad filters are very well defined mathematically,
> variations in their numeric implementation can lead to all sorts of
> different phase and frequency responses. E.g. bit length of floats used
> in the calculations, and coefficient manipulation.
>
> This is not a big deal right now - what is currently in the Web Audio
> API is a great starting foundation - but these issues should be noted as
> a consideration for future specification refinement and reference
> implementations.
IMHO a spec which defines an API shouldn't leave out the part which
actually defines what the API does.
Currently it is not defined what the output of the API is.
That makes it impossible to implement fully compatible implementations.
It makes also automated testing pretty much impossible, and manual 
testing would rely heavily on user's perception.




> Conversely, maybe it'll be healthy for browser vendors
> to compete on providing the best sounding native effects. (But what if
> the user prefers the convolution in browser whilst their favourite
> filter is provided by another?)
>
>
> Regards,
> Anthony.

Received on Tuesday, 18 October 2011 10:06:01 UTC