Repository navigation
Report finished audio buffers at the renderer update, so a speaker no longer goes silent - #1181
Merged
Conversation
…pdate, not mid-pass Ocarina's sound thread feeds its six speaker voices one after another: it reads every voice's GetWaveBufferCount, then for each one takes GetReleasedWaveBuffer and appends when it looks short. The mixer released buffers from its own thread at any moment, so a buffer finishing between two of those reads made one voice look a buffer short. The game appended it an extra one, then kept topping it up whenever its count was off, until the voice's queue reached MAX_WB and that speaker went silent for the rest of the session. It happened in about one launch in five, in stereo as well as 5.1 (one stereo run was left with only the centre's share in the left channel). On the console a voice's state changes only at RequestUpdateAudioRenderer. Now a buffer the mixer finishes is reported to the game at the next update (commit), as there: until then GetReleasedWaveBuffer does not return it and GetWaveBufferCount still counts it. tests/test_audio_wave_buffer_release.py compiles the actual calls, queue and mixer step around an authored six-voice pass; it fails on the previous nn_audio.c (count 3 where the game must see 4). Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 9, 2026
Contributor
Author
|
Thanks for the review. This was merged just before I pushed 3e7ee9a, so the |
janvitos
added a commit
to janvitos/Hookshot
that referenced
this pull request
Nov 9, 2026
…n_all.py (review of NotRexed#1181) The test defaulted to `cc` and had no ARGS entry, so run_all.py --strict would call `cc` on the windows-2022 job, where there normally is none. It is now listed with ["--cc", "gcc"] next to the other audio entry and defaults to gcc itself, so the runner skips it (or fails it under --strict) when gcc is missing. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A wave buffer the mixer finishes is now reported to the game at the next
RequestUpdateAudioRenderer(commit()), as on the console, instead of the moment the mixer thread finishes it. Until that update,GetReleasedWaveBufferdoes not return it andGetWaveBufferCountstill counts it. Onlyhost/nn_audio.cchanges (anrel_seencount per voice).Why
In about one launch in five, one speaker channel went silent and stayed silent for the rest of the session. This happens in stereo too: one stereo run lost the left channel's own sound and kept only the centre's share in it.
Ocarina's sound thread feeds its six speaker voices one after another. It reads each voice's buffer count, then takes released buffers and appends to any voice that looks short. Hookshot's mixer released buffers from its own thread at any time. When a buffer finished between two of those reads, one voice looked a buffer short and got an extra append. From then on the game kept topping that voice up whenever its count was off, until its queue reached
MAX_WBand that channel died.I found this while testing #1124 (5.1 surround). It has no issue of its own that I could find.
How it was tested
tests/test_audio_wave_buffer_release.pycompiles the actual append, released, count and play-state calls, the update queue,commit()and the mixer's buffer step, then runs a six-voice pass through them. It fails on the currentmain(count(2) == 4) and passes with the change.python -I -B tests/run_all.pygives 132 passed, 0 failed, 17 skipped on Linux.🤖 Generated with Claude Code