[rdoupe]

Refs obs-rust/obs-studio#2328 (upstream obsproject/obs-studio#10586)

What and why

When Chromium's audio service process dies (a crash, a device change, or on Windows the audio hang monitor ending it after 3 minutes), every running AudioContext fires error and is suspended. Chromium never resumes it, so a browser source that plays through WebAudio (alert boxes) stays silent until the page reloads or "Control audio via OBS" is toggled. Pages that use new Audio() recover by themselves.

BrowserApp::OnContextCreated now evaluates a small script in every frame, before the page's own scripts, next to the obsstudio bindings:

• AudioContext (and webkitAudioContext where present) is wrapped in a Proxy, so pages still see the native constructor, prototype, name, length, property descriptors and [native code]; instanceof, subclassing and ctx.constructor === AudioContext behave as before.
• On a context's error event, a context the page wanted running is resumed. One the page suspended itself (suspend() is wrapped, the same way, to track that) is left alone.
• OfflineAudioContext is untouched.
• The script only uses functions it captured before the page ran, so pages that replace or freeze Reflect, Promise.prototype.then, EventTarget.prototype.addEventListener, WeakMap, Function.prototype.call, setTimeout or AudioContext.prototype.resume do not break it.
• The first resume waits 3 s. With "Control audio via OBS", CEF keeps the capture stream of the dead audio service until the page has been silent for 2 s (kRecentlyAudibleTimeout in AlloyBrowserHostImpl), and only starts a new one after that; a context resumed sooner plays into the dead stream for as long as it stays audible. Later attempts retry every 1 to 2 s, and a new error starts a new chain.

RED → GREEN

• RED commit test: WebAudio after the audio service dies (9e1be0d): tests/audio_recovery.py plays a local WebAudio tone through real browser sources with reroute_audio, SIGKILLs only this run's audio service process (found through the harness's process tree) and requires packets in the 5th second after the kill. On master all 4 scenarios fail with 0 packets: plain, repeated (3 kills, on a page that replaces and freezes globals), page-suspend, two-sources.
• GREEN Resume WebAudio after the audio service dies (654d2b9): 4 of 4 pass; audio is back 3.1 to 3.2 s after every kill. In page-suspend the context the page suspended stays suspended; plain also checks that the page sees an unchanged AudioContext (passes before and after).
• Runs: Linux, CEF 8078, isolated (loopback-only network namespace, private Xvfb and dbus, fresh HOME, no audio server). clang-format 22.1.3 clean.
• CI: the test is not run in CI. Like the other tests/ harnesses it needs a CEF build and an X display, and it kills a Chromium process. See tests/README.md for the command.

Notes

• Verified on Linux only. The script is platform independent; the 3 s delay is tied to CEF's 2 s audible timeout, which is the same on all platforms.
• Sources without "Control audio via OBS" get the same resume (there is no capture stream to wait for; the delay is harmless there).

[zackees]

Coordinator review: approved.

• The injected script uses only functions it captured before the page runs (Reflect, Promise#then, addEventListener, WeakMap/Map methods, setTimeout), so pages that replace or freeze globals can't break it. Object spread in the descriptor copies can't be hooked by the page either.
• A suspend the page started itself turns off the resume through wanted/pendingSuspends; closed ends a chain; each error starts a new chain and ends the old one. That covers the repeated-kill case.
• constructor and suspend are replaced only when the descriptor still holds the native value, and aliases share one proxy through wrapped. instanceof and identity hold.
• An Eval failure leaves the page with the native AudioContext. RED → GREEN is documented, and the harness lives in tests/ like the others; it can't run in CI (needs CEF and X).