Handle audio context state of interrupted

[nanek]

Using Chrome on iOS 11, if the screen is turned off the web audio context goes into an interrupted state. Using Howler, it never resumes and no audio plays after turning the screen back on. This updates the autoResume to also handle the interrupted state.

[filharvey]

Can this please get merged, this is causing games for FB Instant Games, to lose sound, if an ad is played, or a phone call is recieved.

[nanek]

Note, even after this I continued to encounter issues with audio after the screen was off then back on. After investigating, it seemed related to the autoResume after an autoSuspend, which autoResume could attempt to restart the AudioContext based on the timer and not a user touch event, which mobile browsers will ignore.

Therefore I'm currently disabling, autoSuspend with Howler.autoSuspend = false.

Howler appears to track the AudioContext state internally, separately from the actual state. At times this seemed to get out of sync. Therefore I am now calling Howler.ctx.resume() before attempting to play an audio file, if the Howler.ctx.state is suspended or interrupted. This is similar to what autoResume is attempting, however autoResume appears to use the Howler.state instead of the actual AudioContext state which could be different.

[goldfire]

@nanek Would you mind submitting that as a separate issue? I'm going to merge this shortly and wouldn't want to lose track of that.

[goldfire]

Oh sorry, I see what you are saying now. I'll have to look at this a bit more before merging.

[Rolandisimo]

Have the same issue currently.

Tested this out on iPhone X (11.3), 6s and 7. Unfortunately, this doesn't fix the issue. Also, no interrupted state was received. Chrome and Safari

[rowild]

Any progress in the merging here?

[tywang2006]

I believe i have the same issue here

[alvov]

Seems that this check will never be true since self.state doesn't really depend on the AudioContext state (apart from initialisation inside HowlerGlobal.prototype._setup) and seems unlikely to ever have the interrupted value.
One way to fix this would be to check the state of AudioContext directly, but the downside is that the code gets more ugly and complicated:

if (self.state === 'running' && self.ctx.state !== 'interrupted' && self._suspendTimer) {
  clearTimeout(self._suspendTimer);
  self._suspendTimer = null;
} else if (self.state === 'suspended' || self.state === 'running' && self.ctx.state === 'interrupted') {

[alvov]

@nanek I reread the discussion and it turns out that's what you already proposed :)

[alvov]

one more thing: in this case inside the play method the condition

if (Howler.state === 'running') {

needs to be rewritten as

if (Howler.state === 'running' && Howler.ctx.state !== 'interrupted') {

otherwise sounds will try to play before the context state is resumed

[alvov]

added this fix to this PR #1106

[hansagames]

@nanek @goldfire any news on this ? something need to be done still ?

[heand]

My issue is similar:
I have a wep app, added to home screen om my ipad. When i press home button on ipad (while a sound is playing with howler) the sounds stops. When I click the web app icon and brings the web page up again, the sound is gone. I then have to clear safari memory to get it working again, any ideas?