Home/ Questions/Q 7771381
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T16:38:19+00:00

Dear HTML5 developers, I’m having some troubles with this HTML5 audio… So let’s jump

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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 fcking system able to play any multi/media via fcking 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" (I don’t know 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.

    • 0