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

看板Headphone (耳機)作者Oswyn (Oswyn)時間5年前 (2020/03/16 02:22)推噓32(32推 0噓 59→)

留言91則, 16人參與討論串5/8 (看更多)

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 會依據 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 不然看不出會有好處就是了。 -- 人間五十年、化天のうちを比ぶれば、夢幻の如くなり ^,,,^ 一度生を享け、滅せぬもののあるべきか (ミ‵ω′)\m/ NOBUMETAL DEATH!!(乂'ω') -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.45.253.183 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Headphone/M.1584296563.A.A8F.html

→

max8201

03/16 05:21, 5年前 , 1^F

03/16 05:21, 1^F

→

alanswill

03/16 06:39, 5年前 , 2^F

03/16 06:39, 2^F

→

alanswill

03/16 06:39, 5年前 , 3^F

03/16 06:39, 3^F

推