In order to play audio, you need to use the video element. See Supported Media Formats in official Android documentation for more.įun fact: Android 2.2 supports the element but not its counterpart. Generally, mp3 and Ogg Vorbis can be assumed. Various versions of Android include different codecs. †† mobile browsers generally use codecs on the host operating system. † WAV since Chrome 9 Mobile browser audio codec support Mobile Browser Desktop browser audio codec support Desktop Browser
Let’s check the codec support in the current crop of modern browsers. Var canPlayOgg = !!audio.canPlayType & audio.canPlayType('audio/ogg codecs="vorbis"') != "" Īll we’re doing here is checking that canPlayType is supported ( !! effectively casts to a boolean) and then checking that canPlayType of our chosen format doesn’t return an empty string. So to test for support, you could do this: var audio = new Audio() The browser can only guess at whether a certain codec is playable without actually trying to play it.
The reason we have these odd return types is because of the general weirdness surrounding codecs. Worth knowing for use with early audio enabled browsers such as Firefox 3.5, Chrome 4, and Safari 4, although these make up a very small percentage of active browsers. Previously, canPlayType returned “no” instead of the empty string. You can even explicitly include the codec: audio.canPlayType('audio/ogg codecs="vorbis"') To test format support, you can use the canPlayType method, which takes a MIME type as a parameter: audio.canPlayType('audio/ogg') Once you have your audio element, you’re ready to access its methods and properties. Var audio = document.getElementById('my-audio-id') Īlternatively, you can also create your element entirely in JavaScript: var audio = new Audio() If you mark up your element in HTML as we did in our previous example, you can grab the element by doing the following: var audio = document.getElementsByTagName('audio') But first, here’s a quick recap on how we manipulate the audio element via the API. But what if we want to supply the correct source in a more dynamic manner? Knowing in Advance: canPlayType Can Help, Probably #įortunately the audio API provides us with a way to find out whether a certain format is supported by the browser. So now we know how to define our audio sources, and the browser will happily pick the first source that it supports. If not, supplied the browser will guess and take a trial-and-error approach to detecting the media type.Ĭool. 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. Note that you can omit the codecs portion of the type attribute, but for robustness and efficiency, I recommend you supply the browser with as much media information as possible.Īlong with the source, we specify a type attribute. In this code, we also place a fallback solution after the elements. Here we define the element and the sources to use.
To set up HTML5 audio in the most robust manner, you could write something like this: When defining sources in your code or markup, you can also specify the MIME type, which will help the browser identify the media correctly. Further, in the case of a fallback solution, Flash does not support gzipped media. Most formats are already compressed, and there’s limited support for those that aren’t.
Tip: Do not apply gzip compression to your media files on the server. In the case of the Apache web server, this means adding the following lines to your. Server Side #įirst things first: your media server should be configured to serve correct MIME types. MIME types (also known as Internet Media Types) are a way of defining file formats so that your system knows how to handle them. So how do we get started? Well, there are a few things we need to do to prepare the ground. That’s what I’ll attempt to do in this post. Ī good way of understanding how the land lies is by going through a few use cases. With many new advanced audio APIs being actively worked on and plenty of improvements to the existing native audio we all know and love, it’s certainly an exciting time to revisit the heady world of. Now, two and a half years later, it’s time to see how things are progressing. It may well be worth reading if you want to get a feel for the element and associated API. This is a follow up to my 2009 article Native Audio in the Browser, which covers the basics of HTML5 audio.
0 kommentar(er)
