Chrome On The Dev Branch (version 66) May Block Audio For Unity WebGL

So I fired up one of our applications today in chrome (version 66) and mysteriously there was no audio. The applications worked fine in other browsers and sites like youtube played audio fine in Chrome. So what gives? Well I checked the console and…

That links to this page here: Política de reprodução automática no Chrome  |  Blog  |  Chrome for Developers

I guess there’s no way around this huh? This is probably “by design” according to Chrome. Is there a way that unity could let us “restart” the AudioContext as a callback to an event listener? I really don’t know how we will get around this issue…

We can repro that inhouse and will take a look. Will post issue tracker link as soon as I get the number.

1 Like

Do you have a workaround or a fixe ready for the 2018.x version?
It look that chrome will release the version 66 in a week :
So what we do if the audio do not work?
Thank you

There is currently no workaround, but we’re still looking into it.

Like the google update is planned for the next week and that i doubt that like per magic you will release a patch for that, can you tell us if a workaround is possible on the Audio.js file present on Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\lib ?

Thank you.

Setting to false should get you going again in Chrome66.

Let me know if that helps for your project. We're still looking into a fix from our end.


Sorry, but this solution do not help.

After a few test, it seem that :

  • If you click the page where the game is loading, then we do not get the warning message in the console and the audio should work.

  • If you do not click the page (just do not click the page or move your mouse till loading is complete), then we get the warning message in the console and the audio should not work.

Tested on chrome canary 67.0.3394.0
The both build do not contain any audio.

Link with captureAllKeyboardInput set to true :
Link with captureAllKeyboardInput set to false :

The result is the same in the both build. It’s maybe a window focus problem?
If the user do not interact with the page where the game is loading, then chrome shut down the audio and we have no way to get it back (we have to refresh the page).

Why you do not add a preloader (like on most video player or 3d viewer) that cover the content of the game and wait after a click on the game view in order to init the _JS_Sound_Init() (info here )

For me, it’s a critical issue as chrome is used by 80% of our players.

This problem has been reported 2 months ago by kognito and we are at the same point. I’m sorry, but the unity team are doing something wrong somewhere in term of communication.

The unity staff said working or been in contact with the google team but google have annouced this audio change in September 2017 and we are still talking about that…

Thank you

We can confirm that the suggested workaround did not fix the problem for us, either. Is there some additional requirement?

There are no additional requirements for it. We are still looking into a solution but can't promise anything at this point.

Are you serious? I think that you need to stop drinking coffee and start working.

You are a complet team working on the webgl stuff and no one of you are able to find a workaround before an internal fixe?

It’s an april fool or what???

As simple hobbyist, it take me 2 hours yesterday to fixe this issue and nothing in 2 months for you??

Can i generate an invoice to Unity because i have lost 2 hours with my wife and son because of some lazy guys?

It’s really unbelievable to see that, really crazy …

Sorry for this message, but that webgl story with unity start to piss me off.

There you go …

Is that hard?

1 Like

First of all apologies for the inconvenience. This issue clearly fell through the cracks.

Adding a button per-se is not hard but this is probably something you want to customize based on your content anyway. Ideally, you have your own WebGL template which implements such flow.

Having said that we understand this is a problem, especially for first-time users, and we are going to provide a solution as soon as possible.

could you try to the following?

  • make a development build
  • open the generated .framework.unityweb
  • replace _JS_Sound_Init() with:
function _JS_Sound_Init() {
  try {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    WEBAudio.audioContext = new AudioContext();
    var tryToResumeAudioContext = function() {
      if (WEBAudio.audioContext.state === 'suspended')
      else {
    var resumeInterval = setInterval(tryToResumeAudioContext, 400);
    WEBAudio.audioWebEnabled = 1;
  } catch (e) {
    alert("Web Audio API is not supported in this browser");

with the above code, audio should start as soon as the user interacts with the page. If that works you can patch your Unity installation by changing the source code in PlaybackEngines/WebGLSupport/BuildTools/lib/Audio.js

Ideally, we should also display a message to the user.


One more note, this workaround is an alternative to a playButton-style solution previously suggested, which we are also investigating.

It works! A little brute force, but it works! :smile:

Can we update the live games(non development) without needing to rebuild from unity? We have a lot of games with web license bought from the developers(ofc without source code), so wanted to know if we can have this workaround without the needing of extra “Play” button ahead. @Marco-Trivellato

Yes, you still can patch .framework.unityweb. Non-dev version is minified version of the development one, so it’s slightly harder to find that code.

FYI the chrome release is now live. Thanks again @Marco-Trivellato for the workaround. Looking forward to seeing it in a patch release! :stuck_out_tongue:

Thanks to @jura_z :slight_smile:

Yes, this will make it into a patch release in the next few weeks.

Is this in a patch release yet?

we are being overwhelmed with the number of support tickets coming in right now.

No yet. We are finishing to work on a couple of other Chrome-WebAudio fixes. We will back-port them all together.

In the meantime, you can patch your Audio.js file so you don’t need to wait for us.