New Chrome policy for autoplay

#1

Hi,
we are investigating about a problem with Chrome: it looks like, starting from April 2018, a new policy for inhibiting autoplay of multimedia content has been introduced. The consequence is that in certain conditions audio is disabled, maybe because of unusual URL detection.
I knew Chrome was going to block autoplay for clips, but not for applications…

Anyone knows/encountered this problem?

#2

Well, yesterday I compile one game and have some issue with audio, but wasn’t sure it’s what’s about.
I found this (http://www.html5gamedevs.com/topic/37399-games-sounds-suddenly-stopped-playing-and-browser-console-says-the-audiocontext-was-not-allowed-to-start/) I have same problem like this.
Is this the same issue?

#3

Yes, this should be the same problem.

#4

Any idea where to fix it as suggested on previous link?

sound.context.resume();

Lime or howler?

#5

Eh, I see HTML5AudioContex in Lime and WebAudioContext in Howler… @singmajesty ?

We need to resume the audio context consequently to an interaction, but… what kind of interaction (a mouse event?), and… where can I find that context to resume?

#6

Is there anything on https://github.com/goldfire/howler.js? A newer commit, or a pull request?

Lime 6.3 (used by OpenFL 8) updated to Howler.js 2.0.9

#7

Yes it is. Updated just 5 hours ago. I update it to newer version and problem is solved. There are still warnings in chrome but sound is playing.

#8

Good, I will update and let you know.

#9

I upgraded to the new Openfl/Lime versions, but now I have new problems with masks, some event detection etc…:cold_sweat:

#10

I updated only howler.js and for now, everything is OK. :slight_smile:

#11

Seems to work for me too.

#12

Sorry to bother you with something that should be really simple but… how do you only update howler.js?

#13

Download from git (you have link above) and replace it in haxelib/lime/dependencies/

1 Like
#14

Does the 2.0.9 version (used in Lime 6.3.0) fix it, or do we need a newer version?

#15

I’m still in lime 6.2.0 and newer howler.js 2.0.10 fix the problem.

#16

I’ve just update to Lime 6.3.0 and openFl 8.0.0 and it 's OK.

1 Like
#17

I have copied the howler.min.js file from Lime 6.3.0 lib/dependencies folder to the same folder of Lime 6.2.0.
I can’t use Openfl 8 + Lime 6.3.0 because of a problem with filters.

#18

I noticed a very annoying problem introduced by the new Chrome policy: when my apps start I play certain sounds (like music) by default, and before the new Chrome everything was ok.

Now sounds don’t start until I interact in some way, and when I do they starts, but the sounds with a loop can’t be stopped anymore, unless I force them to start AFTER the AudioContext has been resumed by the initial interaction. Could it be that these sound effects are initialized (even if they can’t be heard) in a different AudioContext, and when context is resumed the correct reference to them is lost and can’t be controlled/stopped anymore?

#19

It seems that autoplay without user interaction works depending on the server (it works on my server but not in my client server). So I would like to add a button only in this case so I could keep autoplay on my server.

To detect whether browser will require user interaction to play audio, you can check the state of the AudioContext after you’ve created it. If you are allowed to play, it should immediately switch to running . Otherwise it will be suspended . If you listen to the statechange event, you can detect changes asynchronously.
https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio

Is it possible to check the state of the AudioContext so I could know if the sound is blocked?

#20

It’s not a server thing. It’s a chrome version thing.

If chrome (or safari, for that matter) detects that an audio sound begins playing due to an user input then it unlocks the audio.
Browsers tell apart real user inputs from progamatically simulated inputs. We can’t fake it. Said inputs include things like: mouse, keyboard or the order to refresh the webpage.

howler (openfl html5 sound backend) has a protection in place that forces a mute sound to play whenever the user clicks anywhere on the screen thus unlocking the audio.

Finally an answer to your question: https://github.com/goldfire/howler.js/issues/1149