Re: Adding Web Audio API Spec to W3C Repository

On 06/10/2011 11:47 PM, Chris Rogers wrote:
> I'd like to take a moment to consider design philosophy and use cases.
>   The main use cases I believe we need to address in an audio API are:
>
> * Basic Sound Playback - play sound now
> * Games
> * Interactive Audio Applications
> * 3D / Virtual Environments
> * Music Applications
> * Educational Applications
> * Visualizations and Artistic Audio Exploration
> * Custom Audio Processing via JavaScript
> * Webrtc Communications
>
> My proposal and implementation are designed with all of these use cases
> in mind.  I believe that games will be one of the largest consumers of
> an audio API, and as such, my proposal includes state-of-art console
> game engine features.  It is capable of rendering audio scenes with a
> complexity and quality of cutting edge games like "Portal 2" and "Little
> Big Planet".  With the new advanced features now offered in WebGL, and
> accelerated canvas 2D, I think it's very important to consider the
> importance of games and try to bring the level of expectation a bit
> higher for audio than the casual Flash games of the past.
>
> As for the integration with the Stream proposal, I've had discussions
> with Ian Hickson and we concluded that it would be best to keep the two
> APIs separate and provide a way to gain access to a Stream via AudioNode.
Why should the APIs be separate?


>
> I hope we will consider the big picture when designing an audio
> architecture.  I think games, music, and other non-webrtc use cases will
> be the 90%+ case, so I'm hoping we will have a well considered design
> for them.  It's very important to be able to handle integration with
> webrtc, and Ian and I have already discussed how to do this.  But an
> audio API needs to have good support for games, musical applications, 3D
> environments, custom processing etc.
I don't see how having Stream based API would make it harder to
support games/music/3D etc.
In fact for many things we need good synchronization which
(Media)Stream API is aiming for, AFAIK.
AudioNode-like things could be added (later?) as stream processing
units - or if worker based processing units work well enough,
web apps could just rely on them.

One thing to keep in mind is that audio (and other stream data)
processing must be able to be done in workers.
Keeping the API rather low level makes it easier to implement it
so that both main thread and workers can be supported.


> I'm putting forward not just a
> rough sketch of an API, but an API with multiple working implementations
I thought only webkit/chromium supported your API ;)

> which I hope will provide a very high-quality audio experience.
>
> Chris
>

Received on Friday, 10 June 2011 21:14:42 UTC