|
從理論上的數字以及製造商的量測結果來看，通常認為軟體合成器的延遲是可被忽略的-- 但如果當你彈奏它們時，這延遲是隨處可得的時候，我想這樣的認定是沒用的。我們的實際量測將會有助於你建立正確的觀念 |
|
|
|
原著：Martin Walker 翻譯：方寶明 回到SOS November 2000的時候，我們那時討論過釵h文章，談到有關合成器如何由硬體轉為軟體的變化，包含了音質、取樣以及軟體合成的替代、延遲以及延遲時基錯誤(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 March 2001的一個文章追蹤到這個特徵，它綜觀呈現出各種由於Midi以及Audio的Timing所導致的問題，範圍從聲音的clock jitter到一些短的clicks 以及pops的雜訊，編曲軟體的解析度、Midi的瓶頸以及MIDI與音軌跑了幾分鐘之後的偏移，我同時準備了幾個建議的實驗方式，來證明在你自己的PC上面也有相同問題。
自從我寫下了這個特徵之後，我發現釵h的’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發聲數的合成器，對於希望硬體合成器能具備即時回應的人來說，這些結果似乎蠻令人滿意， 不過大多的合成器都是透過他們本身的微處理器來驅動，雖然其作業系統都明顯經過仔細的調教以致於能夠即時演奏，然而要處理每個動作與弁鄋漁伬唌A仍會佔用固定的時間。
PC MIDI 介面
既然我們已經建立某些硬體合成器的反應時間結果，接下來就是把PC的MIDI介面合併到我們的訊號流程中，我開始把我的鍵盤YAMHA SW1000XG的Midi輸入端利用Midi線連接起來，由於1000XG內建MU100R這台音源，所以當然也是將它加入到整個訊號流程中， SW1000XG內建音源，是使用P21 custom gate array處理器來處理MIDI訊息，不過聲音是透過PCI匯流排傳輸，還有數位的Clock訊息以及其他弁遄C
當然我們現在的測試開始包含了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?
|
|
早期的PC，大概幾乎所有的MIDI介面都使用serial port、parallel port或是ISA的擴充卡，最普及的ISA Midi介面要算是Roland的 MPU401，即使是與其他的ISA或是PCI的錄音卡整合，這幾乎在那時都是其他製造商依循的工業標準，然而，serial以及parallel-port的設備也是非常普及，特別是透過適當的驅動程式，它們就可以同時讓PC或是Mac使用。 早期的Serial/Parallel介面除了速度較慢之外，大多還具備優異的表現，但是通常在設定跟安裝上比較麻煩，特別是在擁擠的PC環境之下，要找到一組空出來的IRQ可能很不簡單，當然在Windows 98之下可以在BIOS內部強制設定parallel port的IRQ值，否則可能會因為碰到共用IRQ而產生相衝突的情形。 為了解決這個問題，無疑的讓製造商在1999年選擇使用USB的傳輸介面，因為它可以容章F127台的設備在 Mac 或是 PC的平台上串聯，而且還可以熱插拔，電腦不斷會自動辨識，也沒有IRQ的相衝突問題。然而，如同我的測試結果顯示，相信有些音樂人也發現，USB介面可能會造成多一點的延遲，更重要的是，造成比較大量的時基錯誤(jitter error)。 這原因是因為它不像USB audio一樣使用isosynchronous timing技術，它可以保證傳輸的時間只要不被干擾，可以跑到Buffer完全被用光為止，USB MIDI 則是使用asynchronous timing技術，資料在它們抵達時才開始傳輸，這必須依賴一些其他的外在因子，當你同時利用USB傳輸MIDI 以及audio資料時， 它們可能會有潛在的排擠問題，我個人唯有在這兩個介面是存在同一個設備時才會推薦如此使用，至少它的驅動程式會小心的撰寫以避免MIDI與audio的相爭，並且確保兩者可以在最微小的排擠情形下共用USB的頻寬。 我的測試似乎顯示了不值錢的serial或是parallel-port的MIDI介面對需要準確Timing的音樂人來說仍然是有價值的，但是可悲的是只有在Windows 98, SE 或是ME的作業系統才有用，在NT/2000/XP的平台是很難找到適當的驅動程式， 因為它們不像Windows 95/98系列一樣，NT/2000/XP系統會嚴格的控制I/O ports，因此除非有特別的優先權去呼叫這些I/O Port，否則就很容易產生一些異常的錯誤。 Microsoft 現在是推薦在新的PC平台上使用USB或是FireWire I/O 的介面，這也是為什麼serial以及parallel-port的版本會被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的延遲增加，這樣的設計讓大家更混淆了，還好現在很多錄音卡都已經不做這樣的設計。
不過這也告訴了我們不能一昧相信軟體所提供的延遲時間數?，釵hSW1000XG的使用者都說在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驅動程式
有釵h的音樂人目前都依賴由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) ，不過，這些細節我們容後再詳談。
|
真實世界的聲音延遲測量
|
|
你可能會期望決定聲音的延遲是件容易的事情：不論是用音樂應用程式或是公用程式，只要打開適當的控制台對話框，讀取它以Sample為單位的buffer size，然後根據當時的取樣頻率轉換成延遲的時間。舉例來說，當使用44.1kHz，512 sample的時間大約等於512/44100，也就是約11.6ms (大部分的軟體都會計算 為四捨五入的整數值，即12ms)，同理，128 samples則相當於2.9ms的延遲，通常都會顯示為3ms。 然而，真實世界裡的測量結果會比較大，這是由於如先前所說的A-D轉換以及D-A轉換所造成，我提供大家一個測量你錄音卡實際延遲的簡單方法，這也是一個檢測是否你的軟體對於錄音卡Buffer size或是延遲的報導是否正確的方法。 這次你不需要特別的音源， 不過如果你有MIDI合成器可以當成訊號產生器那當然是比較好， 這次你需要一個上升速度比較快的脈波，必如說可能你可以用方波這個音色， 最好是不要通過任何的濾波器-- 如果不能避免要通過，那請將率波頻率調整到最大，並且把Resonance調到最小。把任何封包(envelope)都提升到最快的 attack，並且確認內建的DSP效果器是關閉的。 現在，你需要一個全多工的音樂應用軟體，並且具備監聽弁遄A我使用Cubase VST，將監聽設在Record Enable的模式， 將合成器的輸出插入至錄音卡的左聲道的輸入，然後將左聲道的輸出連接到右聲道的輸入，如果你是透過混音座來連結，記得要將錄音卡左聲道的輸出的相位轉到左邊，否則會造成回授現象。接下來，彈奏幾個合成器的高音來錄音，這包含了以下幾個聲音，左聲道是合成器的原音，右聲道的聲音是經過了A/D轉換之後，當然加入了一串錄音卡的輸入Buffer，以及另一組輸出的Buffer，最後經過D/A轉換之後所發出的相同聲音。你現在可以從起點量測這兩者之間的延遲，這就是真實世界的監聽延遲。你可以將這個數據分為兩部分來取得聲音輸出的延遲，這是軟體合成器放時所造成的延遲。 在這樣的測量底下絕沒有時基錯誤發生，而且如果你能將起點非常精準的放在同一個時間點，得到的結果可以準確到一個Sample，以一個128-sample的buffer來說，在 44100Hz下得到的理論延遲為128/44100=2.90ms，而我的Echo Mia糧測的結果是為10.07ms，或者說錄音與放音各佔了5.03ms-- 其中2.13ms的差異在44.1kHz下計算結果為94個samples-- 接下來的檢測顯示不論是什麼Buffer Size或是取樣頻率，都會有一個固定常數的延遲-94個sample存在於輸入與輸出，所以，真實世界中即時彈奏合成器時，播放的訊號流程只增加2.13ms，而經過了Buffer之後監聽到聲音的輸出則總共延遲。 |
最終看法
|
即使沒有任何MIDI元件，真實世界的聲音延遲量測還是比Buffer Size上所顯示的要來的大 不論你是否已經看完這整套理論，或是只是依照喜好選擇你認為有興趣的來看，應該都會讓你有很多地方可以思考，雖然有釵h音樂家完全依賴軟體的公用程式所得到的數據，而事實顯然遠比所認定的要複雜， 包含釵h比錄音卡的Buffer大小以外的因素，所以有時會與報導的數值有些酗ㄕP，有時則根本大相逕庭。 |
 |
主應用程式如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沒有設定好，或者有很多背景程式在跑，你所聽的遲緩音符將會更多，,雖然釵h音樂家抱怨MIDI天生就有暇疵，因為MIdi將一個含有8個音符的和弦展開成超過8ms來呈現，不過這個事實在現實世界當中幾乎是不可能聽的出來， 然而，當你將其他的不確定性因素算入時間延遲當中，那麼當音符進入Midi介面之後，可能又要被展開一次，在現場演出的時候，被混淆的機會就會增加很多。
PCI MIDI連接方式看起來對使用PC的音樂家來說算是延遲最短的，然後才是Printer或是Serial port，USB端子目前來說延遲最大，導致演奏結果較"鬆散"，即使像Emagic's AMT以及Steinberg's Midex這樣的產品，已經改進了播放時的 timing問題，還是沒有辦法忽略錄音時產生延遲的不確定性。 如果你像我一樣，有一張Midi界面掛在上面的錄音卡，同時有一組8進8出的介面連接在其他的埠上，你或野i以將主控鍵盤的Midi端子連接在PCI錄音卡上使演出表現比較"密集"，然而，保持時間量測的客觀性也是很重要的。
如果延遲是合理的常數時，即使是高達15ms的延遲，大部分的音樂家能夠輕易的調整自己來配合 – 但如果是時機錯誤就會變成很有問題，而這個決定了"鬆弛度"的數量， 精銳技術如FireWire/mLan以及USB 2.0已經容釩雂j的頻寬來傳輸Midi資訊， Steinberg的VST System Link 能夠將多台執行Cubase VST、Cubase SX以及Nuendo等具備sample-accurate MIDI timing程式的電腦連接在一起。然而，只要我們一開始依賴傳統的Midi介面以及錄音介面來錄製我們的演奏，我們仍然得面對釵h這裡所討論的種種延遲以及其不確定性，不論未來發生些什麼，我在我的錄音卡測試報告中都應該把報導與實際的聲音延遲數值都放進來，最後，記住我們都活在真實的現實世界!!
在我針對這個專題做繼續的報導之前，希望能將更多製造商的回應包括進來，我也會更趨向以使用Windows XP的音樂家的腳色來思考，因為釵h人都承認透過Sonar內部的WDM驅動程式以及只有2000/XP版本的Cubase SX，所造成的延遲比較低，因為這些2000/XP平台與Windows 95/98/ME是完全不同的家族，所以對音樂家來說，這又是另一個可能產生的時間延遲問題，無疑地又投入了不確定性。
