fixed audio (we're done here)

[redpenguiney]

Summary

None

Purpose of change

While cleaning up the code for PR #80033, I accidentally completely ruined the control flow, causing sound effects to never get halted, so sound effects stopped working after enough sounds had been played to use up all the available channels.

Describe the solution

Fixed the control flow, making it so audio loops (silently) until it is halted by the main thread.

Describe alternatives you've considered

None

Testing

Played a great deal of sound effects over ~10 minutes, some of which were done in slow motion. Seemed okay.
Even when I set it so that only two audio channels were available for sound effects, it still worked correctly (although, as expected in that case it could only play two sounds at a time).

Additional context

It's possible that when I did a bunch of git suffering to get this on its own branch that I messed something up (although I did test it after moving it here).

[Maleclypse]

I love a good title pun, but I also want it to be readable enough that when I include that pun in the permanent changelog it makes sense. Sorry for adding context to your title.

[redpenguiney]

I love a good title pun, but I also want it to be readable enough that when I include that pun in the permanent changelog it makes sense. Sorry for adding context to your title.

oh whoops, i forgot it defaulted to the name of the commit, lol

[akrieger]

I took a look into it while on the plane, and a more straightforward option instead of this juggling of responsibility back and forth would be to call something like Mix_FadeOutChannel with a 0ms timeout. This internally lets the sdl mixer framework handle cleanup naturally. It seems like the audio callback gets invoked one more time but we can just return all zeroes for the sample.

[akrieger]

Is handler->loops_remaining < -1 necessary here? If we're in this branch it's already -1 or less which means we've already played all zeroes before.

[redpenguiney]

yes, it seemed necessary: I found that when I stopped it immediately, the last part of the sound effect got cut off (I theorize this is because when loops_remaining goes from 0 to -1, while we're done sending the audio data, the audio device hasn't finished playing it quite yet)

[akrieger]

Maybe going with Mix_FadeOutChannel handles that since it seems to allow the current sample to play out.

I may put up my own PR to try that.

[akrieger]

Although IDK at this rate we'd probably expose some other edge case where the fadeout triggers immediately and truncates the audio that we just returned.

[redpenguiney]

I took a look into it while on the plane, and a more straightforward option instead of this juggling of responsibility back and forth would be to call something like Mix_FadeOutChannel with a 0ms timeout. This internally lets the sdl mixer framework handle cleanup naturally. It seems like the audio callback gets invoked one more time but we can just return all zeroes for the sample.

Oh, that would've been convenient. I'd never messed with anything SDL or even audio-related before these PRs so I didn't know. If, god forbid, more issues spring up I'll swap it out to remove complexity.