[webkit-dev] Web Audio API

Chris Marrin cmarrin at apple.com
Tue Aug 24 15:10:39 PDT 2010

On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:

> Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation).  The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator  group.  For those who are interested, the draft specification is here:
> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
> I have working demos here:
> http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
> I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk.  Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event).  The files will be conditionally compiled.  I'm considering using the following enable:
> After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places:
> WebCore/audio
> WebCore/platform/audio

> I know that some had expressed concern that a directory called 'audio' in WebCore would be confused with the audio element.  The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform.  That said, if anybody has grave concerns over this name, then we can discuss alternatives.

I'd rather see the directories named webaudio and the enabled named WEBAUDIO. This would match the naming of 'websockets' (although not web workers, which is simply named 'workers'. I agree that this is directly related to the audio element, but it is an optional piece (hence the enable flag) and so I think it should have its own naming.

cmarrin at apple.com

More information about the webkit-dev mailing list