Re: The future and direction of web audio

On Wed, Jul 13, 2011 at 1:03 PM, Alistair MacDonals <al@pwn.io> wrote:

> It makes sense as computational power increases over time, these
> browser limits can be increased accordingly. Jussi raises a good
> point, I think considering a maximum that the music industry would
> feel comfortable with is an important choice.
>
> Chris, when you say the sample rates are quite huge, do you have an
> estimate as to how huge? For example: I am used to using 96Khz audio
> with my DAW and software synthesizers (I know some people go higher
> than this still, though there is some falloff in usage at this level
> due to the cost of hardware that can handle the computations).
>

I mentioned something like 384KHz, 4x the already audiophile-quality of
96KHz which you use.


>
> Another issue to take into consideration is 64bit. A lot of serious
> music producers choose to *only* to work with 64bit audio to keep the
> nuances in their sounds as close to their original recordings as
> possible. Where do we stand with regards to 64Bit ?
>
> Alistair
>

32bits is already of an *exceedingly* high-quality, but we can also
accomodate 64bits.  Already in the Web Audio API implementation in WebKit
there are parts of the code (such as the biquad filter implementation) where
64bit double-precision is used (mainly for filter stability).  There's
nothing to stop implementors from using 64bit internally in places where
they wish.  However, using native code, there are places where substantially
faster code can be written with SIMD optimizations such as SSE instructions
which use 32bit.

As far as the JavaScript interface, there are places in my proposed spec
which make reference to Float32Array.  With suitable abstraction we may be
able to hide that completely opening up the possibility of Float64Array, or
at the very least allow for variants for both Float32Array and Float64Array.

At this point, I think we have much bigger fish to fry such as worrying
about latency, glitching, and performance concerns as compared with desktop
audio applications.  But certainly we should look toward the future and make
sure the API is properly scalable.

Chris