Closed roig closed 1 year ago
The core issue is that the mixing thread has a linked list of playing sound instances, of which reference your audio. I can change this behavior to e.g. queue up the destruction of the audio in-memory and let cute_sound figure out when the reference count hits zero.
But, if you set a sound active to false with cs_sound_is_active
, or cs_music_stop(0)
the playing instance will immediately stop playing, despite the audio source (the audio samples in memory) still hanging around in memory. They have to hang around in memory at least until the audio source reference count hits zero.
Ultimately the quirk you saw is a thread sync'ing thing that's getting leaked through the abstraction. I'm sort of thinking this through myself, but queue'ing up delayed destruction of the audio source seems like a great solution.
When I'm closing my application and I free my cs_audio_source that is currently playing I receive an error that can't free it if it's playing. That's good.
But how you can really stop it playing? I'm doing this to force cute_sound to release the current playing cs_sound_source:
But I'm getting the same error that you can't free it because is currently playing. (But I have stopped it :D)