Recent Chrome changes to sound autoplay settings

[kripken]

Chrome now blocks audio from automatically playing. We are seeing reports of games and art being broken or audioless because of this.

To mitigate it, perhaps we should

• Document it in the FAQ?
• Try to connect user input to the audio device? See e.g. https://github.com/emscripten-ports/SDL2/issues/57

[kripken]

A good summary of the problems people are encountering: https://twitter.com/mcclure111/status/993627449991688193

[Kaosumaru]

I guess, generic polyfill for AudioContext on chrome could be added, making them 'auto-resumable' when user interacts with website. Not sure why chrome devs don't choose this to be default behavior, would be more backward compatible.

[kripken]

@Kaosumaru yeah, we might want that. Not sure yet though what the best polyfill is. Here is one option:

https://gist.github.com/surma/301c9c377aaf90a3fdae615d4840bb2e

[ruby0x1]

It's worth noting that this change is unacceptable on chrome's behalf, so while a polyfill is helpful, everyone who cares about the web platform should be making their voice heard to chrome as well.

[Beuc]

Any news on getting the audio to work with Chrome's autoplay policy? :)

[Beuc]

For the record my current all-JavaScript work-around:

      // Work-around chromium autoplay policy
      // https://github.com/emscripten-core/emscripten/issues/6511
      function resumeAudio(e) {
      if (typeof Module === 'undefined'
          || typeof Module.SDL2 == 'undefined'
          || typeof Module.SDL2.audioContext == 'undefined')
          return;
      if (Module.SDL2.audioContext.state == 'suspended') {
          Module.SDL2.audioContext.resume();
      }
      if (Module.SDL2.audioContext.state == 'running') {
          document.getElementById('canvas').removeEventListener('click', resumeAudio);
          document.removeEventListener('keydown', resumeAudio);
      }
      }
      document.getElementById('canvas').addEventListener('click', resumeAudio);
      document.addEventListener('keydown', resumeAudio);

[kripken]

@Beuc Is there a good place in our default HTML to add that?

[Beuc]

I put it right after the <canvas> tag in shell.html. However this is somewhat specific to SDL2.

[kripken]

I wonder if we shouldn't add it in the SDL2 port, then. Worth opening a PR or at least an issue to discuss that there.

It would also be good to add more details on this to our docs, like say in the FAQ.

[Beuc]

Haha, there already is (cf. https://github.com/emscripten-ports/SDL2/issues/57 in this item's description) - where you pointed people here for a more library-independent solution ;)

[kripken]

Heh, yeah, I guess this just isn't generic code, and should be in SDL2. I'll comment there, thanks.

[raysan5]

I worked on this issue today for raylib and just implemented a RESUME/SUSPEND button in my shell.html. It's based on the Google proposed solution.

Here it is a working example implementing this shell.

[ghost]

A little late, but I thought I'd chime in anyways. @raysan5 has a good way of enumerating audio contexts that is not specific to SDL2. It may be wise to add something like that to the default shell. I personally prefer to build libraries from source rather than using Emscripten ports.

[kripken]

@fluffrabbit I agree that could be useful. PR would be welcome. One thing to consider though is that it would be good to not emit this if it isn't necessary (to not increase code size of code not using audio), which I'm not sure how to do offhand. If there isn't a good way, it might be added as an option.

[ghost]

@kripken So, shell_minimal_audio.html? Not sure about the internals of Emscripten's build system; my use case mainly requires working code in my own dark theme. I'll work on it as soon as I can.

[Beuc]

Nice. This looks like a small snippet of javascript so I would just add it to shell.html (not "minimal", nor another "audio" variant).

[ghost]

@Beuc The other guy has commit access, so I'll wait for more feedback. However, keeping the code shorter and not duplicating too much sounds good to me. Also, this particular workaround relies on the user either clicking on the canvas or pressing a key. Is this acceptable?

[kripken]

I just commented in the PR - maybe best to move the discussion there? (That's an interesting point, @Beuc , that maybe we should consider adding this to the regular shell but not minimal. However I sort of prefer the PR's current code of a new file as I wrote there.)

@fluffrabbit I think it's unavoidable to require the user clicking on something, as I understand it that's the only way for browsers to allow audio now. So I think it's the right approach.

[raysan5]

@kripken Just a side note on a related issue, for some reason my shell stopped displaying the icons properly (audio on/off) after updating to upstream version 1.39.9, it worked previously with 1.38.42-upstream (sorry for the versions gap). I saw that generated .html (minimized) has the icons mangled (converted to equivalent ASCII chars).

In the meantime I changed shell.html to avoid using the icons... but it's more ugly.

EDIT: I think it could be related in the way shell.html is read for processing... maybe related to Python version change? It worked with python 2.7.13 and now it uses python 3.7.4.

[kripken]

@raysan5 I'm not sure what you mean exactly, but I believe @juj started to minify the HTML in that range of commits, so that sounds like the cause maybe - perhaps something is being minified that should not be?

Perhaps you can provide a testcase to verify, that would help.

[raysan5]

@kripken here some images to better illustrate the issue:

example compiled with 1.38.42-upstream:

example compiled with 1.39.9:

With latest version, icons (4 bytes utf8) are converted to the equivalent ASCII (4 bytes).

EDIT 1: Attaching my shell.html with icons: shell.zip

EDIT 2: I think issue is not about minification process but how the shell.html string is read for processing, it should be read and processed as UTF-8. I guess it's probably converted to ASCII when read.

[kripken]

@raysan5 yeah, I'd guess that is related to the new processing of html files.

To make sure this isn't missed I'd suggest opening a new issue for it.

[raysan5]

@kripken Excuse me for the delay, just opened a new issue for this: https://github.com/emscripten-core/emscripten/issues/10802.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.