IOS 15 block play background web audio api

[rbermudez]

From IOS 15 when the device is blocked stop play any sound generated by howler ctx(web audio api)

[djole1973]

this issue is really annoying. I am not able to use howler on my project.

UC description:
I’m playing sounds with help on howler, one is looped, while others aren’t. When I close browser (tried on Safari and Chrome) sounds stop playing (that’s ok) and when I reopen browser inside few seconds (5 sec for example), it will continue playing sound as it should. But if I wait for 15 seconds or more before reopening browser, then I’m getting no sound even though I’m still getting console logs that sound is playing (when looped or when new sound starts). I can even start sounds inside of console, but I’m getting no output. Nothing is muted and volume is always > 0, when debugging.

[damrbaby]

What are the steps to reproduce this issue?

[djole1973]

UC description:
I’m playing sounds with help on howler, one is looped, while others aren’t. When I close browser (tried on Safari and Chrome) sounds stop playing (that’s ok) and when I reopen browser inside few seconds (5 sec for example), it will continue playing sound as it should. But if I wait for 15 seconds or more before reopening browser, then I’m getting no sound even though I’m still getting console logs that sound is playing (when looped or when new sound starts). I can even start sounds inside of console, but I’m getting no output. Nothing is muted and volume is always > 0, when debugging.

[damrbaby]

@djole1973 I am also having issues with the sound muting on iOS 15 after Safari is in the background or there is an incoming call. Seems to be a regression in iOS 15, and I remember a previous version of iOS had the same bug before it was fixed. iOS 15 seems to have a number of audio regressions (also with WebRTC). The following "hack" resolves the issue for me most of the time, curious if it helps you:

document.addEventListener('touchstart', () => {
  // Hack for iOS 15, which suspends audio when app is in background,
  // and mutes audio when there is an incoming call.
  Howler.ctx.resume()
})

[djole1973]

@damrbaby unfortunately it dos not help at least on the newest version of the iOS 15(Safari and Chrome).

[rbermudez]

To reproduce the error:

Get context Howler.ctx and create an ocillator, run and block the device.

I found workarround in chrome, you can minimize tab.... stay in view show all tabs you have in browser and block the phone and the sound of oscillator still in background, this is working fine but is not a solution of the problem.

[rlyttle]

I'm also experiencing this on iOS 15 - howler fails to play the next song in a playlist if safari is in the background. Can anyone lend some advice as to how they solved this?

[inear]

Have been looking for weeks for a solution to this. I have the same problem in a capacitor-app (or similar bug). All audio gets blocked after 25 seconds in background. Web audio context still says "running", so it's something in a layer above this library. Tried to resume the context on app activation. It's a blocker for the core functionality of our app.

[inear]

I found a solution for when audio is gone when reactivating the app. It will not solve playing audio in background though @rlyttle :(. Just calling Howler.ctx.resume() did not solve it for me since audio context is blocked by the OS when app is inactive for more than 25 seconds or something. This behaviour introduced with iOS 15 I believe and is also the same for any webpage running webaudio in Safari.

Instead I had to call Howler.unload() when app wakes up to close the blocked audio context. The next call (or directly after calling Howler.mute(false/true)) will create a new context for you.

Remember that all currently played instances will be unloaded, so if you have ambient loops going on or storing the instance returned from 'new Howl()' they have to be replaced.

[wengbiancheng]

@inear Howler.unload and recreate Howler.ctx is work.But Some browsers/devices will only allow audio to be played after a user interaction.This approach cannot automatically play audio after returning to the foreground from the background.

[inear]

@wengbiancheng Yes that is unfortunatelly (for us) standard nowadays. But in this case the block is on OS level. So from what I have seen in my tests the audio returns even without an initial user action after the context has been replaced. I even think it's processing the audio file in the background (context reports 'running') so could be good to turn it off manually when putting the app in background mode to save battery. But that is just a guess right now.

[damrbaby]

The webkit bug for this issue is https://bugs.webkit.org/show_bug.cgi?id=237878. Hopefully next iOS release will have the fix included.

[milcktoast]

This is the fix for this issue in PlayCanvas – playcanvas/engine#4062