Three answers:
- What is the desired fallback behavior if your deadline is going to be missed? Call the delegate callback with a “deadline missed” error condition (aka the submitted request wasn’t processed in time to make the hard deadline.) This prevents music from playing under the wrong conditions. I suspect I can do this right now with transport relative mode, but I haven’t tested it. The point is in current position mode if I say “play next beat” expecting next beat to be beat 2 but I have a lag spike and the audio thread doesn’t process until beat 3 I’m a beat off.
- Out of curiosity, what info would that callback provide? It gives me the opportunity to do math and give you the correct StartTime offset, instead of assuming the one handed in from the game thread is correct. What I’m seeing right now is that if I want to sync up a piece of music that’s 8 bars long with one that’s already playing that’s 8 bars long it’s very difficult to align without waiting until the next full loop boundary. My current approach is to queue the new track for “next beat” and do math to calculate how far to skip into the sound file in order to start playback on the new file from the position that aligns with what “next beat” ought to be. The problem is that when I miss that deadline with the background audio thread, it’ll correctly align to the “next next beat”, but then play a beat offset because the math I did is out of date. If I got a callback from the audio thread just before it wrote to the outgoing buffer, I could update StartTime to be correct.
- Would this be calling back to your BP or do you have a C++ implementation? Given the likelihood of badness having multiple threads enter BP, I would assume this would only be available to C++ implementations. You could solve this with additional information in PlayQuantized that would let the audio thread do the StartTime calculation instead.