audio: Added SDL_SetAudioIterationCallbacks(). #12763
Conversation
|
Does this solve the per-sample needs? e.g. at sample 498 I need to splice in track B We may need to support multiple callbacks if someone wants to do additional custom work. |
|
No, it just lets us change multiple tracks atomically (notably, start them at the same time, or start a fade at the same time, to the sample). The current SDL_mixer redesign should allow all the sample-perfect needs mentioned in the Factorio blog, I think (for example, it can start a new track as an old one finishes during mixing without a gap, fades no longer operate in blocks aligned to iterations of the device thread, etc), but we don't currently have a "start this track at exactly this sample frame in this other track" operation. |
icculus
force-pushed
the
sdl3-audio-iteration-callbacks
branch
from
f3d2ebe to
18f4160
Compare
|
Just remembered this is still pending, and I need this for SDL_remixer, too. Let's try to get this (or something that solves the same problem, if this isn't it) merged soon. |
|
(To answer the question about multiple callbacks: each logical devices get a single callback, and this is almost certainly not where people should be hooking in for most things...for something that needs this and doesn't have control of the app as a whole, they should probably open their own logical device and not mess with others...which is more or less what SDL_mixer will be doing, too.) |
|
Last call on this one, ideally this is in before the Factorio people pull the latest SDL3 from revision control for their SDL_mixer work. |
|
Let's do it! |
This adds a hook that runs in the audio device thread, before it starts processing bound audio streams, and a second hook that runs after.
The specific need here: the SDL_mixer rewrite wants to be able to change things on multiple tracks (what SDL2_mixer calls "channels") atomically. For example, stopping multiple tracks with a fadeout should have them all start fading at the exact same time, which it can't accomplish if the device thread is halfway through processing streams when SDL_mixer tries to start the fade...some will be fading a little sooner than the rest.
A generic "lock the whole device" API wasn't feasible, since there's already a ton of locking needed to find the lock that applies to the SDL_AudioDeviceID the app would have, so when one goes to unlock the device later, we'd have to grab those initial locks again in a different order (as the app is holding the final lock at the time), risking deadlock in normal situations.