[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposal for WebAL

On 01/11/2011 12:59 PM, Benoit Jacob wrote:
> ----- Original Message -----
>> On Tue, Jan 11, 2011 at 10:50 AM, Steve Baker <steve@sjbaker.org>
>> wrote:
>>> In the course of writing my WebGL game, it became painfully obvious
>>> that
>>> the audio capabilities of present browsers is woefully inadequate to
>>> the
>>> task of rendering game audio - and I've decided to try to evangalize
>>> what I think is the clear and obvious solution to the problem. I
>>> call
>>> it "WebAL".
>>> This is off-topic for this list - but I'm trying to propose a
>>> solution
>>> that closely mirrors WebGL, both in structure and in how it gets
>>> adopted
>>> and implemented and I presume that the people who inhabit this list
>>> will
>>> either be the right people to talk to - or will know who those
>>> people are.
>>> I have written a white-paper describing why we need it, what it
>>> should
>>> be - and how I think it should happen:
>>> http://www.sjbaker.org/wiki/index.php?title=WebAL_-_Interactive_audio_for_browsers
>>> Please SPAM it to anyone who will listen!!
>>> I also created a mailing list to centralize the discussion:
>>>  http://lists.sjbaker.org/listinfo.cgi/webal-sjbaker.org
>>> Thanks in advance
>> Please look into the Web Audio incubator group at
>> http://www.w3.org/2005/Incubator/audio/ and in particular the Web
>> Audio API specification proposal at
>> http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html
>> . This is an API designed by an audio processing expert (Chris Rogers)
>> which provides low latency audio and extremely powerful capabilities.
>> The initial implementation in WebKit is nearly complete on all
>> platforms. I think it would be best to focus efforts on the
>> development of this API rather than start a new one.
> And also, a different (lower level, I'm told) approach is being implemented in Firefox 4:
> https://wiki.mozilla.org/Audio_Data_API
> Benoit

I'd seen the Audio_Data_API before - I'm not sure what applications it's
designed to address - but it doesn't cover any of the issues that
practical game folk are likely to need.  Basically, it lets you read out
and write back raw audio data and have the <audio> tag system play it
back.  That's not the problem here - it's that the <audio> playback
system itself is fundamentally flawed.

The Audio API specification is a new one on me - I searched for such
things and failed to find them.

However, it suffers from the same problems as previous efforts - it
re-invents the wheel.  Consequently it's a complete unknown to anyone
who might be considering switching to Web-based gaming.  The reason
WebGL is so interesting is precisely that there is absolutely nothing
new or novel about it.   We have OpenGL-ES 2 - translated to
JavaScript.   My proposal is to take the nearest thing in the gaming
world to OpenGL-for-audio (which is OpenAL) and do the exact same
thing.   Because OpenAL is so widely used (there are a slew of shipping
games using it) - we know it covers all the bases and is familiar to

I need to read the Audio API specification more closely though - despite
asking around everywhere I could find over the last few months - this is
the literally the first I've heard of it!

The thing that's compelling about OpenAL is that it's just like OpenGL. 
The API is instantly familiar - if you know OpenGL (or, by extension,
WebGL) then you know OpenAL (and by extension, the WebAL that I
propose).   But also, you can position audio sources in 3D space with
the same 4x4 matrices you use for positioning the corresponding
graphical object.  You position "listeners" just like you'd position a
camera - and let the API worry about all the spatialization, doppler,
range attenuation, etc.

Anyway - this isn't the place to discuss it - and I need to read the
Audio API spec in detail.

  -- Steve

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl