Work when AudioContext is not supported

[comods]

Many online games use emscripten to run in the browser, but most will crash if AudioContext is not supported.

This includes most Unity and SDL games.

These crashes are preventable if emscripten would have audio playback be a no-op when AudioContext is not supported (and still init). For programs/emscripten using AudioContext for compute, a shim/polyfill of either AudioContext or OfflineAudioContext would work.

Example rust shim: https://crates.io/crates/web-audio-api
Example node.js shim: https://github.com/ircam-ismm/node-web-audio-api

Example SDL reproduce error: Could not initialize SDL2, No audio context available
DustinBrett/daedalOS#500

Example Unity reproduce error: Web Audio API is not supported in this browser
https://purejamgames.itch.io/artificer

The easiest way to test this is to use the Tor browser or in about:config set dom.webaudio.enabled to false.

This is NOT a crash you can expect every downstream Dev to manually fix.

[sbc100]

Are there browsers out there that don't support AudioContext? According to https://developer.mozilla.org/en-US/docs/Web/API/AudioContext it seems that all browsers have supported it for a long time. Is disabling webaudio something that is common among users? Why would a user disable an API like that? If an API is part of the web platform doesn't it seem reasonable to assume that it exists?

[comods]

Thank you for looking into this. Yes, there are browsers out there that do not support AudioContext or have it disabled by default. The user is not disabling it in these situations, and with Android Tor, users cannot access about:config to reenable it (if it would even be there). Browsers like Tor and Brave disable features for security, privacy, and rarely to also hinder hidden bitcoin miners (which steals compute).

It is not reasonable to assume an optional API feature exists, that is why modern browser APIs started to be designed with easy feature detection. I remember the hellscape of using browser detection and it not being reliable. There is at least one widely used browser, which the presented assumption does not hold, causing no graceful fallback but instead crashing. I was hoping emscripten, frameworks, and mobile game engines, could fix this bug because it effects many of your down stream developers and users. These sites should just work without audio.

[sbc100]

Can you point to any documentation about the optional nature of AudioContext? IIUC these APIs are not optional and are part of the platform. If we have to start feature detecting core APIs like this I worry that it will lead to a lot of unnecessary complexity. Perhaps there are some docs that are part of the Tor project that describe the rationale here. How to they expect web sites to work if they disable core features like this?

[kripken]

I think it might be reasonable to support this as an option. (An option, since doing it by default would add too much code size for users that don't need it, and also some users might not want it - e.g. an audio mixer app would prefer to crash than silently not work.)

We do have something similar for other WebAPIs, "headless mode":

• https://github.com/emscripten-core/emscripten/blob/main/src/headless.js
• https://github.com/emscripten-core/emscripten/blob/main/src/headlessCanvas.js

Those do not check if the feature exists already, though, but they do show how to fake an API from JS. Something similar could be done from JS for AudioContext.

That would take some work, though, and I don't see an existing project that has that among the links here. But I think it would make sense to welcome a contribution that looked like

• A shim for AudioContext. It checks if the class exists, and if not, it defines the fake shim. I.e., it is a polyfill, but doesn't provide the actual audio-emitting part. It just warns in the console + avoids the app crashing.
• Rather than a new option, this could just be a JS file that is included in emscripten and users can add it with --pre-js (to avoid adding yet another option). We could perhaps have a directory src/ for such things, which would be aligned with the ideas in Replace ENVIRONMENT_* logic with Web default + polyfills? #12203

[sbc100]

I think OP is asking for this by default, since its unlikely that app developers will go out of their way to support Tor browser explicitly the hope is that emscripten (by default) will just work in absence of AudioContext.

I'm not sure offering a optional polyfill is any better than that what folks can do today with --pre-js=SomeAudioContextPolyfill.js

[comods]

I think OP is asking for this by default, since its unlikely that app developers will go out of their way to support Tor browser explicitly the hope is that emscripten (by default) will just work in absence of AudioContext.

• Yes, a tiny default no-op, the website or game acts muted but still loads (like disabled <video> tags do not crash).
• Websites using it for compute (like audio mixers) either: most already do not work (no worse), some already are feature detecting (no change), or a few are incorrectly try/catching a crash (and would also need to feature detect).

Boring Tor info:

• Fingerprinting: https://gitlab.torproject.org/legacy/trac/-/issues/13017
• Tor, and Firefox which it is based on, expects feature detection https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Testing/Feature_detection instead of crashing.

@sbc100 I want to be helpful, but I cannot spend more time on this, the following is just the obvious, and I do not have time to edit it better. I mean no offense anywhere in it.

---

I feel you, that the web has rough edges to navigate for browsers, frameworks, websites, and users. Since emscripten is the main framework to compile non-web codebases to the web, fixes to and safeguards in emscripten save thousands of man hours from your downstream devs and users. It is commendable what emscripten has already accomplished in cross-platform compatibility.

The web strives to have graceful fallbacks, so it can be beneficial to more people. Major-Browsers disable standard APIs that are a security risk. So do Minor-Browsers! Many browsers have intentionally not supported, partly or wholly, AudioContext over the years, including Tor, LibreWolf, and Brave (partly & may eventually block in private-mode: brave/brave-browser#16185). Mozilla-Firefox making 86% of its revenue in deals for tracking user information, shows their conflict of interest, but they do keep a negative list of APIs that are too extreme even for them: https://mozilla.github.io/standards-positions . So what these other browsers are doing is not out of the ordinary, it just is not being done by the Oligopoly.

Browsers are pragmatically required to be different then the standards, because most (and popular) websites refuse to follow the standards, like the "Do Not Track" feature. This has always been the case for the web.

w3.org/TR/webaudio-1.0 is only a W3C "recommendation" and no one fully follows the standard (see: https://wpt.fyi/results/webaudio?label=master&label=stable&aligned).

Organizations such as W3C and the ISO are consortiums made up of government agencies and industry and professional bodies. The standards which they formulate may be necessary for specific kinds of certification, but very often, they function as guidelines, rather than officially sanctioned and enforced requirements.

Vendors and developers are encouraged to comply with such standards, but compliance is voluntary, and they may choose to include features which are non-compliant.

• https://saucelabs.com/resources/blog/open-standards-dont-mean-standardized-browsers

AudioContext working is not required any more than <video> tags are required to play videos. The web is built to do best effort, even if the user is blind. A website shouldn't completely fail to load because Audio is muted.

Tracking Vulnerabilities:

• AudioContext trackers are for sale: https://fingerprint.com/blog/audio-fingerprinting
• The "Audio" part of: Brave still exposes too much fingerprintable information brave/brave-browser#35646

[sbc100]

The the record I believe "recommendation" is the highest level in the W3C, its just the term they used for a standard that is complete, and there is no further step after that.

It was pointed out to be the Brave has a way to disable in the fingerprinting without disabling the API: https://fingerprint.com/blog/audio-fingerprinting/#brave. Specifically they have 3 levels the most strict of which is: The sound wave is replaced with a pseudo-random sequence. This seems like a good approach that doesn't break websites.

[kripken]

Yes, a tiny default no-op

I would strongly object to a change in default here, I'm afraid. As I mentioned before, some apps are audio-focused, like a sound mixer. For them to claim to work when they are silent/broken would be a serious regression for them. Even if most apps could tolerate silence instead of audio, that needs to be decided by the developer of the app.

In other words, yes, feature detection makes sense, but only the app can decide what the proper response is to the lack of a feature, not Emscripten. (And a specific way an app can do this, e.g. when getting Could not initialize SDL2, No audio context available is to init SDL2 without audio, if audio is not available. Similarly to how apps can handle the lack of say WebGL2 and using WebGL1 instead, if 1 is enough for them, maybe with lower quality.)

Otherwise I agree with all the rest here. There are definitely valid reasons to want this, and an easy way to do this for all Emscripten users would be good to have.