Re: [閒聊] HTPC/CAT建構的自身經驗

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 這些
音頻故障。只是聽個音樂而不是二、三十個音軌在混音＊ｎ個 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 會依據 audioframe 的大小（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 不然看不出會有好處
就是了。

--
人間五十年、化天のうちを比ぶれば、夢幻の如くなり
^,,,^ 一度生を享け、滅せぬもののあるべきか
(ミ‵ω′)\m/ NOBUMETAL DEATH!!(乂'ω')

--

但以 32-bit 傳輸 24-bit 的資訊表示 data payload 無謂的增加 更耗時耗功、事實上也增加了系統 DPC Latency DPC Latency 不佳最常見的狀況就是有問題的硬體或驅動佔了茅坑不拉屎 卡住了後面排隊的，今天 24-bit 精度的 Audio 以 32-bit 傳送就表示 ３秒能傳完的要花４秒，多佔用了１／４的時間，然後只是沒用的零 而且耗的點是直接加諸在 Audio interface & controller 所以說有沒有差也不確定，這跟原原PO 你把 WASAPI 兩個 mode 的 buffer 都設成了零一樣。既然不能確定就照不知道有什麼原理的經驗法則 這不都只是心理用而已了嗎 能真心肯定的說出設成 0ms 真的比 10ms 好，因為是 ABX 盲測出來的確定結 果，而不是因為過去CAT玩家的原則所影響的？

其實在 Audio 的相關 Latency 出現在很多地方，也有不同的意義 個人感想是可能很多玩家搞混了這些不同的 Latency 像合成樂器的 Latency About Latency / VST Instruments | Steinberg.help

這的 Latency 就只是延遲，譬如樂創作者接到電腦的 Keyboard 琴鍵按下去 要 400ms 後聲音才發出來。這延遲會讓人感到不舒適但不會影響音質 同樣的在現場進行 RT監聽的狀況設備的 Latency 也會是重要的關鍵 DAC digital filters 的兩個主要分類 IIR & FIR 的重要參數 Latency

Latency 較低的 IIR 系因較沒有 "pre-ringing" 受部分人士的喜好 但這的 Latency 也只是 digital filters 的特性所表現出來的結果 而不是因為低 Latency 所以聲音好 但傳輸過程中的 Buffer 造成的 Latency... 我要說的是不管是 WASAPI or ASIO 都只是整個傳輸過程中的其中一段 這就像用卡車在送貨，你可以只裝一、二箱就出車，也以裝幾十箱再出車 但收貨方的需求如果是持續且定時定量的話，你就必需一直出貨 每次送的少你就必需發更多車 一次裝的多就可以少出點車次，但等貨裝貨的時間就＝Latency 為什麼車在跑的時間沒什麼人在計算 Latency？因為以現在的電腦來說這個時 間太短了，有部分 DAW 如 PEAPER 有 Performance Monitor 計算實際時間 但在路上每台車都會碰上各種交通狀況，這就是 DPC Latency 所反應給你的 每次送的少、收貨方的備貨就少，容錯值就低。貨架空了就是音頻故障 每次送的少＝Latency 低、是比較新鮮啦，但就如上述除了有互動需求的話 早個幾 ms 聽到的音樂是會比較鮮啦、但 Audio data 又不是生鮮 跟 SI 又有什麼關係就實在讓人搞不清楚了 另外車次多、排放就高，所需要的總 CPU 時間也會更多產生的熱能也更多 這方面的負面影響又要如何考量？ 這就又回到跟上面討論的 24-bit vs 32-bit 類似的狀況，一個感覺問題而已

系統在處理 audio data 幾乎都是以浮點數在處理，因為整數沒效率 foobar 也是、不管你的來源檔是什麼解碼後放到記憶體中都是浮點格式 foobar DSP chain 也是浮點，我想 WASAPI 也是 但這跟【傳送】是兩碼子事，如上述 CPU & RAM 的速度不是 interface 可比 為什麼現在 ITB 混音後製可以二三十個音軌＊Ｎ個 plug-in 進行大量的 DSP 計算後還來得及以幾百 ms 的 Latency 輸出？當然這些都是以浮點在計算 但算完必然有量化的問題，會有抖動或噪聲整形的需求 可如果沒進行任何會改變數據的 DSP 處理，USB & S/PDIF 都是 serial bus 這 8-bit 就是多出來的，多傳送沒必要的資訊有何益處？ 另外我也覺得沒可能也沒必要每個值都去設定試聽 但 0ms、1ms、3ms 有沒有不同？10ms 真有比較差？ 還是根本無法肯定就只是隨波逐流？ 人耳的精度有限、尤其聲音是變動的不像視覺可以同時比較兩個畫面 除非差異足夠大不然聽覺要分辨不同的難度很高不是嗎

是啊、所以我認為需要真正的 ABX 盲測 有足夠正確的測試、充足的樣本來證實真能分辨出不同設定的差異與好壞（喜好 如果沒、只是聽信他人言這樣設棒棒，不就只是隨波逐流嗎 且如果真的能聽出差異，別人喜歡的一定是你喜歡的嗎？ 聲音這東西的好壞跟喜好不本就是各形各色嗎

喜好這東西本就各形各色啦 NOS 這種嚴重失真的都會有些人覺得自然好聽了 但設完是不是真能分辨就是另一回事了 人耳不精準＆人腦是不可信的，換個盤子的顏色都會影響到味覺判斷了 我並沒有想要戰什麼的意思，但沒有 ABX 就沒有真相只是走感覺流並不理性

但 NOS 完全沒法重建原始 Audio 帶有大量的噪聲與失真及混疊，除了整體響度會下降且越往高頻越失真與衰減 但有些人就喜歡失真跟討厭高頻啦XD Nyquist frequency 之所以能以離散數據重建 Audio 就是因為需要以正弦補值 沒有 OS 以單單的 PCM 點所重建的階梯並不能說是完成了 DAC

你熟的音樂不用 ABX 多半就能分辨 NOS 的聲音很特殊

sinusoid 用 sinc 是因為計算問題啊 如果有其它算法能補正弦波、沒震鈴又效能好那就發財了啊

肥環燕瘦各有人愛啦 但我舉 NOS 只是為了表示就訊號重建的角度 NOS 完全 OUT 以 Nyquist frequency 採樣的數據並沒有遵照 Nyquist frequency 重建