Re: Web Audio API is now available in Chrome

On Wed, Feb 2, 2011 at 5:43 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> > * all audio processing is done in JavaScript which although fast enough
> for
> > some applications is too slow for others
> > * has difficultly reliably achieving low-latency, thus there's a delay
> heard
> > between mouse / key events and sounds being heard
> > * more prone to audio glitches / dropouts
>
> I agree - these are indeed the disadvantages of writing your own audio
> sample handling in JavaScript. But they are best effort and often
> enough completely sufficient for many applications.


The "start minimal" thinking behind the audio data API is useful
to get things going to figure out what people would actually want to do
with the API, but it is hard to declare it as *the* approach as it stands.
Consider the possibility of support on the mobile device front.
Chris' approach with the web-audio api -- that of implementing some
units and the pipeline natively -- is likely to be better in that scenario
in two ways - a) just plain speed (and, by implication, power consumption)
and b) improvements in the audio pipeline benefit everybody.

Also, low latency and glitch-free audio are near and dear to
quite a few interested in this space I think (you're looking at one
who switched for those specific reasons), but the audio data api is
yet to address them satisfactorily. They are critical to a good online
gaming experience for example. Granted that improved javascript
performance may bring that closer to practicality, there is still a
single-threaded model standing in the way as far as I can tell.

It looks like web workers might offer a way out by letting
an audio worker run uninterrupted. ... but wait! Workers can't
access the DOM and the data api ties into <audio> using the
same DOM class. So it looks like audio data API based code
can't run in workers *by design* (and at least in the current
implementation). An orthogonal api, though, stands a chance of
being able to run in a worker (at least in the future if not right now)
with the main thread dedicated to visuals (ex: WebGL).

Meanwhile, let's hope JS performance approaches light speed - I mean "C" :)

Regards,
-Srikumar K. S.