Native Audio in the browser

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:

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:

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.

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:

check for HTML5 audio support, and if not present, fall back on Flash,

check the level of HTML5 audio support and adapt your code accordingly for each browser, and

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:

Category

Tags

Translations

This article was written by Mark Boas. Mark makes, teaches, writes about and promotes new and open web technologies. Co-founder of Happyworm - a small web agency and makers of the jPlayer media framework, he enjoys pushing the limits of the browser using HTML5 and JavaScript. Though a generalist at heart, Mark spends much of his time playing with web based media and real-time communications. A lover of all things audio, his passion often drives his work and is currently enjoying the challenge of taking audio ‘somewhere new’ with his Hyperaudio experiments. You can follow Mark on Twitter.

@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 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.

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.

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.

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).

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).

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.

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.

@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.

> 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:

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.

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

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?

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.

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

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:

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

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!!

@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!

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.

[…] Notice the need for 2 demos because chrome cant read wav and mozilla wont do MP3! Ogg vorbis is a common format for the two, but i couldn’t quickly find any example files to use! Read here for browser file format support. […]

@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.

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.

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.

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.

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.

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

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.

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).

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?

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:

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();”.

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.

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.

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.

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.

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.

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

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

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

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 :)

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.

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:

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.

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.

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.

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.

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).

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.

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!

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.

Andrey Superstar I think it is fantastic that MP3 is dying I just wish it would die much quicker. MP3 is an old 80’s format so not sure why anyone would want to continue using such inferior and antiquated codec.

For lossy Opus is the new king it plays well on mobiles phone made 2015 and newer, it streams well over the mobile cellular towers. The audio quality is far superior to mp3 and even though its not lossless Opus does tug on the coattails of lossless formats. Lossless will be king in the very near future and I would say in the next 3-5 years but this won’t happen till mobile phone towers data speeds and range improve as mobile data still isn’t very reliable no matter where you go.

If any objects due to hard drive space all I have to say is its an extremely poor excuse as hard drive space is only 150 bucks for a 2TB drive and even using Opus to store all the music a single 2TB drive is enough space to hold most everyone’s music collection. The Support of Opus is growing and as stated before Samsung Galaxy phones already support it. So MP3 is pretty much dead as its about Opus,Flac, and Aiff, the 2 latter of the 3 are lossless. So to all those hanging on to MP3 all I have to say is its time to move forward and stop using a codec that was produced in the 80’s