[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.

OpenAL controlled by _javascript_ just isn't fast enough for audio. Especially when that same _javascript_ is also handling rendering, physics and A.I. This is why in some people's opinion (mine included) a JS wrapper on OpenAL is not enough.

In some idea world where _javascript_ is multi-threaded and runs only 10% slower than C++ even on cell phones controlling audio at an OpenAL level is exactly what I would want. Give me low-level access and get out of my way. But we're not in that ideal world. _javascript_ is still 10-20x slower than C++ in most cases, it's single threaded by design and will get frozen whenever the browser is frozen (alerts and other events) at least in browsers and that's not going to change anytime soon and it has to run on underpowered hardware. Hence the need to move all the real audio processing to C++ and just provide an interface for _javascript_ to manipulate it.

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.

(sorry, this discussion doesn't belong on the WebGL mailing list. If you want to influence the direction of audio in the browser join the Web Audio Incubator Group. http://www.w3.org/2005/Incubator/audio/charter)
 

On Tue, Mar 8, 2011 at 8:20 AM, <steve@sjbaker.org> wrote:

> On Mar 4, 2011, at 5:21 AM, steve@sjbaker.org wrote:
>>
>> Congratulations!
>>
>> 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
> direction?

Not exactly...but it's not what I (as an application author) need.

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
already written.
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
could also have it done REALLY fast.  We'd write some quick _javascript_
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
paradigms.

 -- 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
-----------------------------------------------------------