The past month or so, i've been working on a sound/music engine for custom game engine using DirectX 9.
The sound engine works great in the main thread of an app, but I'd like to put the sound engine in it's own thread, so that window messages don't interfere with filling sound buffers. The problem is I'm not very good with multithreaded programming. Even though I've been programming since high school (96), I still haven't played much with threads (at least not in Windows).
Within the sound engine test app, I create a separate thread, in which all it does is check to see if all sound buffers need to be updated, and updates them if needed. (Yes, it polls.. I simply haven't gotten around to setting up notifications just yet).
The problem is that when stopping the buffer from within the main thread, DirectSound could potentially stop the buffer while it's being updated in the other thread, which makes things sound out of place if Play( ) is called again.
So I thought I could use the CRITICAL_SECTION related win32 functions, but when I press the key that calls Stop( ), sometimes it takes a good 5 seconds before the buffer actually stops playing.
I also tried writing my own "critical section" code.... so basically, in the Update and Stop functions, I do this...
// at start of both Update and Stop...
g_bLocked = TRUE;
// at end of both Update and Stop
g_bLocked = FALSE;
The problem with this is that when I call Stop, it gets stuck in the while loop and never actually stops the buffer. I think that because it's not getting back to the main message loop, the process never does a context switch to the other thread. (Again, it goes back to me not understanding threads).
Unless anyone can clue me in on what i'm doing wrong, I think how I'm gonna fix it is have a Queue object within the sound engine, and that's how it would determine what operations to perform next... so when I call Update in the thread, it will "Queue" a call to Update in the main thread. Calling Stop will also Queue up a stop event in the main thread, which will cause the sound engine to "wait" until the Update for that particular buffer is done.
The problem then becomes one of syncronizing reads and writes to the queue.
I'm not sure why the CRITICAL_SECTION related win32 functions would not work. Aren't these supposed to be pretty effecient? Makes me wonder how long the Updates are taking. I know the Updates are NOT taking 5 seconds tho [smile]
EDIT: I think I found out what I'm doing wrong with the CRITICAL_SECTION functions. I'm only calling InitializeCriticalSection once upon engine initialization, and calling DeleteCriticalSection once upon engine shutdown. Wups. Now I just need to get out of work, so I can go home and try it out.