AudioLoader doesn't behave correctly without user interaction

The AudioLoader makes use of window.AudioContext. This is problematic because any use of audio in Chrome requires a user interaction. While that’s normally solvable by triggering audio with a click, this isn’t suitable when dealing with asset loading, as this sort of thing should start the moment the page loads.

For example, I’d like to make use of AudioLoader when the page first loads, to download audio files along with other assets. If I do this, Chrome may bring up this warning (although this seems to be intermittent):

The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://goo.gl/7K7WLu

To be clear, I have a click event for playing the sounds. Currently, we need a click event even when loading the sounds.

Looking at the source code for AudioLoader, this is happening because it’s trying to load and decode the audio in the same step.

There doesn’t seem to be a clear solution on how to fix this. It’s a real pain that Chrome is restricting even the decoding of audio. Perhaps audio files need to be treated as normal files while downloading, and then there is a separate step (after a user interaction to start the app) for the audio to be decoded.

Tested on Chrome, Windows. Three r116.

[Mugen87]

Maybe you can convince the Chromium project to alter its audio policy 😉

[funwithtriangles]

Sure, I think a splash screen makes sense, but while it’s displaying is usually the best time to load all of your assets. If the user clicks “start” and is then faced with another loading screen, this isn’t ideal.

I’d agree that this is a matter of application design but a library can help with common patterns. Loading a second round of assets after clicking “start” is not a common pattern.