[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL 1.0 ratified and released
I think the problem is audio is far more sensitive to latency. If your game's visuals slow from 60hz to 15hz your game is likely still playable (Halo, GTA3). If your audio has latency issues it is crap. A piece of music with notes not played precisely when needed will not sound like music at all.
Sure, the Audio Data API is in the spirit of OpenAL and there are some great demos but I've yet to see any real apps (ie, games that use lots of simultaneous sounds with 3d effects, echo, low and high pass filters, and dynamic music + physics (even 2d) plus A.I and run on an iPhone or Android phone. Hence the need for the Web Audio API.
On Tue, Mar 8, 2011 at 8:20 AM, <email@example.com>
Not exactly...but it's not what I (as an application author) need.
> On Mar 4, 2011, at 5:21 AM, firstname.lastname@example.org
>> I've gotta say that this has been the smoothest, friendliest and most
>> effective piece of web standardization effort I've ever participated in.
>> I'm pleased to see that WebCL is heading in the same direction. I
>> *really* wish we could get the audio side of things moving the same way
>> instead of trying to continually re-invent the wheel though.
> Are you saying you don't believe the Audio XG is going in the right
I think it's a terrible idea to "reinvent the wheel". The success of
WebGL (and, I confidently predict, the future success of WebCL) is due to
the fact that:
a) Development of the spec is fast because we're just specifying JS
bindings for an existing, documented API.
b) We know that the API we're cloning is complete, stable, useful,
popular, portable, understood by developers and has 95% of the code
c) We have existing hardware-accelerated implementations - there are
stable, well-supported, pre-existing drivers for us to "wrap".
When you reinvent the wheel, you're in danger of missing stuff that's
important, having to write a LOT of code that'll take a while to get
stable, you'll be putting in features that developers don't need, etc.
The god-awful <audio> tag suffers from all of those problems - it's an
ugly compromise, developers hate it, it doesn't work as described in ANY
browser, the spec is full of junk that nobody needs and is missing utterly
vital features without which it's completely useless - and it's really
vague on fundamental issues like "how many sounds can I play at once?".
I don't know whether Audio XG falls into any of those traps - but I do
know that if we had just done for OpenAL then application writers would
embrace it like a long-lost friend...just as we did for WebGL/OpenGL. We
wrappers - add support for the typed arrays - added some loaders for
common copyright-free sound formats - tie it all up in a pretty red bow.
All of the tricky lessons we've learned on WebGL would carry over to WebAL
without the need for debate. I bet we could write a spec in a week that
we'd all agree on.
The process should have been easy, no problem to get the big players
signed on to implementing it...it could be done to a full release standard
in a matter of months.
There are hundreds of games and simulations (both FOSS and Commercial -
Indie and Big-publisher) that already use OpenAL - developers seem to like
it. There are implementations for all of the desktop and game console
platforms - several with hardware acceleration - and the source code is
easy to port to new platforms. (I got it working on a Nintendo DS in
about a day!)
The need for an <audio> replacement is urgent. Look at the winners of the
Mozilla GameOn contest - without exception, they call out the <audio>
system as a pile of poop and for almost all of us it was the flakiest part
of the whole process of getting games up on a plugin-free browser.
The WebGL steamroller is in motion - we need an audio system to go with it
ASAP. OpenAL 'fits' with OpenGL...it was designed to use similar
You are currently subscribed to email@example.com
To unsubscribe, send an email to firstname.lastname@example.org
the following command in the body of your email: