I’ve been looking into the SDL and SDL_mixer source to try to deduce any possible cause for the crashes that our multicore users get. It seems evident to me that it is not in fact SDL_mixer but SDL_audio itself which must be to blame, since only the latter deals in calling routines on separate threads.
I’m not much for multithreaded programming, and I’m not going to pretend that I know this is the cause, but shouldn’t the SDL_audio core at least check for mutex acquisition failure before assuming it is safe to modify the audio buffer? As is, it is simply calling SDL_mutexP without checking the return value. Also, there are possible return values from Win32 function WaitForSingleObject other than WAIT_FAILED which might indicate there’s some kind of problem, such as WAIT_ABANDONED. The SDL_mutexP API does not provide for checking these other values.
To quote MSDN on WAIT_ABANDONED:
“If the mutex was protecting persistent state information, you should check it for consistency.”
I’d imagine if the return value was anything other than strictly positive, it would be best to not to try to dispatch the audiospec callback routine. I don’t understand what would be causing the mutex acquisition to fail, or if it is in fact failing. All I know is that something is wrong, leading to invalidation of the audio buffer during execution of the SDL_mixer postmix callback routine. This is Win32-specific and only occurs on multicore processors.
Though my users have these problems with SDL 1.2.12, I am referring to the current trunk sources for these investigations, so this is not an out-of-date concern.
Lead Programmer, Team Eternity_________________________________________________________________
The other season of giving begins 6/24/08. Check out the i?m Talkathon.