Is there any way to get a callback when a ma_sound_stop_with_fade_in_*() function finishes the fade

[dgnuff]

The problem I'm trying to solve is housekeeping when fading from one background music track to another.

Starting and stopping the sounds isn't a problem:

ma_sound_stop_with_fade_in_milliseconds(&currentSound, 2000);
ma_uint64 const now = ma_engine_get_time_in_milliseconds(&engine);
ma_sound_set_fade_start_in_milliseconds(&newSound, ...., 2000, now + 2000);

That set of calls ought to fade down the current sound, and then when it's finished fade in the new sound. No problem at all.

The issue is that I want to maintain a pointer to the currently playing sound, so that I can (A) fade it out when it's time to transition again, and (B) mute it if the game loses focus. To reliably do this, I'd like to get a callback when the first ma_sound_stop_with_fade_in_milliseconds() completes. That'll be the exact point in time when the transition to the new sound happens.

Is this possible with the current miniaudio API, or do I have to roll my own housekeeping function to take care of this? I'd like to avoid rolling my own, because that means I will probably need another thread to take care of these delays.

I did find this thread when looking for other discussions: #682 it's a bit of a far cry from what I want, but it does address callbacks in some detail. First of all, I'm somewhat hesitant to look at the dev-0.12 branch, since you note that this branch may suffer API changes, something I want to avoid if possible. Secondly, it's not at all clear if what's discussed there can even be repurposed to get what would be ideal: a callback when a sound stops playing, and possibly one when it starts.

I understand that these callbacks would not happen in the context of my main thread. That's not an issue, since the main thread also processes window messages for the game window. This means it'd be trivial to use PostMessage() to get a message to the main thread. That will be sufficiently fast that it'll be totally workable.

--- Edit ---

It occurs to me, thinking about this for the last few hours that this might be a classic XY problem. The underlying objective is to get a pointer to the sound that's currently playing. If I could figure out how to create a group, then I could put the background track(s) in one group, and SFX in another. Then possibly ask the background track group for a pointer to the sound that's playing.

If I do things properly, I shouldn't ever have more than one background track playing at a time, so this might be an option.

[mackron]

This is sort of half addressed in the dev-0.12 branch, though I suspect it'll be an unsatisfying solution for your specific case. In that branch you can configure a notification callback for when the sound reaches the end of it's data source, but that will not work robustly for a fade out because that is technically different to a stop. So unfortunately I don't think a good solution exists for your problem right now, at least not a simple single-function solution.

However, I agree that this is something miniaudio needs to support. Indeed, I have had the idea of a generalised trigger system in the back of my mind for a while which is something I should start planning for. My idea is that you should be able to install any number of triggers that can get fired based on a specified time, either in milliseconds or samples, which you can handle either via a callback or some kind of message queue mechanism similar to Win32's Get/PeekMessage().

To address your issue in the mean time, I can think of two things. 1) Manually keep track of the time and any sounds scheduled for a fade out and just periodically check if they're ready to be handled. 2) Install a custom node that is configured with MA_NODE_FLAG_PASSTHROUGH and inside that check the timings and do your callback handling.

[dgnuff]

but that will not work robustly for a fade out because that is technically different to a stop.

I wasn't 100% certain about this. My choice of ma_sound_stop_with_fade_in_milliseconds() was intended to have the effect of fading out the sound, and then when the fade is finished automatically stopping the sound.

The bottom line is that for the time being, I'll probably have to look after tracking the current background music sound on my own. I have a Heartbeat thread already running to maintain the display. Right now it just kicks off a redraw every 20 ms, for a framerate of 50 FPS. The draw is so fast that this thread spends the majority of its time asleep waiting for the next draw tick. I've written short term task schedulers for other projects. It'd be easy to use the Heartbeat thread to watch for when events have to be triggered, and deal with them as they happen.

But if you do start on a general purpose notification system, then please consider adding a mechanism to trap more than just temporal events. Events like sound stop, sound start, sound "loop" (+), fade start, fade end, etc. etc. Sure, my application would only use sound start and sound stop, but I can see use cases where other programmers might need these other events.
(+) Sound loop is what I'd call the event when a sound that's been set to looping jumps back from the end to the beginning. Consider the case where you use a looping sound of a telephone ring in a game that you want to play for some finite number of rings, and then stop. This would let you count the number of times it's rung, and stop when appropriate.