When attempting to play music I receive soundmanager2.js:3094 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()
Opened this issue · 6 comments
This was tested with Chrome Version 65.0.3325.181
Works fine without forceUseGlobalHTML5Audio.
However, we are having issues with Safari, where if soundmanager is open in a tab that is not selected, then it will go to sleep.
I believe it was noted in the release notes for SM 2015 that this option forceUseGlobablHTML5Audio is supposed to solve that issue. However, it now causes chrome to get
soundmanager2.js:3094 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()
This occurs when trying to play any music.
I'm attempting to use the latest release SM 2017 when the above error occurs.
Thank you!
FMadden
Essentially, we make a call to soundmanager.play(). The sound begins playing and then in soundmanager2.js line 3040 we have the following.
/**
* "First things first, I, Poppa..." (reset the previous state of the old sound, if playing)
* Fixes case with devices that can only play one sound at a time
* Otherwise, other sounds in mid-play will be terminated without warning and in a stuck state
*/
if (useGlobalHTML5Audio) {
if (dURL === decodeURI(lastGlobalHTML5URL)) {
// global HTML5 audio: re-use of URL
sameURL = true;
}
} else if (dURL === decodeURI(lastURL)) {
// options URL is the same as the "last" URL, and we used (loaded) it
sameURL = true;
}
if (a) {
if (a._s) {
if (useGlobalHTML5Audio) {
if (a._s && a._s.playState && !sameURL) {
// global HTML5 audio case, and loading a new URL. stop the currently-playing one.
a._s.stop();
}
That last a._s.stop(); is called after the music has already started to play, and is then interrupted.
@maddenf Thanks for the report. The logic in play() gets a bit messy and these days, the stop() call can probably be dropped in favour of simply changing the URL and then calling play().
However, the useGlobalHTML5Audio stuff was introduced to deal with mobile devices, particularly iOS which were initially very restrictive in that only one Audio() object could actively be playing at a time.
These days, browsers are now becoming more restrictive about auto-play. Safari and Chrome both block play if they didn't originate from a user action.
I'll need to review the pause() stuff and see what's going on there in the background Safari tab case. 🤔
@maddenf Does the SM2 homepage demo, the "bar ui" player under the turntable loop, work OK for you in desktop Safari? If I load that up and click the play button, it seems to advance through the playlist as I'd expect.
The useGlobalHTML5Audio option is suggested only for mobile, given their history of being more restrictive. I don't recommend using useGlobalHTML5Audio in a desktop browser.
Let me know if the SM2 demo mentioned doesn't work for you, and versions of OS X + Safari you're seeing this on.
Hi it seems latest chrome update has restricted auto play by defualt:
https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
User interaction is required before audio can be played automatically.
+1
I had this issue. A workaround is to check the readyState property of the audio element before calling sound.pause().
function pause() {
if (sound._a.readyState < 3) return;
sound.pause();
}