<!DOCTYPE html> <html> <head> <script type="text/javascript"> function load() { myAudio.addEventListener('canplay', function () { console.log('Audio Ready to play!'); }); } </script> </head> <body onload="load();"> <audio controls src="http://stream.radiocampusparis.org:8000/stream_rcp.mp3" preload="auto" autobuffer></audio> </body> </html> Try this on a Mac, then on a WebKit Mobile device. Won't work on the Mobile device. Tested on Android, iOS, WebOS.
Forgot a line in the code :) myAudio = document.getElementsByTagName("audio")[0]; Hope it's a bug or there's a workaround as I can't find the way to be notified of the readiness of a <audio> tag. Note you can replace this stream URL with a "normal" MP3, local - but it's less useful.
(In reply to comment #0) > <audio controls src="http://stream.radiocampusparis.org:8000/stream_rcp.mp3" preload="auto" autobuffer></audio> > > Try this on a Mac, then on a WebKit Mobile device. Won't work on the Mobile device. Tested on Android, iOS, WebOS. (In reply to comment #1) > > Hope it's a bug or there's a workaround as I can't find the way to be notified of the readiness of a <audio> tag. > > Note you can replace this stream URL with a "normal" MP3, local - but it's less useful. "preload" is a *hint* to the user agent, it may not cause buffering to begin automatically: The preload attribute is intended to provide a hint to the user agent about what the author thinks will lead to the best user experience. The attribute may be ignored altogether, for example based on explicit user preferences or based on the available connectivity. http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-preload On iOS buffering does not begin until the user triggers playback so the observed behavior is correct. I don't know what the policy is on Android or WebOS, I suggest filing bugs against those projects if you think there is a bug.
Kind of a shame. The reason why I want to preload is for the user experience to be better. It suck to have to "wait" for a stream to start, for a radio app. What you as a user want is that the stream starts right away. Furthermore, the *real* reason I do that is to only display streams that are "ready". There's always a possibility that a stream of a radio is "down" or "not ready" and in this case I don't want to show it to the user. It's not the first time I hear those "user need to do something" from Apple, and I really don't understand how it's meant to be good for the user :( Thanks for answering though! I guess I'll have to play and pause the sound, if that's the only option I'm giving, together with providing a horrible "wait for the stream that might even never arrive but we still show it to you" user experience.
Oh, btw, what about "autoplay" - just tested and it works on WebOS :) Neither on iOS nor Android though :(