The audio stack we ship is whatever the packing machine had installed

pack-dist copies OpenAL32.dll out of the build machine's SysWOW64. That is
the same shape as the d3dx9_43 bug found this week - a runtime dependency
the dev box quietly satisfies - except here it does not fail outright, it
just means the audio implementation a customer gets is decided by whatever
was installed on the machine that happened to pack the release.

And what that machine has is Creative's 2009 stack. OpenAL32.dll v6.14 is
only a router; the real implementation is wrap_oal.dll v2.2.0.5 beside it,
with oalinst.exe bundled as a 791KB fallback installer. The router exists
so several vendors' OpenAL implementations could coexist on one machine,
which stopped being a thing about fifteen years ago.

Bundling OpenAL Soft instead is the fix: vendored like steam_api.dll is,
not lifted from the system. wrap_oal.dll and oalinst.exe go, dist gets
1.2MB smaller, and the same implementation runs on Windows and Linux -
which matters more than the size, because it means an audio bug reproduces
on both instead of being someone's Windows. It also removes the only
__declspec in the tree, which lives in Creative's al.h.

Only al.h, alc.h and efx.h are ever included, eleven sites across ten
files. efx-creative.h, EFX-Util.h and xram.h are vendored and referenced by
nothing, so they simply go.

Filed as a near-term item rather than a port phase, and written up in both
docs, because it stands on its own: OpenAL is not what makes the game hard
to move. The API is cross-platform and all ninety-one call sites compile
unchanged against libopenal - it is the reason audio barely appears in the
port plan at all. Dropping OpenAL itself would mean reimplementing EFX
reverb and rewriting ninety-one working call sites to remove a dependency
that is not in the way. The note says so, so nobody talks themselves into
it later.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/RP412-LINUX.md

@@ -121,6 +121,13 @@ is genuinely required; Steam installs it as a depot prerequisite.)
   calls (texture format conversion at load — shipping textures in device format
   skips it) and 150 `OptimizeInplace` calls (the `.X` loader; baking meshes to
   an in-house format at build time would retire the `.X` dependency).
+- **Swap Creative's OpenAL for OpenAL Soft** — the same shape of bug as the
+  `d3dx9_43.dll` one above: `pack-dist.ps1` copies `OpenAL32.dll` out of the
+  build machine's `SysWOW64`, and what ships is Creative's 2009 router +
+  `wrap_oal.dll` + a 791 KB installer. Bundling OpenAL Soft instead means the
+  same implementation runs on Windows and Linux. Scoped in
+  [RP412-UNIFIED-BUILD.md](RP412-UNIFIED-BUILD.md) — near-term, independent of
+  the port.
 - **The native port** is scoped separately in
   [RP412-UNIFIED-BUILD.md](RP412-UNIFIED-BUILD.md) (proposal, not scheduled).
   Its survey supersedes several figures in §1 and §3 below — notably that

docs/RP412-UNIFIED-BUILD.md

@@ -12,6 +12,61 @@ tree producing a native binary on both platforms — and exists because the
 question "what would that actually take?" deserved a real answer rather than a
 guess.
 
+## Do this one now, independent of the plan
+
+**Swap Creative's OpenAL for OpenAL Soft.** This is not port work. It is the
+same shape of problem as the `d3dx9_43.dll` bug found on 2026-08-14 — a runtime
+dependency the build machine quietly satisfies — and it is worth fixing on
+Windows whether or not any of the phases below ever run.
+
+What ships today is Creative's 2009-era stack: `OpenAL32.dll` v6.14 is only a
+**router** that dispatches to `wrap_oal.dll` v2.2.0.5 (the real implementation),
+with `oalinst.exe` (791 KB) bundled as a fallback installer. Worse,
+`pack-dist.ps1` copies `OpenAL32.dll` **out of the build machine's `SysWOW64`**,
+so the audio stack that ships is whatever happened to be installed on the
+machine that packed it. The router architecture exists so multiple vendors'
+implementations could coexist, which stopped mattering fifteen years ago.
+
+The work:
+
+- Bundle **OpenAL Soft** — ship its `soft_oal.dll` renamed to `OpenAL32.dll`,
+  vendored in the repo like `steam_api.dll` is, not copied from the system.
+- Delete `wrap_oal.dll` and `oalinst.exe` from `dist\` and from
+  `pack-dist.ps1`; drop the "copy from `SysWOW64` if present" branch. Net
+  ~1.2 MB smaller.
+- Replace the vendored Creative headers in `MUNGA_L4\openal\` with OpenAL
+  Soft's. Only `al.h`, `alc.h` and `efx.h` are ever included (11 sites across
+  10 files) — `efx-creative.h`, `EFX-Util.h` and `xram.h` are referenced by
+  **nothing** and can simply go.
+- Replace `lib\OpenAL32.lib` with OpenAL Soft's import library.
+
+Why it is worth doing on its own merits:
+
+- **The same implementation then runs on both platforms**, since Linux distros
+  ship OpenAL Soft as `libopenal.so`. Audio bugs reproduce across platforms
+  instead of being "works on my Windows."
+- It removes the **only `__declspec` in the entire tree**, which lives in
+  Creative's `al.h`.
+- It ends the silent dependency on the packing machine's system state.
+
+Licensing is unremarkable: OpenAL Soft is LGPL, and shipping it as a separate,
+dynamically-linked DLL is the standard compliant arrangement for a closed-source
+game.
+
+*Verify: audio plays in a mission; EFX reverb still engages (`EFX_Available()`
+in `L4AUDEFX.cpp` — it probes `ALC_EXT_EFX` and degrades silently, so confirm
+the log does **not** say "filters and reverb inert"); the two-pod harness
+passes; `dist\` contains no `wrap_oal.dll` or `oalinst.exe`.*
+
+**What this does *not* do: remove OpenAL.** The API is cross-platform and is
+precisely why audio barely features in the phases below — all ~91 call sites
+compile unchanged against `libopenal.so`. Dropping OpenAL entirely is possible
+in principle (the game disables OpenAL's own attenuation and Doppler, does its
+own 3D math, and never streams — it is using OpenAL as little more than a
+mixer) but would mean reimplementing EFX reverb and rewriting ~91 working call
+sites to remove a dependency that causes no portability problem. Not
+recommended.
+
 ## The four decisions this plan assumes
 
 Taken 2026-08-14. Changing any of them changes the plan's shape.