This forum is read only and just serves as an archive. If you have any questions, please post them on

7 years ago by Joncom

Under simple circumstances, Chrome reliably fails to load audio files. This results in the ImpactJS game staying stuck at the pre-loader bar phase.

A live demo can be found here:

About the demo:

- The first page load is always successful.
- Refreshing the page will almost always result in the pre-loader bar getting stuck.
- But if you wait a minute or so before refreshing, the load will always succeed.

The test case (demo) is dead simple:

// main.js
.defines(function() {

       MyGame = ig.Game.extend({
               audio1: new ig.Sound('media/audio1.ogg'),
               audio2: new ig.Sound('media/audio2.ogg'),
               audio3: new ig.Sound('media/audio3.ogg')

       ig.main('#canvas', MyGame, 60, 640, 64, 1);

Demo repo is available here:

7 years ago by Joncom

Perhaps this bug report relates to these unresolved issues?

7 years ago by Joncom

To quote Dominic from the first thread, assuming this issue is closely related:
Quote from dominic
I have seen this happen from time to time, but I have yet to find a test case that reproduces this behavior somewhat reliably
Can anyone confirm the demo fails reliably for them as well?

7 years ago by dominic

Impact uses WebAudio and loads via XHR since version 1.24 when the browser supports it. This works way more reliably than HTML5 Audio in my experience. So upgrading should help.

That said, HTML5 Audio is still used for music and I can also reproduce the behavior you reported in 1.24 when setting ig.Sound.useWebAudio = false; before calling ig.main() (i.e. forcing HTML5 Audio for everything).

I attached a bunch of event listeners to each audio clip to see what&039;s going on and it really seems to be a bug in Chrome. The #loadeddata, canplay and canplaythrough events are never fired for the third audio file on a page reload. None of the Loading interruption events are fired either - indicating no error.

Attempting to play this third, unloaded Audio element will result in the waiting event ("Sent when the requested operation (such as playback) is delayed pending the completion of another operation (such as a seek)."). No play event will ever be fired and the audio will never be played. So simply listening for loadedmetadata (the last event fired by this broken Audio element) instead of canplaythrough won't be enough to work around this issue either.

The only reliable workaround that I can offer right now, besides using 1.24 with WebAudio, is to circumvent Chrome&039;s cache: Use <3> or append #?nocache to the URL:

Just for the record, these are the events I get after a reload:

create audio element media/audio1.ogg
create audio element media/audio2.ogg
create audio element media/audio3.ogg
emptied media/audio1.ogg
loadstart media/audio1.ogg
emptied media/audio2.ogg
loadstart media/audio2.ogg
emptied media/audio3.ogg
loadstart media/audio3.ogg
suspend media/audio1.ogg
suspend media/audio2.ogg
suspend media/audio3.ogg
loadedmetadata media/audio1.ogg
loadedmetadata media/audio2.ogg
loadedmetadata media/audio3.ogg
loadeddata media/audio1.ogg
canplay media/audio1.ogg
canplaythrough media/audio1.ogg
loadeddata media/audio2.ogg
canplay media/audio2.ogg
canplaythrough media/audio2.ogg

Edit: Test case and Chrome bug report:

7 years ago by Joncom

Feeling silly now that I did not check the version of ImpactJS being used on the project where this issue cropped up.

Using 1.24 indeed made the problem go away.

And I suppose continuing to use HTML5 Audio for music is OK because, as you noted in your Chromium bug report, the problem occurs when creating multiple instances off the same audio file, which music does not do. :)

Thank you for looking into this!
Page 1 of 1
« first « previous next › last »