Mobile Safari sound muted after incoming call

[selirion04]

Steps to reproduce:

1. Run page with soundjs used
2. Answer incoming call
3. Reset call
4. All sounds play become silenced

At least Safari 10.0, iOS 10.1.1, 10.2.1, both in browser and webapp mode
Looks like operating system mutes page in some way, but forgot to restore it after call
upd1: notice that webkitAudioContext.state stuck as "interrupted" after call
upd2: colud be reproduced right on http://www.createjs.com/soundjs

[selirion04]

Just need to call s.context.resume() in right place of WebAudioPlugin. I don't know where it should be logically, just for test I place it to unlock method and call it on every touchend.

	s._unlock = function() {
		if (s.context.state == "running") { return; }
		if (s.context.state == "interrupted")
			s.context.resume();

		s.playEmptySound();
		if (s.context.state == "running") {
			//document.removeEventListener("mousedown", s._unlock, true);
			//document.removeEventListener("touchend", s._unlock, true);
			s._unlocked = true;
		}
	};

[lannymcnie]

Thanks! This was already on our short list to implement. Appreciate the contribution - feel free to submit a pull request.

[k8w]

@lannymcnie It seems this still not resolved?

[gSkinner-Blair]

So, we looked into this, and here are our main findings. There are two FOL issues that make a proper solution impossible at this time:

1: No events from iOS phone calls. We tested with blur, focus, pageshow, and visibilitychange, and none of these events are fired when a phone call begins or ends.

2: Audio context doesn't detect interruptions past the first: We tried resuming the audio context from its interrupted state, and this worked once per page. After that, the Audio Context state remained as "running", even though no sound was playing and no new sounds could be played. Suspending and resuming the context manually when it is in this state fixed the issue.

However... since we can't get an event from the phone to tell us when a call occurred, but the context claims that all is well, the only thing we could do to "fix" this on a library level would be to manually suspend and resume the audio context on either every user interaction or on a timer. Neither is suitable, because a suspend/resume of the audio context causes an audible break in sound playback.

We're considering adding a permanent touch event to check to see if the context is "interrupted", and if so, resume it (similar to the solution you provided). This would be an imperfect (and rather heavy handed) fix, though, and would still break if the page was interrupted more than once. But, due to the reasons above, this seems to be the best we could do for now.

[MariaRalevaMWS]

Any update on this one?

[gSkinner-Blair]

Because of the destructive nature of this workaround, we won't be implementing it into the library itself. This issue unfortunately boils down to inconsistent and/or missing behavior from the iOS device itself - and until such time as those features are fixed/implemented, there isn't likely to be any movement on this issue.

[Maqsyo]

So we have the problem now, that this error occurs if you switch between tabs or if you minimize safari, open a different app and open safari again. The event for visibilitychange is triggered.
We have tested it with Howler and SoundJS and everywhere occurs the exact same behavior - the sound is interrupted.

It would be great if you could rethink your decicion and test these behavior on ios13

[JustFly1984]

I have killed 3 days on this. I have not experienced issues with call interruption, but if I lock an Iphone and unlock it, I have issues with webkitAudioContext.status === 'interrupted', and there is nothing I can do to change that, only reload the page, which is not the way to go.