Mus*_*sis 1 windows audio waveoutwrite waveout
我正在与另一个论坛上的一些开发人员就准确生成MIDI事件(Note On messages等)进行辩论.人耳对于轻微的定时误差非常敏感,我认为他们的主要问题来自于他们使用相对低分辨率的定时器,这些定时器以大约15毫秒的间隔量化它们的事件(这足以引起可察觉的不准确性).
大约10年前,我编写了一个示例应用程序(Windows 95上的Visual Basic 5),它是一个组合的软件合成器和MIDI播放器.基本前提是一个蛙跳缓冲回放系统,每个缓冲区是十六分音符的持续时间(例如:每分钟120个四分音符,每个四分音符是500毫秒,因此每个十六分音符是125毫秒,所以每个缓冲液是5513个样品).每个缓冲区都通过waveOutWrite方法播放,此方法的回调函数用于排队下一个缓冲区并发送MIDI消息.这使基于WAV的音频和MIDI音频保持同步.
在我看来,这种方法工作得非常完美 - MIDI音符听起来甚至没有声音(如果你使用一个普通的计时器,精确到15毫秒来播放MIDI音符,它们会听起来明显不合时宜).
理论上,这种方法可以产生对样本准确的MIDI定时,或0.0227毫秒(因为每毫秒有44.1个样本).我怀疑这是这种方法的真正延迟,因为在缓冲区完成和通知waveOutWrite回调之间可能存在一些轻微的延迟.有谁知道这种延迟实际上有多大？
默认情况下,Windows调度程序以10毫秒或16毫秒的间隔运行,具体取决于处理器.如果使用timeBeginPeriod()API,则可以更改此间隔(以相当大的功耗成本).
在Windows XP和Windows 7中,wave API以大约30ms的延迟运行,对于Windows Vista,wave API的延迟大约为50ms.然后,您需要添加音频引擎延迟.
不幸的是,我没有一个方向的引擎延迟数字,但我们确实有一些关于引擎延迟的数字 - 我们运行了一个测试,通过USB音频设备播放音调并测量往返延迟(渲染到捕获).在Vista上,往返延迟约为80毫秒,变化约为10毫秒.在Win7上,往返延迟约为40毫秒,变化约为5毫秒.然而,YMMV由于音频硬件引入的延迟量对于每个硬件而言是不同的.
我完全不知道XP音频引擎或Win9x音频堆栈的延迟是什么.