title: SDL_CloseAudio() Suspend in Windows
body: <p>By using SDL, I need to play audio/video continually, so, after a audio/video playing, I have to call <code>SDL_CloseAudio()</code> to close the audio thread, or when playing the successive audio/video, by using <code>SDL_OpenAudio()</code>, I'll get error, because the last playing have not close the device.</p>
  
  <p>There should be a callback that you must hook to SDL before call <code>SDL_OpenAudio()</code>, and comes the trouble.</p>
  
  <p>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 <code>SDL_CloseAudio()</code>, and before calling it, you'd better calling <code>SDL_LockAudio()</code> first. The <code>SDL_LockAudio()</code> ensure that the audio callback is not been called by its internal thread and then is the secure point to call <code>SDL_CloseAudio</code>.</p>
  
  <p>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 <code>SDL_LockAudio()</code>, I think this is perfectly safe, and sometimes it's runs well indeed, but some other times, still suspend in the <code>SDL_CloseAudio()</code> calling.</p>
  
  <p>I have tried to change the <code>SDL_CloseAudio()</code>. In SDL source code, the audio module is a singleton, we can access its audio thread(is a <code>SDL_Thread</code> instance), by using <code>SDL_KillThread()</code>, we can terminate the audio thread, this is really <em>perfectly-safe</em>, but I'm not sure whether such <em>brute force</em> will cause any other problems.</p>
  
  <p>My question is why the lock operation success, but the close operation still suspend?</p>