Interesting situtation the other day with the new HTML 5 audio tag on the Safari browser. I was testing cross platform compliance for a HTML 5 game that I had written and noticed that on Safari for Windows (7) when a hit test was performed and a sound played, there was jerkiness and a small delay whilst the sound played and then the game continued. This occured on Safari 4.0.3 and after upgrading on version 5.1 as well.
The code used to declare the initial variable to allow sound was as follows:-
var soundClick = new Audio(“audio/click2.mp3″);
When the hit test is carried out and the sound is required to be played, the following code was invoked:-
soundClick .load();
soundClick .play();
This appears to be the correct way to use HTML5 audio within code to play a single sound with no audio tag declared in the HTML markup. Although this worked on IE9 and Chrome (no sound on Firefox – separate matter), didn’t work correctly on Safari. I then tried declaring an audio object in the HTML game markup between a hidden DIV like so with “preload” set to “Auto”:-
<audio id=”click2Sound” src=”audio/click2.mp3″ preload=”auto”></audio>
Commenting out the previous code (declaration and usage in the hit test) I simply inserted the following new code in the hit test instead:-
document.getElementById(“click2Sound”).play();
To my surpirse when playing the game in Safari there is now no jerkiness or delay and IE and Chrome still play fine as well! My disection of what is going on here is that using load() and play() requires the audio file to be loaded each time dynamically, and there seems to be some overhead in Safari when doing this as other browsers don’t seem to exhibit the same problem (caching audio file maybe?). However, when using the declarative audio tag in HTML markup with preload set, it appears that since I am only playing a single sound on that object (with no swapping of src) I get the effects of preload and Safari is happy to play the sound without any jerkiness in the game play. Strange.
All comments gratefully received on this as I would like to understand why this is 
UPDATE: The problem with the sounds not playing in Firefox using the Audio element is that Firefox 3.6/4.0 doesn’t yet support .mp3 so a WAV fallback will also have to be provided in the Audio element.
Doesn’t yet? You certainly did not do the research: Using MP3 amounts to licensing fees, while using Vorbis does not and the file format has better compression. Every browser not including Microsoft and Apple stuff plays Vorbis just fine. Note that Apple uses WebKit – as does Chrome; the latter has support for Vorbis.
Hi,
Thanks for the rude comment. Perhaps you are getting a little carried away with the Vorbis format because as I understand it, there is no support for it on ANY version of IE up to version 9 nor is it supported by Safari or mobile safari. As I am not in the practice of producing software that works only some of the time I used example formats that do work across ALL browsers.
Besides, the post is not so much about what sound format you use, it was more about static vs dynamic loading of the sound file and it’s affect on the gameplay. Perhaps better manners would help you come across with a more constructive comment next time.
Happy New Year.
that sort of fixes the issue but now repeated fast clicks on the object won’t generate new instances of the sound. for example repeatedly clicking for gun bang sounds won’t work anymore.