[…]
I suppose this is because Mix_PlayMusic() needs to do some heavy
initialization, or at least some memory allocation and other "realtime
unsafe"
stuff… Doing that in the contexts of the audio callback would obviously
be a bad idea.
I went through the code, it uses SDL_LockAudio which seems to be like a
non-recursive mutex.
That would probably generate a loooooong drop-out…! 
I don’t know what you’re doing here, but games tend to have a main loop
spinning at some 30+ fps. Polling from there wouldn’t cause any
significant in
this context.
If you’re lucky enough to get 30+ fps. The timing is not the real problem,
but i am relunctant to resort to polling when there’s a callback.
Of course, but then it’s either doing the job right then and there, or relying
on some proper blocking mechanism.
[…]
It may not even be possible, if the audio callback is running in some
sort of interrupt context, though you probably won’t see that often these
days. (Win16 and Mac OS prior to X did that.)
I think that’s not a problem anymore. There were threads in those good old
days?
Threads and various other strange contexts have coexisted on many Windows
versions at least, and I suppose they still do, although in an "emulated"
form, in the Win16 compatibility layer… And of course, there are Kernel
Streams in later NT based systems. (2000 and later, IIRC.)
If you want to include less common systems, there are various industrial
realtime platforms (Linux/RTAI, for example) that “piggy-back” on a general
purpose OS, where realtime threads and normal treads play by rather different
rules.
That said, I think the only time you’ll see any of this with SDL is if
you’re running on a pre-OSX Mac. Don’t know about handheld devices and game
consoles, though…
If going for threads, I’d set up a permanent background thread for such
things, and have that block on a suitable locking mechanism, waiting for
commands from other contexts. To avoid timing issues on less realtime
So let a thread wait for a signal would be better?
Yes. At least, that’s designed to be fast and low overhead, whereas creating
and destroying threads is not.
friendly
platforms, you may use lock-free mechanisms and have that thread poll at
a sensible rate.
Then i could poll again in the main thread. Which is really the simplest
way.
Yes, exactly.
Or, since you’re probably checking for SDL events somewhere anyway, possibly
even blocking on them, how about sending an SDL_USEREVENT to your mainloop?
That said, a worker thread is motivated in some situations, such as:
* You have a main loop that blocks, waiting for input events.
* You’re writing a library, and don’t want to force applications
to call some do_some_background_work() on a regular basis.
* You need to do some long term heavy work in the background,
while the game/UI loop keeps running.
I suppose none of those motivations really apply here, though.
But there must be some more fancy way.
Well, the cleanest, most accurate and most efficient way would probably be to
have playlist support in SDL_mixer, but I suspect that might be non-trivial to
implement. Initializing a new song probably isn’t a “realtime safe” operation
with some music formats (and this is assuming all data is already in RAM!), so
SDL_mixer would have to send that off to a background thread.
Basically, there’s no way you can avoid that issue without risking audio drop-
outs when switching songs. It’s just a matter of where and how it’s
implemented.On Monday 30 November 2009, at 17.35.43, Christoph Nelles wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
