howler.js icon indicating copy to clipboard operation
howler.js copied to clipboard

Audio Looping not working in Android Chrome when browser goes to background

Open aareeph opened this issue 5 years ago • 6 comments

Hi, I am trying to play an audio on loop and it's working fine everywhere except when the Android Chrome browser goes to background or mobile screen is locked. Audio doesn't restart but as soon as browser window comes to foreground the looping sound continues to play.

Anyone else experiencing the same behavior?

Thanks!

aareeph avatar Nov 20 '19 10:11 aareeph

I have the same problem. Does anyone know a solution?

dmytro-rudenko avatar Dec 30 '19 18:12 dmytro-rudenko

@Dmitry-Rudenko for this reason alone I had to remove the Howler library from my project and used native HTML5 Audio tag

aareeph avatar Jan 09 '20 05:01 aareeph

@aareeph I too. So far this is the only solution.

dmytro-rudenko avatar Jan 13 '20 08:01 dmytro-rudenko

Unfortunately I have the same problem:

On an Andorid device, a Fairphone 3+ I use the looping feature with the explicit use of the HTML5 "fallback". Looping works fine as long as the screen is on.

After screen timeout (screen goes dark), it continues to play until the end, but does not loop anymore.

This differs from the behviour, when I use an HTML5 audio element directly. This would loop forever, which is what I need in my scenario.

@goldfire Could you look at this?

Does this differ from the WebAudioAPI? Would the flag "autoSuspend" to false help here (although, per the does, is intented for WebAudio API only? Could you expose the HTML5 audio element, so that we could use the loop feature directly from there?

suterma avatar Jan 04 '22 16:01 suterma

I have looked into the code, and howler does not use the HTML5 audio element's loop feature. Instead it maintains an internal loop flag and re-issues a play command at the track's end. See

https://github.com/goldfire/howler.js/blob/f128f9d975c2bc87610eac0eab5239980b3a4dda/src/howler.core.js#L1969

Now this might be useful is some cases, probably with sprites, but has the above mentioned drawback.

A solution might be, to directly use the loop feature IF

  • the playback method is actually HTML5
  • the looped part is not sprite, but the whole track.

This would help me and the OP out. For howler, this might be a far-fetched edge case, and addressing it would be a bit to much involved?

suterma avatar Jan 04 '22 16:01 suterma

Interestingly, today, It worked on both Firefox and the Brave browser (which is Chromium based), on the same FP3+ device as mentioned earlier. However, with Chrome, it did not work, still.

The loop still is executed right after once the screen is unlocked again.

suterma avatar Jan 19 '22 20:01 suterma