Question

I cannot find any information about the thread-safety of the waveOut API.

After i creating new waveOut handle, i have those threads:

Thread 1: Buffers handling. Uses those API functions:

• waveOutPrepareHeader
• waveOutWrite
• waveOutUnprepareHeader

Thread 2: Gui, Controller thread. Uses those API functions:

• waveOutPause
• waveOutRestart
• waveOutReset
• waveOutBreakLoop

Those two threads are running while using concurrently the same waveOut handle.
In my tests, i didn’t saw any problem with the functionality, but it doesn’t mean that it safe.

Is this architecture thread-safe?
Is there any documentation about the thread safety of the waveOut API?
Any other suggestions about the waveOut API thread-safety?

thanks.

Answer 1

In general the waveOut API should be thread-safe. Because usually a waveOutOpen() creates its own thread, and all waveOut* functions send messages to that thread. But I can not give you a proof…

However, you can change your application to make it safe in any case:

1. start your thread for buffer management, remember dwBufferThreadId
2. from GUI thread call waveOutOpen with dwCallback set to dwBufferThreadId and fdwOpen to CALLBACK_THREAD
3. your buffer management thread: “waveOutWrite” some buffers in advance, the loop on GetMessage()
4. waveOutOpen will send a WOM_DONE whenever a buffer is finished and a new buffer is required, this is the moment to waveOutWrite a new buffer from within that thread
5. make your calls to waveOutPause, waveOutRestart and so on from GUI thread (nothing in MSDN speaks against it, and all examples do this, even if the buffers will be filled from another thread)

example 1

If you want to be 100% sure, you could just grab a windows message (WM_USER+0), and call PostThreadMessage( WM_USER+0, dwBufferThreadId, MY_CTL_PAUSE,0 ) and then upon receiving that message in your buffering thread, you call waveOutPause() there. Windows message queues save you some work on writing your own message queues 😉