Server Side #

First things first: your media server should be configured to serve correct MIME types. In the case of the Apache web server, this means adding the following lines to your .htaccess file:

# AddType TYPE/SUBTYPE EXTENSION
AddType audio/mpeg mp3
AddType audio/mp4 m4a
AddType audio/ogg ogg
AddType audio/ogg oga
AddType audio/webm webma
AddType audio/wav wav

Client Side #

When defining sources in your code or markup, you can also specify the MIME type, which will help the browser identify the media correctly.

To set up HTML5 audio in the most robust manner, you could write something like this:

<audio>
   <source src="elvis.mp3" type='audio/mpeg; codecs="mp3"'>
   <source src="elvis.oga" type='audio/ogg; codecs="vorbis"'>
   <!-- add your fallback solution here -->
</audio>

Here we define the element and the sources to use. The browser will only pick one. It won’t play both. In this code, we also place a fallback solution after the <source> elements.

Along with the source, we specify a type attribute. Although not strictly necessary, this attribute allows the browser to know the MIME type and the codecs of the supplied media before it downloads it. If not, supplied the browser will guess and take a trial-and-error approach to detecting the media type.

Cool. So now we know how to define our audio sources, and the browser will happily pick the first source that it supports. But what if we want to supply the correct source in a more dynamic manner?

Containers, Formats, and File Extensions (oh, and MIME types again) #

Above, I’ve referred to the audio formats as they’re commonly known, but technically we should refer to their container format. (A container can contain more than one format — e.g., MP4 can contain AAC or AAC+.)

We have <audio> and we’re not afraid to use it! #

Okay, we’ve done the minimum amount of work to get our audio element set up and playable. What else can we do? At the moment, we’re relying on the browsers’ default audio players, each of which looks and works a little bit differently than the rest. Perhaps we’d like to customise the experience and create our own. To help us do that, the <audio> element supports several different properties exposing its current state.

Some of the more commonly used properties:

Using these properties is pretty straightforward. For example:

var audio = new Audio();
var duration = audio.duration;

The variable duration now holds the duration (in seconds) of the audio clip.

The buffered Attribute #

The buffered attribute will return the time ranges that have been completely downloaded. A little bit of a code:

// returns TimeRanges object of buffered media
var buffered = audio.buffered;

// returns time in seconds of the last buffered TimeRange
var bufferedEnd = audio.buffered.end();

The TimeRanges Object #

The TimeRanges object contains data on the parts on buffered media in the form of one or more — you guessed it — time ranges. A TimeRanges object consists of these properties:

1. length — number of time ranges
2. start(index) — start time in seconds of a particular time range
3. end(index) — end time in seconds of a particular time range

You may be wondering in what situation the TimeRanges object would contain more than one time range. Imagine the user clicks forward to a portion of unbuffered media. The idea is that the media would then start buffering from that point, and you’d have two time ranges:

------------------------------------------------------
|=============|                    |===========|     |
------------------------------------------------------
0             5                    15          19    21

So in this case:

• audio.buffered.length returns 2
• audio.buffered.start(0) returns 0
• audio.buffered.end(0) returns 5
• audio.buffered.start(1) returns 15
• audio.buffered.end(1) returns 19
• audio.buffered.end() returns 19

Note that if the user is actively seeking through the media throughout the buffering process, a contiguous buffered progress bar actually makes little sense. Also consider that some browsers will read part of the end of the file to establish duration and so create two time ranges almost immediately. Now you’re starting to appreciate why making an accurate buffered progress bar is a little tricky!

You can check out TimeRanges in real-time using this handy HTML5 Media Event Inspector.

Seeking and Seekable #

Seeking is the act of looking forward (or backward) in a media file. This usually happens when a section of media is requested before it’s finished loading.

The seeking attribute can be used to determine whether that part of the media is being actively “seeked”. When it returns true, the portion of the media the user requested is still being loaded.

To recap a little, the buffered property tells us what’s been downloaded and is often used as an indication of what part of the media can be directly played. If the browser supports it, however, it may make more sense to use the seekable attribute to determine which parts of the media can be jumped to and played immediately.

seekable returns a TimeRanges object of time ranges that can be played immediately. This uses a technology known as byte-range requests, which allows part of the content to be requested over HTTP. In short, we don’t have to load all the data prior to the desired part in order to play it.

An example:

// Is the player currently seeking?
var isSeeking = audio.seeking;

// Is the media seekable?
var isSeekable = audio.seekable && audio.seekable.length > 0;

// Time in seconds within which the media is seekable.
var seekableEnd = audio.seekable.end();

Note that media being in a “seekable” state is different than media being in a “buffered” state. Media doesn’t have to be buffered to be seekable.

Buffered and seekable data can be useful information, but it would be too easy if there weren’t a few gotchas.

1. Preloading is not supported in all older audio-capable browsers (Opera 10/Firefox 3.6).
2. The buffered attribute is not always supported (Blackberry PlayBook).
3. Not all HTML5 browsers allow byte-range seeking — for example, Safari on Windows. In this case, you can still seek within the downloaded content. It downloads from the start until the end, as does Flash.

If you want to deliver the best possible solution to your users, you’ll need to feature test.

A Note about Preloading #

I mentioned the preload attribute in the previous article. This attribute accepts three possible values:

1. none — Do not preload any media. Wait for a play event before downloading anything.
2. metadata — Preload just the metadata. Grab the start and the end of the file via range-request and determine the duration.
3. auto — Preload the whole file. Grab the start and the end of the file to determine duration, then seek back to the start again for the preload proper.

When it comes to preloading, remember that it’s a request or hint to tell the browser how you’d like to preload the media. The browser is not under any obligation to fulfill that request. For this reason, certain browsers may handle these requests differently.

The load Method #

Until fairly recently, the load method was required in order to tell the browser about a change in the media source and to get it to update appropriately. Now, media.load() causes the element to reset and to start selecting and loading a new media resource from scratch.

So for older browsers, such as Firefox 3.6, in order to change the media source, you’ll not only need to change the source value but also issue a load command:

var audio = new Audio();
audio.setAttribute("src","mynew.mp3");
audio.load(); // required for 'older' browsers

When Browsers Go Off-Spec #

When creating cross-browser solutions, it’s useful to know which browsers follow the W3C spec to what extent and how they deviate.

A Change of Pace #

A couple of noteworthy upcoming features are playbackRate and defaultPlaybackRate. As you can probably imagine, these fellas let us alter the speed and direction of playback. This functionality could be used for fast-forward and rewind functions or perhaps to allow users to tweak the playback speed so they can fit more podcasts into their day.

• audio.playbackRate returns 1 at normal speed and acts as a multiple that is applied to the rate of playback. For example, setting playbackRate to 2 would double the speed, while setting it to -1 would play the media backwards.
• audio.defaultPlaybackRate is the rate at which the audio will play after you pause and restart the media (or issue any event for that matter).

Media Fragments #

Currently, if we wish to reference some part of a media file, we often first have to download at least some of the media we don't actually need. The W3C Media Fragments proposal was created to address this issue and others, such as the retrieval of an area of video or just the associated text track. In the case of audio, it will allow us to specify which parts we want to download using parameters on the source URI.