xenia-rs/audit-runs/phase-host-audio-bridge/investigation.md

Phase Host-Audio-Bridge — Investigation (2026-05-19)

Outcome: AUDIT-048 cascade C NOT landed this session. Root cause is upstream state divergence in XAudio voice struct initialization, NOT a missing host-side write. Progression metric (swaps=1, draws=0) unchanged. Per-chain matched-prefix unchanged.

Diagnosis

Canary semantics (verified)

• xenia-canary/src/xenia/apu/audio_system.cc:84-159 — AudioSystem::WorkerThreadMain is a HOST thread that loops: WaitAny(client_semaphores_) → processor_->Execute(callback). Semaphores are seeded by RegisterClient line 210: client_semaphore->Release(queued_frames_=8, nullptr).
• After SDL plays a frame, sdl_audio_driver.cc:199 calls semaphore_->Release(1) — re-arming the loop. With --mute=true, SDL still consumes frames via SDLCallback and still releases.
• There is NO host-side write to a guest field at offset +356. The XAudio voice struct at r31 is GUEST-allocated and managed entirely by the GUEST callback code at 0x824D6640 and the XAudio worker thread bodies at 0x824D2878 / 0x824D2940.

Ours's current state

• AUDIT-048 Plan B (dedicated guest worker thread, parked on synthetic handle, injected by ticker) is wired in xenia-kernel/src/exports.rs:4048-4168 + xenia-kernel/src/xaudio.rs
  • xenia-app/src/main.rs:3461-3536.
• Ours's tid=11 (entry=0x824D6640 = the registered callback) DOES execute. Per deadlock dump: pc=0x824d2a94 lr=0x824d2a94 state=Blocked(WaitAny { handles: [0x82928B04, 0x82928AE0] }) — the callback called KeWaitForMultipleObjects on two guest dispatchers and is now waiting.
• xaudio.callback.delivered=1 — only one injection, because is_in_callback stays true while tid=11 is blocked on the real handles (the saved context is only cleared on LR_HALT_SENTINEL return, which tid=11 never reaches).

The spin loop in tid=9/10 (the XAudio worker guest threads)

PCs 0x824D1400-0x824D141C (canary tid=14 / ours tid=9):

0x824d1400: beqlr cr6                ; return if cr6.eq (success)
0x824d1404: cmpd  cr6, r10, r11      ; compare r10 with r11
0x824d1408: beq   cr6, 0x824D1420    ; ok-branch on match
0x824d140c: mr    r31, r31            ; yield nop
0x824d1410: ld    r11, 0(r4)          ; reload [r4]
0x824d1414: cmpdi cr6, r11, 0        ; check r11 == 0
0x824d1418: bne   cr6, 0x824D1404    ; loop if nonzero
0x824d141c: blr                       ; return on r11 == 0

LR=0x824D22B4 (caller does addi r4, r31, 356; bl ...; <0x824D22B4 is next>).

Live runtime probe (ours, 100M instr, --dump-addr 0x42511040 and 0x42510edc)

At halt (tid=9 still spinning at pc=0x824d140c):

• r3 = r31 = 0x42510edc (an XAudio voice/driver struct in heap-mapped guest mem).
• r4 = r31 + 0x164 (=356) = 0x42511040.
• r10 = 0x01010000 (expected success value).
• Last-known r11 = 0x00000000 (from the load) — but the spin continues, so the value at [r4] keeps changing? Or the snapshot doesn't reflect steady state.

Memory dump at 0x42511040:

+0x00: 01 00 00 00 00 00 00 00   →  ld interpretation = 0x0100000000000000
+0x10: 00 00 00 03 42 51 10 54   →  linked-list head with 3 entries
+0x20...: list nodes with prev/next pointers in 0x4251xxxx range

This is a GUEST-OWNED linked-list / voice-state struct. Byte 0 = 0x01 is clearly a "state flag" that distinguishes the poll target. ld reads 8 bytes BE → 0x0100000000000000. r10 expected is 0x01010000 (zero-extended). r11 read is 0x0100000000000000. Not equal, not zero → spin.

Memory dump at r31=0x42510edc:

+0x00: 82 00 6c f4                →  VTABLE POINTER (code at .rdata 0x82006cf4)
+0x04: 00 00 00 02                →  refcount or count
+0x08: 42 51 0e c0                →  back-pointer
+0x40: 41 ea 0d 5c                →  matches XAudio register callback_arg

So r31 is the XAudio voice object Sylpheed allocates and passes as the callback argument. The vtable at 0x82006cf4 is ANON_Class_* per sylpheed.db. The voice owns a linked list (head at +0x164) that tracks audio buffers / voice state.

Why ours diverges from canary

Ours's tid=9 sees [r31+356] as 0x0100000000000000; canary's tid=14 sees it as 0x0000000000000000 (or 0x0000000001010000 matching r10). Both engines run identical guest code starting from the same .data values. So the divergence must be a kernel-call return value OR a memory write that happens between thread spawn and the spin loop.

Per cross-trace of tid=9 events idx 0..76 vs canary tid=14 events 0..~80, the kernel return values match (KeWaitForSingleObject→0, KeRaiseIrqlToDpcLevel returns the same sequence 0,2,2,2 etc., KfLowerIrql→0). The setup chain emits the same events. But host_ns wall-clock diverges: canary's KeWaitForSingleObject blocks for ~85ms (1727→1813 ms); ours's wait returns in ~7 microseconds (1603890→1603904 ns).

The root cause class

This is upstream scheduling divergence, not host-bridge missing:

1. In canary: tid=11 (host AudioSystem WorkerThreadMain) starts FIRST and runs the callback at 0x824D6640. The callback modifies the XAudio voice struct (clearing byte at +0x164). Then tid=14 spawns, hits the spin, sees zero, proceeds.
2. In ours: tid=9/10 are spawned by main and resumed via KeResumeThread. They start running BEFORE the audio ticker (period 48,000 instructions) ever fires. tid=9 hits the spin loop with the struct in its uninitialized state (byte +0x164 = 0x01). Stuck forever.

The audio worker (tid=11) DOES eventually get injected and runs, but by then tid=9/10 are stuck in the spin loop and the callback blocks on guest dispatchers that only tid=9/10 can signal — circular deadlock.

Why a host-side write is the wrong fix

The session brief hypothesizes a missing host-side write to clear [r31+356]. This is not correct:

• Canary's host audio worker does NOT write to any guest VA in the +356 range. It only calls processor_->Execute(callback) and waits on its host semaphore.
• The byte at offset 0x164 of the voice struct is touched only by GUEST code (the callback or the worker functions). No host code in either engine reaches into that field.
• The "missing write" framing came from assuming the host audio worker does something analogous to SubmitFrame's buffer-complete bookkeeping. SubmitFrame only acks the host SDL driver semaphore (line 199); it does not modify the voice struct at +356.

Writing 0 to [r31+356] from host code would be a band-aid that crosses reading-error #23 (matching divergent guest behavior) and risks corrupting the voice struct's invariants.

What the correct fix shape would be

To make ours converge to canary's behavior, the audio worker callback at 0x824D6640 needs to RUN AND COMPLETE before tid=9/10 reach the spin loop.

Option A — Force-fire callback at register time: Inside xaudio_register_render_driver, after spawning tid=11, synchronously execute the callback to completion (treat as a synchronous shim). Tricky because the callback calls KeWaitForMultipleObjects which would block.

Option B — Defer spawn of tid=9/10 in guest: Not feasible — guest controls spawn timing.

Option C — Inject the callback eagerly + spin tid=11 forward: Tick the audio loop hundreds of times immediately at register. But tid=11 blocks on guest objects that need tid=9/10 to be running already.

Option D — Match canary's actual concurrency model: Spawn tid=11 as a native HOST thread that runs processor_->Execute(callback)-equivalent. This is a significant rework of the threading model.

Option E — Identify the specific guest write that clears +0x164 in canary: Disassemble sub_824D6640 (the callback) and find the store. Then ensure ours's execution of the callback reaches that store before tid=9/10 spin. Requires fixing the deeper scheduling-ordering issue.

None of these is a 30-150 LOC fix. All require either:

• Architectural threading-model changes
• Sub-cycle ordering control between guest threads
• Deep guest-code disassembly + emulation of the byte-clear path

Recommendation

This session declines to land a fix. The session brief's hypothesis (missing host-side write to clear [r31+356]) is empirically wrong: the byte is owned by guest code in both engines. The deferred AUDIT-048 cascade C is correctly deferred — the necessary work is scheduling-ordering matching, not host-bridge wiring.

Next-session recommendation: probe-instrument the byte at r31+0x164 for the XAudio voice (around 0x42511040 ours, similar address canary) on FIRST guest write. Identify in canary trace which PC writes the byte and on which tid. That's the actual fix target.

Per-chain delta (no change)

chain	pre	post	delta
main tid=6→1	105,046	105,046	0
sister tid=14→9	41	41	0
sister tid=15→10	16	16	0
sister tid=4→4	preserved	preserved	0
sister tid=11→11	preserved	preserved	0
sister tid=16→16	preserved	preserved	0
swaps	1	1	0
draws	0	0	0

Artifacts

• investigation.md (this file)
• Cold trace: /tmp/ours-cold.jsonl (121k events, halt-on-deadlock after 100M instr cap)
• Memory dumps captured via --dump-addr 0x42511040 and --dump-addr 0x42510edc
• Phase B image_canonical_sha256 = ea8d160e… UNCHANGED (no engine modification)