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:
http://www.html5rocks.com/en/tutorials/webaudio/intro/



> - 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:
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AudioPannerNode-section

The distance models are defined exactly as OpenAL.  Please see section 3.4:
http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.pdf

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:

http://www.html5rocks.com/en/tutorials/webaudio/intro/#toc-abstract

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!
Cheers,
Chris
Received on Thursday, 12 January 2012 22:49:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 January 2012 22:49:22 GMT