HTML5 Audio on Android: DOA

This Android bug with HTML5 audio is awful. After a phone call or SMS, it resumes playback EVEN IF the audio was paused and EVEN IF the browser isn’t active. I just added a +50 bounty to this question as I still can’t figure how to prevent playback from happening.

Try it yourself on Android Browser:

Meanwhile Chrome audio is so temperamental it shuts down when the screen turns off, a critical flaw which no-one is prepared comment on ( much for open web standards.

And you wonder why native apps are eating HTML5’s lunch. Even with packaging from PhoneGap and it’s building apps on a house of cards. Until the default Android runtime is Chrome, and Android Chrome gets up to parity with Mobile Safari and beyond, there’s not much point using HTML5 to develop anything serious on Android, not when the native platform keeps running ahead on turbo mode.

Cross-posted and modified from G+

Audio/Video Tag: Don’t Forget to load() before you play()

This is a gotcha that will catch a lot of people out because it goes against the expectation that you just change an image’s appearance by setting its “src”, done. And also, it’s a deviation from the more general convention that you change DOM properties declaratively to make stuff happen. Probably for good reason, given the temporal nature of audio and video playback, but just beware it’s a different model.

Bottom line is – load() between changing src and play()ing:


  1. function play(url) {
  2.   var audio = document.querySelector("audio");
  3.   audio.src = url;
  4.   audio.load(); // !HUL|_O! PAY ATTENTI0N!
  6. }

A lot of online sources talk about play() and omit to mention this vital fact, because they’re only play()ing a single track…and the first track works fine. This is an oddity – you can just call play() the first time and it will automatically load. This happens whether you set “src” in the initial HTML’s “audio” tag or whether you set it programatically. I did some fiddling and it looks like the behaviour is the same in Chrome and Firefox. It’s like the track is auto-load()ed the first time you set its source. (And note that Firefox doesn’t auto-buffer so that’s nothing to do with it.)

devx has you covered on this topic, and points out the subtle issues which you would need to look at for a quality production:

However, media by its very nature is a time-spanning process. You’re working with both the need to load and cache audio and video files and the network connection, which itself can prove to be a challenge that’s usually not a factor for most non-temporal resources. For these reasons, when dealing with video and audio on the web, if you want to take control of the process in any way, you have to work asynchronously, tying into the various events that are passed back to the client from the media-serving website. Table 4 (taken directly from the HTML 5 documentation) provides a full listing of the various events and when they are dispatched. … Of all the events in Table 4, perhaps the most useful are the canplay and canplaythrough events. The first, canplay, will fire when enough data has been loaded for the video player to start actually rendering content constructively, even if not all of the data has been loaded. The canplaythrough event, on the other hand, will fire when the data has essentially completely loaded into the browser’s buffer, making it possible to play the video all the way through without the need to pause and retrieve more content.