Re: Comments on the Web Audio API proposal

Hi Silvia,

The problem with creating a library of math functions is that almost all
audio processing contains a lot of state.  So it's not simply a matter of
calling a series of functions on audio buffers, one after the other.  Here
are some examples of state in very common audio processing:

*  The supreme example of this type of statefulness is convolution for
creating room effects which can require significant amounts of memory and
which (in an optimized and practical implementation) is processed in
multiple threads.

* Panning / Spatialization for positioning sounds in space (can use
convolution or lower-order filters)

* Delay lines have delay memory

* Simple low and high-pass filters implemented as biquad filters carry
filter state for previous input and output values.

* Dynamics compressors keep state for power detection and attack/decay
behavior.

* Waveshapers can have up and down-sampling filters.

* Even a simple gain (volume) change requires state to handle de-zippering
(smoothing) when changing the gain dynamically.

An AudioNode manages this state along with the tasks of accepting an audio
input stream and generating an output stream.  AudioNodes may be connected
together in simple or complex processing graphs with very little JavaScript
code.

Cheers,
Chris



> Has the group ever considered creating a maths JavaScript library for
> which hardware support can be implemented and making that generally
> available to the Web browser rather than creating audio-specific
> filters? It was a question I was asked recently when discussing the
> Audio API work and I didn't have an answer for it. I think it's a
> valid question and it might make a lot more sense to provide a fast
> library of mathematical functions rather than FFT filters and
> convolution etc that can only be used by AudioNodes.
>
> Cheers,
> Silvia.
>