赛因技术：从理论上的数字以及制造商的量测结果来看，通常认为软件合成器的延迟是可被忽略的-- 但如果当你弹奏它们时，这延迟是随处可得的时候，我想这样的认定是没用的。 我们的实际量测将会有助于你建立正确的观念回到SOS November 2000的时候，我们那时讨论过许多文章，谈到有关合成器如何由硬件转为软件的变化，包含了音质、取样以及软件合成的替代、延迟以及延迟时基错误(latency jitter)..等问题，相关文章可自以下连结取得 http://www.sospubs.co.uk/sos/sep02/articles/。 VST与DX软件合成器之美，在于其播放自Midi+Audio编曲软件时的Timing总是被保证如取样精确度(Sample Accurancy)般的准确，因为其波形的产生时间较早，而输出的声音刚好跟其它的音轨同时出现。
然而，在其后SOS的讨论区中，有些人发现Midi延迟所产生的时基错误却是让他摇头的问题，实际上，这意味着不是只有某些应用软件存在着按下音符与听到软件合成器声音之间的时间延迟，而是这样的延迟非常不稳定，举例来说，如果我们把Cuabse 5.1的Buffer设成12ms，则当你实际演奏时的MIDI-to-audio的延迟可能会在12ms 到24ms之间变化。 
自从我写下了这个特征之后，我发现许多的SOS 读者仍然陆续发表了一些Midi Timing的牢骚问题，不论是来自标准MIDI录音以及弹奏软件合成器都有。所以，我想该是时候把理论先放一边，我们该来做些更实际的真实测试方法。我想做的其实是以各种不同的软件与硬件，测试从外部键盘按下琴键之后，到声音从喇叭输出时所量测到的实体延迟。
测试的设定
在设定我的测试设备时，我的焦点在于比较整个信号流程末端的声音输出时，以及Midi信号开始产生时，最前端的时间点，所以我决定尝试直接从我的Midi键盘后端的Midi输出端口撷取信号，焊上一个修改过的MIDI 信号转接器，在优秀的“Hinton Instruments Professional MIDI导引”中有关于它的描述。
(http://www.hinton.demon.co.uk/midi/promidi.html)，这使得我能够有效的从Midi端口的第二以及第五个接脚直接撷取信号来监看，这部分唯一不能减少的延迟是键盘扫描的延迟，这通常花1ms的时间，虽然某些早期的合成器如 Prophet 5只扫描键盘大约200次/秒，亦即每次产生5ms的延迟，时间长短其实取决于在每个扫描循环中你何时按下键盘。
我决定用我的录音卡来录制MIDI波形，所以为了安全起见我在第五个接脚接上一个5.1kOhm 的电阻，来避免因Midi信号错误对录音卡造成的伤害，然后将它焊到Line-in的输入导线上，我把这样的组合从Midi键盘的输出端，插入至录音卡的信号输入端，我想要探查这样输入的Midi信号转为Audio所需的时间，.我弹下了几个音符，然后录制起来，最后结束时我停留在MidiNote On的信息，所以一个Midi频道 录Midi信号，另一个轨道则是录制相关联的声音信号，这两者的差异提供了关于Midi to Audio延迟的精确数值，包含整个信号流程的各种变量，包含MIDI接口、驱动程序、Windows操作系统乃至于软件合成器的处理以及暂存的延迟。 最后才是数字转换为模拟信号时产生的延迟，因为这些流程中产生的延迟可能都是某些使用者会遇到的问题，所以看起来把它们总合起来似乎是很重要的。 
如果你想要在家自己做测试，只把这条特殊线接上你的录音卡，在测试过程中，因为在接上某些键盘时可能会产生接地循环(Ground Loop)的情形。 虽然MIDI的规格通常是很谨慎的设计过来避免这种问题，藉由迫使每组Midi输入都绝缘，使得两组相连的Midi设备他们的金属底座绝不会直接接触，即使是声霸卡的Gameport MIDI转接线(即MidiKit)在Midi输入端也会做绝缘，让第二个接脚如同没有接信号一样，所以如果你接上了MidiKit之后机器产生了Hum声，记得要要求更换。 录音与量测
在接下来的量测当中，我企图屏除因实验所发生的错误，因此我每按一个音都取大约6次的结果来平均，过程中如果有某些不寻常的数值出现，我则会多加考虑(多加测试)， 大部分的时候结果都是相似的，偶尔会有些数值偏高，大多都还在一个重复的范围之中变化，而这些变化就预设为是因为jitter延迟所造成。我使用我的Echo Mia来录音，大部分在44.1kHz的取样频率，即使使用22kHz的频宽，仍然可以非常清楚的看到31.25kbaud的MIDI data所呈现出来的证明。
大部分的Midi设备都发出一种称为Active Sensing的侦测信息来探测连结的MIDI线或是设备是否故障，所以在你用录音卡录Midi信息时可能会看到负象限的波形，好在它们是很容易跟其它信息如Note On来做区别，Note On的信息如同一丛宽大的脉波，延迟大约1ms，因为你已经知道延迟的大约数值，所以你会很快聚焦在Note On信息与每个软件合成器的声音音符之间的关联数值，只要你证明出第一组数值，之后出现的你都会很容易看得出来。 
我所有的测量都起始于弹下键盘让MIDI Note On message出现时，严格说来， 没有一台合成器可以完全将MIDI data的信息反应至完全实时，这会使得真实的MIDI Note On的信息比实际量测时要少1ms， 所以如果你要求严格的反应时间，那最好要将结果减1ms，然而，键盘又于内部扫描延迟的问题，大多会比Midi信息提前1ms送出信息，两者刚好可以相抵销， 所以我们所报导的数字可以准确的表现出从键盘被按下到合成器开始发声的时间。
产生一个易于测量合成器发声起始点的方法，就是以一个方波或是脉波来发音，把它的截止频率(CutOff Frequency)开到最大，把响应(Resonance)开到最小，把它们的波形产生器的上升(Ataack)时间调到最快，测量它的波形上升起始时间， 我重复测量了几乎上百次，很有自信的认定它们的准确度可达误差小于 0.1ms
硬件的MIDI 延迟
藉由开始量测几台合成器的Midi Note On数据与声音输出之间的延迟，来提供一些有用的信息，并与它们相对应的软件合成器来做比较，看起来是个蛮明智的方法。 所以我开始测量我的老琴Korg M1，结果如同大部分的硬件合成器，我所测量的延迟结果非常一致，而且极低到仅有3.2ms，以一个16-note发声数的琴来说是个很不错的结果。
另一台工业标准则是Roland's JV1080,，它的延迟也非常稳定，不过比较长一些，有4.4ms之久，当然无疑的因为它是64-note发声数的合成器，对于希望硬件合成器能具备实时响应的人来说，这些结果似乎蛮令人满意， 不过大多的合成器都是透过他们本身的微处理器来驱动，虽然其操作系统都明显经过仔细的调教以致于能够实时演奏，然而要处理每个动作与功能的时候，仍会占用固定的时间。
PC MIDI 界面
既然我们已经建立某些硬件合成器的反应时间结果，接下来就是把PC的MIDI接口合并到我们的信号流程中，我开始把我的键盘YAMHA SW1000XG的Midi输入端利用Midi线连接起来，由于1000XG内建MU100R这台音源，所以当然也是将它加入到整个信号流程中， SW1000XG内建音源，是使用P21 custom gate array处理器来处理MIDI信息，不过声音是透过PCI总线传输，还有数字的Clock信息以及其它功能。
当然我们现在的测试开始包含了PC的操作系统，在Windows 98SE的系统之下，几乎一定会有某种程度的不确定的时间延迟问题，特别是当我透过软件把接口、音源连结起来的时候，在这个测试中，我使用XGedit95，大部分的时间我所测量的延迟结果都还不错，大约只有3.4ms到3.9ms之间， 和硬件合成器的表现几乎相当， 但是偶尔也会运行到11ms这么多， 我猜想这可能是因为被gate array (or Windows)占据的时间
然后，我使用Midiman Midisport 8x8/s接口(使用serial port的版本而非USB)， 连接键盘到Midi in的端口，如同SW1000XG的方式相同，它的延迟变成大约是4.3ms以及4.9ms，比直接输入到SW1000XG的Midi in大约要慢1ms，虽然如此，录音量测最高的延迟是7.7ms， 这个数据显示了使用不同的PC MIDI 接口，其延迟也会有不同，.这并不是接口本身的问题，而是而是由于透过Serial port端口多增加的路径让时间延迟变大了。
推荐大家多使用PCI版本的MIDI界面，或是透过某些PCI录音卡本身提供的Midi端口， 来取代serial, parallel 或是USB版本的设备，因为它们的传输速率比较快，我的测试结果似乎支持这样的说法， 不过，我的Midisport 8x8/s支持serial 以及USB两种连接方式， 所以我们有个理想的机会来测量使用不同连接方式的结果， 为了做这个测试，我解除安装1.05版的 serial port驱动程序(这是目前能取得最新的版本)，并且安装了最新的1.08 USB的驱动程序，在测量之后，所读取的数值大约是在7.0ms到9.1ms之间，大约比 serial port的版本还要慢3ms左右，.我猜想这可能是因为传输结构的不同，可能也跟每个接口接受数据的频繁程度有关
此外，很偶尔的情况之下，延迟会高达13.2ms，这似乎印证了某些人常说“USB接口比较容易产生时基错误”的传言，而且产生的机率要大于其它方式的两倍，不过这还不能就这样下定论，特别是这个结果还是会受我计算机设定的影响，如果你们还有其它的程序或指令同时执行的时候，可能会遇到更大的延迟，这取决于这些东西是否需求的很频瀪以及它们是否被赋予较高的优先权…等。
Serial, Parallel, PCI Or USB?
录音卡的MME驱动程序
我们的下个步骤是测试软件合成器，要增加整个信号流程里录音卡播放时的不确定性，我从测量Native Instruments' Pro 52在MME Driver下的表现开始， 我选择它的原因是因为无疑它是目前最能被证明的软件合成器，有独立版本、VSTi以及现在最新的DXi多种格式，也因为它的Play Ahead silder(提前播放滑杆)延迟测量广为PC之下的所有NI软件使用，包含 Absynth, B4, Kontakt 以及 Reaktor。
当我评鉴录音卡时，我通常会以我所能做到最低的MME Pro 52延迟设定来当做该卡MME驱动程序的品质预估，但有时我也会对显示出来的数字有些存疑。 现在是我第一次有机会可以好好的量测一下它们的数值，当然也包含Midi接口的组件在内。
如果你想自己做这些实验，请确实注意要检查Midi/Audio录音成品播放的速度，以确认其音高与原来在软件合成器上弹奏的相同。在几次Pro52的试验后，我发现如果Pro 52 已经确定要使用我的Echo Mia来当输出44.1kHz的接口，然后我在Wavelab 4.0内选择它的输出来做MIDI/audio的录音， 不管我在Wavelab 里如何选择取样频率，我都用44.1kHz 来录音，举例来说，我用96kHz来录音，那播放时自然也是96KHz，但是当你在听声音的时候，你要知道播放的却是44.1kHz两倍的速度，这会在延迟时间的测试过程中，把你自己全部搞混乱。
我首先做10ms设定的Play Ahead(提前播放)测试，从SW1000 MIDI 输入信号时，约有8.9 到13.7 ms的延迟，当我们提前50ms来播放时，大约有40ms的超前情形，所以，所以当我们减去Midi本身的3.5 到 3.9ms的Midi延迟，剩下的就是MME驱动程序带来的的延迟，所以剩下的延迟大约是5ms。 
NI公司说当使用MME 驱动程序时要尽量让MIDI的延迟降低，他们准备了大约5ms (at 44.1kHz)的Buffer，当Buffer准备完成，他们才会送信息让录音卡动作，而当录音卡结束播放Buffer时，会将信息再次送回。如果信息比Buffer要大，Buffer的容量就会慢慢增加，反之，他们就会稍微缩小，而提前播放时间所指示的5ms，就是要让你确定你的录音卡不会用完声音所需要的Buffer容量。
然而，当我在SW1000XG上测量Pro 52 的时候，我得到非常不同的结果， 在不破音之下我所能用的最少Buffer也需要20ms，但是这却造成了42.3ms 到46.0ms的测量延迟，如果把提前播放时间调到40ms，则结果会是在61.3与66.1ms之间，这个证实了我的疑点—所有被测量的数值都比报导的要高出约20ms，我这样说的理由是因为NI的结构只会显示在它控制之下的软件Buffer大小，但是在现在这个SW1000XG的测试中，录音卡上还有一个浮动的硬件Buffer，在44.1kHz的状态之下会造成23.2ms的延迟增加，这样的设计让大家更混淆了，还好现在很多录音卡都已经不做这样的设计。
不过这也告诉了我们不能一味相信软件所提供的延迟时间数?，许多SW1000XG的使用者都说在Sonar底下使用WDM驱动程序所造成的延迟只有12ms，可是为了避免掉拍，通常硬件都避免让延迟低于28ms，这其中的误差是来自于驱动程序并没有正确的回报Buffer Size所造成。
GigaStudio GSIF驱动程序 我对于测量GigaStudio's的延迟表现特别有兴趣，因为他们的程序发展者已经持续的对Windows保留与Midi接口对等的低阶接口， GSIF明显的是直接跟录音卡的内核(kernel)去沟通，也同时让软件的操作流程都停留在内核，这点不像是ASIO 以及 WDM，它们两者是透过Windows 的I/O Manager来跟录音卡内核沟通， GSIF的驱动程序一般使用3组128 samples的Buffer，使MIDI to audio的延迟在Midi Data被接收时，理论上能保持在5.8ms 到 8.7ms(在44.1kHz之下)。
在我的Echo Mia录音卡上使用GSIF的驱动程序， 并使用SW1000XG的Midi输入，我测量的延迟约在9.8ms 到 12.9ms之间；使用Midisport 8x8/s 的Serial Port，延迟约为10.6ms 到13.7ms 之间；使用Midisport 8x8/s 的USB驱动程序，延迟则约在15.3ms到17.7ms之间。跟测量XGedit95的情形不同的地方是，即使使用USB的Mdii接口，也不会有偶发的高延迟情形出现，这似乎证明了GSIF驱动程序确实能够将jitter延迟控制在3ms， 所以即便它的整体延迟会高于硬件合成器，弹奏GigaStudio 还是会因而感到比较“紧实”一点。
Steinberg ASIO驱动程序 
有许多的音乐人目前都依赖由ASIO drivers提供他们足够低的延迟，以监听他们的录音过程， 同时也能够实时弹奏软件合成器，为了量测他们的表现，我还是再次使用Echo Mia以及独立版本的NI's Pro 52，不过这次我使用ASIO驱动程序，在Buffer为128-sample、 44.1kHz下量测，它的理论数值是2.9ms。
这次我也实际录制声音的延迟(如附图所示)为大约5.0ms，所以当弹奏Pro 52 时我所量测到的延迟约在7.8ms 到 9.7ms之间，这包含了serial MIDI接口的部分，感觉上是个很优秀的结果，我使用Pro 52 来当作VST Instrument在Cubase 5.1之下使用相同的ASIO驱动程序做交替测试，证明其结果相同。
使用相同的接口来与GSIF来做比较，透过ASIO驱动程序来运行Pro 52 ，不论是在独立或是VST Instrument上，在延迟与时基错误的图表表现上都比较优秀，然GigaStudio 160 能够在发声数高达160个的时候还保持它的表现(假设你的硬盘可以处理)，这里大部分的音乐人都知道如果你要增加ASIO驱动程序的负载时，为了避免断音都必须要调高Buffer Size。
因为这个想法，所以我又多做的其它的测试，首先将Buffer Size设到256个Sample，理论的延迟为5.8ms (而透过我的Echo Mia 所量测到的实际延迟为8.0ms)，而MIDI to audio的延迟约在10.3ms 至 15.5ms之间变化，跟GSIF的3ms的延迟比较，显示ASIO jitter组件提升高了将近5ms的延迟， 对于因某些原因导致无法使用256Sample而必须使用512 sample的使用者来说，虽然在Cubase内部报导的延迟仍为11.6ms (实际为13.7ms)，实际上的MIDI to audio的延迟变化则为16.0ms 至 27.4ms -- 这是个蛮大的jitter问题。
我也同时使用M Audio's USB Duo来测量， 让我们也有机会来测试现今流行的USB audio接口的延迟，它最由Pro 52得到最低的ASIO设定是 441 samples，相当于在44.1kHz 之下有10ms的延迟 ，而在此Sample下实际的量测结果为11.7ms --只有增加了76个samples，这比我的Echo Mia所得到的结果要好，然而，当我们透过USB Duo弹奏软件合成器时，事情看来却不是那么乐观，为了减低任何因为同时连接两组USB设备所造成的干扰， 于是我决定把我Midisport 8x8/s的USB驱动程序拿掉，而使用我 SW1000XG上的MIDI输入，然而，即使是在这么基本的设定之下，从按下键盘到软件合成器声音输出所经过的时间，仍然是约有13.6ms，而变化最大则到32ms，我测量了大约12次，不论是从Pro 52 的独立版本或是透过Cubase的VSTi， 并且一再检测任何我所想到可能影响Duo USB优先权的因素，结果都没有任何改善。
我唯一可以推测的是， USB audio的动作也许因此而造成了MIDI Data被延迟， 这是令人烦恼的，因为我的USB MIDI接口单独使用时非常正常，即使它的延迟以及时基都比使用Serial Port的时候要来的大， 而M Audio Duo再录音时使用也很正常，在全双工的模式之下延迟约为10ms(44.1kHz) ，不过，这些细节我们容后再详谈。
即使没有任何MIDI组件，真实世界的声音延迟量测还是比Buffer Size上所显示的要来的大不论你是否已经看完这整套理论，或是只是依照喜好选择你认为有兴趣的来看，应该都会让你有很多地方可以思考，虽然有许多音乐家完全依赖软件的公用程序所得到的数据，而事实显然远比所认定的要复杂， 包含许多比录音卡的Buffer大小以外的因素，所以有时会与报导的数值有些许不同，有时则根本大相径庭。
主应用程序如Cubase VST, Logic Audio或是Sonar等的VST/DX软件合成器现在都提供Sample-accurate的playback timing。然而当录音卡的Buffer的延迟降至3ms，或甚至1.5ms或是更少的时候，实时来弹奏软件合成器时绝不可能提供sample-accurate的timing，由我的测量结果得知，在你听到声音之前，录音卡的延迟是可能增加3ms到15ms，延迟多来自于MIDI接口与Windows操作系统。
这也同时解释了为什么有些音乐家会宣称他们发现软件合成器很迟钝的原因，即使录音卡的buffer已经调到只剩下10ms --真相是因为这样的设定会在弹奏音符到听到声音之间造成25ms的延迟，这是应该要被注意的地方。
如果你的PC没有设定好，或者有很多背景程序在运行，你所听的迟缓音符将会更多，,虽然许多音乐家抱怨MIDI天生就有暇疵，因为MIdi将一个含有8个音符的和弦展开成超过8ms来呈现，不过这个事实在现实世界当中几乎是不可能听的出来， 然而，当你将其它的不确定性因素算入时间延迟当中，那么当音符进入Midi接口之后，可能又要被展开一次，在现场演出的时候，被混淆的机会就会增加很多。
PCI MIDI连接方式看起来对使用PC的音乐家来说算是延迟最短的，然后才是Printer或是Serial port，USB端口目前来说延迟最大，导致演奏结果较"松散"，即使像Emagic's AMT以及Steinberg's Midex这样的产品，已经改进了播放时的 timing问题，还是没有办法忽略录音时产生延迟的不确定性。
如果你像我一样，有一张Midi界面挂在上面的录音卡，同时有一组8进8出的接口连接在其它的端口上，你或许可以将主控键盘的Midi端口连接在PCI录音卡上使演出表现比较"密集"，然而，保持时间量测的客观性也是很重要的。
在我针对这个专题做继续的报导之前，希望能将更多制造商的响应包括进来，我也会更趋向以使用Windows XP的音乐家的脚色来思考，因为许多人都承认透过Sonar内部的WDM驱动程序以及只有2000/XP版本的Cubase SX，所造成的延迟比较低，因为这些2000/XP平台与Windows 95/98/ME是完全不同的家族，所以对音乐家来说，这又是另一个可能产生的时间延迟问题，无疑地又投入了不确定性。
如果延迟是合理的常数时，即使是高达15ms的延迟，大部分的音乐家能够轻易的调整自己来配合 – 但如果是时机错误就会变成很有问题，而这个决定了"松弛度"的数量， 精锐技术如FireWire/mLan以及USB 2.0已经容许很大的频宽来传输Midi信息Steinberg的VST System Link 能够将多台执行Cubase VST、Cubase SX以及Nuendo等具备sample-accurate MIDI timing程序的计算机连接在一起。
然而，只要我们一开始依赖传统的Midi接口以及录音接口来录制我们的演奏，我们仍然得面对许多这里所讨论的种种延迟以及其不确定性，不论未来发生些什么，我在我的录音卡测试报告中都应该把报导与实际的声音延迟数值都放进来。 最后，记住我们都活在真实的现实世界!!我从SOS March 2001的一个文章追踪到这个特征，它综观呈现出各种由于Midi以及Audio的Timing所导致的问题，范围从声音的clock jitter到一些短的clicks 以及pops的噪声，编曲软件的分辨率、Midi的瓶颈以及MIDI与音轨运行了几分钟之后的偏移，我同时准备了几个建议的实验方式，来证明在你自己的PC上面也有相同问题。 |
赛因酷图
成功案例
相关文章
