Re: Web Audio API is now available in Chrome

On Wed, Feb 2, 2011 at 6:54 AM, Chris Rogers <crogers@google.com> wrote:
> Hi Tom,
> They are different API proposals.  The "Web Audio API" which I just wrote
> about is described here:
> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
> Mozilla's proposal is called the "Audio Data API":
> https://wiki.mozilla.org/Audio_Data_API
> There has been a fair amount of discussion about the two approaches on this
> list.  Here is my comparison:
> Web Audio API
> * implementations in WebKit - Google Chrome (Mac OS X only, but Windows and
> Linux soon), Apple Safari
> * high-level API - easy to do simple things like play sound now
> * API is modular and scalable
> * allows for the lowest possible latency - time between, for example, key
> and mouse events and a sound being heard
> * most of the implementation is in optimized assembly / C / C++ for
> efficiency, so more can be done without bogging down the system
> * more resistant to audio glitches / dropouts
> * superset of Audio Data API functionality

That's an unfair comparison: the Web Audio API is in no way shape or
form a superset of the Audio Data API functionality. For one: it
doesn't integrate with the Audio() API of the existing <audio> element
of HTML5. It also makes it really difficult to access individual audio
samples and manipulate them. And finally, the Web Audio API only
implements a certain set of audio manipulation functions in C/C++ - if
a developer needs more flexibility, they have to use the JavaScript
way here, too. And, to be honest, to get to include a JavaScript
function through the Web Audio API is rather complicated, while it's
dead simple in the Audio Data API.

> * more advanced audio capabilities
>
> Audio Data API
> * implementation in Mozilla Firefox (Mac OS X, Windows, and Linux)
> * low-level API - requires writing JavaScript code to render audio one
> sample at a time - requires low-level knowledge of audio to use
> * API is monolithic and "ad hoc"

Again, I would recommend refraining from such statements. I have
experimented with both APIs and found both have their advantages and
disadvantages, but neither is "monolithic" or "ad hoc" - no matter how
you define these terms.

> * 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.

> * more limited audio capabilities

I'd argue the other way around: since you have access to the audio
samples directly, the Audio Data API IMO has more flexible audio
capabilities. Anything can be done once you have access to the samples
directly.


My description of the comparison is that the Audio Data API is a
low-level API that allows direct access to samples and to manipulating
them in JavaScript with your own features. It does require either a
good JavaScript library or a good audio coder to achieve higher level
functionality such as frequency transforms or filters. But it provides
the sophisticated audio programmer with all the flexibility - alas
with the drawback of having to do their own optimisation of code to
achieve low latency.

In comparison, the Web Audio API is built like traditional audio
frameworks as a set of audio filters than can be composed together in
a graph and then kicked off to let the browser take advantage of its
optimised implementations of typical audio filters and achieve the
required low latency. By providing a by nature limited set of audio
filters, the audio programmer is restricted to combining these filters
in a means that achieves their goals. If a required filter is not
available, they can implement it in JavaScript and hook it into the
filter graph.

In my opinion, the difference between the Web Audio API and the Audio
Data API is very similar to the difference between SVG and Canvas. The
Web Audio API is similar to SVG in that it provides "objects" that can
be composed together to create a presentation. The Audio Data API is
similar to Canvas in that it provides pixels to manipulate. Both have
their use cases and community. So, similarly, I would hope that we can
get both audio APIs into HTML5.

Best Regards,
Silvia.

Received on Tuesday, 1 February 2011 21:44:15 UTC