Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent Chrome changes to sound autoplay settings #6511

Open
kripken opened this Issue May 7, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@kripken
Copy link
Member

kripken commented May 7, 2018

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

@kripken

This comment has been minimized.

Copy link
Member Author

kripken commented May 8, 2018

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

@Kaosumaru

This comment has been minimized.

Copy link

Kaosumaru commented May 8, 2018

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

This comment has been minimized.

Copy link
Member Author

kripken commented May 8, 2018

@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

@underscorediscovery

This comment has been minimized.

Copy link

underscorediscovery commented May 12, 2018

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.

Akaricchi added a commit to taisei-project/taisei that referenced this issue Mar 6, 2019

Akaricchi added a commit to taisei-project/taisei that referenced this issue Mar 6, 2019

Akaricchi added a commit to taisei-project/taisei that referenced this issue Mar 9, 2019

Emscripten compatibility (#161)
* Major refactoring of the main loop(s) and control flow (WIP)

run_at_fps() is gone 🦀

Instead of nested blocking event loops, there is now an eventloop API
that manages an explicit stack of scenes. This makes Taisei a lot more
portable to async environments where spinning a loop forever without
yielding control simply is not an option, and that is the entire point
of this change.

A prime example of such an environment is the Web (via emscripten).
Taisei was able to run there through a terrible hack: inserting
emscripten_sleep calls into the loop, which would yield to the browser.
This has several major drawbacks: first of all, every function that
could possibly call emscripten_sleep must be compiled into a special
kind of bytecode, which then has to be interpreted at runtime, *much*
slower than JITed WebAssembly. And that includes *everything* down the
call stack, too! For more information, see
https://emscripten.org/docs/porting/emterpreter.html

Even though that method worked well enough for experimenting, despite
suboptimal performance, there is another obvious drawback:
emscripten_sleep is implemented via setTimeout(), which can be very
imprecise and is generally not reliable for fluid animation. Browsers
actually have an API specifically for that use case:
window.requestAnimationFrame(), but Taisei's original blocking control
flow style is simply not compatible with it. Emscripten exposes this API
with its emscripten_set_main_loop(), which the eventloop backend now
uses on that platform.

Unfortunately, C is still C, with no fancy closures or coroutines.
With blocking calls into menu/scene loops gone, the control flow is
reimplemented via so-called (pun intended) "call chains". That is
basically an euphemism for callback hell. With manual memory management
and zero type-safety. Not that the menu system wasn't shitty enough
already. I'll just keep telling myself that this is all temporary and
will be replaced with scripts in v1.4.

* improve build system for emscripten + various fixes

* squish menu bugs

* improve emscripten event loop; disable EMULATE_FUNCTION_POINTER_CASTS

Note that stock freetype does not work without
EMULATE_FUNCTION_POINTER_CASTS; use a patched version from the
"emscripten" branch here:

    https://github.com/taisei-project/freetype2/tree/emscripten

* Enable -Wcast-function-type

Calling functions through incompatible pointers is nasal demons and
doesn't work in WASM.

* webgl: workaround a crash on some browsers

* emscripten improvements:

    * Persist state (config, progress, replays, ...) in local IndexDB
    * Simpler HTML shell (temporary)
    * Enable more optimizations

* fix build if validate_glsl=false

* emscripten: improve asset packaging, with local cache

Note that even though there are rules to build audio bundles, audio
does *not* work yet. It looks like SDL2_mixer can not work without
threads, which is a problem. Yet another reason to write an OpenAL
backend - emscripten supports that natively.

* emscripten: customize the html shell

* emscripten: force "show log" checkbox unchecked initially

* emscripten: remove quit shortcut from main menu (since there's no quit)

* emscripten: log area fixes

* emscripten/webgl: workaround for fullscreen viewport issue

* emscripten: implement frameskip

* emscripter: improve framerate limiter

* align List to at least 8 bytes (shut up warnings)

* fix non-emscripten builds

* improve fullscreen handling, mainly for emscripten

* Workaround to make audio work in chromium

emscripten-core/emscripten#6511

* emscripten: better vsync handling; enable vsync & disable fxaa by default
@Beuc

This comment has been minimized.

Copy link
Contributor

Beuc commented Apr 11, 2019

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

@Beuc

This comment has been minimized.

Copy link
Contributor

Beuc commented Apr 14, 2019

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

This comment has been minimized.

Copy link
Member Author

kripken commented Apr 18, 2019

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

@Beuc

This comment has been minimized.

Copy link
Contributor

Beuc commented Apr 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.