Hacker News Reader

Comment by kevingadd | Hacker News Reader

The Web Audio API is Chrome-only (or I guess it shipped on iOS 6 now? I still can't use it in Safari on my desktop PC) because Google wanted it that way. The API is incredibly poorly specified and poorly designed.

HTML5 games have been able to use <audio> to play sounds since before the Web Audio API existed, but Google never bothered to actually make it work right in Chrome. They were too busy coming up with their own thing.

View on HN

Game devs all over the net have praised the Web Audio API. Abusing the audio tag was never the correct solution for games. The audio tag was designed for streaming long files, never for sound effects. Just because people were able to abuse it into game use doesn't suggest that was a good solution.

There's nothing fundamentally bad about 'new Audio("effect.wav")' and it performs stunningly well in both Firefox and IE and has for a long time. The one real 'downside' - prebuffering - is absolutely trivial to compensate for and the code to do it in JS is not any larger than the necessary scaffolding to make basic use of Web Audio.

Chrome was always the loser here; I won't speculate as to the reasons why, only state that for multiple versions, playing simple sound effects with Audio instances had severe latency, audio quality issues, and even crashes. Why wouldn't devs praise the Web Audio API if the only alternative was broken? I certainly was happy when I finally managed to get my HTML5 games to play audio in Chrome without crashing, but that doesn't mean the Web Audio API is well-designed or that it was a good idea for me to have to write Chrome-specific code just to play sound effects.

I'll acknowledge that Web Audio's design probably delivers better runtime performance in scenarios where you're playing dozens or hundreds of non-streaming sound effects, but I still question the motives of anyone who prioritized that over having basic support for audio working correctly.

EDIT: Because I forgot to mention this - I mean seriously, you put a method call in the Web Audio API that blocks the UI thread to synchronously decode audio? In 2012??? And didn't cover the documentation in 'don't use this' warnings?

The main point of the web audio api is for procedural generation of sounds rather than playing of pre-computed buffers or files. This is why "new Audio('effect.wav')" isn't a real alternative to it.

Mozilla had procedural audio generation through <audio> with a simple, documented API back when Chrome couldn't even play non-procedural audio through <audio> properly.

http://phoboslab.org/log/2011/03/the-state-of-html5-audio

Procedural audio is also effectively a corner case compared to the vast majority case, which is playing static sounds.

Simple, documented, and slower - you had to do everything in JavaScript. Web Audio API retains the ability to use JavaScript but provides a nice set of fast primitives.

More to the point: As soon as you want to mix audio levels, <audio> alone is completely insufficient. You need mix control in order to fade background music and loops. I consider this a basic need; the Mozilla API allows you to roll something yourself, but Web Audio is more clearly suited to the application.

The web audio API has sample-accurate scheduling which, in our games and this modern age of procedural audio, is critical.

Reply on news.ycombinator.com