Problem with waveOutWrite and waveOutGetPosition deadlock

Question

I'm working on an app that plays audio continuously using the waveOut... API from winmm.dll. The app uses "leapfrog" buffers, which are basically a bunch of arrays of samples that you dump into the audio queue. Windows plays them seamlessly in sequence, and as each buffer completes Windows calls a callback function. Inside this function, I load the next set of samples into the buffer, process them however, and then dump the buffer back into the audio queue. In this way, the audio plays indefinitely.

For animation purposes, I'm trying to incorporate waveOutGetPosition into the application (since the "buffer done" callbacks are irregular enough to cause jerky animation). waveOutGetPosition returns the current position of playback, so it's hyper-precise.

The problem is that in my application, making calls to waveOutGetPosition eventually causes the application to lock up - the sound stops and the call never returns. I've boiled things down to a simple app that demonstrates the problem. You can run the app here:

http://www.musigenesis.com/SO/waveOut%20demo.exe

If you just hear a tiny bit of piano over and over, it's working. It's just meant to demonstrate the problem. The source code for this project is here (all the meat is in LeapFrogPlayer.cs):

http://www.musigenesis.com/SO/WaveOutDemo.zip

The first button runs the app in leapfrog mode without making the calls to waveOutGetPosition. If you click this, the app will play forever without breaking (the X button will close it and shut it off). The second button starts the leapfrogger and also starts a forms timer that calls the waveOutGetPosition and displays the current position. Click this and the app will run for a short while and then lock up. On my laptop, it usually locks up in 15-30 seconds; at most it's taken a minute.

I have no idea how to fix this, so any help or suggestions would be most welcome. I've found very few posts on this issue, but it seems that there is a potential deadlock, either from multiple calls to waveOutGetPosition or from calls to that and waveOutWrite that occur at the same time. It's possible that I'm calling this too frequently for the system to handle.

Edit: forgot to mention, I'm running this on Windows Vista. This might not happen at all on other OSes.

Edit 2: I've found little about this problem online, except for these (unanswered) posts:

http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/c6a1e80e-4a18-47e7-af11-56a89f638ad7

Edit 3: Well, I'm now able to reproduce this problem at will. If I call waveOutGetPosition immediately after waveOutWrite (in the following line of code) the application hangs every time. It also hangs in an especially bad way - it seems to lock up my whole OS for awhile, not just the app itself. So it appears that waveOutGetPosition deadlocks if it occurs at nearly the same time as waveOutWrite, not just literally at the same time, which might explain why the locks aren't working for me. Yeesh.

Answer 1

The solution to this was very simple (thanks to Larry Osterman): replace the callback with a WndProc.

The waveOutOpen method can take either a delegate (for callback) or a window handle. I was using the delegate approach, which is apparently inherently prone to deadlocking (makes sense, especially in managed code). I was able to simply have my player class inherit from Control and override the WndProc method, and do the same stuff in this method that I was doing in the callback. Now I can call waveOutGetPosition forever and it never locks up.

Answer 2

It deadlocks inside the mmsys API code. Calling waveOutGetPosition() inside the callback deadlocks when the main thread is busy executing waveOutWrite(). It is fixable, you'll need a lock so these two functions cannot execute at the same time. Add this field to LeapFrogPlayer:

    private object mLocker = new object();

And use it in GetElapsedMilliseconds():

        if (!noAPIcall)
        {
          lock (mLocker) {
            ret = WaveOutX.waveOutGetPosition(_hWaveOut, ref _timestruct,
                _timestructsize);
          }
        }

and HandleWaveCallback():

        // play the next buffer
        lock (mLocker) {
          int ret = WaveOutX.waveOutWrite(_hWaveOut, ref _header[_currentBuffer],
              Marshal.SizeOf(_header[_currentBuffer]));
          if (ret != WaveOutX.MMSYSERR_NOERROR) {
            throw new Exception("error writing audio");
          }
        }

This might have side-effects, I didn't notice any though. Take a look at the NAudio project.

Please use Build + Clean the next time you create an uploadable .zip of your project.

Answer 3

I'm using NAudio and querying WaveOut.GetPosition() frequently, and also seeing frequent deadlocks when using the Callback strategy. This is essentially the same problem the OP was having, so I figure this solution might help someone else.

I tried using window-based strategies (as noted in the answer) but the audio would stutter when lots of messages were being pushed through the message queue. So I switched to the Callback strategy. Then I started getting deadlocks.

I'm querying audio position at 60 fps to sync an animation, so I'm hitting the deadlock quite regularly (about 20 seconds into a run on average). Note: I'm sure I can reduce the amount that I call the API, but that's not my point here!

It seems that winmm.dll calls are all locking internally on the same object/handle. If that assumption holds, then I'm nearly guaranteed a deadlock in NAudio. Here's the scenario with two threads: A (UI thread); and B (callback thread in winmm.dll) and two locks waveOutLock (as in NAudio) and mmdll (the lock I'm assuming winmm.dll is using):

1. A -> lock (waveOutLock) --- acquired
2. B -> lock (mmdll) for callback --- acquired
3. B -> callback into user code
4. B -> attempt to lock (waveOutLock) -- waiting for A to release
5. A -> resumed due to B waiting
6. A -> call waveOutGetPosition
7. A -> attempt to lock (mmdll) -- deadlock

My solution was to delegate the work done in the callback to my own thread so that the callback can return immediately and release the (hypothetical) mmdll lock. This seems to work perfectly for me, as the deadlock is gone.

For those interested, I've forked and modified the NAudio source to include my change. I used the thread pool, and the audio is occasionally a little crackly. This may be due to thread pool thread management, so there may be solution that performs better.