Native Audio in the browser

by .

This article was last updated on 14th October 2010 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 nearly all of the major browsers support it — currently Firefox, Chrome, Safari and Opera, but they are soon to be joined by Internet Explorer 9 which is currently in beta. 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.

Note preload supercedes autobuffer in the latest HTML5 spec. Previously autobuffer took a boolean value specifying whether the file is to be buffered in advance. Currently, browsers are making the transition from autobuffer to preload so we suggest that you use both attributes for the time being.

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" autobuffer></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.)

Of course, the spec is not finalised, and there isn't yet a consensus on which codecs to support. This table details the codecs supported by today's browsers:

Codec support in modern desktop browsers
Browser Ogg Vorbis MP3 WAV
FireFox 3.6+
Safari 5+
Chrome 6
Opera 10.5+
Internet Explorer 9 (beta)

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" autobuffer> 
  <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 Mobile Safari and older versions of Firefox.

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 (and in Opera's case, WAV) versions of the audio file they want to stream!

Since the HTML5 standard is still a work in progress, several aspects of the <audio> element vary from browser to browser. For example, there seems to be no way to determine the load progress of an audio file in all browsers as this relies on buffered DOM attribute being implemented. Chrome has implemented buffered, in Safari it's there but seems to behave slightly differently, current versions of Opera and Firefox however don't support it (although Firefox 4 beta does).

Although these inconsistencies aren't showstoppers, in order to compete effectively with plugin-based solutions, we believe any HTML5 audio implementation should be consistent across all browsers and match current implementations feature for feature.

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:

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

Andrey Superstar says

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.

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.

HTML 5 and Audio | The Worm Hole says

[...] 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 [...]

[...] 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 [...]

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.

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

My University Dissertation | NDE Designs says

[...] 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?

Flash-less audio is in the future « b&k m online says

[...] 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.

Paul says

I ran into a problem getting the HTML5 audio tag to work with Firefox (just the HTML5 tag, no javascript). The player/controls would show up, but it would not play my ogg vorbis audio file, and a big “X” was shown above the player instead of the “loading…” animation.

After some trial and error, I determined that it was not a problem the HTML or with my audio file. (It worked when the source was set to a file hosted on a different domain. And it would not work with that same file hosted on my domain.) So it turned out to be a problem with my server setup. Apparently my server was not serving the ogg file with the correct MIME type. Here was the answer on the Mozilla site: Configuring servers for Ogg media

“Most servers don’t by default serve Ogg media with the correct MIME types, so you’ll likely need to add the appropriate configuration for this.” I just needed to add the following to my .htaccess file:

AddType audio/ogg .oga
AddType video/ogg .ogv .ogg

That did the trick, and now it works like a charm in Firefox!

Pubmedia Commons says

[...] (John Denver’s X-rated “Annie’s Song” from WFMU. More audio-tag info at HTML 5 Doctor.) [...]

Så utvecklar du för iPad | lillbra.se says

[...] dig av Flash så kommer det inte att visas. Använd istället html5-element som <video> eller <audio> för bild och ljuduppspelning, eller javascript och css-animationer för animeringar och [...]

De-Flashing The AudioShocker at AudioShocker says

[...] new HTML5  audio tags, it just raises the latent format war between webkit browsers and Firefox. This article at html5doctor sums it up: The most significant issue is the cross-browser implementation, where lack of a common [...]

[...] is audio. What kind of audio support is there in HTML 5 and the other related technologies? Well, you’ve got playback but that’s about it. No synchronization, no volume control, no panning and definitely none of [...]

Jeff King says

This was very helpful. Thank you.

There are a few typos in your support checks:

basic support should be tested with one less “!”: !!(!audioObjSupport ? myAudioObj.play : false);

canPlayOgg, canPlayMp3 and the surrounding if use the uninitialized variable myAudio. I think you mean myAudioObj

You may want the if condition surrounding canPlayOgg and canPlayMp3 test for audioObjSupport instead of myAudio.canPlayType

Jeff King says

To correct my first point above, the basic support test should be: !!(audioObjSupport ? myAudioObj.play : false);

Mark P says

@Jeff King: That code was to test for basic audio support in Opera 10, where only parts of the Audio() object were implemented.

So in other words, if the canPlayType() method exists, we do not need to check for basic audio support. ie., Because it had full support, or at least a higher level of support conforming with the HTML5 draft spec.

Basic Audio support was a purely there to demonstrate that Opera 10 did make an attempt at audio support. With the release of Opera 10.5, the browser supports OGG audio well.

To sum up…
Our is correct, but in practice I recommend only acting on the existence of the HTMLAudioElement.canPlayType() method if you want to write JavaScript that works with HTML5.

Barry Walker says

As a musician I rely on mp3 streaming, i feel that it is a shame that Mozilla cant come to some kinda of understanding on this.

MP3 is the most widely used audio format, by not including it i think they may be shooting themselves in the foot.

Mark Boas says

@Barry. There are all sorts of issues with streaming in all the different browsers just now. The exception perhaps being the latest versions of Safari. Note that some are reporting issues with Safari on iPad and iPhone though.

You can find a good breakdown of the issues here : http://www.trygve-lie.com/blog/entry/html_5_audio_element_and

Interesting that of those browsers that support HTML5 Audio, more support OGG than MP3.

Henry Gilbert says

I think ALL browsers should support WAV as a default. Apparently Chrome doesn’t?

Why? Because it is the raw format. And music studio producers would probably want to show off that instead.

Now the rest of da people could then choose their compressed formats, ogg, mp3 whatever.

I designed a site for a music producer in London and he keeps nagging me to somehow have people download the raw wave format instead. He is probably unaware how much it will cost him in bandwidth tho!!

Jonathan says

@Henry: Then the music producer is an idiot. Very few internet connections could sustain the enormous bandwidth needed to stream the incredibly wasteful and old wav format, and end users on capped broadband connections would hate him for it too when their bill came through.
You need to explain to him just 5 of the 1001 reasons NOT to use wavs for streaming, and if he still wants it, sit him down in front of Living TV and get the nurse to bring the medicine!

Corey Mwamba says

Because this article was written a year ago, I think it’s unfair to dredge it up: but I think it needs bringing up-to-date.

To be honest, I reckon that the browser should leave the support for formats to a dedicated audio/video framework. That way the web master/web user can decide what he or she wants to support [this of course might scupper me since I only use Ogg Vorbis on my site, but there you go!].
The current Opera snapshots for Linux support any format you throw at it because they use GStreamer, and I can tell you from experience that it works very well indeed. I think the Windows builds are limited to Ogg Vorbis.

Could Mozilla use VLC without affecting its licence? I don’t know what Apple would use, because they seem to have to intention of supporting Ogg Vorbis. Which is unfortunate.

@Jonathan, @Henry: WAV isn’t wasteful – otherwise we’d have stopped using it – but you’re right about the bandwidth. The best compromise is FLAC, I guess: but does web streaming really need to be such high quality when people usually listen to things using MOBILE PHONES?? Heh.

witek says

What, I’m sure opera supports html tag. Not only JS API for it.

Mike says

@Jonathan
The Producer is no idiot just because he wants the best Audioquality to show his work or
to deliver his stems for mixing/mastering studios or for sessions etc.

no producer or audio audio engineer uses a compressed format, even on the net.
I.e. we swap in online Sessions Data with about 800 MB or more for one song.
Some of us use digi-delivery servers for exchanging complete album productions.

Never mind about the costs. :)

Jonathan says

@Mike – my comment was aimed at Henry, who was suggesting streaming wav, not talking about data exchange between studios.

Trevor Jordet says

I LOVE html5 audio tag and i am a die hard flash developer.

BUT I am pretty upset at apple for hobbling the functionality of the audio tag on iphone/ipod/ipad.

they disable autoplay, which I suppose you could make a case for, but they also disable the javascript play function.

That makes it impossible for me to create a continuous play playlist even after play is initiated by a user click.

NOT COOL!!! I love apple, but they are really getting on my nerves trying to be big brother and not giving me as a developer to create applications without obeying their oppressive rules that prevent anyone from building anything that competes with their products.

Trevor Jordet says

not giving me the freedom as a developer

Trevor Jordet says

see above url for a demo of what I am complaining about.

in a browser everything works fine, but on ipad/ipod/iphone, continual play is disabled. That is a HUGE problem!!!

Joeri says

The solition to that is simple.
Check for browser and if its an iflop safari then redirect to the istore where the user can buy the app for 5€ . Make sure the user understands this is the route they have choosen for buying Apple gear.

Trevor Jordet says

heres the problem –

I don’t want to pay a yearly fee for the privilege of developing censored apps that only get approved if they are in apple’s best interests. and on top of that they take a cut of every sale. I don’t intend to sell my app.

I also don’t trust them to not deny my app and then steal my idea.

I could develop for jailbroken phones, but I hate working with xcode. If html5 is the “new flash” then it should be free to work un-hindered by the browser.

Trevor Jordet says

I’ll do my best to cater to apple mobile devices, but if users want the real experience without any BS, they can catch my apps on android.

[...] mean audio is supported, right? maybe android is just for silent movie lovers… both html5doctor and this o’reilly article claim audio is supported, but perhaps they just made the same [...]

HTML5 Audio Tag Mess : Hugh McGuire says

[...] tag, but they don’t all support the same codecs – or kinds of audio files. Here, from HTM5 Doctor, is a list of current [...]

[...] the new HTML5 audio element have been explained in a number of places but I found the guide from HTML5 Doctor particularly useful. The WebReference client-side storage page explained all I needed to know about [...]

mark says

gosh, thats really annoying
i want to include a “new message” alert if the user got a new unread one

but this seems to work only in a few browsers… and for chrome i dont get it to work at all…
is there no crossbrowser-solution available? either js or html?

Barry Walker says

Is it possible to style the player using CSS? Just wondering as i think the player looks really bland and would like to change the colours to fit my website.

Linda says

Barry, I was only able to style the default control’s width. Nothing else. The other option is creating a custom control.

Linda says

I am trying to create some pages for the iPhone and iPad. A page may have multiple audio file to play. My problem is that on the iPhone or iPad, if the user starts one audio file and then pauses it then tries to play the second file, it will not play. The only way that the second one will play is if the first one is allowed to play completely through.

So, does anyone have any suggestions for how to implement a “stop” button in a custom control. Or another option would be when the user tries to play the second file, is there a way to cause the first one that was played to actually end so that the second one can play?

What if there are 10 short audio files? We would need to make sure that they are all ended before one could be started.

Thanks

One Creative Thing: Checking in early… says

[...] Did discover a slight issue with <audio> which I hadn’t found yesterday though. The gurus of HTML 5 online have been saying things like this: you need to be careful about the order of the <source> elements. Because of a bug in Firefox, if you list the MP3 first (which Firefox doesn’t support), it will silently fail and refuse to render that particular <audio> element. The trick is to list the Ogg Vorbis file first and the other formats after. Webkit (Safari and Chrome) handle unsupported formats just fine.HTML5 Doctor: http://html5doctor.com/native-audio-in-the-browser/ [...]

Project: Apollo Pre-Alpha Update | MethodKnowledgy says

[...] the sample audio, the first track is in Ogg Vorbis format and relies on HTML5 <audio> tags to render, which will likely only work if you are in Firefox 3.5+, or Chrome 6+. It works in [...]

Prior Semblance says

You should add aac to that table, IE9 supports it and I bet at least one other browser does.

darkpenguin says


<audio controls preload="auto" autobuffer src="elvis" />

Then return whichever format you want to use for that browser from the server, switching using the user agent, and defaulting to wav.

simples

Justin Lindh says

I’m wanting to use ogg with wav fallback support, but am unable to modify the server’s configuration to serve ogg with the correct mimetype (htaccess is also blocked). Can anybody think of a way to overcome this limitation using javascript? I’d be OK with using mp3 instead of ogg, but am concerned with licensing issues since the file would be played back on a commercial web application.

Paul says

Chrome 8 (or 9) apparently will be supporting pcm wav. I say 9 as I tried one of the dev version 8′s and it had wav support – unfortunately the next dev released it didn’t work :(

Hope they add (fix) it again..

Justin Lindh says

Note that the audio support table in this article is out of date. IE9 Beta only supports MP3; WAV support for HTML5 in IE9 was dropped (though it apparently supports WAV playback through its bgsound tag).

Walt Ribeiro says

This code is perfect and exactly what I was looking for with the feature posts on my website homepage. I’m trying to proof myself from people still using IE7 and IE8. Any help on how to write the “flash fallback” in the source example?

Carsten says

We found out that the mobile versions of Safari do not allow to play more than one sounds from audio elements. due to some limitation in CoreAudio.
As we cannot use flash on mobile devices (with iPhone/iPad as the main target) we have to rely on the tag in our html/javascript code.

I tried to use caf files as well but it did not play two sounds at the same time:

Using a short javascript snippet of playing one sound 600ms after the first one has started, shows in incapability of the browser:

document.getElementById(“ambient”).play();
setTimeout(function(){
document.getElementById(“loop”).play();
},600);

Mobile Safari plays the first audio element, it is told to play or encounters with an autoplay attribute and just does not care about the following elements. Also loop is not working here. You need to place the small hack onended=”this.play();”.

Mark Boas says

@Carsten @Linda it appears that mobile Safari has issues with multiple instances of the audio element. Certainly my experiments show that it cannot play more than one audio file at the same time.

@paul You can find a Flash fallback here Though not sure how much use it will be to you as it’s quite specific.

@Justin Lindh You are right that you can use .htaccess to force the correct ogg mime type but I don’t think this can be done using JavaScript alone.

@Justin Lindh @Prior Semblance Yes the browser support table needs updating continually, these are rapidly shifting sands. Thanks for the heads up.

@Barry Walker jPlayer facilitates custom styling (amongst other things) :)

Linda says

I had reported the bug of Mobile Safari not being able to handle multiple audio files. I have not tested it yet but had an email from Apple that this has been corrected in the current (4.2) version of iOS.

Foldi says

I can play both wav and mp3 files via the Audio tag on my iPhone 4 in Safari. However, the browser’s volume is not controlled by the phone’s volume or mute buttons. In other words, I can mute the phone or lower the volume all the way down and the Audio continues to play. My iPad behaves like you would expect… muting the iPad mutes Safari.

Has anyone else experienced this on their iPhone? Thx.

J says

To whoever said the mp3 standard is 20 years old and shouldn’t be used: who makes these decisions? Certainly not the people who have to spend the time and money to convert thousands or tens of thousands of songs in their online music libraries to another format. There’s a lot of arrogance in how thee unofficial standards like HTML5 audio (which is not official yet) are handled.

Joeri says

Sure.
But the reason mp3 is a bad format is because its not a free format.
There is some german company that wants 2 cents for every mp3 you create.
Sure, this patent will be set free some day, but for now lets take a format that can be used without paying some company a fee.

CHoc DOnut says

your first simple audio code example doesnt work in Firefox as of Super Bowl Sunday 2011. THe controls dont show up and the audio doesnt play.

Carsten says

Mark, did you try the audio playback with the latest iOS version already? I will test it in a short while but wanted to hear if you’ve already got any results.
@J well right we don’t even have the freedom of choosing the format freely as every browser uses its own format. I would love to only have OGG maybe or any other free format – the important fact is not to have to produce 3 different formats of the same file.

markv says

Hi.
I would like to create a website with grid of images,
As you rollover each image, a short audio clip plays.
So if you roll over 10 images is a row, you could potentially have more that 10 audio clips playing at once, until each one finishes.
What technology should I investigate for this?
Many thanks,
Mark

markv says

Could HTML5 help me with multiple parallel roll-over audio?

[...] getting that same thrill you first did when you first heard about html5 its geolocation, canvas, audio and video are still as impressive as they ever were but I started to notice the little things as [...]

Barry Walker says

To the folks saying use jPlayer for styling, i need a player that is slimlined. jPlayer is too big for my website layout. I would really like one that looks like the flash audio player i already use.

HearVox says

[...] If no to either, write only the Flash stuff, not the HTML5. (More info and scripts at HTML 5 Doctor.) [...]

Tyson says

Is there a good way to make a song play and not have to reload it as pages change?
Any best of examples anyone would care to share? current project… djmscott.com
I’ve got the same song reloading on every page and coincidentally had trouble with the location of the player.
Love some pointers if anyone cares to offer them.
Thanks!
-tyson

Carsten says

We also needed such a solution and had to use iframes. The parent window played the audio and the inner window initiated the playback by talking to the parent.
Right now I don’t know another solution jere but it works like a charme right now :)

Mark Boas says

@Tyson @Carsten

There are 3 basic approaches that we’ve used to ensure playing of audio is continuous throughout a website (ie audio doesn’t stop or pause when navigating to another page) :

1. The Single Page Web App – blogged about here : http://happyworm.com/blog/2010/08/23/the-future-of-web-apps-single-page-applications/ It takes a bit of work but results can be good.

2. Audio player fixed but content held in an iFrame – the page doesn’t change but the content of the iFrame does. Simpler than 1 (but you have to be careful to make sure search engines pick up the link to pages with surrounding player – NB here be monsters).

3. Pop up Player – player pops up in another window – there can be some issues with player to page communication and modern browsers require that the URL be displayed in any browsers window so can result in a lot of surrounding window chrome.

Hope that helps.

James says

Has anyone else noticed that Safari won’t play html5 audio without Quicktime being installed? And doesn’t that defeat the whole point of supporting html5 audio?

Mike says

Why create the variable “audioTagSupport” if your not going to use it?

Hamranhansenhansen says

The best way to deal with the codec issues are to use ISO/IEC 14496-14:2003 audio, which is standardized consumer audio. It is to audio as HTML5 is to markup. If you’re using HTML5 and not using MPEG-4, then what are you thinking? Just go ahead and use nonstandard markup if you are going to use nonstandard audio. If standards are important to you, then support standards.

ISO/IEC 14496-14:2003 is the successor to MP3. It is an MPEG-4 container with AAC-encoded audio in it, MIME type “audio/mp4″ and you can use a “.m4a” filename extension. Make sure your Web server knows what these files are, e.g. for Apache you would use this directive:

AddType audio/mp4 .m4a

To deal with browsers that do not support the audio tag, you nest a link (a tag) to the audio file inside your audio tag, so that browsers which do not support the audio tag will show the user a link to the audio, which they can play in an external helper app such as iTunes.

To deal with browsers that block the content from accessing the user’s built-in hardware MPEG-4 decoder, such as Firefox or Chrome, you simply use JavaScript to test for support for audio/mp4. If that codec is not supported, you remove the audio tag from the DOM, leaving only the a tag link to the audio, and again, the user clicks the link and plays the audio in a helper application.

Help with detecting audio tag support and codec support can be found here:

Dive Into HTML5
http://diveintohtml5.org/

If you don’t know how to modify the DOM with JavaScript (that is actually what JavaScript is FOR) then read “DOM Scripting” by Jeremy Keith.

Notes: WAV is not suitable because it is uncompressed, the bitrate is off the scale; Ogg is not suitable because there are no professional tools and no hardware support in the clients and no protection from patent liability (MP4 has all 3); MP3 is not suitable because it lacks quality compared to MP4 and you have to pay MP3 patent holders for every play over 100,000 plays, while with MP4 it is royalty-free for any use where the user does not pay for the audio (i.e. on a website, even with ads, you can serve a million MP4 plays and no royalties are applicable). Further, nonstandard audio is not suitable in standardized markup. Every single PC and mobile ships out-of-the-box with both W3C HTML5 support and ISO MPEG-4 support. There is absolutely no excuse for the Web publisher to send any other markup or audio video other than that.

cyberGotama says

How does HTML5 handle streaming audio?

How would one create a streaming server (C#, .net).

I have been searching around for references on this – no one seems to be discussing these topics.

charlie says

Hi.
There is a way to not show the audio controls for the iphone safari?
Thanks

Lee says

How about moving the track to one minute and four seconds?
IE Transport controls?

Lee says

Regarding FLAC as ‘such high quality’ — FLAC has variable encoding qualities, despite the words behind the acronym.

Alice Wonder says

Got a reference for flac having variable encoding qualities?

Every flac file I have ever encoded decodes to a matching md5 sum of the wav file I started from (lossless), and I do not recall there being any options to make the encoding lossy.

Alice Wonder says

I think I found the confusion on flac. It does have different compression levels. Higher compression = smaller file = longer encoding time. The quality though is the same. Decode and you get the original wav with matching checksum.

henry says

A question is why the src=”http://xxxx/test.mp3?p1=xxx&p2=xxx” won’t work on the IE9 but Chrome is ok.

if the url is http://xxxx/test.mp3 the IE9 will be ok.

Tom says

Is possible that Firefox 10.0 doesn’t support .ogg format? .wav is working ok, but .ogg seens doesn’t work, maybe audio file (700kb+) is too big?

Ray says

Hi. If I use the Google audio player via this code:

The displays on a webpage and plays whatever file it’s pointed to (the one here is just placeholder text).

But if I add the HTML5 player code to it like you have above:

and include the above code for the Google player in place of , I don’t get the flash player displaying in place of an HTML5 player.

Can you tell me where this is going wrong? I definitely want the HTML5 player to attempt to display first but in cases such as Firefox, I want the Google flash player to take it’s place, i.e. fall back.

Thanks.

Transom » HTML5 Audio Tag Test says

[...] The screenshots below — from the great HTML5 test resource — show the current state of browser support for the <audio> tag. [...]

Lalon says

That’s mean, we need both file (.ogg and .mp3) in server to support all the browser..?

Kiyo says

Tyakumerositai

Multiversum says

It’s 2012 now. As a musician and web developer (btw, making my own music website right now), I’m quite disappointed in a few things:
- There’s still no tag that would group audiofiles under one playlist with a single control bar. If the <audio> tag is supported, it looks very natural to have something like <audiogroup> tag. It must not be a job for Javascript; it should be just a new way of logical multimedia markup. I hate scripting in the places where it looks unnecessary; so I promise no JS (and no Flash, of course, and other fallbacks for IE morons) on my HTML5/CSS3 website. So… Will have to use the series of containers with audiotags until they create a tag to group the tracks.
- There’s still no way to style HTML5 audio controls with CSS only. They are heavily browser-dependent. One has to reinvent the wheel with JS/jQuery to do the job that must be done by the browser rendering engine. I won’t until they add those properties to style audio controls to CSS3.
- There’s still no agreement between browser vendors. Why not to use (for audio) just OGG, and OGG alone? (Vorbis, I mean.) It’s a free format, it yields better compression with the same sound quality, comparing to MP3. Most likely you will _save_ bandwidth and make things simpler. Patent wars are always the pain for end-users and especially for developers.
- And yeah, still no stability, especially when having several audio elements on the page. Some audio elements just don’t load sometimes in Firefox (Iceweasel) and Opera. No place to trace the errors from. So let us just hope they fix it in next versions… As well as everything said before.

Rakesh says

Hi,

I tried to load the .wav audio file using HTML 5 audio tag. The html page is not loaded, can anyone please look t the below piece of code and please correct if I did any mistakes.

Ariaan says

Could the table be updated?

JustGuess says

I think Firefox rocks, but when it comes down to the audio tag, it shares the realms of Opera… it s#cks!

If things keep developing this way, there’s plenty of future left for Adobe’s Flash and/or Quicktime plugins. Yet, is that really what the internet expects when hearing “html5″? Surely not.

Btw: That table could indeed use an update. FF3.6+ is rather outdated. We’re shoving an official public version of FF14.02 throught the voids of the web, and technology did change inside since FF10. Would be nice to see that reflected in the table (among other things).

Joeri says

I removed FF as a browser from my list of browsers.

On osx ff will freeze the os to a hold after a while.
If ff is open for more then 2 minutes i can no longer removely log in to that machine and the rainbow ball will appear after every click.
An app that causes that is no app but a virus.

Vijay Kankhare says

Does it support control over audio samples?
For e.g. If I want to modify a “Wave” file on the fly would it work with HTML5?
I am looking something similar provided by Mozilla as -
‘MozAudioAvailable’.

function audioAvailable(event) {
var samples = event.frameBuffer;
var time = event.time;

for (var i = 0; i < frameBufferLength; i++) {
// Do something with the audio data as it is played.
processSample(samples[i], channels, rate); //LIKE THIS??
}

Kit Eakle says

I see NO discussion of MIDI here! I have an old website for music education. MIDI is the standard for writing music and my site is a music education site. It uses HUNDREDS of midi files I have written over the years to teach kids songs, accompany their practice, etc., and now they won’t play in most browsers.

How can I get them to play. Is there a plug-in that will do it out there? I can’t believe that MIDI language is no longr spokemn on the internet. It is an elegant and efficient wat to transmit musical information.

I KNOW midi sounds tinny and inelegant, BUT it started it all. The web MUST support it!

ronan says

I need to play shoutcast streaming aacp on html5 any way to get this working on android browser phones??? thanks!!!!!!!!!!

Mauro says

I’m sorry to be critic.
But I must say that once again the “novelty trial” is not complete.
Did you never try for example to create a real loop?
Your wanderful “audio” systemisn’t able yet to do what was simply done with the easy “embed sound”.
In fact if you wish to create a simple loop as background music (just for example):
- if you want to adjust volume you need to create a javascript construction just to do the most normal of operations
- if you put a loop sample in easy sequence you cannot avoid the “gap silence” every each loop
So you need:
Javascript to adjust volume
“God jQuery” with a diabolic study to try to avoid the looping gaps

well!!
Is it the “novelty trend”?
And why
What about:

No, this now works only in older IE version..
is it because it’s “ancient”?
And what does it mean “modern” in your mind?
Try to find the most complicated way to do simple things?
Or give to Google API’s importance also where it’d be useless?
Sorry if I disagree:
problem is the war of financial interests between browsers, and missing of a common plugin.

Alice Wonder says

Been playing with Opus. It appears that Opus works in every open source browser I tried, as long as the server sends the correct mime type (audio/ogg).

It does not seem to work in latest Google Chrome which is odd, Chrome supports opus for webRTC – hopefully they will soon enable it for the standard audio tag as well.

It does not seem to work in Opera on Windows but I think that is just lack of GStreamer plugin.

Opus also does not work with IE or Safari. Hopefully it will with both of them soon, but…

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<b>
<blockquote cite="">
<cite>
<del datetime="">
<em>
<i>
<q cite="">
<strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.