HTML5 audio won't play on mobile devices

Question

Dear HTML5 developers,

I'm having some troubles with this HTML5 audio... So let's jump into it.

ap  = "<audio width='200' height='30' preload='auto' controls autobuffer>";
ap += "<source src='util/blob_audio.php?i=" + w + "&ogg=1' type='audio/ogg' />";
ap += "<source src='util/blob_audio.php?i=" + w + "&mp3=1' type='audio/mpeg' />";
ap += "</audio>";

I am generating it in JavaScript and a method returns it when needed. I guess I should not have to mention that "w" variable, that's a parameter (YouDon'tSay) and it works just fine.

It should be ok, right? They appear on desktops but they are having troubles on mobile devices (I have tested on an iPad2, Android 3.2.1 tablet, Android 2.3.6 smartphone).

It sais on the iPad 2: "Cannot play audio file." in the element. And the Droid shows the default audio element, but without volume control, visually it sais that it is playing - jumping from the beginning to the end.

The PHP headers looks like this (in the blob_audio.php)(we're storing the audios as blobs in the DB [don't ask me why, it wasn't my idea]):

header("Content-Type: audio/ogg"); // this is inside of a condition, this is the "ogg" part of it
header('Content-Length: ' . $length);
header('Content-Disposition: inline');
header('X-Pad: avoid browser bug');
header('Cache-Control: no-cache');

This works just fine since everything works on desktops.

I was thinking that maybe these formats (mp3, ogg) are not correctly (not supported codec) encoded for ARM architecture CPUs. Can this sh*t happen in case of the mp3?

A thought? Anyone? =)

Thank you, Ben

Answer 1

Okay, we have got this figured it out. =)

So here are the facts (see below listed):

Problem at iStuffs -> We are working over secure connection (HTTPS). That screwes up the iShit HTML5 audio handling. They need some "intermedia certificate" - probably for authentication or I don't know - between the server's certificate chain. So the thing is not working on our test server via SSL. Who knew... It works in when you deploy it normally. But, here comes Android, watch out!

Android is funny, since (as documented -_O ) Droid does NOT support any media formats via SSL below version 3.1. This is a complete "screwing up with humanity"... I don't understand why it is such a problem to make a f*cking system able to play any multi/media via f*cking SECURE connection in the 21th century... This must be some copyright law sh*t again which I have to vomit again...

In case you want to know what we have done to solve this sh*t: We figured out that if we REALLY want to make our app cross-browser and "cross-device-compatible" (dunno if this is correct naming for it but I'm sure you get it ;) ), we need to "take out" the audio (multi/media) from under SSL. So for the sake of simplicity we have created a simple HTTP sub-domain (separate folder in the hierarchy) for our audio files (we only need audio by now) and make it accessible through that subdomain + authenticate/validate through a script file. So everything goes under HTTPS but the multi/media is separate on HTTP.

Works fine, on every f*cking device, anytime. I know it is a "larger" solution but this is the most "implementable" for any device we are testing these things on.

Hope it helped somebody! =) Cheers!

Answer 2

There is no attribute "autobuffer". Here are the possible attributes, according the documentation:

src
crossorigin
preload
autoplay
mediagroup
loop
muted
controls

The type attribute gives the type of the media resource, to help the user agent determine if it can play this media resource before fetching it. If specified, its value must be a valid MIME type. The codecs parameter, which certain MIME types define, might be necessary to specify exactly how the resource is encoded (according [RFC4281])

The following list shows some examples of how to use the codecs= MIME parameter in the type attribute, valid not only for audio, but for video files too.

H.264 Constrained baseline profile video (main and extended video compatible) level 3 and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
H.264 Extended profile video (baseline-compatible) level 3 and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="avc1.58A01E, mp4a.40.2"'>
H.264 Main profile video level 3 and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'>
H.264 'High' profile video (incompatible with main, baseline, or extended profiles) level 3 and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="avc1.64001E, mp4a.40.2"'>
MPEG-4 Visual Simple Profile Level 0 video and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="mp4v.20.8, mp4a.40.2"'>
MPEG-4 Advanced Simple Profile Level 0 video and Low-Complexity AAC audio in MP4 container
<source src='video.mp4' type='video/mp4; codecs="mp4v.20.240, mp4a.40.2"'>
MPEG-4 Visual Simple Profile Level 0 video and AMR audio in 3GPP container
<source src='video.3gp' type='video/3gpp; codecs="mp4v.20.8, samr"'>
Theora video and Vorbis audio in Ogg container
<source src='video.ogv' type='video/ogg; codecs="theora, vorbis"'>
Theora video and Speex audio in Ogg container
<source src='video.ogv' type='video/ogg; codecs="theora, speex"'>
Vorbis audio alone in Ogg container
<source src='audio.ogg' type='audio/ogg; codecs=vorbis'>
Speex audio alone in Ogg container
<source src='audio.spx' type='audio/ogg; codecs=speex'>
FLAC audio alone in Ogg container
<source src='audio.oga' type='audio/ogg; codecs=flac'>
Dirac video and Vorbis audio in Ogg container

See http://www.whatwg.org/specs/web-apps/current-work/#the-audio-element for more details.

Answer 3

You should use AAC instead of MP3.

It looks like your content-type is hard coded to audio/ogg - you want to make sure that's set right when requesting an MP3/M4A.