Repository navigation
Conversation
mixer_emit_round re-applies the frequency of every channel below hi_ch at the start of each round, and mixer_ch_apply_freq checks it against the channel limit. mixer_ch_stop keeps the last frequency, so lowering the limit of a stopped channel made the next poll assert, although nothing was playing above the new limit: frequency 66142.5 exceeds configured limit 44095.0 on channel 2 xm64player_close does exactly this on each of its channels (stop, then mixer_ch_set_limits back to the defaults), so closing a player that had played a note faster than the output rate asserted a round later. A stopped channel's step is not used by the round, and mixer_ch_play sets the frequency again (a limit change that frees the channel buffer also drops the waveform uuid, so play takes the new-waveform path). Skip stopped channels in mixer_ch_sync_freq. tests/test_wav64.c: test_mixer_stop_lower_limit reproduces it with a plain PCM waveform. Claude-Session: https://claude.ai/code/session_01JRLT3zFXKe5nUc64aTuPEo
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.
Fixes #6.
mixer_emit_roundre-applies the frequency of every channel belowhi_chat the start of each round, andmixer_ch_apply_freqchecks it against the channel limit.mixer_ch_stopkeeps the last frequency, so lowering the limit of a stopped channel made the next poll assert, although nothing was playing above the new limit.xm64player_closedoes exactly that on each of its channels (mixer_ch_stop, thenmixer_ch_set_limits(ch, 0, 0, 0)).This PR makes
mixer_ch_sync_freqreturn early for stopped channels (!c->ptr).mixer_ch_playsets the frequency again. A limit change that frees the channel buffer also clearswave_uuid, so the next play takes the new-waveform path, which callsmixer_ch_set_freq(ch, wave->frequency).mixer_ch_stopinstead would break replaying the same waveform. That path reuses the kept uuid and never sets the frequency, so it would play at 0 Hz.Test
tests/test_wav64.cgainstest_mixer_stop_lower_limit. It plays a PCM waveform at 1.5× the output rate under a 2× limit, stops the channel, resets the limit to the default and polls. It then replays at the output rate and checks that the output is not silent. It runs last intestrom_wav64, because without the fix it stops the ROM on the assertion.testrom_wav64.z64in ares:ASSERTION FAILED ... frequency 66142.5 exceeds configured limit 44095.0 on channel 2, frommixer_pollin the new test. Every earlier section ran without a failure.ALL TESTS PASSED (407).As a regression check, I also built a game against this branch. It plays two xm64 modules at once, plus sound effects. In ares it passed its N64 self-test and all 33 of its replays, which run with the music on. That game uses
xm64player_stopand never callsxm64player_close, so it does not exercise the fixed path itself. Nothing was tested on hardware.https://claude.ai/code/session_01JRLT3zFXKe5nUc64aTuPEo