feat: Add DirectAudio driver support

[joshuatam]

Description

Introduces DirectAudio as a new audio driver option for Wine.

This driver provides direct audio output to Android's AAudio, bypassing PulseAudio or ALSA middleware, potentially improving audio latency and compatibility for users.

Thanks for the interesting work from @The412Banner
https://github.com/The412Banner/directaudio

Recording

N/A

Type of Change

• Bug fix
• Performance / stability improvement
• Compatibility improvements
• Other (requires prior approval)

Checklist

• If I have access to #code-changes, I have discussed this change there and it has been green-lighted. If I do not have access, I have still provided clear context in this PR. If I skip both, I accept that this change may face delays in review, may not be reviewed at all, or may be closed.
• This change aligns with the current project scope (core functionality, stability, or performance). If not, it has been explicitly approved beforehand.
• I have attached a recording of the change.
• I have read and agree to the contribution guidelines in CONTRIBUTING.md.

---

Summary by cubic

Adds DirectAudio as a new Wine audio driver on Android, routing audio via AAudio to reduce latency by bypassing PulseAudio/ALSA. Previously only ALSA/PulseAudio were supported; now Proton 11 arm64ec (Bionic) users can select DirectAudio, with automatic fallback to PulseAudio when unsupported or when Wine/variant changes.

• UI: Adds “DirectAudio (Proton 11 arm64ec only)” to audio settings; validates selection against Wine version and variant; keeps the dropdown synced with config changes.
• Runtime: Writes Software\Wine\Drivers:Audio=directaudio. When a container uses DirectAudio, ContainerManager.extractDirectAudio installs winedirectaudio.drv and winedirectaudio.so into Wine (lib/wine/aarch64-{windows,unix}) and copies the .drv to the prefix system32. XServerScreen.refreshComponentsFiles now triggers extraction for DirectAudio containers.
• Assets: Bundles DirectAudio v1.2.1 (directaudio-20260813.tzst) plus a diagnostics build (directaudio-20260813-diagnostics.tzst); defaults via DIRECTAUDIO_ASSET. v1.2.1 includes fixes for a MIDI notify CPU spin and background/foreground audio stalls.
• Legal: Updates THIRD_PARTY_NOTICES for DirectAudio (LGPL-2.1-or-later).

Rollout

• Proton 11 arm64ec (Bionic) users can select “DirectAudio”; the driver installs automatically. Others continue on PulseAudio.
• To trace issues, set DIRECTAUDIO_ASSET to directaudio-20260813-diagnostics.tzst for additional logcat probes.

^{Written for commit 600958b. Summary will update on new commits.}

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 98770955-4a85-4cb5-8d9f-4ddc263a82ab

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[The412Banner]

Hi @joshuatam — DirectAudio author here. Thanks for the credit, and for taking the packaging side on. Three things have moved since this PR was cut on 2026-08-12 that I think are worth folding in before it leaves draft. Happy to open a PR against your branch for any of them.

---

1. The driver is three files, not two — this will break 32-bit titles

This is the important one. On the mmdevapi unixlib model a complete driver set is:

file	loaded for
lib/wine/aarch64-unix/winedirectaudio.so	the Unix side (AAudio backend), shared
lib/wine/aarch64-windows/winedirectaudio.drv	a 64-bit guest game
lib/wine/i386-windows/winedirectaudio.drv	a 32-bit / wow64 guest game

Which PE loads is decided by the guest game's bitness, not by the Proton build or the device — verified on-device from /proc/<pid>/maps: a 32-bit game on an arm64ec layer loads the i386 PE plus the shared .so.

extractDirectAudio currently installs only aarch64-windows/.drv + aarch64-unix/.so, so a 32-bit title gets a stale-or-absent i386 PE next to a new .so and fails with:

mmdevapi:init_driver No driver could be initialized

64-bit titles are unaffected, which is exactly why this stays hidden in testing. We shipped the same bug and hit it in the field.

The fix is small — the v1.3.1+ release zips already carry i386-windows/winedirectaudio.drv, so it's one more source file and one more copy:

File drvSrc     = new File(tempDir, "winedirectaudio.drv");        // aarch64 PE
File drv32Src   = new File(tempDir, "winedirectaudio-i386.drv");   // 32-bit PE  <-- add
File soSrc      = new File(tempDir, "winedirectaudio.so");
...
File i386WindowsDir = new File(wineLibDir, "i386-windows");        // <-- add
...
boolean success = FileUtils.copy(drvSrc, drvWineDest)
                && FileUtils.copy(soSrc, soWineDest)
                && (!i386WindowsDir.isDirectory()
                    || FileUtils.copy(drv32Src, new File(i386WindowsDir, "winedirectaudio.drv")))
                && FileUtils.copy(drvSrc, drvSystem32Dest);

One gotcha if you re-use an existing install: if you version-stamp the extraction to skip re-installing, make sure the stamp changes when this fix lands — otherwise layers already stamped by the two-file path will never receive the i386 PE. We had to change our marker format for exactly that reason.

2. The pinned driver is two releases behind — and Wine 10 works now

The PR bundles v1.2.1 (directaudio-20260813.tzst). Current is v1.3.2 (2026-08-31). Between them: live in-game config mailbox, soft-knee limiter (fixes an audible ~2.4x downmix clip), honest exclusive-mode reporting, adaptive decay, watchdog, and the daprobe diagnostic tool.

More relevant to your gate: Wine 10 is supported now, so DirectAudio (Proton 11 arm64ec only) is stricter than it needs to be. There are two ABI families, and both are built and released as complete 3-file sets:

zip	Wine	layers
directaudio-wine11-arm64ec-sdk{28,35}.zip	11	Proton 11.0-1 / 11.0-2 / 11.0-3 / 11.0-5 / GE 11.0-6 — all ABI-interchangeable
directaudio-wine10-arm64ec-sdk{28,35}.zip	10	Proton 10.0-4 / GE-Proton 10.0-34

Device-proven 2026-08-16 with complete 3-file swaps: one Wine-11 build serves every 11.0-x point release, but Wine 10 is a genuinely separate ABI and needs its own build — installing the Wine-11 driver on a 10.0-4 layer gives no audio. So if you widen the gate, extractDirectAudio needs to dispatch on the layer's Wine major and pick the matching archive. sdk28 = 4 KB pages, sdk35 = 16 KB — worth selecting off sysconf(_SC_PAGESIZE) rather than hardcoding.

(arm64ec only either way — the unixlib calls libaaudio in-process, so there's no x86_64/box64 path.)

3. v1.3.2 adds in-game microphone capture (opt-in) — it needs an app-side half

New in 1.3.2: the driver exposes a WASAPI capture endpoint backed by an AAudio INPUT stream (VOICE_COMMUNICATION preset, so you get platform AEC / NS / AGC), opened lazily on first capture. That means working in-game voice chat over DirectAudio — device-proven on an AYANEO Pocket FIT (Adreno 750) with a real mic recording and TF2's in-game mic test. Not yet validated: a real two-player online voice round-trip, and the input stream's effect on the output latency floor.

Two things to know before wiring it up:

• It's off by default and must stay that way. Enable per-container with BANNER_AUDIO_DIRECT_MIC=1. With the flag off, get_endpoint_ids exposes zero capture endpoints and every capture op returns AUDCLNT_E_DEVICE_INVALIDATED. That's deliberate: titles that probe the mic at startup (God of War, DiRT 3) black-screen on an enumerable-but-unopenable endpoint. Default off is byte-for-byte v1.3.1 behaviour.
• The app owns the permission, the driver owns the capture. Android needs RECORD_AUDIO granted to the app process before the driver's AAudio input stream will open. Our app-side half is a RECORD_AUDIO permission + optional android.hardware.microphone feature in the manifest, a per-container/shortcut Microphone toggle (default off, only shown when the driver is DirectAudio) that requests the permission on enable, and plumbing that seeds BANNER_AUDIO_DIRECT_MIC=1 into the launch env. The app never touches AudioRecord/MediaRecorder itself. Happy to share that patch if it's useful.

If you'd rather keep this PR's scope to output only, that's completely reasonable — just leave the flag unset and the mic path stays dormant.

---

Diagnostics builds now ship for both Wine ABIs as complete sets too (directaudio-v1.3.2-diagnostics-wine{10,11}-arm64ec-sdk{28,35}.zip) — running with BANNER_AUDIO_DIRECT_LOG=1 and watching logcat for the DirectAudio tag is the fastest way to confirm the endpoint actually went hot, which is handy for triaging field reports.

Licence is unchanged (LGPL-2.1-or-later) — your THIRD_PARTY_NOTICES entry is correct as-is.

Ping me if you want the 1.3.2 assets repacked into the flat .tzst layout this PR already expects, or a PR against feat/directaudio with the i386 fix + version bump.

[joshuatam]

Hey @The412Banner , thanks for pinging me in this PR, thanks for explaining the changes so far, I agree that providing input feature will make game support better, and I am interested to bring it in too. Just I have been very busy on my own company recently, so didn't have time to look at it yet.

Meanwhile, what I really concern is the possibilities to have a single build for proton 9, 10 and 11, as you have mentioned different proton have different ABI, are the ABI conflicting with each others? Would it be ever possible to have a single ABI build that can work on different protons?

[The412Banner]

Hey @joshuatam, no worries, take your time.

Short answer: a single binary across 9/10/11 isn't possible, and it's not really the driver's fault. DirectAudio has no ABI of its own. It just fills mmdevapi's private unixlib vtable (dlls/mmdevapi/unixlib.h), and Wine changes that table every major. 9→10 inserted two entries mid-table, 10→11 dropped a field from is_format_supported_params and added midi_get_driver. That's the same reason nobody ships one winepulse.so across Wine versions either. A Wine 11 driver on 10.0-4 just gives silent no-audio, I've tested it.

On Proton 9: I only build and ship wine10 and wine11 drivers today, there is no Proton 9 build. That said, your proton_9.0 branch has the exact same mmdevapi header as your proton_10.0, so the wine10 driver would probably bind there and it'd be two builds for GameNative, not three. That's a guess from the header though, I haven't built or tested it.

What I'd actually recommend is what I do in my own proton-wine fork: put dlls/winedirectaudio.drv in the Wine tree like winepulse, so it gets built with every Proton/GE build and ships inside the wcp already matched. Then the app needs no asset and no version dispatch, just the registry key and the fallback. It's one source file plus a Makefile.in. Happy to open PRs against your proton_10.0 and proton_11.0 branches if you want that, and I can add a proton_9.0 leg after that once it's actually tested. Or add the assets to ship with the app (future directaudio updates) so they update users containers in place on their next launch after an update, since they layers already support directaudio the app updates it in place automatically on future installs of gamenative. No new layer needed or container created required.

If you'd rather keep the sidecar approach for now, the cheap fix is one .tzst with wine10/ and wine11/ subfolders and extractDirectAudio picking by the layer's Wine major. Either way the i386 fix and 1.3.2 bump from my last comment don't depend on this.