html5 audio in the year 2012

audio,gamedev,html5 — 25. May 2012

html5 audio in 2012 is still in a rather sad state. true, there has been some progress. the <audio> tag is now widely supported across browsers and usable. however, anyone who has tried using it for a real life application like a game will have noticed that html5 audio is still pretty much unusable.

for one, there is the codec issue – there still isn’t a codec supported by all browsers, you need at least mp3 and ogg if you want to reach a significant part of the userbase. if you want a single format that covers all major browsers, your only choice is WAV. i think this alone is enough of an annoyance to make working with the platform a headache.

second, the <audio> tag just doesn’t cut it for games. even for the most basic games (beyond tic-tac-toe) you need at least the following two features: immediate playback and support for overlapping samples. that’s because with games, you are usually dealing with short samples (sound effects) that need to be played back without delay, and they also need to be able to overlap. timing is crucial. the <audio> tag has not been created for that purpose, and it just won’t work reliably across browsers if you attempt to use it that way. a simple example with an html page that has a button and some javascript hooked up to it that plays a short sound via <audio> tag when clicking the button is enough to show the problem: when you click it a couple of times repeatedly it will give strange and unreliable results in different browsers. it’s just not good enough for games. there are a lot of people these days who say that html5 is going to kill flash on the web soon, but it makes me wonder whether those people have looked into audio at all?

the good news is that the w3 is working on a much more sophisticated web audio API. you can follow the discussion here. however, it’s still in draft version and currently only webkit has a (vendor prefixed) implementation. it seems to me that the w3 audio group is pretty much focusing on the web audio API now, so that’s probably where we are headed. mozilla’s own lowlevel audio data API appears to be on the way out. although there is one working implementation of the web audio API (webkit), it is clear that the specification process is far from over, with a large amount of issues recently brought up by the opera team. the group seems to be targeting 2013 for a first release of the spec (recommendation status), but some members have described this as very optimistic.

i’ve been playing around with the web audio API myself and i must say it makes a lot of sense and it has an impressive feature set. it provides all the functionality that i will ever need but is still fairly easy to pick up. for html5 games it really seems like the ideal solution. so here’s to hoping that it will reach a stable version soon and that other vendors will pick it up. with neither mozilla nor opera having started an implementation (as far as i can see), and no sign from microsoft whether they are planning to support it, it seems unfortunately that html5 audio still has a long road ahead.

in the meantime, you have three choices: 1) stick with the <audio>-tag and live with the poor results, 2) use the web audio API when available, otherwise fall back to the <audio>-tag, or 3) fall back to the flash plugin.

update: check out this talk about the web audio api from google i/o 2012.