I’m attempting to embed an HTML5 audio element pointing to MP3 or OGG data served by a PHP file . When I view the page in Safari, the controls appear, but the UI says “Live Broadcast.” When I click play, the audio starts as expected. Once it ends, however, I can’t start it playing again by clicking play. Even using the JS API on the audio element and setting currentTime to 0 fails with an index error exception.
I suspected the headers from the PHP script were the problem, particularly missing a content length. But that’s not the case. The response headers include a proper Content- Length to indicate the audio has finite size. Furthermore, everything works as expected in Firefox 3.5+. I can click play on the audio element multiple times to hear the sound replay.
If I remove the PHP script from the equation and serve up a static copy of the MP3 file, everything works fine in Safari.
Does this mean Safari is treating audio src URLs with query parameters differently than URLs that don’t have them? Anyone have any luck getting this to work?
My simple example page is:
<!DOCTYPE html>
<html>
<head></head>
<body>
<audio controls autobuffer>
<source src="say.php?text=this%20is%20a%20test&format=.ogg" />
<source src="say.php?text=this%20is%20a%20test&format=.mp3" />
</audio>
</body>
</html>
HTTP Headers from PHP script:
HTTP/1.x 200 OK
Date: Sun, 03 Jan 2010 15:39:34 GMT
Server: Apache
X-Powered-By: PHP/5.2.10
Content-Length: 8993
Keep-Alive: timeout=2, max=98
Connection: Keep-Alive
Content-Type: audio/mpeg
HTTP Headers from direct file access:
HTTP/1.x 200 OK
Date: Sun, 03 Jan 2010 20:06:59 GMT
Server: Apache
Last-Modified: Sun, 03 Jan 2010 03:20:02 GMT
Etag: "a404b-c3f-47c3a14937c80"
Accept-Ranges: bytes
Content-Length: 8993
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
I tried hard-coding the Accept-Ranges header into the script too, but no luck.
Can you post the headers sent by the server both with and without the PHP script? I’m wondering if the PHP script is sending a different
Content-Typethan serving the files normally.It would also be a good idea to specify the
typeattribute on thesourceelements, so the browser does not have to download both clips to determine if it can play them.I cannot reproduce your problem. I have tried to recreate the problem in Safari 4.0.4, and the current WebKit nightly, with the following test page. I am simply using mod_rewrite to dispatch to different formats based on a parameter instead of PHP, but I don’t think that should make a difference, unless somehow PHP is modifying the file.
Can you try my example out and let me know if it works for you?
edit Ah. After poking around at it a bit more, it appears that the problem is due to an odd way that the
<audio>element in Safari behaves in attempting to determine the size of the content.Here’s an excerpt from a packet capture of Safari upon encountering an
<audio>element pointing to a file served directly from Apache. As you can see, it first tries to fetch the first two bytes of the media, presumably so it can get a Content-Length back, and possibly other headers. It then tries to fetch the whole thing. Then, inexplicably, it tries to fetch the first two bytes again, but passes appropriate caching headers to get a “304 Not Modified” response. And finally, still inexplicably, it fetches the last 3440 bytes of the file all over again. It does all of these in separate TCP connections, which adds considerable overhead, in addition to the overhead of fetching the data a couple of times.Anyhow, on to how it deals with the output of your PHP script. Here, Safari again tries to download the first two bytes, but your script ignores the
Rangerequest and returns the whole thing. Apparently, WebKit doesn’t like that, and so it tries again, without theRangerequest. Again, your script sends the full contents. Safari now tries once more, adding anIcy-Metadataheader, which indicates it thinks that it’s downloading a stream and wants streaming metadata to be sent. It finally accepts the output of that, and the<audio>element can play.In summary, it appears that Safari (or more accurately, QuickTime, which Safari uses to handle all media and media downloading) has a completely braindamaged approach to downloading media. Something in the way you send your data back, probably the fact that you don’t respond to
Rangerequests, makes it think that you are sending streaming media, causing it to download the content repeatedly (though even when confronted with a server that does respond to aRangerequest, it still does several more requests than it really needs to).My advice would be to try to respond appropriately to
Rangerequests; when serving up media, browsers will likely use them to try to minimize bandwidth, by only buffering as much as they need to be able to play through (although have theautobufferattribute which indicates that you would like them to buffer the whole thing, browsers may ignore that). I would recommend usingX-Sendfileto let Apache deal with serving the file, caching, and range requests, but you appear to be on Dreamhost, which doesn’t havemod_xsendfileinstalled, so you’re going to have to roll your ownRangehandling.