Thursday, July 30th, 2009

The Doctor subscribes HTML 5 Audio cross browser support

Category: Sound

The doctor is in, and this time the specialist is Mark Boas who walks us through HTML5 Audio in various browsers and how to get audio working on the various implementations that are in the wild today.

This early in the game especially, all implementations are not equal. For one there is the codec support:

But also there are the various levels of API support (and even the fact that Opera current supports Audio() but not the audio tag for example).

Mark worked on the jPlayer jQuery plugin which lead him down this path, and in conclusion it comes down too:

  1. Check for HTML 5 audio support and if not present fall back on Flash.
  2. Check the level of HTML 5 audio support and adapt your code accordingly for each browser.
  3. Check what file types are supported and link to appropriate formats of the files.

You can go to a audio checker in various browsers to see them poked and prodded.

Mark shares code such as:


  1. // Using JavaScript You can check for audio tag support like this:
  2. var audioTagSupport = !!(document.createElement('audio').canPlayType);
  4. // Checking for the audio object looks more like this:
  5. try {
  6.     // The 'src' parameter is mandatory in Opera 10, so have used an empty string "",
  7.     // otherwise an exception is thrown.
  9.     myAudioObj = new Audio("");
  11.     audioObjSupport = !!(myAudioObj.canPlayType);
  12.     basicAudioSupport = !!(!audioObjSupport ? : false);
  13. } catch (e) {
  14.     audioObjSupport = false;
  15.     basicAudioSupport = false;
  16. }
  18. // Need to check the canPlayType first or an exception will be thrown for those browsers that don't support it
  19. if (myAudio.canPlayType) {
  20.    // Currently canPlayType(type) returns: "no", "maybe" or "probably"
  21.     canPlayOgg = ("no" != myAudio.canPlayType("audio/ogg")) && ("" != myAudio.canPlayType("audio/ogg"));
  22.     canPlayMp3 = ("no" != myAudio.canPlayType("audio/mpeg")) && ("" != myAudio.canPlayType("audio/mpeg"));
  23. }

Posted by Dion Almaer at 6:12 am

3.6 rating from 14 votes


Comments feed TrackBack URI

Wouldn’t that be “The Doctor *prescribes* html 5 audio cross browser support”? That said, awesome article!

Comment by beren — July 30, 2009

The idea behind getting an audio and video tag was that the browser would have the ability to play media natively, without the need for plugins (such as Flash).

I don’t mean to be a negative nelly, but I don’t see this happening any time soon (if ever) the way this is shaping up.

Forget for a moment that in order to completely move off of Flash(including as a backup) you need to wait for support for these tags to become ubiquitous or for IE to make meaningful movement towards HTML 5 support; to me the real show stopper is the lack of ability of the browser vendors to agree on standard codecs.

Look; Flash wasn’t the first technology capable of displaying audio and video on the web. What made it popular was that it *was* everywhere, you no longer had to encode your media in seven different formats for all different browsers and platforms (wmv, qt, etc…etc.) – you could just encode it in Flash and it would work for everyone no matter what they were running.

To turn around and say – ‘the browser has this ability natively now; you just need to encode your media in ogg, mp3 and wav’ is a step backwards and leaves me doubting that this will ever achieve widespread adoption (let’s see, I can encode in several formats and due all kinds of checking to get it to work, or just encode in one format and know it will work…hmmm…tough decision).

I know this statement will be like pouring gasoline on flames in these parts, but: I’m for the Open Web, but not when it comes to making everything harder or providing a worse or more inconsistent user experience. I suspect you’ll find your average developer who cares more about getting his job done will feel likewise. Unfortunately for web standards, history has proven this to be true (to state the obvious, standards that have been too difficult to work with or have inconsistent implementations have seen slow or limited adoption).

Comment by coryn1 — July 30, 2009

It’s the element issue all over: what codes are we going to use and support?

Comment by MartijnHoutman — July 30, 2009

That should have said element :-)

Comment by MartijnHoutman — July 30, 2009

Alright, VIDEO element. Where’s the preview button? :-)

Comment by MartijnHoutman — July 30, 2009

I had such high hopes for using video and audio tags in the future, but as long as this indecision and/or lack of consensus continues between browsers it will never happen.

In order to create a substitute to Flash for multimedia playback, we need consensus.

Comment by RoryH — July 30, 2009

This clearly isn;t an issue of consensus, but one of politics. For Apple and MS (and Google and Opera to a lesser extent) support for standards and doing the right thing for the web are secondary to their attempts to leverage their platforms to make more money for themselves. Apple wants to exert influence over media formats so that it’s iPhone and other hardware and software can continue to operate via making controlled deals with other big companies. MS is holding out while it attempts to leverage other proprietary technologies.

Mozilla has the health of the entire web echo-system at heart. Pressure from them, and from us, may tip the scales and make it more of a priority for all browsers to support unpatented, royalty-free techologies.

Comment by jamienk — July 30, 2009

@coryn1 Maybe the point is not to eliminate Flash completely but to use it as a ‘patch’ for HTML 5 non compliant browsers so that developers can start using the tag in a meaningful and consistent manner and not worry about cross browser compatibility.

@RoryH Perhaps a consensus will be achieved but for now at least as @jamienk states, it appears that the folk behind browsers have very different ideals. It is of course still an option for developers to provide both OGG and MP3 versions of audio. It’s not THAT hard, just not ideal. Maybe people will start using OGG supporting browsers motivated by quality and/or filesize.

Comment by GalloNero — July 30, 2009

Could someone clarify when it is that `Audio` throws error and so need to be wrapped with try-catch?

Comment by kangax — July 30, 2009

I just wanted to say thanks for doing the work up front to determine what these new browsers can do with the audio tag.

If the need arises, a dev can refer to your post to see what kind of tools they have to play with to support audio in a web page.

Thanks man!

Comment by someguynameddylan — July 30, 2009

@GalloNero – My concern is that even if you are using it as a patch for HTML 5 non-compliant browsers, it still requires far more work for you, me, and the average developer since even HTML 5 compliant browsers don’t agree on standard codecs for the audio and video tags. So if I want to use these tags for browsers that support them, I still need to have multiple versions of all my media, along with a library (similar to the jquery plugin above) that picks the appropriate media you’ve encoded based on HTML 5 browser. One word sums this up nicely: Yuck!

Comment by coryn1 — July 30, 2009

You could actually test for OGG support specifically, and in browsers that don’t support that codec, you could use one of the SWF players (there are two different public implementations, one in HaXe, and one compiled using Adobe Alchemy). In case anyone would like to just use one format, instead of two. Of course, you could do the same for mp3. :-)

Comment by CaptainN — July 30, 2009

@CaptainN – And really, couldn’t exactly the same shim be created with a chromeless flash video player that replaces video elements in browsers that don’t support the video element natively?

So, it would be possible to use the video/audio formats that the vendors are planning to support, and the elements that html 5 is looking to implement, in today’s browsers; without too much fuss?

Comment by sixtyseconds — July 30, 2009

…if only I knew a little actionscript…

Comment by sixtyseconds — July 30, 2009

The functionality of jPlayer seems OK, but I hate the philosophy behind it. I want to write semantic HTML5 and nothing else, and have a script provide a transparent fallback for old browsers. A good script library should insert fallbacks into all audio elements it encounters and implement the HTML5 scripting interface on top of those fallbacks, not an extra idiosyncratic layer of Javascript functions. It should be a shim for the standard (HTML/DOM) syntax, not introduce just another new syntax that on top is plain ugly:
$("#jpId").jPlayerId( "play", "thePlayButton" );

Comment by randomrandom — August 1, 2009

interesting trivia: Safari will play ogg file if you have the QuickTime ogg component( ) installed.
Though it will still report “no” to canPlayType(“audio/ogg”)
I’m not sure if there’s a wy to test installed Quicktime plugins.

Comment by matasp — August 4, 2009

Oh my god…

("no" != myAudio.canPlayType("audio/ogg")) && ("" != myAudio.canPlayType("audio/ogg"))

The canPlayType() method DOES NOT return a boolean?! WTF?! Who designed this API?! (I’m looking at you, WHATWG)

Comment by whyisjasontaken — August 7, 2009

Leave a comment

You must be logged in to post a comment.