WASAPI (push) 是較新的 WaveRT Port Driver、使用 cyclic buffers,Audio device
需要支援 DMA。有人不推是因為部分 Audio device 相容性不佳,為了省麻煩就叫你別
用,不用就不會有機會有問題。話說什麼年代了硬體還不支援 DMA(笑)、硬體相容性
、支援度不佳並不是這個模式的問題。用 WASAPI (push) 有問題該吐草的是兩光硬體
或其不良驅動程式。但你知道的做 Audio 設備的很多在這塊通常都....
WASAPI (event) 是舊式的 "ping-pong" buffers。
工作正常 Buffer 大小能滿足傳輸的話兩者沒有不同。不管是 WASAPI or ASIO 其功能
都只是在程式與 Audio interface 間傳遞 Audio data 並不決定聲音品質。
Buffer 是拿來緩衝的,夠大傳輸就不容易出包不易有 Pops、Clicks and Cracks 這些
音頻故障。只是聽個音樂而不是二、三十個音軌在混音*n個 plug-in 在 DSP,除非
硬體或驅動有問題啦...
in foobar【讀檔>解碼>ReplayGain>DSP chain>Output】=>Audio Device
一連串的 Audio playback stream,在其中一個地方強迫資料流變得零碎並不會讓它
變實時只是形成瓶頸,更容易發生音頻故障。
Audio interface 都有硬體最小 buffer size 限制與實際最大 buffer size。
一般常見的最小 size 是 30000 hundred-nanosecond、也就是 3 ms。但這不代表這硬
體在 3ms 一定能完美工作就是了,畢竟能不能操極限是要看整台設備的軟硬體。
而 foobar2000 的 foo_out_wasapi 寫的很陽春,它沒有互動也沒有防呆雖然功能上是
沒有問題啦。
在設定中向 WASAPI 提出的是 buffer size 的【請求】,實際上 WASAPI 會依據 audio
frame 的大小(ch 數 * bit-depth * Sample rate)來回應一個可行 buffer size。
零是不可能的、也不能比硬體的最小 buffer size 要小。以上面的例子 3ms 會回給一
個能放 3.xx ms audio大小的 buffer。而 audio 的位元深與採樣率會影響實際大小。
太小的 buffer size 對 WASAPI (push) 的 cyclic buffers 不利。Cyclic buffers
是你追我跑的環形緩衝區,設太小=跑道太短會很容易撞車。cyclic buffers 是先進
先出(FIFO)其延遲是看硬體自發性的讀取。foobar 是 music player 所以 audio
data 都是已知的,buffer size 設大點沒什負面問題但最好不要設的太小。
WASAPI (event) 的 "乒乓" buffers 則不能設太大,如上述沒有防呆。如果在此
設定了超過硬體的最大值,多出來的部分則會丟失。
極端例子如硬體最大 buffer size 只有 250ms 如果設了 500ms,foobar 每次會傳送
500ms 的 audio 但硬體只能實收 250ms 然後播放、多出來的 250ms audio 會被放生
。然後 foobar 會再送下一個 500ms...250ms 被播放 250ms 被放生。會聽到很嚴重的
輟音,然後進度條跑的飛快。以此例五分鐘的音樂會跳針成二分半就播完。
但如果只設成大了點,只丟失幾個 samples 輟音不夠嚴重,如不知原因可能只會聽出
比較不好聽。但根源上的問題是設定已經錯誤了,但 foo_out_wasapi 並沒有防呆也
沒有任何互動告知使用者的 buffer size 出問題。
應該些人聽信 push mode 不可用,用 event mode 設大有問題所以得出小=好的結論
另如上述如果硬體的 buffer size 最小值是 3ms,這代表設成 0~3ms 之間的任何值
WASAPI 所回應的 buffer size 大小都會是相同的,所以聽起來不可能會有不同。
但如果使用者覺得設成 0ms 最棒,那有什麼理由不能說 3ms、5ms、10ms、50ms 到超
過最大值前聽起來都跟設成 0ms 一樣好?有人能挑戰用聽的聽出硬體的最小 buffer
size 值?如果小真的好音質真有差、盲測應該能分辨出最小 buffer size 這個界線才
是。
聽出硬體最大 buffer size 大致上的大小應該不難,基本上這就是嚴重的音頻故障。
因為就算每次只最小丟失一個 sample 也會因為定時定頻率重複發生而顯得明顯。參考
出問題/正常的分界適中的設定 event mode 的 buffer size 應該是不錯的選擇。
在這部分應只有 audio interface 耗盡 audio data 而後面的 audio data 來不及備
妥產生的音頻故障,而沒有正常備妥&傳輸但影響音質的問題。
另外這的 32-bit 指的是 32-bit float?不論是整數或浮點,在 source audio data
一般最高只有 24-bit 的 playback 的狀況下這應該沒有什好處。只會增加無謂的資料
傳輸量,這會讓低延遲的設定環境更容易撞車。除非有進行 DSP 不然看不出會有好處
就是了。