2

我正在开发一个应用程序，该应用程序使用waveOut...来自winmm.dll. 该应用程序使用“跳跃式”缓冲区，它们基本上是一堆样本数组，您可以将它们转储到音频队列中。Windows 按顺序无缝播放它们，并且在每个缓冲区完成时 Windows 调用一个回调函数。在这个函数中，我将下一组样本加载到缓冲区中，然后处理它们，然后将缓冲区转储回音频队列。这样，音频就可以无限期地播放。

出于动画目的，我正在尝试将其合并waveOutGetPosition到应用程序中（因为“缓冲区完成”回调是不规则的，足以导致生涩的动画）。 waveOutGetPosition返回播放的当前位置，所以它是超精确的。

问题是在我的应用程序中，调用waveOutGetPosition最终会导致应用程序锁定 - 声音停止并且调用永远不会返回。我把事情归结为一个简单的应用程序来演示这个问题。您可以在此处运行该应用程序：

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

如果你只是一遍又一遍地听到一点点钢琴声，它就起作用了。它只是为了证明问题。这个项目的源代码在这里（所有的肉都在 LeapFrogPlayer.cs 中）：

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

第一个按钮以越级模式运行应用程序，无需调用waveOutGetPosition. 如果单击此按钮，应用程序将永远播放而不会中断（X 按钮将关闭它并关闭它）。第二个按钮启动跳跃器并启动一个表单计时器，该计时器调用waveOutGetPosition并显示当前位置。单击此按钮，应用程序将运行一会儿，然后锁定。在我的笔记本电脑上，它通常会在 15-30 秒内锁定；最多只需要一分钟。

我不知道如何解决这个问题，所以非常欢迎任何帮助或建议。我发现关于这个问题的帖子很少，但似乎存在潜在的死锁，无论是多次调用waveOutGetPosition还是waveOutWrite同时发生的调用。我可能过于频繁地调用它，系统无法处理。

编辑：忘了提，我在 Windows Vista 上运行它。这在其他操作系统上可能根本不会发生。

编辑2：除了这些（未回答的）帖子外，我在网上几乎没有发现这个问题：

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

编辑3：嗯，我现在可以随意重现这个问题。如果我waveOutGetPosition在之后waveOutWrite（在下面的代码行中）立即调用，则应用程序每次都会挂起。它还以一种特别糟糕的方式挂起 - 它似乎将我的整个操作系统锁定了一段时间，而不仅仅是应用程序本身。因此，waveOutGetPosition如果死锁发生在与几乎相同的时间waveOutWrite，而不仅仅是字面上的同时发生，这似乎可以解释为什么锁对我不起作用。是的。

4

3 回答 3

3

它在 mmsys API 代码中死锁。当主线程忙于执行 waveOutWrite() 时，在回调死锁中调用 waveOutGetPosition()。它是可以修复的，你需要一个锁，这样这两个函数就不能同时执行。将此字段添加到 LeapFrogPlayer：

    private object mLocker = new object();

并在 GetElapsedMilliseconds() 中使用它：

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

和 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");
          }
        }

这可能有副作用，但我没有注意到。看看NAudio 项目。

下次创建项目的可上传 .zip 时，请使用 Build + Clean。

于 2010-03-16T11:29:14.147 回答
1

我经常使用NAudio和查询，并且在使用策略WaveOut.GetPosition()时也看到频繁的死锁。Callback这本质上与 OP 遇到的问题相同，因此我认为此解决方案可能对其他人有所帮助。

我尝试使用基于窗口的策略（如答案中所述），但是当大量消息被推送通过消息队列时，音频会断断续续。所以我转向了Callback策略。然后我开始陷入僵局。

我正在以 60 fps 的速度查询音频位置以同步动画，因此我经常遇到死锁（平均运行大约 20 秒）。注意： 我确信我可以减少调用 API 的数量，但这不是我的意思！

似乎winmm.dll调用都在内部锁定在同一个对象/句柄上。如果这个假设成立，那么我几乎可以肯定 NAudio 会陷入僵局。这是有两个线程的场景：A（UI 线程）；和B（回调线程winmm.dll）和两个锁waveOutLock（如在 NAudio 中）和mmdll（我假设 winmm.dll 正在使用的锁）：

  1. A -> 锁 (waveOutLock) --- 获得
  2. B -> lock (mmdll) for callback --- 已获得
  3. B -> 回调到用户代码
  4. B -> 尝试锁定 (waveOutLock) -- 等待 A 释放
  5. A -> 由于 B 等待而恢复
  6. A -> 调用 waveOutGetPosition
  7. A -> 尝试锁定 (mmdll) -- 死锁

我的解决方案是将回调中完成的工作委托给我自己的线程，以便回调可以立即返回并释放（假设的）mmdll锁。这似乎对我来说非常有效，因为僵局已经过去了。

对于那些感兴趣的人，我已经分叉并修改了 NAudio 源以包含我的更改。我使用了线程池，音频偶尔会有点噼啪声。这可能是由于线程池线程管理，所以可能有性能更好的解决方案。

于 2013-05-09T18:46:03.300 回答
0

对此的解决方案非常简单（感谢 Larry Osterman）：将回调替换为 WndProc。

waveOutOpen 方法可以采用委托（用于回调）或窗口句柄。我使用的是委托方法，这显然天生就容易死锁（这是有道理的，尤其是在托管代码中）。我能够简单地让我的播放器类继承Control并覆盖该WndProc方法，并在此方法中执行与回调中相同的操作。现在我可以waveOutGetPosition永远打电话而且它永远不会锁定。

于 2010-03-17T15:54:39.777 回答