I have a bug thats driving me nuts. I use some middleware as a sound engine. its the ONLY middleware I use, and its bugging me. theoretically its easy to use, but I have a situation that it seems incapable of coping with.
With this middleware, I can play a sound, and request a pointer to track it. I can use that pointer later to adjust volume, or stop the sound, or query if its finished. For various reasons, I need to keep my own list of what sounds are currently playing. Thus I have a list of ‘current playing sounds’.
The middleware gives me a callback which triggers when a sound ends. This is handy, as I can then loop through the current playing sounds and remove it, keeping that list up to date. The sound engine runs in its own thread, so that callback triggers in a different thread to the main game.
This is where it goes wrong (but only on fast speed). I decide from the main game, to stop a sound. I firstly check that the sound exists within the current playing sounds. It does, so I access the sound pointer and tell it to stop. But wait! in-between those two events, the sound has expired naturally (in another thread) and the pointer has become invalid. CRASH.
using critical sections just produces race conditions, because stopping the sound has to happen in the same thread as the callback, and there are likely several sounds generating callbacks in the same frame (on fast speed) as the one I’m trying to stop, and it reaches a deadlock. It’s a real pain.
One solution is to make all such sounds loop (and thus never expire naturally, and rely on me killing them, which should work ok) and I thus never hit this problem. Another is to just not stop them prematurely (looks weird). I have currently hacked it, but I suspect the 1.18 build still has this issue manifesting itself as a 4x speed lots of beam-lasers crash.
Another solution is to tell the sound engine to run single threaded but that seems horrendously hacky.
I may have to try the always-loop solution. One day I’ll write my own sound engine again.