[krishalivaibhav]

What

Drain active legacy AudioOut calls before closing SDL audio devices during normal libc shutdown. Reject new calls once shutdown starts and cancel paced output waits so teardown does not race port state or mutex destruction.

Add a regression test using the actual AudioOut implementation and libc shutdown registry. A controlled guest clock keeps an output call waiting until shutdown cancels it.

Tested

Rebased onto main f40b6930ff156834b786730771518b3bd7fe8648; head 11ad8bd1a. The shutdown fixture now links the SDL initialization helper added on main. New title-backed A/B evidence for Vampire Survivors (PPSA21703): main AudioOut source aborts in sleepUs → mutex::lock after a normal exit request; candidate exits 0. Only AudioOut differs between the recorded game binaries. This uses an older adapted Mac runtime around current-main AudioOut, not a complete current-main title build. The PR stays closed pending the maintainer’s assessment of that evidence scope. Earlier platform reports below refer to their explicitly stated older heads.

• Mac M2, x86_64 under Rosetta: actual AudioOut CMake test target, using existing local runtime libc and SDL2 dependencies; 20 consecutive CTest passes (0.7–2.7 seconds per run).
• Same fixture with the main-branch AudioOut implementation fails with pending output was not cancelled.
• Local convention checks and diff whitespace checks pass.
• Independent contributor xXPBSXx reported a Windows Release full build and passing audio_out_shutdown, using head 243bcfadd merged onto main c6efe068a together with three other PRs. Their 20-test result is for that combination, not this branch alone; they did not run a no-fix negative control or a title run.
• Hosted full Linux/Windows jobs were skipped and are not counted as passing. Clean Linux execution and standalone Windows validation remain unverified. Rebased onto main after the checkout repair in build: remove accidental imgui gitlink #3511 merged. Local validation uses the existing macOS runtime dependencies rather than a complete clean upstream build.

This covers legacy AudioOut shutdown. It does not establish game loading compatibility or AudioOut2 shutdown coverage.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

[xXPBSXx]

Windows test of head 243bcfadd merged onto current main (c6efe068a, clean merge; built together with three other open PRs from the same list, so the numbers below are for the combination): Windows 10 (19045), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release, full build 0 errors.

audio_out_shutdown (the test this PR adds) passes, with the other audio_out* tests (20 of 20 in the filter audio_out|guest_directory|guest_dup|guest_kernel_sys|guest_sce_net|guest_file).

Not checked: that the test fails without the change, Linux, a title run.

AI-assisted (Claude Code).

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#4789	core/libs/prx/libSceAudioOut/CMakeLists.txt L19
#5558	core/libs/prx/libSceAudioOut/CMakeLists.txt L19

[oneandonlydean]

Closing: no title is known to reach this. With the queue at 700+ open PRs, please hold off on new PRs that don't name a title needing the change until it's down. If a title stops on this on current main, reopen with the title ID and the log line.

[krishalivaibhav]

Title-backed follow-up for the closure request: Vampire Survivors, PPSA21703, on Apple M2 / Rosetta / MoltenVK. This reproduces the AudioOut shutdown defect; it is not a gameplay-crash or performance claim.

I rebased the branch onto main f40b6930ff156834b786730771518b3bd7fe8648; candidate head 11ad8bd1a6b587275301c187626c5361ca8beed8. The shutdown fixture now links main's newly added AudioOutSdl.cpp, while retaining the existing SDL initialization test.

Controlled title A/B:

1. Compile main's exact AudioOut.cpp (Git blob fcd7d359f82f93dab75949e89df458e07e2136aa) and AudioOutSdl.cpp into the baseline AudioOut library. Build the candidate with the rebased admission/drain/cancel change, using the same auxiliary objects and dependencies. Process both libraries through the same NID patcher.
2. Run PPSA21703 with the baseline and request normal exit at 30 seconds using the existing exit harness. It aborts after 33.56 seconds, exit SIGABRT (-6), without forced termination. Log: libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument.
3. The faulting-thread crash stack is std::__1::mutex::lock() → sleepUs(std::__1::unique_lock<std::__1::mutex>&, unsigned long long) in libSceAudioOut.prx; crash-report PID matches the recorded title process, 8644.
4. Change only AudioOut and repeat the same normal-exit harness. The candidate exits 0 after 30.88 seconds, without TERM/KILL. Manifest hashes confirm that the recorded executable, graphics, VideoOut, kernel and libc binaries are unchanged between runs.
5. The focused shutdown fixture against main's AudioOut aborts with pending output was not cancelled; against the rebased candidate it passes. These fixtures compiled with current-main headers and the new SDL initialization helper. Parent and independent low-reasoning agent reviewed the integration and evidence.

Important scope limitation: this is current-main AudioOut source executed in our older adapted macOS runtime; auxiliary AudioOut2 objects and the surrounding libc/libkernel/graphics runtime are not a complete current-main build. The initial test dependencies also use that adapted Mac libc/SDL. I am not presenting this as a pristine/current-main whole-title run, Linux/Windows validation, or proof of long gameplay stability. There was one title run per variant.

The branches and original test evidence are preserved. Does this isolated, current-source title shutdown reproduction meet the reopening requirement for the macOS case, or should I keep it closed until the entire Mac runtime is aligned to main? I have kept it closed pending that distinction.

AI-assisted: yes (Codex).