SDL_CloseAudio() Suspend in Windows
===

By using SDL, I need to play audio/video continually, so, after a audio/video playing, I have to call `SDL_CloseAudio()` to close the audio thread, or when playing the successive audio/video, by using `SDL_OpenAudio()`, I'll get error, because the last playing have not close the device.

There should be a callback that you must hook to SDL before call `SDL_OpenAudio()`, and comes the trouble.

I noticed that you cannot access the audio thread directly created by SDL internal(and it's really created the thread). The only way to close the audio is `SDL_CloseAudio()`, and before calling it, you'd better calling `SDL_LockAudio()` first. The `SDL_LockAudio()` ensure that the audio callback is not been called by its internal thread and then is the secure point to call `SDL_CloseAudio`.

By using a flag, we can ensure that the callback is not been called by SDL internal audio thread, and then we try to lock the audio by calling `SDL_LockAudio()`, I think this is perfectly safe, and sometimes it's runs well indeed, but some other times, still suspend in the `SDL_CloseAudio()` calling.

I have tried to change the `SDL_CloseAudio()`. In SDL source code, the audio module is a singleton, we can access its audio thread(is a `SDL_Thread` instance), by using `SDL_KillThread()`, we can terminate the audio thread, this is really *perfectly-safe*, but I'm not sure whether such *brute force* will cause any other problems.

My question is why the lock operation success, but the close operation still suspend?