Blog Home

The State of HTML5 Audio

When I started to work on my JavaScript Game Engine back in October 2009, the biggest problems I encountered were with the new HTML5 Audio Element. The Canvas Element already worked nicely in all browsers that supported it at the time, albeit some were a little slow.

Now, in 2011, the rendering performance for Canvas has been improved dramatically, audio however is still broken in large parts. I think it is time for a change in tone. Be warned, there's some profanity ahead because HTML5 Audio is still that fucked up.

Before we start, you may want to play a quick round of Biolab Disaster or Z-Type and have a look at a simple test case to experience the sound issues first hand.

Browsers From Companies That Actually Care About HTML5 Audio:

Firefox 4, Beta 13pre

Almost perfect Audio support with occasional clicks & pops when playing many sounds. Notably, Firefox 4 also features the Audio Data API for generating and modifying sounds on the fly – which I think is brilliant and desperately needed to compete with Flash.

Note that the current Beta 12 still has some larger timing issues, but this seems to be fixed in the Beta 13 nightly build.

Opera 11

Good Audio support overall. Some clicks & pops and minor timing issues. Works nicely for games but still needs improvement.

Chrome 11

Severe problems with short sound clips, timing issues, clicks & pops, goes completely silent after a few seconds. Pretty much useless for games at the moment.

(Come on guys, you've done some amazing things in the past, I'm sure you could get HTML5 Audio right if you just tried!)

Update: As mentioned on Twitter and in the comments, Chrome also has an Audio Data API that is somewhat similar to the one in Firefox 4.

Browsers From Companies That Hate the Web Enough to Not Support Ogg/Vorbis, but do Have an <Audio> Tag So They Can Say They Have an <Audio> Tag (Seriously, Fuck You):

(Wohoo, big surprise, it's Apple and Microsoft! Who would've thought?)

Safari 5

Some clicks and pops, lag for short sound files. Doesn't support Ogg/Vorbis, but instead favors MP3 – a patent encumbered codec with a far worse quality to size ratio that was never meant for short sound clips and introduces a leading and trailing silence. Ride on.

Internet Explorer 9

Doesn't play audio in my test case at all. Sure, I could adjust my test case so that it would work, by doing something like this:

if( IE ) { 
else { 

But quite frankly, I don't give a shit anymore about this stupid piece of crap that Microsoft calls a Browser and throws out a release for every 3 years, just in time to not let it fade out completely but annoy web developers for more years to come. IE9 is not even out yet and already 2-3 years behind of every other major browser.

Internet Explorer, you would do us all a huge favor if you would just die a silent death. Please go away. Nobody likes you.

Browsers That Say They Support HTML5 Audio But Actually Don't Support HTML5 Audio:

Android Browser

Understands the <Audio> element, but can't play sounds at all, because it has no codecs. Not even Wave. Utterly useless for anything.

Mobile Safari

Can't pre-load sound files, only plays one sound at a time, severe lag, timing issues, clicks & pops, completely ignores every other call to play a sound, doesn't support Ogg/Vorbis. Utterly useless for anything. Oh, and did I mention it doesn't support Ogg/Vorbis?

Final Thoughts

Surprisingly, Google's Chrome has the worst HTML5 Audio support of all the good Desktop Browsers - that is every Browser but IE. I'm not an audio engineer, but before Browser vendors took their shot at it, my impression of digital audio was that it is a solved problem. I'm amazed that after so many iterations HTML5 Audio is still that broken.

The Audio support on mobile Browsers (iOS and Android) is laughable at best. It's completely unusable for even the simplest of tasks. You can jump through hoops and ask real nice, but it still sucks ass.

I've heard some arguments that it is crippled on purpose, because you don't want a website to start blaring music at you as soon as you open it. Fine, I understand that argument. But why not ask the user for permission to play audio and then do it right? It's already been done with Geo Location and Storage.

And as for Vorbis support, Adobe should send some flowers to Microsoft and Apple for being in the same douchebag company league as they are. By trying to make things as complicated as possible they ensure that the easiest way to have audio in all Browsers is still Flash. Good job.

But seriously, I really don't understand why they can't support Ogg/Vorbis. This is not the same discussion as with HTML5 Video, mind you. Quality wise there is no question that Vorbis is better than MP3; there are no patent issues with Vorbis like there are with WebM and I even fail to see any "company politics" reason for not supporting it.

“Mimimi, there are no hardware decoders for Vorbis” you say? Fuck you. The first gen iPod touch can decode Vorbis in software while running Wolfenstein 3D with 60fps.

To conclude this rant, let me say that I'm a bit angry at myself for giving Internet Explorer that much screen time again, when instead we should all stop caring about that piece of shit.

Wednesday, March 9th 2011
— Dominic Szablewski, @phoboslab


#1Emil Loer – Wednesday, March 9th 2011, 16:55

Recent nightlies of Webkit and Chromium have support for the new Web Audio API, which is similar in nature to the Audio Data API that Firefox offers.

#2Joa Ebert – Wednesday, March 9th 2011, 17:12

Android Eclair did say it supports <audio> but, as mentioned by you, does not play it back. However this has been fixed with Gingerbread. I am not sure about your gaming issues or as far as low latency is concerned. After all you will need a dynamic audio API for low latency with something similar to web workers.

In fact it would be nice to get exactly something similar to what Flash offers in terms of dynamic audio. Couple that with binary file support and you can write your own Ogg/Vorbis decoder in JS.

#3 – Börger – Wednesday, March 9th 2011, 17:13


#4Scott Schiller – Wednesday, March 9th 2011, 17:13

[ Gets popcorn ]

I approve of the article title, having written a similar series of observations/complaints. ;)

To add to the amusement, don't forget about the Safari on Snow Leopard-only bug where audio just sometimes "stalls" and fails to load, intermittently - for that reason, my JS audio library falls back to using Flash by default specifically for that browser + OS since QuickTime X came out, with OS X 10.6.2. (It's still broken as of 10.6.6.)

My other favourite one is that Safari on Windows doesn't have any of these problems.. So Safari on Windows actually supports "HTML5" better than OS X Safari, in that regard. Also, if you don't install "Safari + QuickTime", you don't get HTML5 audio/video on Windows. Ah, fun.

#5Mr.doob – Wednesday, March 9th 2011, 17:18

Well said. Hopefully Chrome changes the priority of this.

As long as Firefox, Opera and Chrome continue at their pace, Safari and IE can do whatever they want. Just don't use Flash as fallback, encourage the user to switch to a good browser instead.

#6Seth Ladd – Wednesday, March 9th 2011, 17:50

The workaround I usually recommend is

BTW while I'm looking forward to the new Audio APIs from Chrome and Mozilla, and I believe it's the "right" solution for gaming, they need to be fast tracked on the standards process ASAP if we want a full HTML5 gaming story.

#7Matt Dunphy – Wednesday, March 9th 2011, 17:52

This is the biggest complaint I have when people try to convince me that HTML5 can do anything Flash can do. I tried my hand at emulating a very specific drum machine using Javascript and the audio tag (linked it to my name here), and while it's barely passable in Firefox, every other browser falls apart even trying. The audio tag is incredibly naive at this stage, and that's been pretty frustrating. So, yay, thanks for your rant, heh.

#8Rockwilder – Wednesday, March 9th 2011, 18:13

We are using as a workaround on mobile, however we noticed inconsistencies between the various versions of Android. It falls back on Flash if the browser can't recognize the audio tag. We would be curious to know how it works for readers of this blog?

#9 – Stephen – Wednesday, March 9th 2011, 18:14

Let me know when Firefox Opera and Chrome will use whatever installed codecs I have, until then #fail

#10Kumar McMillan – Wednesday, March 9th 2011, 18:14

Have you tried your tests on the beta of Firefox Mobile (fennec) on Android? I'm just curious; I don't know if it has any audio support at all. For javascript it is faster than the stock Android browser which is nice.

#11Joseph Huckaby – Wednesday, March 9th 2011, 18:25

Hear hear! Well said, sir. You are my new hero. I have been screaming about this for years (that webkit bug is mine), and am so glad to hear others join in. What really kills me is that HTML5 Audio worked PERFECTLY in OS X 10.5 on Safari 4. Apple utterly blew it with OS X 10.6. Sigh.

#12Viraj Mody – Wednesday, March 9th 2011, 18:31

Agree with most of what you have up here - I spent a ton of time fighting HTML5 Audio and felt as much pain.

Chrome's lack of proper Ogg Vorbis support is disappointing. Resulted in hitting a couple of Chrome bugs that others tracking this might be interested in: and

#13 – lol – Wednesday, March 9th 2011, 18:32

Someone make this article into a compare-by-browser spreadsheet

#14 – Giles – Wednesday, March 9th 2011, 18:35

Safari supports AAC for audio; how does that affect the quality/size issue, and the leading/trailing silence? It seems unfair to compare to standard MP3 if they support a more recent option. Obviously it remains patent-encumbered either way.

#15 – Blake r. – Wednesday, March 9th 2011, 18:43

Running cm7 (gingerbread ) on my Evo 4g. I have plugin support set to on demand and it won't play the music unless I load the plugin (which I assume must be flash ). It plays fine but obviously it doesn't recognize the tag.

#16 – Phil – Wednesday, March 9th 2011, 19:17

Ogg is not a standard audio codec for HTML5, so I'm not sure how to can make the claim that Safari hates the web because of this.

#17 – John Devalle – Wednesday, March 9th 2011, 19:26

In my experience, ogg has been a nightmare to use and I now avoid it at all costs.

mp3's patent issues are only relevant if you are writing an application that writes to mp3s since the decoding part is free.

#18richtaur – Wednesday, March 9th 2011, 19:26

Hilarious and accurate. I said a while ago that audio and performance are the biggest things holding back serious HTML5 gaming, in that order.

#19Artur Kot – Wednesday, March 9th 2011, 19:38

... Co tu dużo gadać. Niestety masz rację. :/

#20Mark Finkle – Wednesday, March 9th 2011, 19:51

Firefox for Android supports the audio tag as well as the Audio Data API

#21ponce – Wednesday, March 9th 2011, 20:02

Excellent and much needed rant.

#22 – T. T. – Wednesday, March 9th 2011, 20:02

John, I have no clue what caused you problems with ogg/vorbis. I've found it to be very easy to use. The MP3 decoder is _not_ free until 2014 or something like that, it's still very expensive:

#23Jos Hirth – Wednesday, March 9th 2011, 20:03

(As you know) I'm also very dissatisfied with the current situation. There is high (random!) latency, very short samples are troublesome, and... well... Chrome is just a f-ing train wreck.

Sound kinda works for a little bit, then it quickly gets worse, and after a few minutes it's usually completely silent. Even F5 won't help.

As far as I can tell there is no reason to use MP3. As I tweeted yesterday: "Ogg/Vorbis for the good guys. HE-AAC/MP4 for Safari and IE9. MP3 for the Flash fallback¹."

[¹ I "cross compile" to Flash.]

As far as I can tell, anything that qualifies as LC-AAC should work, but I'm not really sure if this also includes HE-AAC and HE-AACv2, which are both technically some flavor of LC-AAC.

There is some potentially annoying detail to this, most (all?) encoders switch between different flavors (and sub flavors) automatically, depending on the used quality settings. This might be a problem. (Sorta like Flash's H264 decoder only supports a specific subset of H264.)

Another thing I found really weird is that some tools will erroneously report that your mono file is stereo, but that only happened with files created by FAAC. MP4Box still identified it correctly as mono (VLC and Foobar didn't). This didn't happen with the files created by neroaacenc. Even though both created LC-AAC files.

Kinda weird, really.

There are also a bunch of different container formats. MP4, 3GP, and MOV are plausible choices, but I think MP4 (i.e. M4A) is the safest bet. But I haven't tried it yet. To make matters worse I can't even run bloody IE9 here.

AAC is of course a lot better than MP3. The size/quality ratio is better and there also is no leading and trailing silence. So, you can actually loop it without resorting to cue points (that's the cheat Flash is using - if you use the authoring tool, that is). It's very similar to Ogg/Vorbis except that it isn't free.

Of course I also agree that Safari and IE should just support Ogg/Vorbis. Makes most sense, really.

#24John Dowdell – Wednesday, March 9th 2011, 20:13

Recent related links show the differences may be understated:

(If planning debug/support costs, be sure to check the same browser brand across operating systems, and across device types.)

And if you're seeking to deliver audio as Ogg Vorbis, then there's some work being done to handle this in Flash... haven't evaluated it yet myself, but you may want it on your radar:


#25 – smarterthanyou – Wednesday, March 9th 2011, 20:34

i was enjoying this post until i got to the rant about ogg/vrbis. ahh well, shame i'll never read the rest.

#26Paul Brunt – Wednesday, March 9th 2011, 20:40

Spot on, As usual mozilla leads the pack in the open domain. I've been really surprised by google with chrome I would have thought they'd be on it in a heartbeat but given there release rate allow them a few weeks then see where it's at, I'm sure it'll be wobbly but at least there :-) I thought it'd be a few more months before requestanimationframe kicked in, I'm constantly surprised by how fast this stuff can happen.

As for apple, I think they may supprise in the not to distant future they've already felt the hurt that microsoft is now at, I doubt they'd want to do that again.

TBH I think IE is already dead I stopped caring at least 18 months ago,everything I do only sorta works in IE, if it doesn't work fully then mehh! who cares, it's reason for people to upgrade!! If they want to stay in the game let them chase the devs and sack their marketing department.

#27Peter Parente – Wednesday, March 9th 2011, 20:54

Excellent post. Your review unfortunately matches our experience working a on text-to-speech JS library that (attempts) to use <audio> ( We've discussed falling back to Flash many times, but are trying to stay on the open web train as long as possible.

#28 – Nikki – Wednesday, March 9th 2011, 20:55

Phil, do you know why Ogg Vorbis isn't part of HTML5 standard?
Because of Apple.

Which makes Apple guilty on both accounts:
1. For not supporting Ogg.
2. For succeeding in removing Ogg support from the standard, in favor of formats which bring Apple money. Read about an extortion organization called MPEGLA which Apple is a proud member.

AAC is also patented. You can use it on your web site, but one day some corporate lawyers will knock on your doors, asking for a nice big fat donation.

#29 – Andy – Wednesday, March 9th 2011, 21:06

You confirm my suspicions that Internet Explorer 9 is still a piece of crap, like its predecessors.

#30 – Matthew Heaney – Wednesday, March 9th 2011, 21:56

You only use .ogg and .mp3 in your test harness. Can you add webm to your list of audio files to test with canPlayType?

I wouldn't expect .ogg to work, unless there is a byte stream handler for .ogg installed on the user's system. (I don't know about whether .mp3 should also work out of the box.)

The IE9 Media Foundation components for WebM should be ready in a few days. If you fix your test harness to also include .webm, then we can verify that the audio tag will work.

#31 – Matthew Heaney – Wednesday, March 9th 2011, 22:10

Thinking about this some more, I think the problem is that you're using .ogg as the audio container. (Other commentators here have made the same point.)

You are confusing .ogg the container with Vorbis the audio codec. Use a webm as the container, and populate the file with a single audio track ("A_VORBIS").

The MIME type is "audio/webm".

When the IE9 Media Foundation components for WebM are installed, then I would expect the audio to play just fine. (But let's verify it: replace .ogg in your HTML5 page with .webm, and then I'll try the latest IE9 and MF WebM components.)

#32Dominic – Wednesday, March 9th 2011, 22:21

Matthew: if we need to rely on installed codecs, then what's the point of HTML5 Audio anyway? Why not rely on a Plugin (Flash) instead?

Also, the reason that IE9 doesn't play sound files in my test case is not the Codec I used (I supplied an MP3 file after all, that is loaded by IE), but the fact that it doesn't play audio elements that have been cloned with .cloneNode() at all.

#33Jos Hirth – Wednesday, March 9th 2011, 22:26

>Can you add webm [...]?

WebM is sorta meh if it's used as audio container. The typical file extension is "webm", but this extension is used for "audio/webm" and "video/webm". That's kinda annoying.

WebM/Vorbis is also a little bit bigger than Ogg/Vorbis.

I also don't see a reason why a browser vendor would support WebM/Vorbis but not Ogg/Vorbis.

#34 – tzs – Wednesday, March 9th 2011, 22:37

Ogg/Vorbis plays just fine on Safari on my Mac. That's because I installed the appropriate codec.

#35Jenna Fox – Wednesday, March 9th 2011, 22:50

As someone who develops html5 games, I can also state without hesitation that mp4 AAC is far superior to mp3, and equivalent to Ogg Vorbis. If encoded properly (just use iTunes and it'll come out great) AAC files do not suffer from leading/trailing silence - make perfect loops (aside from any browser issues which would even affect a wav) and has quality of the same level as Ogg Vorbis.

There are two important differences between Ogg and mp4 from the manufacturers perspective:

Ogg Vorbis could very well step on some patents. Nobody of suitable qualification has done very extensive work to find this out. Developing in a clean room is not the same as being patent unencumbered, and as an open source project, they cannot even strongly claim clean room environment. Apple's stance on Ogg Vorbis has always been that they're a big enough company that if they supported it, patent holders would become very motivated to find their patents in Vorbis. With AAC Apple and Microsoft know up front what the costs are - no risk. In this sense it is exactly like the video debate.

Further, there aren't many hardware chips on the market which accelerate Vorbis decoding, and AFAIK no chips which straight up do the decoding for you. Apple has always been of the position that hardware decoding is important to them for battery usage reasons. In my experience with Ogg compatible portable media players, Ogg consumes about 20% more battery in a given time than equivalent quality audio encoded with hardware decodable codecs like mp3/mp4. As a consumer I stopped using Vorbis for this reason years ago.

I don't think this is a good situation to be in, but I completely understand why we are in it. Regardless, use mp4 AAC encoded with iTunes and you should loose the lag issue as well as the lesser encoding performance of mp3. I haven't tried yet, but I believe flash can support it also for fallback on troublesome browsers like Google Chrome.

#36 – Matthew Heaney – Wednesday, March 9th 2011, 22:52

To Dominic: Microsoft has made the engineering decision that their browser not be monolithic application. (I agree with their decision.) Media Foundation allows the behavior of the system to be extended, so IE9 (and WMP too) gets the it automatically. That includes rendering webm audio and video, so you just have to install the necessary components. (We are very near a public release. If you want to build from sources now, then just clone the git repository at .)

Fix your test harness to use webm audio, and then let's see what IE9 does. If there is a problem with the WebM components, then I'll just fix it. If there's a problem with the browser, then I'll report the bug to Microsoft (with whom we have been working very closely for several months). I can promise you that both Microsoft and Google want Vorbis to work in IE9, but to do that you have to use webm as the container.

To Jos: to the extent that there is a "standard container" for HTML5, that container is WebM, not Ogg. If you want IE9 to support .ogg as an audio container, then you can lobby Xiph to write the necessary components (a "byte stream handler"). This has nothing to do with IE9. In the meantime, Google and Microsoft have made the engineering decision to support Webm/Vorbis, so if you want something now, just use webm as the container. I recommend you forget about .ogg audio containers for HTML5 audio rendering. That bridge has already been crossed.

#37 – pascal – Wednesday, March 9th 2011, 22:59

WHAT there is audio/webm? That's even more mental than Google's attempt at replacing the free JPEG by the shittier webm still-frame format.

How's PCM support? Shouldn't at least RIFF/WAV work everywhere? (And for short samples, with HTTP compression enabled…)

#38 – Matthew Heaney – Wednesday, March 9th 2011, 23:15

Audio/webm is a webm container with a Vorbis audio track. I don't know why this is "mental" if the OP was already trying to render Vorbis but in a different (non-HTML5) kind of container.

I don't understand the question about PCM -- we're talking about streaming from an HTTP server, and that usually implies a compressed format (here, Vorbis).

#39Dominic – Wednesday, March 9th 2011, 23:23

I choose MP3 because it is supported 'out of the box' by Safari and IE9. My goal is to eventually only need to provide _one_ sound file that works in every browser.

I don't want to introduce another file format that only works for users who are technically savvy enough to find and install a separate audio codec, yet somehow think that using IE is a good idea.

#40 – Matthew Heaney – Wednesday, March 9th 2011, 23:34

Well, your test harness uses both ogg/vorbis and mp3, so I don't understand your argument about wanting only one sound file.

Send me the ogg file, and I'll convert to webm for you, if you'd like. Then fix your web page to use "audio/webm" and use the .webm file as the test clip (replacing .ogg part--you can keep the .mp3 part if you'd like), and then let's see what happens in IE9.

#41Jos Hirth – Wednesday, March 9th 2011, 23:43


>How's PCM support? Shouldn't at least RIFF/WAV work everywhere?

Chrome doesn't support WAV. Speaking of which, it would be great if browsers wouldn't support BMP, too. If a stupid format works, people will use it. Yes, there are people who put BMPs on the web. Seriously.

@Matthew Heaney

>If you want IE9 to support .ogg [...]

I want IE to disappear. Completely. All existing copies and future versions included.

A browser which doesn't update itself is bad for the web. Everyone should be painfully aware of that by now.

Support for the Ogg container would add about 24k. Decoding Vorbis takes less than 200k. Big deal. (A typical fat home page these days is over 700k.)

>I recommend you forget about .ogg audio containers for HTML5 audio rendering.

Because some minor browser doesn't support it? Seriously, IE9 will be at less than 10% in 2 years. Of course I'll use Ogg/Vorbis for the good browsers and IE will get some special treatment. IE always needs some special treatment. IE is very "special" (please imagine me doing some air quotes) after all.

Do you really think that telling the user to install some codecs is a viable option? Really? If so, I'd tell them to install Chrome Frame. :P

#42Dominic – Wednesday, March 9th 2011, 23:45

My argument is, that I'm currently using two files (mp3 and ogg) and have support for Firefox, Chrome, Opera, Safari and IE. There is no gain in providing the sound file in a WebM container as well.

The sound file is here:

But as I said, it's a bug with IE, not with the format. I can build a test case that works in IE with that exact same mp3 file.

#43 – pascal – Wednesday, March 9th 2011, 23:58

@jos yeah, but I have seen dynamically generated images pre-canvas by using data:-urls and BMP. So it's not all bad.

@matthew: I think audio/webm is as useless as the other webm formats. There is already a perfectly good container format for vorbis: ogg. There's no reason why a browser should support decoding vorbis (which is webm's audio format) but not support ogg. They are both under the same license, but less heavyweight than matroska (which is webm's container format)

#44 – Matthew Heaney – Thursday, March 10th 2011, 00:25

@Pascal: but such support doesn't happen by magic. Someone has to write the component that understands ogg file format. (Perhaps Xiph has one already.) Google and Microsoft have decided that webm --not ogg-- will be used to carry vorbis audio payload for HTML5 rendering in IE9, and have allocated the necessary engineering resources to make it so. If you insist on using ogg as the container for vorbis audio, then you will just be very frustrated, because it won't work. This has nothing to do with IE9 and everything to do with the fact that webm is the HTML5 container standard. The fact that Firefox happens to be able to render ogg/vorbis is irrelevant.

#45Jos Hirth – Thursday, March 10th 2011, 01:18


Yes, but those days are gone. Same thing goes for WAV. It's only interesting if you want to generate some audio data, but there will be better ways to do that.

@Matthew Heaney

Firefox, Chrome, and Opera support Ogg/Vorbis. These browsers got about 50% market share worldwide.

IE9 got 0% and Safari got 5.08%. These browsers do not support Ogg/Vorbis. WebM/Vorbis needs extra software on IE9 and it's probably similar with Safari. So, in both cases you need to provide a fallback like M4A/AAC.

I mean, even IE6 "supported" SVG. If you installed that plugin, that is. Problem is, virtually no one did that. The same thing will happen here, too.

Since you do need to provide a non-Vorbis alternative as fallback, there is no benefit in using WebM/Vorbis. It won't improve anything. You'll still need two different versions of any audio file.

Merely shifting the percentages slightly doesn't help.

In 2 years there will be eventually about 10% IE9 users. If 5% of those (=0.5%) can also play WebM/Vorbis you can't stop providing non-Vorbis fallbacks.

Even if you inflate those numbers as optimistically (or pessimistically) as possible, you'd still only end up with maaaybe 3% more on the Vorbis side. That really doesn't change anything.

#46Rich – Thursday, March 10th 2011, 05:05

I've had these same issues with my project. I've opened a few bugs with chromium specifically about freezing when using the jsapi/buffering poorly/scanning slowly etc etc. I'm excited to have the tools, but the polish level is minimal. Firefox broke my heart a bit supporting only ogg/vorbis - while it's a better compression/SQ it's just not the format most people's music libraries use. so now not only do I have to workaround codec support but also whether to back out to flash and introduce even more uncertainty. It's all leading to some pretty serious conditional soup. I'm hoping by sometime next year, fuelled by development in FF4 and Chrome 11/12 a lot of this will be ironed out and web based music players and games can give apps a run for their money.

This code, the conditionals I needed to use, sums up the problem nicely T.T:

And that's not even the mobile bit :((((

#47 – Matthew Heaney – Thursday, March 10th 2011, 06:12

If I make a web page using this tag:

audio src="beep.webm" type="audio/webm" autoplay controls

then it renders without error in IE9.

As far as your test page goes, there seems to be a problem on line 45:

//Line 45

clips[0].currentTime = 0; //DOM Exception

Do you need to wait for the "loadedmetadata" event to fire before setting the currentTime?

#48 – aleks – Thursday, March 10th 2011, 12:21

Thumbs up for the rant as a whole and kicking some browser developer asses, hope this post will get quite some attention. While I don't give a fuck about .ogg support as it's a format mainly used by geeks (face it) but that's a whole different topic. (Bottom line: I agree it should be supported as well but I am more bothered by the limitations regarding audio creation and processing right now.)

I am currently working on something audio-related in pure JS and FF 4 is the only browser that is capable of handling it at all. But even in FF you'll have to do a lot of common audio tasks in JS and that will definitely step on the brakes, performance-wise.

Chrome's API looks promising, I'll definitely take that for a spin soon. But having a shitload of different APIs across browsers (and most likely platforms - mobile - as well) will probably be a pain in the ass. I never worked with it but considering things like that, Flash doesn't seem all that bad after all.

2011 and it's VHS versus Betamax all over, all the time.

#49Zack Hovatter – Thursday, March 10th 2011, 15:29

Awesome article, sir. Hopefully mobile browser developers will step it up soon.

#50 – Terry Schubring – Thursday, March 10th 2011, 16:20

MIDI has been around for 15 turns of Moore's law and my phone now plays 1080p video. Two sounds at once on the web? Ooooh, that's a tall order.

The original E-Mu Proteus had 4mb of sample ROM. I've seen bigger lolcats. Who could possibly build a multi-timbral polyphonic MIDI rompler into a browser? You would need to control the hardware, drivers, OS and browser.

Apple? Bueller? Anyone?

#51 – Harry – Thursday, March 10th 2011, 20:14

Your test case works fine in IE9 (plays 5 times in a row) as well as the other browsers if you add the audio element to the page's DOM tree like so:

var clip = document.createElement('audio');
clip.src = 'beep.' + (clip.canPlayType('audio/ogg') ? 'ogg' : 'mp3');

#52Dominic – Thursday, March 10th 2011, 23:39

Good to know, Harry. Thanks! It's things like this, however, that I really want to stop dealing with :/

#53 – Harry – Friday, March 11th 2011, 00:06

You're welcome. I agree that this is annoying, but it does not appear to be an incorrect implementation of the standard but a genuine bug. Have you reported this to Microsoft? If you click on the cogwheel icon in IE9 RC and select "Send feedback", you can file a bug report. It requires you to register for a Live ID, but it's probably worth a shot.

#54 – Fred Sauer – Friday, March 11th 2011, 18:09

I wonder if issue in Chrome is this one, with the apparent silence of the 5th playback being caused by the length of the tone and/or the amplitude in the latter part of the audio file

#55MeanEYE – Monday, March 14th 2011, 08:46

Hm, I still wouldn't worry too much about Chrome. We are talking about some really agile developers here. Every 4-6 weeks there's a new version out there. Thanks to Chrome's update system most of users get updates.

#56 – Ced – Monday, March 14th 2011, 11:40

Actually, IE9 is up to date with all standards in a way that makes W3C happy.
It is in fact W3C's fault, for not having completed the standard yet.
Ofcourse there can be argued over whether or now IE9 should try implement 'unofficial standards', but they choose not to so that devs that develop something right now are way more sure of having working code in ~3 years then with the browsers that are making their own 'bleeding edge'.
For more information on the standards, check out W3C's own HTML5 test/information page,

#57john – Monday, March 14th 2011, 15:37

I was just testing my app on Honeycomb and the latest iteration of iOS on the iPad 2. The use case is that when you click on a play button a small window will pop-up and it will begin playing your song.
They both work ok. Apple supports more codecs but Android has a better overall experience as far as audio playback.

#58 – Mark A. – Monday, March 14th 2011, 16:09

Dose anybody know which keys to use with the Z-Type game.
They don't say, they don't use the normal keys of left and right arrow keys or Z and X
and I can't get it to work with Trident or Mozilla.

"I don't give a shit about Internet Explorer".
Well you should as it's the main browser.
If you don't want to support a browser then don't support Mozilla as one version of Mozilla is incompatible with other versions.
If you look at your list, Opera, Chrome, Safari some work and some don't. They should allow work or none of them as they use the same engine.

#59 – James Grammer – Tuesday, March 15th 2011, 17:51

As it has been said: The use of profanity proves that user does not have enough intelligence to express themselves in any other way.

#60bertie – Tuesday, March 15th 2011, 18:53

I run an audio site..... I'm really in tangles because of the different support for different formats of audio. Much as I like open source there is nothing wrong with mp3, and only supporting ogg is head-in-the-sand stuff. It's also a pain that mobile safari requires a touch event. I know that those sites that play tunes automatically are silly, but if you want to do some cool stuff, you sometimes need to have the audio all loaded up and ready to rock.

But we can't ignore html5 because tabs and phones are so important now.

Thankfully there is jplayer.

It invisibly falls back to flash when appropriate. It's a really good fix and there's obviously been a ton of work put into it to work through this maze. Hats off to Happy Worm.

#61Jos Hirth – Tuesday, March 15th 2011, 21:37

@Mark A.

Z-Type is a typing game. You play it by (touch) typing those words which appear on screen.

@James Grammer

Personal attacks are worse. You disqualified yourself.


>there is nothing wrong with mp3

Apart from licensing fees, a relatively bad quality/size ratio, and leading/trailing silence.

>only supporting ogg is head-in-the-sand stuff

Ogg/Vorbis for the good guys, MP4/AAC for IE9 and Safari, and MP3 for Flash.

That's what you have to do. Well, you can skip MP4/AAC and deliver MP3 also to IE9 and Safari, but that's a kinda bad choice.

#62 – Matthew Heaney – Thursday, March 17th 2011, 03:09

@JosHirth: but you could also deliver webm/vorbis; this will work in Chrome, Firefox, Opera, and IE9 (with the WebM components installed).

#63Jos Hirth – Friday, March 18th 2011, 22:13

@Matthew Heaney

And then? I'd still need M4A/AAC for Safari. If I don't provide M4A/AAC I don't only lose Safari compatibility, IE9 compatibility will also take a massive hit.

Additionally, I'll waste some bandwidth since the WebM container got slightly more overhead than Ogg.

There is no reason to provide WebM/Vorbis. I removed it from my framework a couple of weeks ago.

canPlayType('audio/ogg; codecs=vorbis') -> Firefox, Opera, and Chrome will say 'probably'. And it does indeed work.

canPlayType('audio/mp4; codecs=mp4a') -> IE9 and Safari (+Quicktime on Windows) will say 'probably'. And it does indeed work.

Everything else (i.e. Safari on Windows without Quicktime¹) gets do-nothing dummy adapters instead of actual Audio objects.

[¹ Safari on Windows doesn't support anything without Quicktime. Audio is undefined!]

Adding WebM/Vorbis won't improve compatibility nor will it reduce bandwidth. So, why should I add yet another format if I get nothing in return?

#64Matthew Heaney – Saturday, March 19th 2011, 16:47

@JosHirth: I don't understand the argument that "IE9 compatibility will take a massive hit", since IE9 supports webm/vorbis audio.

Furthermore, I don't understand the argument that Ogg is more space-efficient then WebM. An Ogg page requires 26 bytes of overhead, plus the payload. (The payload comprises the segment table plus the audio frames.)

For the sake of argument, let's make a conservative estimate of the storage cost of using WebM as the container. (Let's ignore the overhead of the webm file headers, since it's small compared to the size Vorbis ident, comment, and setup packets.)

If we put the payload of an ogg page in its own cluster element (and this is a worst-case scenario), with a single block of Xiph-laced audio frames, then the storage cost would be:

cluster id: 4
cluster len: 3
cluster timecode ID: 1
cluster timecode len: 1
cluster timecode: 4

That's 13 bytes of cluster element overhead. For a single Xiph-laced block, the storage cost would be, using a simple block element:

block id: 1
block len: 3
track num: 1
flags: 1
payload: same as Ogg payload

That's 6 bytes of block element overhead. The max total cost would be 13 + 6 = 19 bytes. That's still less than the 26 bytes needed for an Ogg frame.

Furthermore, that's a conservative estimate of the overhead, since we have used a cluster for each ogg page. If instead we used a cluster as a container for several ogg pages, then the amortized cost of the cluster element overhead would approach 0.

So I don't understand your argument that a WebM file has more storage overhead than Ogg. How are you getting your numbers?

#65Jos Hirth – Sunday, March 20th 2011, 10:29

@Matthew Heaney

>I don't understand the argument that "IE9 compatibility will
>take a massive hit", since IE9 supports webm/vorbis audio.

As I said, it doesn't support it out of the box. As such, you'll probably only find Ogg/Vorbis support on maybe 5% of the machines... in 2 years, that is.

How many people did install the SVG plugin for IE? 0.1%? It was probably a lot less than that. :/

>Furthermore, I don't understand the argument that Ogg is
>more space-efficient then WebM. [...] How are you
>getting your numbers?

From the media I'm currently using of course.

 8,917 blam.webm
 4,517 hush.webm
 4,636 pickup.webm
12,791 wawa.webm


dadadash-webm.ibz 98,067
dadadash-webm.ibz.gz 64,262

 8,589 blam.ogg (-328b, -3.68%)
 4,210 hush.ogg (-307b, -6.80%)
 4,339 pickup.ogg (-297b, -6.41%)
12,424 wawa.ogg (-367b, -2.87%)

29,562 (-1299b, -4.21%)

dadadash-ogg.ibz 96,335 (-1732b, -1.77%)
dadadash-ogg.ibz.gz 60,756 (-3506b, -5.46%)

dadadash-noaudio.ibz 56,793
dadadash-noaudio.ibz.gz 42,079
(contains 42,381 bytes of image data as smushed PNGs and JPGs)

webm minus noaudio

ogg minus noaudio
96335-56793=39542 (-1732b, -4.20%)
60756-42079=18677 (-3506b, -15.80%)

The Ogg/Vorbis files were produced by oggenc2 like this:

oggenc2 -q 0 "foo.wav"

The webm files were created like this:

mkvmerge" -o "foo.mka"  -a 0 -D -S "foo.ogg" --track-order 0:0
@mkclean --doctype 4 --remux "foo.mka" "foo.webm"

"ibz" is my own mxhr-ish format. It contains a very simple header which is followed by the base64 encoded data. (Text is stored as-is.)

Almost 16% less in packaged form is a pretty big improvement. But to be honest, there is some odd effect going on here. The base64 encoding acts in this specific case like a filter, which makes Deflate about as good as LZMA.

With M4A/AAC the base64 encoding doesn't improve the compression. (Well, improving the compression isn't the reason why I base64 encode the data.)

This effect also isn't observable with bigger high bitrate tracks. LZMA also isn't able to compress those files noticeably more effective than Deflate.

But even without that odd phenomenon, Ogg/Vorbis is still slightly (SLIGHTLY!) smaller than WebM/Vorbis.

But even if there weren't any difference whatsoever, there still wouldn't be a reason to use WebM/Vorbis. I'm already annoyed that each sample needs to exist in 4 versions. I really don't want a 5th one. Even more so if there isn't any benefit.

#66Matthew Heaney – Sunday, March 20th 2011, 15:08

@Jos Hirth

Chrome, Firefox, Opera, and IE9 all support Webm/Vorbis ("audio/webm").

Yes, a separate download is required to add WebM support to IE9, but that only needs to be done once. (The installer uses Google auto-update technology.)

Information about the components is here:

The actual download page is here:

Microsoft worked with Google to facilitate the development of the components (their technical support for us was extremely helpful), but left it up to us to provide our own mechanism for actual deployment of the components.

#67Paul – Monday, March 21st 2011, 15:11

RE: Chrome Audio problems - I to have had issues but solved them by using the .load() method before .play(), rather than the .currentTime = 0 before a .play().

Note you have to do browser sniffing as Opera gets a performance hit using the load() method. (FF seems ok with this method)

Hope this helps...

#68Jos Hirth – Tuesday, March 22nd 2011, 02:16

@Matthew Heaney

I still don't know why I should bother with WebM.

Ogg/Vorbis + M4A/AAC = Firefox, Opera, Chrome, IE, Safari.

Ogg/Vorbis +WebM/Vorbis = Firefox, Opera, Chrome, some IE, no Safari.

WebM/Vorbis + M4A/AAC = Firefox, Opera, Chrome, IE (AAC for the most part), Safari.

So, I obviously need M4A/AAC either way, but Ogg/Vorbis + M4A/AAC + WebM/Vorbis does not make it more compatible than Ogg/Vorbis + M4A/AAC. And I do need to create Ogg/Vorbis files either way. Why shouldn't I use them the way they are? After all it does get the job done, by covering Firefox, Opera, and Chrome.

I initially planned to use Ogg/Vorbis as legacy fallback and WebM/Vorbis as primary format for the modern browsers. But I scrapped that idea when I heard that IE and Safari won't support WebM/Vorbis natively.

The existence of some plugin doesn't really change anything. There are thousands of plugins, but how many of those are relevant? (Hint: About five.)

As long as YouTube doesn't go WebM only (or WebM for HD heh), there won't be a noticeable difference.

I mean, it's like saying IE supports text-shadow... you only need to install Chrome Frame. :P

#69 – madbrain – Thursday, March 24th 2011, 02:45

Hmm. Would be really cool if they could extend audio support enough to be able to play MOD-family files without just using software synthesis. But that would require:

- Preload a set of samples (up to 99), ideally from one file.
- Play samples from the set in a bunch of channels.
- Change sample playback frequency on the fly in each channel. This includes frequencies <1000hz and >200khz (to allow for a given sample to be played at different octaves).
- Ideally, play from arbitrary sample position (not so common but used in the MOD family and musically useful).
- Sample loops that start later than the start (ie play once from 0 to 1000 then loop from 1000 to 1080). The looping points must be precise, otherwise it goes out of tune.
- Change playback volume on the fly in each channel. (ideally with volume ramping)
- Change playback panning on the fly in each channel.
- Very tight timing (up to 100hz)
- Ideally a couple of synthesizer-like features such as lowpass filter (with resonance) or reverb.

Incidentally this is the kind of features also used in games, and a lot of console hardware has exactly this feature set (SNES, PSX, Saturn, NDS, etc ad nauseum...), not to mention a lot of synthesizers (almost everything from the 90s, everything "wavetable"/"PCM", everything that plays General MIDI, samplers).

#70Matthew Heaney – Saturday, March 26th 2011, 19:47

@Jos Hirth

I finally got around to changing the WebM ogg source and webm muxer DirectShow filters to support Xiph-style lacing of audio frames, and converted some ogg files to webm to see how much improvement there would be when using webm instead of ogg as the container.

I downloaded a couple of files from here:

For this file:

The difference is:

The_Abyss-4T.ogg: 5473107 B, 5345 KB

The_Abyss-4T.webm: 5447550 B, 5320 KB

Using webm as the container instead of ogg confers a space savings of about 25 KB.

For this file:

Epoq-Lepidoptera.ogg: 4357992 B, 4256 KB

Epoq-Lepidoptera.webm: 4337565 B, 4236 KB

Here webm confers an advantage about about 20 KB.

About the webm files. The packets on each Ogg page were laced using "Xiph lacing" as described here:

This more or less preserves the format of the Ogg packets as they exist in the Ogg file. Call this an "Ogg packet group".

The webm muxer creates a single audio block (using a SimpleBlock element) for each Ogg packet group, and marks the Xiph lacing bit of the block. The audio blocks are then put on clusters, about 5000ms of payload for each cluster.

For these audio-only webm files, the webm muxer does not write a SeekHead element or a Cues element. (Of course it would be possible to write a Cues element, or a secondary SeekHead element, but I was trying to duplicate the semantics of an Ogg container, which don't have a seek index, in order to make an apples-to-apples comparison.)

The conversion from Ogg to WebM was performed using the WebM DirectShow filters. The command I used was:

makewebm --ogg-to-webm --input XXX.ogg

I have checked the requisite changes into the master branch of the origin repositories at We haven't released binaries yet (the IE9 support kept us very busy until very recently), but if you want to build the DirectShow filters yourself, you can pull the sources down like this:

git clone git://

git clone git://

An Ogg container is not as storage-efficient as a WebM container that uses (Xiph) lacing for audio frames. If you're using a muxer that is making webm files that are larger than the ogg files from which they were converted, then there's a possibility that the muxer is creating webm files in a manner that is suboptimal (at least for straight conversion of ogg files).

#71 – Ted's and Bird – Monday, April 4th 2011, 14:29

My html5 friend you need to change the clip.currentTime = 0 to clip.load();
Then it will work across all browsers. :)

function getClip() {
for( var i = 0, clip; clip = clips[i++]; ) {
if( clip.paused || clip.ended ) {
if( clip.ended ) {
clip.load(); // CHANGE HERE
return clip;

// Still here? Pause and rewind the first channel
clips[0].currentTime = 0;
return clips[0];

#72game audio – Thursday, April 7th 2011, 20:27

this is brilliant - thanks for all the info. The hybrid flash/html5 players are the way to go and jPlayer seems to be leading the pack

#73Lab Coat Media – Friday, May 27th 2011, 19:21

I enjoyed your article thoroughly not only for the information on HTML5 Audio support, but also for the passion (and profanity).

#74 – Maurice – Wednesday, June 8th 2011, 09:48

Ow I so agree with what is said here. To learn some HTML5 I started buidling a mahjong game ( very beta) and the most issues I encouter is with sounds. Pushing the frustration here is that Chrome has the worst support for it (while I expected they would have the best, them saying how they support HTML 5).

Ofcourse Microsoft's support is bad, choosing mp3 support instead of ogg (for example), but to be honest, it was no surprise to me. They still haven't learned from their IE6 era, still thinking their standard is the standard. On the other hand, I've stopped testing for IE, any version, they all suck. Sometimes I see sites having 4 extra stylesheets and stuff just to support IE 6->8, that is just stupid. I gave up on that, it takes too much time to get it all IE compatible.

Best thing to do for me is put in a warning that their browser suck (in a poltie way ofcourse) and is not supported. If MS doesn't want to use the standards and their users are too stuburn (or stupid) to use a different browser, well that's then too bad for them.....

#75Ricardo – Monday, June 20th 2011, 12:00

I'm getting ready to build a rather large application capable of handling large playlists of MP3 (and mp3 alone) files, and of course I've been longing to use HTML5 audio with as few constraints as possible. Thank you guys for all your inputs.

I've done a lot of testing and there are indeed some inconsistencies cross-browser with audio files.
But they're easier to overcome if your goal is to play music and not sound clips (as in a game), as you'll never need to play more than one file at a time and there are no short sounds, so you can get away with it.

I've had some trouble making the playlist JS code working on all browsers, but thumbs up to the Sound Manager 2 API for dealing with all of the trouble for me. So far this is working great on all browsers, even in IE9 with HTML5 audio enabled!

My only fear is: memory. Will the SM2 API be able to cope with memory issues when dealing with plenty of large MP3 files with HTML5? I've noticed that Chrome shoots memory usage by a lot when preloading audio files.

What are your experiencie with HTML5 audio and browser performance? In simple test cases, it is obviously bettern than Flash, but I fear it won't be able to cope better as things get trickier.

#76 – Yordan Yanakiev – Friday, July 8th 2011, 15:46

HTML5 is completely dissaster.
Some morrons think that it can replace Flash, but actually HTML5 IS FUCKING LAGGY !


Go f**k yourselfs with this dump s**t called HTML5 spooking my PC to max just for a stupped video on youtube:

CPU : Quad Core 6600
VGA : ATi 6950
Browser : Chrome 13
OS : Windows 7 - 64 bit. ultimate eddition.

All of the CPU cores rise to the max usage, and i can barelly close the page.

get this stupped dump out of youtube !

#77Daniel – Friday, July 22nd 2011, 05:34

To get sound working in IE9, I scoured the intertubes and found a very surprising solution...a META tag...yes a META tag. Adding this to my page, made MP3 files play without issue.


#78Aaron – Wednesday, August 3rd 2011, 07:11

Hilarious article mate! Answered my questions about the state of HTML5 audio at present and gave me a good laugh in the process :P Going to link to this from a blog post in the near future...

#79 – some internet guy – Thursday, August 4th 2011, 18:35

f*cking A-M-E-N brother!

Back to work and bend over to let IE have it's way with me. Believe me, it's not pretty ..

#80Markus – Tuesday, August 30th 2011, 20:23


That also affects the rendering engine, btw. This bit of code I discovered long ago should make IE use it's most up to date engine, regardless of version.

meta http-equiv="X-UA-Compatible" content="IE=edge"

When I found it, it also suggested that "chrome=1" also be added to the content which, iirc, affects the Chrome Frame plugin and has a similar effect.

On topic: I discovered this site while bumming around trying to figure out exactly what the current (read: right now) support for the audio tag is. Mainly because I want to add some sound effects to the browser game I'm working on.

I'm not really worried about the sound not working at all (the game hasn't ever had sound before), but I AM worried about the sound working poorly. Since, imo, poor support is worse then no support at all.

Anyways, I found it amusing and echo your IE sentiments. At least, IE9 is, for what it's worth and from what I can tell, the most standards compliant version of IE. I'm also hoping they pick up the update slack and don't go for years between revisions like they have in the past.

Look at me, hoping Microsoft will do something the right way... HA! In my dreams, perhaps.

#81 – peterg4000 – Thursday, September 1st 2011, 09:05

The sentiment of your article is SO SPOT ON!
I like the cut of your jib.

Get your act together browser makers!!!

#82 – Jack – Monday, October 10th 2011, 02:05

Hi Dominic,

You sound just like the way I did before I gave up web development during the browser wars of the 1990's. Best decision I ever made. I suggest you do the same. Seriously.

Best Regards,

#83 – Sparky – Sunday, October 16th 2011, 13:47

@ Jack
I've been waiting for the W3C to finish standardizing HTML5 and CSS3 before I continue web development. There's no way I'm going to cater to hypocrisy over the definition of "standard". Either it's standard and supported or I'm not using it. I've decided to use my own best judgement on what I think should be standard: for audio files, I'm only going to use .wav files (but they sound warped, so I have to still decide for sure) and for image files, I'm only using .png for static graphics and .pdf for vector graphics.

What we are all looking for is the best quality of sound and most scalable graphics. Internet connections and computer hardware has developed enough so that they can download relatively large files within a short period of time, so file size is not the issue. Web designers should allow the user to determine what they download and when, which is an aspect of web design accessibility. Therefore, the focus should ONLY BE on achieving the ideals by using them ourselves, as web designers, not on the internet hardware or software that is dragging its numb leg behind it. Make the web pages that should be made, and watch everyone else come up to that level.

#84damn_it_audio_doesnt_work – Saturday, October 22nd 2011, 20:18

Hah. Great article. After trying to hack my way into getting the older Android browsers to play an audio file (tried HTML5 audio- wav, ogg, and mp3, a flash audio player, and even a quicktime player), we still haven't figured out anything that will work consistently.

The best part is that the Android browser CLAIMS it supports HTML5 when you use JS feature detection (we were using HTML5 shiv, I think).

Fuck. Good job on the "undocumented feature," assholes.

#85damn_it_audio_doesnt_work – Saturday, October 22nd 2011, 20:20

Oh. forgot to add that we tried jPlayer, too. That didn't work for us either.

#86 – Hubert – Tuesday, November 8th 2011, 16:57

Not a real audio until it supports:

- Pitch/Speed (ie modifying the sampling rate, impossible to do a racing game without this)
- Panning, of course

#87 – TGM – Sunday, November 13th 2011, 12:58

@Jenna Fox: Shame on you. The concept of the web is to be open and free to create on it. Bringing patent trolling into the mix will end in tears. Just look at the current free license for m4a. What do you think will happen when the majority are on m4a? It'll come out of the content creators wallet. Welcome to the restricted web.

#88Epicanis – Monday, November 14th 2011, 22:23

Personally, I'm considering offering both audio-only webm ("weba"?) and ogg-vorbis. Since the source Vorbis stream can (I assume) just be remuxed losslessly between the two formats, I'm willing to accept a few extra MB of disk space needed to offer both containers.

mp3 doesn't seem to be as much of a patent risk as some of the other proprietary formats (like AAC audio or h.264 video) - there's definitely still some patent risk, but as far as I can tell it's only aimed at developers or distributors of encoders and decoders, not on people distributing the final .mp3 "content". I still intend to avoid it unless I decide I absolutely must have that last 5-6% of the web that insists on Apple browsers.

(And that's a key point - for all the volume of noise that Apple corporation gets on the web, every time I check browser statistics, the Safari web browser hovers around 4%-6% market share. The iPad&reg; browser, for all the noise IT gets, was less than a tenth of a percent in the one measure I was able to find of market share that mentioned it. If it becomes fairly routine for people who insist on using IE9 to install the .webm media support, that just leaves about only 5% of HTML5 browsers that don't support Vorbis audio in either Ogg or Webm containers [or both - I'm guessing Chrome will end up supporting both if it doesn't already, and it wouldn't surprise me if Firefox ended up supporting both as well])

Admittedly, my own use case will just be basic web-based playback of individual audio tracks, no fancy scripting/seeking/special-effects needed in my case.

Now I just need to figure out how hard or easy it is for me to remux Ogg Vorbis files to webm...

#89 – Sti – Wednesday, November 23rd 2011, 14:51

Whathever the codec/format, please enable true html5 audio support in mobile webkit-based browsers!
The overwhelming number of people who are going to use and benefit from such a move should be stronger than the false debate about royalties, if there is still one after that.
Additionally, there will always be countries where this crazy anglo-american legal stuff doesn't apply anyways; (very) big countries, that is.
Just move where the grass is greener for your business, at least virtually!

#90Rap and Hip Hop Beats – Saturday, November 26th 2011, 16:21

This is a great post. Currently i've been diving into html and recently just discovered about html5. Im learning html from a website at if anyone wants to know. Thank you very much. I can see the major issues hear. Im sure they'll be fixed as soon as enough people complain.

#91me agains – Thursday, December 15th 2011, 18:35

complain about what lulu dear?! uh'd ! complain to who!? came here december 2011 from riverleaf dot net? where there is a real sweet ie9 audio tag demo and that's all but browsers supports is changing everyday heck all out of date waywayway here but still very tastefully spent anguish so kudos - future update time !! ie10 is nosediving from 97% support for current html5-css3 to 74% support in just one month so weheywoah should surface right about bang-on 5-30% per usual lol wonder if they'll fuck up riverleaf' demo on their way to hell? ... poor peoples, eh what a resume "i did ie did i" [xrashk] who says we do tent city in redmond and demand immediate release before they screw it over even more like imagine you got this psycho blobotsky blacklist crapola in all our fart holes and then we unleash this animal system-destrucxtive renegade windows browser free of crippling anything yet even broadcasting hourly updates on censorshit helll from 126 nations around planet earth, including super blacklisted China with 12% GDP growth 10 years running.btw do you see any labels on your desktop says made in China? now crack it open and google the part refs lol why was we borns in a 3rd world grunt camp where we can't even see what they do with code where they own everything we use ! shit eh, you code mongers you, redmond today! you too lulu, homework's fun in freezingraincanvasses SSSHHHHHHH we are not suppposed to know anything more how toop'd we r (just pretend japankoreavietnamcambodiaphilippinesafghanistan never happened) cuz we gots the "major issues hear" to complain ... oh yeah xrshkxrshkxrshkxrshkxrshkxrshkxrshkxrshkxrshkxrshkxrshkxrshkxr

#92swf to html5 converter – Thursday, March 1st 2012, 10:46

I don’t think Flash is the one that requires a lot of computing power, it’s the fact of decompressing and decoding a very complex data in real time called “Digital Video”, or you think HTML5 wont use the processor exhaustively to achieve a realtime HD video decoding ?, smoothly and leaving some computing for the another tasks ?, like Flash actually does it ?, yes its a lot of computing power, but for seeing a Full HD video (1920×180) at a 60fps, in full screen and my computer still alive for another tasks…Flash makes transparent the hardware calls implementation for the developers, which you will need to deal with conversion of flash to html5 players by rendering a lot of hardware engines, then multi-platform apps will be a true headache for the developers, the same problem than always: HTML hacks for each browser but with a more complex technology: HTML5

#93 – Angry at FF – Friday, March 2nd 2012, 02:06

Actually Firefox is what deserves the fuck you.

It's Feb 2012, and NO HTML5 audio controls work in Firefox 10.0.2, or at least on top of a floating bg. It keeps coming up and turning into a blank X. None of this is happening inside of Safari. In fact, I can go multiple routes in Safari, using mp3, m4a, but not ogg vorbis, BFD. FF's audio controls look like they were designed by some moonlighting engineer, and not an actual graphic designer anyway.

Meanwhile, I have to go to ogg so that Firefox doesn't spend one blank minute playing the file, but guess what, it doesnt autostart ogg either.

Firefox is also slowing to molasses on my computer. Its a disaster.

#94 – Tony Reed – Saturday, March 10th 2012, 18:59

I can't get <b> any </b> HTML5 audio to play in Chrome 18.0.1025.54 beta; OS X 10.5.8.

S'a shame, 'cause I like Chrome.

#95 – henry – Thursday, March 22nd 2012, 06:25

Wow, very comprehensive review. I'm thinking about learning HTML5. I'm seeing more and more job/freelance listings asking for <a href="">html5 media player</a>knowledge and so along with reading some of the online references you listed, I'm going to have to pick up the book as well. Really appreciated the chapter breakdowns.

#96Kevin Gadd – Monday, March 26th 2012, 17:03

It blows my mind that it's March 2012 and <audio> is still totally busted in Chrome. I guess if I want things to work I'll have to use their braindead AudioContext API.

#97 – Ken – Sunday, April 15th 2012, 19:29

The Powers that be wanted HMTL5 to succeed (at first!) , But now after rethinking , they have understood that good HTML5 audio and Video (speed up) support would lead to people making games that would not have to be sold through their stores., Just look at the companies that are dragging their feet, Apple ( Store), Google ( Store ), MicroSoft (store). If I understand right, they even turned HTML5 development back over to the assholes that were procrastinating over HTML for the last 10 years WWWC.

So I feel HTML5 will only advance because Mozilla keeps pushing it and the other companies are now afraid to get left behind. APPLE MICROSOFT AND GOOGLE stop the lie now!!!. Oh and if you think this is a crazy Idea, Apple is now being sued for teaming with book companies to fix E-book prices. It never ends

#98 – ken – Sunday, April 15th 2012, 19:30

p.s... Sorry for the typos, Insert HTML5 where needed. just woke up

#99html5 player – Friday, April 27th 2012, 12:22

Awesomecailsz!!!!!!!!youtube finds its repository.The scrobber finds its effectiency as such forcomming youtube html5 had to be implemented to make browser more faster.<a href="">html5 media player</a>

#100Michael Dionne – Wednesday, May 2nd 2012, 04:57

I totally agree with the article.
However, there are other ways, without using Flash. The Unity WebPlayer still requires a plug-in to run, but at least you can make the Unity WebPlayer listen to external HTML Javascript functions (external calls), and use it silently in a 1x1 pixel iframe on same domain to control all your audio. Also, it is free. I would explore this way if I was facing that problem. Chrome is supposed to embed the Unity WebPlayer directly already, or soon, which eliminates the need to install any plug-in for Chrome users.
This is what happens, when things are not elegant by default; you must find your way through, and this is a complete waste of time.

#101Whity – Wednesday, June 20th 2012, 17:09

Can someone kind drop here URL of webm Audio file. Need sample.

#102 – Kyle Newsome – Tuesday, July 31st 2012, 01:31

The scumbag steve hat on the paragraph made this post for me. Good show!

#103industrial training indore – Tuesday, August 14th 2012, 10:03

Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog.Please do keep up the excellent work.
<a href="" title="industrial training indore"> industrial training indore</a>

#104wa-jerr – Tuesday, September 25th 2012, 15:01

I found a bit of hack workaround
if you want to have a background sound or not onClick sound in mobile Safari.
so far so good, seems to work
and the hack is
It has to be initiated on onCLick but you can pause it straight after
and play whenever you want after
so if you ask user at the beginning if they want sound in your app
if they click yes
you play them and pause
starlight after

and after that you will be able to resume the sound whenever you want

<audio id="audiotag1" src="" preload="auto" loop="true"></audio>

js example works on Ipad 3

I hope it does make sense :-)

#105Confused--Guy a73ae3 – Sunday, October 7th 2012, 14:47

This article was wonderful last year, but for the sake of anyone reading it now in 2012, it needs to be updated to talk about the new Web Audio API, which I just found out about last night after revisiting how HTML5 audio support has been going.

For me, compared to last year’s terrible support, it’s nothing short of a miracle. It seems to be supported by not only Chrome, but also Safari on OS X 10.8 *and iOS 6*. The drum app on this page here ( *works on my iPad.* Mozilla says they’re working on Web Audio API support too. Maybe there *is* hope for game audio after all—and it took only three or so years too many.

This blog has a bunch of more nice projects that use it ( I can't get over how they work as well as they do: no popping or delays or anything. I haven't seen someone try to loop a song continuously yet: hopefully that’s currently possible.

#106dkurland – Saturday, October 27th 2012, 09:53

Yup, on my 3rd-gen iPad running IOS 6, autoplay of HTML5 audio tags has suddenly begun working! (I've had IOS 6 installed for a couple of weeks, and am pretty sure I tested this feature right away, but only noticed it working tonight.) I don't recall seeing any notice of this from Apple, although I did see that mobile Safari had been granted the ability to support file uploads via
form input type="file"
-- another feature I needed but which Apple had withheld.

#107 – petpost – Saturday, December 15th 2012, 17:49

his is a follow up to my 2009 article Native Audio in the Browser , which covers the basics of HTML5 audio. It may well be worth reading.

#108 – petpost – Saturday, December 15th 2012, 17:50

his is a follow up to my 2009 article Native Audio in the Browser , which covers the basics of HTML5 audio. It may well be worth reading.
<a href="">petpost</a>

#109 – James – Friday, December 28th 2012, 18:53

I found this page after a few headbanging days trying to add sound to my iOS game. I started with HTML5 Audio, got it working and then scrapped it due to laginess (looping sound files based on user actions).

I then moved on to SoundManager2 which worked in my desktop Safari (AFTER adding the file folders as trusted Flash sandbox folders) but failed to work on my iPhone. Assuming it's because of the same security exception but didn't explore further. I didn't explore if I can work around this though.

After all of this it seems my last hope is WebAudio, which I originally discounted because it's difficult to grab the mp3 files from a client side app without FileReader (which scumbag safari doesn't seem to support in older versions).

It's good to see that I'm not going crazy and the issues are with the vendors. It's crazy though, that years after the spec is released we still don't have [what I consider should be] bare-bones Audio working for HTML5

#110 – Jatobá – Monday, August 12th 2013, 23:25

Please, update this article.

#111lamafole – Friday, December 13th 2013, 01:37

HTML5 is kinda powerful now, but the big problem is that some of the Tablets and smart phones does not support it, that sometimes customers are kinda complaining about audio output problems like on our site still we are trying to upgrade and find a way to solve this problem.

#112 – Eric – Thursday, March 20th 2014, 18:27

Not sure where you got the idea ogg is a smaller format. I have never encountered an ogg/vorbis file the was less that 3 times the size of an mp3/mp4. In my experience ogg files are frusterating huge and they make Firefox appear slow.

#113Andrew – Wednesday, August 13th 2014, 14:11

I appreciated your rant against IE. I speak the same language!

#114 – Mario – Friday, November 21st 2014, 01:55

Curious what anyone's thoughts would be as of late. I haven't tried it in a few years, but it does look like support is a lot more wide-spread now.

#115 – Techie007 – Saturday, December 20th 2014, 03:44

Opus and Vorbis support in Internet Explorer for HTML5 <audio> is currently up for vote as of this writing. Please vote it up here so that webpages using HTML5 audio with Opus will work in Internet Explorer (all you need is an email address to vote):

Please vote, even if you don't use IE (I use Firefox). If enough people vote on this, hopefully Microsoft will realize that web developers want Opus & Vorbis support. Support from IE will greatly help web adoption of those format, since IE is the world's #2 most popular web browser.

#116 – Techie007 – Saturday, December 20th 2014, 03:55

@Eric: I'm not sure where you got those large OGG files from. Are you sure that they were OGG Vorbis audio files and not OGG Theora video files? Perhaps they were encoded at ridiculously high bitrates "just because". Vorbis easily beats MP3 in terms of size/quality ratio any day. And most of the time, Opus can beat Vorbis and AAC.

Here are the results of a recent 96 Kb/s listening test:
In this test, MP3 was given a 32 Kb/s advantage over the other codecs, which just allowed it to tie with Vorbis. At 96 Kb/s, I'm sure it would have scored 3.2 instead of 4.2.

Here are the results of a 64 Kb/s listening test:
MP3 was not included in this test. Rest assured that it would have ended up a mid-low anchor if it was included, since MP3 music sounds bad at 64 Kb/s.

Please try encoding some audio files to Vorbis (frequently mistakenly called "ogg") yourself with LameXP:

#117 – Nirantali – Tuesday, October 13th 2015, 02:51

Firefox = no midi
Chrome = no midi
HTML5 = no midi

But IE plays them since ever...

(irony on)
But ok, no Problem, then i convert my 5-30kb .mid to 8-30mb's Mp3's, i mean it's no Problem for the Chrome, Firefox and HTML5 Users to download 8-30mb, they all have ultra fast Internet right?
(irony off)