W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: Use Cases and Requirements document

From: Chris Rogers <crogers@google.com>
Date: Thu, 12 Jan 2012 12:10:07 -0800
Message-ID: <CA+EzO0m8HSfUdSGxb88siH2=cSJf2C9t2Db8HW53_XRZRAcTdQ@mail.gmail.com>
To: Christoph Martens <christoph@martens.ms>
Cc: public-audio@w3.org
Hi Christoph, sorry to jump into this thread a little late...

On Mon, Jan 9, 2012 at 5:05 AM, Christoph Martens <christoph@martens.ms>wrote:

> What comes on my mind for game requirements on audio is mostly:
> - Noises that you can overlay. Should be as easy as possible like having
> two different audio sprites.
> AudioNode.addOverlay(noise.**mp3)

That's a fundamental ability which has been highly optimized in the Web
Audio API.  Here's a simple tutorial explaining this:

> - Multi-Channel 3D environment
> Well, in games you definitely need multichannel sound (which is only a
> problem on couple implementations nowadays),
> but you also require a distance to a sound that automatically influences
> the volume, overlays (interruptions with other sounds)
> etc. Imagine you could have the same configuration possibilites that you
> have for Audio Speaker positions in your sounddriver
> environment - but for virtual purposes.

Distance attenuation is handled in the Web Audio API like it is in OpenAL.
 Please see .distanceModel and associated attributes:

The distance models are defined exactly as OpenAL.  Please see section 3.4:

Similarly, other well-established concepts have also been adopted from
common game audio APIs such as OpenAL, FMOD, Creative's EAX, and
Microsoft's XACT Audio.

> - Native AudioSprite support
> Playing back Audio is pain, you will always need a SoundLoop (interval /
> timeouts) if you want to use Audio Sprites.
> Audio Sprites is the only effective solution for transferring Sound via
> the web / http.
> I would be pleased if you could take a look at my Jukebox that solves many
> playback problems on Audio Sprites:
> https://github.com/zynga/**jukebox <https://github.com/zynga/jukebox>

The Web Audio API is optimized for many simultaneous "overlaying" sounds.
 Sounds can be scheduled to happen at exact times, with much higher
accuracy than setTimeout() will allow.

> - Buffering / Caching
> Sadly there's no cross-browser implementation regarding buffering. Every
> vendor implements it a different way due to missing specs.
> It would be nice to have something like AudioNode.onready(123.2, callback)
> if the browser is really sure to playback properly.
> At the moment, it's only guessing - and no-one likes to guess or listen to
> events that don't fire properly across all implementations.

Audio resource loading and playing are de-coupled in the Web Audio API,
giving lots of flexibility in resource loading/caching.  For short and
medium length sounds typically used in games, resource loading is typically
done using XHR.  Here's a tutorial, explaining one way of using the API for
loading audio resources:


But since the audio file data (say from a .wav, .mp3, .ogg file) is loaded
into an ArrayBuffer (normally from XHR) it can also be stored/cached using
the File API.  So, there are many options available for caching.

> Cheers from Germany,
> Christoph (from Zynga Inc.)

Good to hear from you!
Received on Thursday, 12 January 2012 22:49:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:57 UTC