什么是延迟（或延迟）时间从waveOutWrite API方法回调？ [英] What is the latency (or delay) time for callbacks from the waveOutWrite API method?
问题描述
我在与一些开发商在另一个论坛关于准确生成MIDI事件的争论（注意：在邮件等等）。人耳是轻微的计时误差pretty敏感，我认为他们的主要问题来自其使用较低分辨率的定时器其量化约15毫秒的间隔（这是大到足以引起感知不准确），他们的活动。
大约10年前，我写了这是一个组合的软件合成器和MIDI播放机的示例应用程序（Visual Basic中5在Windows 95）。基本的premise是一个跨越式缓冲播放系统，每个缓冲区是一个十六分音符的例子（时间：每分钟120四分之一音符，每个四分音符为500毫秒，因此每个十六分音符为125毫秒，所以每个缓冲区是5513个样本）。各缓冲液经由waveOutWrite方法发挥，由该方法回调函数用来排队的下一个缓冲器并发送MIDI信息。这些都使基于WAV音频和MIDI音频同步。
在我听来，这种方法非常完美 - （而如果你使用一个普通的计时器精确到15毫秒播放MIDI音符，它们将显着试探步）的MIDI音符甚至没小幅试探步<。 / p>
在理论上，这种方法会产生的MIDI定时精确到样本，或0.0227毫秒（因为有每毫秒44.1样本）。我怀疑，这是这种方法的真正延迟，因为有presumably的waveOutWrite回调通知时，缓冲结束时之间有一些轻微的延迟。有谁知道有多大这种拖延实际上是？
Windows计划在任一10ms的16ms的或间隔默认情况下，根据不同的处理器上运行。如果您使用timeBeginPeriod（）API，您可以更改此时间间隔（在一个相当显著电力消耗费用）。
在Windows XP和Windows 7，波的API约30毫秒时延运行的Windows Vista波的API具有约50毫秒时延。然后，您需要在音频引擎延迟添加。
不幸的是，我没有号码在一个方向发动机延迟，但我们有关于发动机的延迟的一些数字 - 我们进行了测试，通过USB音频设备起到了口气环回和测量的往返延迟（渲染捕捉）。在Vista往返潜伏期约10毫秒的变化80ms左右。在Win7的往返潜伏期约5ms的变化40ms左右。因人而异但是由于由音频硬件引入的延迟量是用于每个硬件不同
我完全不知道是什么的潜伏期为XP音频引擎或Win9x的音频堆栈。
I'm having a debate with some developers on another forum about accurately generating MIDI events (Note On messages and so forth). The human ear is pretty sensitive to slight timing inaccuracies, and I think their main problem comes from their use of relatively low-resolution timers which quantize their events around 15 millisecond intervals (which is large enough to cause perceptible inaccuracies).
About 10 years ago, I wrote a sample application (Visual Basic 5 on Windows 95) that was a combined software synthesizer and MIDI player. The basic premise was a leapfrog-buffer playback system with each buffer being the duration of a sixteenth note (example: with 120 quarter-notes per minute, each quarter-note was 500 ms and thus each sixteenth-note was 125 ms, so each buffer is 5513 samples). Each buffer was played via the waveOutWrite method, and the callback function from this method was used to queue up the next buffer and also to send MIDI messages. This kept the WAV-based audio and the MIDI audio synchronized.
To my ear, this method worked perfectly - the MIDI notes did not sound even slightly out of step (whereas if you use an ordinary timer accurate to 15 ms to play MIDI notes, they will sound noticeably out of step).
In theory, this method would produce MIDI timing accurate to the sample, or 0.0227 milliseconds (since there are 44.1 samples per millisecond). I doubt that this is the true latency of this approach, since there is presumably some slight delay between when a buffer finishes and when the waveOutWrite callback is notified. Does anyone know how big this delay would actually be?
The Windows scheduler runs at either 10ms or 16ms intervals by default depending on the processor. If you use the timeBeginPeriod() API you can change this interval (at a fairly significant power consumption cost).
In Windows XP and Windows 7, the wave APIs run with a latency of about 30ms, for Windows Vista the wave APIs have a latency of about 50ms. You then need to add in the audio engine latency.
Unfortunately I don't have numbers for the engine latency in one direction, but we do have some numbers regarding engine latency - we ran a test that played a tone looped back through a USB audio device and measured the round-trip latency (render to capture). On Vista the round trip latency was about 80ms with a variation of about 10ms. On Win7 the round trip latency was about 40ms with a variation of about 5ms. YMMV however since the amount of latency introduced by the audio hardware is different for each piece of hardware.
I have absolutely no idea what the latency was for the XP audio engine or the Win9x audio stack.
这篇关于什么是延迟（或延迟）时间从waveOutWrite API方法回调？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
