Bug 32159 - Short MP3 files do not load using HTML 5 Audio objects in Snow Leopard
: Short MP3 files do not load using HTML 5 Audio objects in Snow Leopard
Status: ASSIGNED
: WebKit
Media Elements
: 528+ (Nightly build)
: Macintosh Intel Mac OS X 10.6
: P2 Normal
Assigned To:
: http://bowser.macminicolo.net/~jhucka...
: HasReduction, InRadar, ReviewedForRadar
:
:
  Show dependency treegraph
 
Reported: 2009-12-04 08:15 PST by
Modified: 2010-11-14 10:38 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-12-04 08:15:17 PST
The HTML 5 Audio implementation in Snow Leopard Safari / QuickTime X has problems loading short MP3 files, specifically those between 0.03 and 0.10 seconds in length.  Sounds that are shorter than 0.03, or longer than 0.10 seconds load and play just fine.

All sounds load and play properly in Leopard 10.5 with QuickTime 7 and Safari 4.0.4.  This bug only occurs in Snow Leopard with QuickTime X and Safari 4.0.4.

Test Page:
http://bowser.macminicolo.net/~jhuckaby/bugs/snow-leopard-audio-short/

All these MP3 files were created in exactly the same way (created as AIFF files in SoundTrack Pro v2.0.2, then converted to 64kbit mono MP3s in iTunes v9.0.2).  You'll notice that the sounds in the 0.03 to 0.05 second range do not load at all, and generate a MEDIA_ERR_SRC_NOT_SUPPORTED error.  The rest load and play fine.

The sounds are not corrupted.  If you click on the MP3 filenames, you'll see that QuickTime X can play them all just fine in their own window.  The problem only occurs in the context of a HTML 5 "Audio" object.

Both production Safari 4.0.4 (6531.21.10) and the webkit nightly (r51580) were tested.
------- Comment #1 From 2009-12-04 21:32:45 PST -------
<rdar://problem/7446739>
------- Comment #2 From 2009-12-07 16:44:04 PST -------
http://bowser.macminicolo.net/~jhuckaby/bugs/snow-leopard-audio-short/
shows 4 failures for me in a recent nightly.
------- Comment #3 From 2009-12-08 08:37:54 PST -------
The short sounds also fail to play when opened in QT Player X. Clicking on the file name works because WebKit falls back to using a plug-in when a file fails to play in a media document, and the QuickTime plug-in does not opt-in to the new QuickTime X playback path.

These failures are in frameworks below Webkit. Investigation is ongoing.
------- Comment #4 From 2010-03-10 22:11:25 PST -------
I found the same problem in Chrome 5.0.342.1 developer version on OSX 10.5.7. On Chrome the bug shows up for both ogg and mp3 audio files. Here are test cases for ogg: 

http://morethanmachine.com/projects/html5audio/works.html
http://morethanmachine.com/projects/html5audio/broken.html

Both of these tests work in Firefox 3.6. 

Also of note, I cannot get audio to replay in Webkit. I've tried calling play() again, which works in Firefox, but nothing happens. If I try to set the startTime on the Audio object this has no effect either.
------- Comment #5 From 2010-03-10 22:51:17 PST -------
(In reply to comment #2)
> http://bowser.macminicolo.net/~jhuckaby/bugs/snow-leopard-audio-short/
> shows 4 failures for me in a recent nightly.

All of the tests work in Webkit r55772 -- Safari 4.0.4 (531.21.10) on Windows XP.

Any of the tests shorter than .40 seconds fail in Chrome 4.1.249.1030 beta (40990) on Windows XP.
------- Comment #6 From 2010-03-11 07:00:40 PST -------
(In reply to comment #4)
> I found the same problem in Chrome 5.0.342.1 developer version on OSX 10.5.7.
> On Chrome the bug shows up for both ogg and mp3 audio files. Here are test
> cases for ogg: 
> 
> http://morethanmachine.com/projects/html5audio/works.html
> http://morethanmachine.com/projects/html5audio/broken.html
> 
> Both of these tests work in Firefox 3.6. 
> 
Both of these tests also work in Safari on OSX if the Xiph QuickTime components are installed


> Also of note, I cannot get audio to replay in Webkit. I've tried calling play()
> again, which works in Firefox, but nothing happens. If I try to set the
> startTime on the Audio object this has no effect either.
>
It won't play again because the audio element is defined in a variable local to the function:

<html>
<head>
<script type="text/javascript">
    function init(){
        var audio = new Audio("Tromboon-sample.ogg");
        audio.play();    
    }
</script>
</head>
<body onload="init()">
</body>
</html>

 so it gets collected once it finishes playing. Declare the variable in the global scope:

<html>
<head>
<script type="text/javascript">
    var audio;
    function init(){
        audio = new Audio("Tromboon-sample.ogg");
        audio.play();    
    }
</script>
</head>
<body onload="init()">
</body>
</html>

and it can be played again.
------- Comment #7 From 2010-04-20 02:23:32 PST -------
I have been experiencing something similar to this with longer audio files as well.
------- Comment #8 From 2010-04-20 08:26:44 PST -------
Can you be more specific about "longer"? A URL to a testcase would be useful.
------- Comment #9 From 2010-05-17 21:39:07 PST -------
I am seeing this (or a similar) issue intermittently on Safari 4.0.5 (6531.22.7) on Snow Leopard, 10.6.3. The MP3 files in question were encoded with LAME, and are 10 seconds and ~4 minutes in length. (Examples can be provided, if helpful.)

Expected: MP3 should start buffering, load a certain amount and then begin playback.

Observed: HTML 5 Audio() "play" event fires, followed by "waiting", then "loadstart", but no audio is heard.

My test scenario involves JS intercepting a link to an MP3 file, and trying to play it via new Audio('foo.mp3') followed immediately by a call to play().

Turning off JavaScript means the link falls through and loads in the "built-in" browser audio player, where it seems to work without issue. However, copying + pasting the MP3 link (or dragging it from the page) into the address bar often (but not always) results in playback failure, similar to how the JS Audio() case behaves.

Sometimes, trying to seek within one of these "hung" sounds (assigning a different value to currentTime at least twice??) will get it playing.

Additionally, this behaviour has *not* been seen in Safari 4.0.5 (531.22.7) on Windows XP, and a friend with OS X 10.5 reported that he could not reproduce the issue on his version of Safari either. I have also not been able to reproduce it on the iPad - neither the physical device nor the simulator - it has played just fine.
------- Comment #10 From 2010-05-17 21:43:13 PST -------
(In reply to comment #9)
> (Examples can be provided, if helpful)

Sample files would be helpful, thanks.
------- Comment #11 From 2010-05-17 22:32:55 PST -------
Example, modified version of Joseph's test page with files that intermittently fail, namely the longer "armstrong" and "untitled groove" drum machine loops:

http://isflashdeadyet.com/tests/safari-html5/
(Pardon the domain, more for fun than anything else. :D)
------- Comment #12 From 2010-05-17 22:40:10 PST -------
Ack, one more note re: behaviour on the test page provided - clicking the links to load the files in a new window does not consistently result in the file playing, even when the play button is clicked.

Reloading the test page also produces inconsistent results with the same files.
------- Comment #13 From 2010-05-18 08:43:42 PST -------
I can confirm the intermittent behavior, on both my test page and Scott's (hi Scott :).  I originally thought this was due to QuickTime X caching the files, but I get random failures / successes just by refreshing the page.

On a side note, does anyone know where QuickTime X stores its cache files?  I sure would like to clear that cache, for a clean test.  From my "lsof" output, I'm guessing its something horrible like:

/private/var/folders/Tx/TxfvOL18Fxesp28QHARcSE+++TQ/-Tmp-/MediaCache/CachedMedia-O8WNt5
------- Comment #14 From 2010-06-07 22:20:31 PST -------
FWIW, a quick test shows the issue still occurring on the newly-released Safari 5.0 (6533.16) on Snow Leopard, 10.6.3.

Similar to the prior release, Safari 5.0 (7533.16) on Windows XP does not show problems with playback.

I develop and maintain a JavaScript audio API that uses HTML5 with Flash fallback, and have previously special-cased Safari 4.0.5 on Snow Leopard because of the playback issue; it feels wrong to have to make Safari on Snow Leopard resort to use Flash to play back MP3/MP4 content, despite it working just fine on Leopard and WinXP (or, maybe I'm just doing it wrong? Bad sample files? "water drop" seems to be most consistently problematic.)

http://www.schillmania.com/projects/soundmanager2/
------- Comment #15 From 2010-09-08 21:11:30 PST -------
FWIW, confirming this behaviour is still seen on Safari 5.0.1 and the just-released 5.0.2 on Snow Leopard.
------- Comment #16 From 2010-09-09 06:30:05 PST -------
(In reply to comment #15)
> FWIW, confirming this behaviour is still seen on Safari 5.0.1 and the just-released 5.0.2 
> on Snow Leopard.

As noted above, the problem is below WebKit ("... also fail to play when opened in QT Player X"), so a new release of Safari is unlikely to fix this.
------- Comment #17 From 2010-09-09 07:58:28 PST -------
Ah, apologies; somehow missed the earlier acknowledgement of QT/underlying frameworks being the cause. Thanks for following up. Looking forward to updates.