[SDL] Problem with mp3 playback using SDL_mixer and SMPeg.dll

[Rhythmic Fistman]

> From: karx11erx <karx11erx at hotmail.com>

> Fistman,

Him? Never listen to that guy. He's a jerk.

However he does worry when folks assert that killing a thread
is safer than convincing it to exit of natural causes. Poor fellow
had a difficult childhood - they used to whip him with threads.

[...]

> Btw, another problem were Windows project settings. The library should be set to
> 'multithreaded *DLL*', not just 'multithreaded'. Inconsistencies in this setting
> through a project (i.e. smpeg settings this way, main program settings that way)
> are likely to result in smpeg not functioning properly.

This is true. The dll part means, at the very least, that you
get a single allocator and the ability to allocate mem in one component
and free it in another. (Heady stuff!) Anyway, that's what using the debug
version of "multithreaded/non dll" lead me to believe, with its handy asserts.

[...]

> Actually, the entire SDL and SDL_mixer sound handling is crap. You have one
> global setting for frequency etc. - no chance to mix sounds and music if they
> are sampled with different frequencies unless you resample one of them (which I
> had to implement in my case :-/). Why the heck global variables instead of
> encapsuled sound objects operating separately from each other?

Beats me. I did my own mixer for SDL and it's crap too. One of the reasons that
it's crap is that it queues up sounds by modifying a pointer without
any synchronisation (ha! storing a pointer is "atomic", what could go wrong!?),
which of course won't work on the increasingly common non-uniprocessor machines.
Can I use the SDL thread synchronisation functions in the sound callback?
Or is the sound callback not always a thread?

RF