Native Audio in the browser

by .

This article was last updated on 28 May 2014 to reflect changes in the spec.

Until recently, the ability to play any type of audio within a browser involved using Adobe Flash or other browser plugins. Although Adobe's Flash player is unquestionably the most ubiquitous of these, most developers and designers would agree that it's better not to rely on a plugin at all.

Enter HTML5 <audio>

One of the most exciting and long-awaited features in HTML5 the <audio> element, enabling native audio playback within the browser. We can take advantage of this now as all of the major browsers support it — currently Firefox, Chrome, Safari and Opera, and Internet Explorer 9+. For browsers that don't support audio natively, we can easily fallback to Flash.

According to spec

Currently, the HTML5 spec defines five attributes for the <audio> element:

  1. src — a valid <abbr>URL</abbr> specifying the content source
  2. autoplay — a boolean specifying whether the file should play as soon as it can
  3. loop — a boolean specifying whether the file should be repeatedly played.
  4. controls — a boolean specifying whether the browser should display its default media controls
  5. preload — none / metadata / auto — where 'metadata' means preload just the metadata and 'auto' leaves the browser to decide whether to preload the whole file.

Incidentally these are the same attributes defined for the <video> element.

Examples

Let's take a couple of these attributes and create a simple example that will play an audio file:

<audio src="elvis.ogg" controls preload="auto"></audio>

(This example will work for the latest versions of Firefox, Chrome and Opera. You'll need to replace the Ogg file with an MP3 to get it working in Safari and Internet Explorer 9+.)

For a list of which codecs are supported on which browser (which may differ depending on device) see our article HTML5 Audio — The State of Play.

To create our own controls, we can use the API methods defined by the spec:

  • play() — plays the audio
  • pause() — pauses the audio
  • canPlayType() — interrogates the browser to establish whether the given mime type can be played
  • buffered() — attribute that specifies the start and end time of the buffered part of the file

Use the Source

The best way to coerce browsers into playing audio (or video, for that matter) is to use the <source> element. The browser will try to load the first audio source, and if it fails or isn't supported, it will move on to the next audio source. In addition, we can embed a Flash player if all else fails:

<audio controls preload="auto"> 
  <source src="elvis.mp3" />
  <source src="elvis.ogg" />
  <!-- now include flash fall back -->
</audio>

One caveat, though: you may need to be careful about the order of the <source> elements. At the time of going to press issues have been reported with older versions of Firefox and Mobile Safari.

Cross-Browser Implementation

When we created jPlayer, an audio player plugin for jQuery, we were attempting to address some of the limitations of the current crop of Flash-based audio players. Many relied on Flash to implement the player's graphical interface, effectively isolating the player from the rest of the web design process.

The original jPlayer relied on Flash to play the actual audio while allowing the look and feel to be styled via HTML and CSS. With growing support for HTML5 in modern browsers, we were inspired to break our Flash dependency and use native audio when it was supported.

The most significant issue is the cross-browser implementation, where lack of a common supported audio format among browsers causes complications. If developers want to take full advantage of all browsers that support HTML5 audio, they'll need to create both MP3 and Ogg versions of the audio file they want to stream!

JavaScript solutions

If we intend to take advantage of each browser's audio capabilities, we need to create different solutions for different browsers. We could use browser sniffing, but considering the rapidly changing landscape, it's better to check what capabilities a particular browser supports and adapt accordingly.

To demonstrate this "feature sniffing", we've created a rough and ready HTML5 audio checker.

Using JavaScript, you can check for audio tag support:

// returns a boolean
var audioTagSupport = !!(document.createElement('audio').canPlayType);

or check file type compatibility:

// Need to check the canPlayType first or an exception
    // will be thrown for those browsers that don't support it      

    var myAudio = document.createElement('audio'); 
    
    if (myAudio.canPlayType) {
      
       // Currently canPlayType(type) returns: "", "maybe" or "probably" 

       var canPlayMp3 = !!myAudio.canPlayType && "" != myAudio.canPlayType('audio/mpeg');
       var canPlayOgg = !!myAudio.canPlayType && "" != myAudio.canPlayType('audio/ogg; codecs="vorbis"');
    }

Note that to change the src attribute of an audio object or element, you'll need to recreate the object or element with the new value for its src attribute or alternatively change the src URL and then issue a myAudio.load() command.

So, to create a solution that takes full advantage of HTML5 audio, you'll typically need to:

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

The Road Ahead

Although HTML5 audio is a relatively immature part of the standard, if recent trends continue and users upgrade to the latest versions of Safari, Firefox, Chrome and Opera, browser support is likely above 30% today. This is a significant chunk of the browser market that will no longer need to rely on Adobe's Flash, Microsoft's Silverlight, or any other browser plugin for audio support. Add to this the fact that Internet Explorer 9 supports HTML5 audio and we could easily see the majority of installed browsers supporting it in the very near future.

And when you consider that mobile and other lower-spec devices such as tablets are choosing to support HTML5 audio, you begin to paint a picture of how important native audio support is becoming.

Further reading:

164 Responses on the article “Native Audio in the browser”

  • Ough! Why Firefox and Opera browsers don’t support .mp3?! That’s a new pitty!

  • Garrett Albright says:

    How about MP4/AAC? I’ll take a guess that only Safari supports it currently…

    But all said, plugin-less audio sounds altogether doable, especially if we can use something like jPlayer to abstract the differences away. Is there anything similar to jPlayer for video?

  • Mark Boas says:

    @Andrey agreed – it’s a real pain! To be fair Safari could also support Ogg Vorbis that would give us a bit of choice. From what I can gather it all boils down to licensing and patents sadly.

    @Garrett – now if we could abstract all HTML 5 differences away we’d be on to a winner :) Regarding video you may want to check out http://camendesign.com/code/video_for_everybody

  • John Dowdell says:

    “most developers and designers would agree it is better not to rely on a plugin at all.”

    Got a citation for that?

    Opera’s MAMA study showed that about a third of sites used Flash, but only one site in 25 would validate:
    http://dev.opera.com/articles/view/mama-key-findings/

    jd/adobe

  • Mark Boas says:

    @John – You’re absolutely right to pick me up on that – I should have written :
    “I think most developers and designers would agree it is better not to rely on a plugin at all.”
    Maybe we should do a poll :)

    Incidentally I wonder how many sites are using Flash just to play audio.

  • […] 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 […]

  • Tim Wright says:

    That’s really strange that the filetype would matter so much

  • F. Piat says:

    @Andrey & @Mark – Opera or FireFox don’t make it bad : MP3 is a patented format and they can’t use it (for example see Licensing and patent issues in http://en.wikipedia.org/wiki/Mp3)

  • Mark Boas says:

    @Tim It seems to matter very much indeed to the people who make browsers and it’s a shame that things have to turn political at the detriment of the developer community at large.

    Let’s say that for the average developer it’s pretty much possible to start using the new tag right now falling back on Flash for Internet Explorer, Opera and older browser support. Then the choice is whether to support Firefox, Safari (or both) depending on which audio formats you provide. Chrome for now is the only given.

  • Mark Boas says:

    @F. Piat – Sure. I can appreciate Opera and Firefox’s point of view.

  • Adam says:

    is the autoplay attribute strongly and I mean STRONGLY advised against?

  • Adam says:

    or should that be STRONGLY ?

  • Garrett Albright says:

    Adam, I strongly against using it if you want me to stick around on your site. Few things will annoy me more about your web site than if it starts making noises without my permission. And I know I’m not alone.

  • Adam says:

    I know, I meant to ask if it was strongly advised against in the spec

  • Mark Boas says:

    @Adam on the subject of Autoplay the spec http://dev.w3.org/html5/spec/Overview.html does not appear to advise against using it. After all if a feature is in the spec it is expected to be used in some form.

    However it does mention:
    Note : Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired, e.g. when using a screen reader. Authors are also encouraged to consider not using the automatic playback behavior at all, and instead to let the user agent wait for the user to start playback explicitly.

    As to whether you use the autoplay attribute, I think that is down to the individual.

  • […] the HTML 5 Doctors. They were interested in publishing a piece on the state of HTML 5 Audio and we were happy to oblige. The post was also picked up by […]

  • […] html5Doctor hacen una tabla, muy útil, de los navegadores y los estándares soportados por cada uno de […]

  • […] 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 […]

  • […] Native Audio in the browser | HTML5 Doctor […]

  • […] 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 […]

  • […] Native Audio in the browser | HTML5 Doctor […]

  • […] Read more: Native Audio in the browser | HTML5 Doctor […]

  • Ben says:

    Why are people confusing native playing ability with built-in codecs?!? Flash came about not because the browsers don’t have built in video players (well, they don’t), but to solve the CODEC problem. Now in HTML 5 they’re trying to conquer both at once and the problems are evident even with audio, let alone video. Likely some browsers don’t support MP3 cause it still is licensed to fraunhaffer (sp?) and requires a licensing fee to put it in your application. Instead, HTML5 should just say the browser needs to support video playback without using an embed, BUT you still have to have the CODEC installed on your O/S. This doesn’t mean they need to bundle the CODEC’s with the browser! If they try to dictate a codec that every HTML5 browser has to support, it will likely be obsolete before any actual implementation (this was the whole reason for codec’s in the first place – so media player software didn’t become useless when new formats came out).

  • Ben says:

    sorry, I meant the ubiquitous use of flash for video playback came about to solve the CODEC problem, not that flash itself was created for video playback (it in fact, was not originally meant for that sole purpose).

  • Ben Scherrey says:

    Is HTML5 silent on streaming audio? Most interesting audio services are those that broadcast a continuous stream rather than selecting individual fixed files. I’d be very interested in hearing about any planned support for this.

  • stephband says:

    In all the discussion of the merits of native audio support against Quicktime or Flash plugin alternatives I’ve yet to see any sensible discussion of the merits of the codecs.

    For me, the main reason not to use Flash is that it is (still) only capable of playing mp3 files. Some people are bemoaning the lack of native mp3 support in the audio tag, but I can only see this as an advance, because the sound quality of mp3 playback does not compare well with playback of more modern codecs, .m4a (aac) or .oga (vorbis), in files of the same size. For reasons of sound quality alone I have always turned to QuickTime to deliver audio on the web.

    mp3 is getting on for 20 years old, and it is high time it is retired. Roll on audio tags with native support for newer, better codecs.

  • stephband says:

    And, to follow on from that, I’d be really happy if the table above noted that Safari 4 is capable of taking an .m4a file as a source!

  • stephband says:

    … although I haven’t figured out how to detect the m4a mime type. I’ve tried:

    audio/m4a
    audio/mp4a
    audio/mp4a-latm
    audio/quicktime

    Any ideas?

  • Joeri Kassenaar says:

    Uggh…

    Cool ! A html tag that needs javascript by default to get to work… Hooray!
    No thanks, I’ll stick to swfObjects if I need to add javascript, it allows me to create nice pause and rewind features.

    O and while I’m at it ( hacking I mean ):
    still no ? When is that going to happen? HTML12?
    With wmv support in IE, mp4 in Safari and m2v with no audio in FF?…

    Useless features hooray.

  • Joeri Kassenaar says:

    ( cool site btw, great work here )
    Sorry that I used < tags for my little rant… made it unreadable. Ofcourse I read your remark only after my post.

  • To rescue the web designers from this aching job of testing browser compatibility in different browsers there are few websites which offer this service. On these websites you can check the compatibility of your website in all desired browsers. You can find these websites at http://www.bestpsdtohtml.com/7-awesome-resources-to-test-cross-browser-compatibility-of-your-website/

  • Victor Rodrigues says:

    Do you know if it accepts a live stream instead of a file?

  • Mark Boas says:

    @Victor – the short answer is no. Browsers implementing native audio currently only support file formats such as OGG, MP3, M4A and WAV. I’m no expert on streaming media but I believe the process requires purpose-built formats. I do wonder whether you could stream a file-format such as OGG with the correct server-side technology but I suspect that there are very real problems in achieving this. Would be happy to be proved wrong though :)

    @stephband – Did you ever find a satisfactory mime format for M4A? I had a look but could only find the same references as you.

  • Hamranhansenhansen says:

    > It’s worth noting that the spec is not yet finalised and unfortunately there has yet to be
    > a consensus on which codecs to support, each browser supporting a different
    > combination of codecs

    Audio standardization is outside the scope of the HTML5 specification. It’s not up to browser makers or Web developers or anyone at W3C to tell the world how to store and play digital audio. The responsibility for browser makers is to bring their products into compliance with existing audio standardization, which means playback support for ISO MPEG-4 AAC, aka MP4. The responsibility for Web developers is to publish audio and video in the existing standards, which means MP4. You are responsible for this in the same way that Kodak and Apple and even Zune all support MPEG-4.

    The thing that’s really important here is to compare the success of Web standardization, which has never, ever succeeded:

    – during the HTML4 years we made proprietary Internet Explorer 6 apps with Flash audio video (FAIL)
    – during the HTML3 years we made proprietary Netscape apps with proprietary QuickTime audio video (FAIL)

    … with the success of audio video standardization, which has never failed:

    [1980]
    – CD was universal
    [1990]
    – MPEG (CD-ROM) was universal
    – MPEG-2 (DVD) was universal
    – MPEG-2 audio layer 3 (MP3) was universal
    [2000]
    – MPEG-4 (iTunes, YouTube, Flash, QuickTime, iPod, iPhone, Palm, Nokia, Blackberry, Zune, Blu-Ray, NVIDIA, Android, Kodak, Flip, Avid, Final Cut, iMovie, Logic, Pro Tools, Performer, many more) was universal

    Me, I’m an audio producer and Web developer, and a huge supporter of HTML5, so I’m embarrassed to see Web developers attempting to open up an audio video standardization debate at this time, as if they are the Kings of the World not just the World Wide Web. Especially when the Ogg vs MPEG-4 debate literally happened 10 years ago and Ogg lost by far, solely on technical merits. Unless there is also a Time Machine in the HTML5 spec, there is no going back to 1999 and redoing the last 10 years of the world’s audio video in Ogg. Had the W3C been thinking about audio video instead of XML at the turn of the century, they might have had some input into MPEG-4. Apple delayed MPEG-4 for 6 months because of issues they had with the licensing (there was a content tax put in, Apple would not support MPEG-4 until the content tax was taken out) but the W3C said nothing. They left audio video to Flash and QuickTime as usual. Well, Flash and QuickTime have both since standardized on MPEG-4. To say now that the Web standard is not MPEG-4 is not practical. The computer time to transcode all the media to Ogg does not exist, the Ogg audio video toolchain does not exist, and we are already into user generated content and camcorders that shoot MPEG-4 and upload via Wi-Fi. How can we say to them “I know you’re making ISO standard media, but we’d like you to find a Linux computer and transcode to Ogg before you upload please so that we can be in compliance with HTML5.” It is not practical.

    Also, notice that if the HTML5 spec were to say “Ogg is standard, MPEG-4 is not” that would mean that YouTube could NEVER comply with the HTML5 spec. YouTube is all MPEG-4 in the back end, no matter what you upload, they create an MPEG-4 to use and store your original as a backup. That is why it runs on mobiles, where the ONLY video playback is MPEG-4. Google has already done a study of “YouTube Ogg” and found that there is currently not enough Internet bandwidth to support it. In other words, if YouTube were switched to Ogg overnight tonight by magic, then tomorrow it would need more bandwidth than exists in the world just to serve its current users, even if everyone else stopped using the Internet for the day somehow. YouTube is also growing, so the day after they would need even more.

    If YouTube is not Web video then I don’t know what is. And there you have Google being a full supporter of HTML5, they are moving YouTube to it quite steadily, and we’re going to say “sorry, you’re out of spec because you use the same audio video format as the rest of the world”?

    It’s also important to understand that MPEG-4 is the ISO standardization of the Apple QuickTime file format that is used almost universally by audio video authoring tools. Therefore, MPEG-4 compatibility in the authoring toolchain came almost for free. What was there was standardized, rather than creating a whole new thing and standardizing that. Instead of replacing QuickTime with something else (which still doesn’t exist), QuickTime was standardized so that now there are “QuickTime Players” from hundreds of manufacturers now. In that sense, MPEG-4 is as practical for audio video people as HTML5 is for Web developers, standardizing what is already happening. So to create a schism between HTML5 and MPEG-4 is terrible sabotage. It would be like HTML5 not supporting UTF-8 text, or JPEG images. It’s so impractical as to make a mockery of the practicality of the whole HTML5 spec. MPEG-4 is how the world’s audio video is stored. Browsers need to be able to (continue to) display it.

    If you’re a Web developer or browser maker and you’re not working with ISO MPEG-4 then your audio video is non-standard. The fact that you’re proud of your standardized HTML5 markup in that case is a joke.

    > Did you ever find a satisfactory mime format for M4A?

    – audio-only MPEG-4 files are audio/mp4
    – audio video MPEG-4 files are video/mp4
    – MPEG-4 files that contain scripts or Java or other application code are application/mp4

    Here is a link to the RFC. This stuff is ancient, even if you’re new to it.

  • John-Paul Harold says:

    re: m4a mimetypes

    I asked about this in a related question on the webkit mailing list. I ended up not using the m4a mimetype as Safari ignores it, and I set my source tags so that Chrome uses the vorbis.

    hope it helps

    jp

  • TomkOx says:

    @stephband: MP4:AAC mime type is: audio/x-m4a.
    HTML5 audio tag and MP4:AAC usage example.

  • […] A few things I want to cover are: the new tags in HTML5 that will help simple interactivity (<audio> and <video>, probably <canvas> too), examples of enhancing interactivity in HTML5 […]

  • Weston Ruter says:

    canPlayMp3 = (“no” != myAudio.canPlayType(“audio/mpeg”)) && (“” != myAudio.canPlayType(“audio/mpeg”));

    The current version of Chrome can play MP3s via HTML5 audio. However, if you try doing audio.canPlayType("audio/mpeg") it erroneously returns "", meaning it doesn’t support playing MP3s. I developed a workaround which loads up a tiny MP3 via a data: URI and detects for support via error or canplaythrough Media events. See http://gist.github.com/253174

  • Wiechu says:

    It is unuseful (at least: an extra effect, not so needed). Why? It is for audio-blogs, some “short previews” or lo-fi music services for mass-customers. If you have to publish your audio/video stuff use a “RAW” data file (like AIFF, WAV, CAF, etc.) zipped into downloadable “ZIP”. Who is using web browser as Music or Movie Player?

  • […] all the javascript options failed, I tried mixing up the audio and flash code, as suggested by HTML5 Doctor.  Eventually I got them to work reliably in FF 3.5+ (Mac & PC), Safari 4, Chrome, […]

  • Pion says:

    Not everyone has the liberty to choose what audio format to offer. Where I work we have a huge archive of mp3s which we want to offer online to our patrons. They belong to filesets which have mp3 as a required format and converting it all would take both time and space.

    Besides the licensing issures, there’s no reason not to support mp3.

  • Jonathan says:

    My requirement needs audio files to be chained together, like a sort of playlist.
    Soundfile1,Soundfile2,soundfile3 – works fine in flashplayers, but I can’t work out how to do it in native audio

  • Mark Boas says:

    Jonathan,

    Me and my colleagues have been working on a project called jPlayer – a jQuery plugin which leverages HTML5 audio where available. You might find some clues on how to achieve a playlist over at http://happyworm.com/jquery/jplayer

    A new version was released yesterday so your timing is impeccable. :)

    It’s also on github here : http://github.com/happyworm/jPlayer

    Hopefully this will be of some use to you.

  • Jonathan says:

    Mark, you are right – brilliant timing, and a brilliant player, too! Looks (and sounds!) REALLY good.

    Just tinkering now, I’ll let you know when the site’s ready then I’ll proudly show it off!

  • scott says:

    Hi,

    What about generation in the browser? specifically, generating sinewaves from the browser without using flash etc. I need this to work on smartphones…

    I recently came across something that does this, but now can’t find it :(

    thanks,
    s.

  • […] consente la riproduzione audio nativa nel […]