Forums » Impact Engine » Bug Report: Chrome Reliably Fails To Load Audio

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:
http://commins.ca/impactjs-chrome-audio-bug/

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
ig.module('game.main')
.requires('impact.game')
.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:
https://github.com/Joncom/impactjs-chrome-audio-bug

Perhaps this bug report relates to these unresolved issues?

http://impactjs.com/forums/help/loader-stalls-on-ig-sound-for-music-file

http://impactjs.com/forums/help/loader-gets-stuck-40-50-of-the-time-not-launching-game

http://impactjs.com/forums/help/loader-hangs-when-loading-more-than-one-music-file-in-chrome

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?

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:

http://commins.ca/impactjs-chrome-audio-bug/?nocache


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:
https://bugs.chromium.org/p/chromium/issues/detail?id=677633

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!