› 看板 Audiophile
作者elguapo (HPHT Synthesized)
看板Audiophile
標題[心得] 第三層交換器 QoS 於音訊網路的應用
時間Sun Jun 30 17:58:50 2024
本文僅討論數據交換如何進一步最佳化並強化資料整體性，做完後的音質是否改善 則是 YMMV (Your Miles May Vary)... 本文建議採用第三層交換器，原因是可進一步對 TCP or UDP 的服務做特定的調整； 又因市售交換器品牌款式無數，QoS 調整手法不一，若對設定有疑慮，建議仍是參考 原廠教學或是手冊。 我個人有一台 Cisco CBS350 用於早期的 Ravenna/AES67 建構，由於已升級為 Netgear M4250，因此 CBS350 轉為一般網路使用，負責連接一般網路、HQPlayer、 Roon 及 NAS。 一般無管型交換器的封包交換，其權重是相同的；為了盡量避免音訊資料流被其他 資料中斷，提升音訊資料在交換器內的優先權是合理的安排。一般而言具備 Quality of Service, QoS 能力的第三層管理型交換器，都能根據 802.1p 或是 DSCP 來處理 資料的優先權，可惜目前多數的音訊軟體並不會將數據資料標上 802.1p 或是 DSCP （目前個人所用的一般音樂播放軟體只有 HQPlayer 有支援 QoS 並主動標註 CS5 以 提升數據優先等級）。 在一個無法分優先權的交換器上頭，Roon 既要接受外界的串流（例如 Qobuz）， 又要將音訊交給 HQPlayer（有在玩升頻的話），若遇到距離遠一點的需要 NAA，那麼 HQPlayer 又要將音訊資料流傳給 NAA，若是播放本地檔案，那麼 NAS 可能也會加入 搶頻寬的戰局內... 這裡 propose 一個合理的優先權分級： 1. HQPlayer -> NAA 應具最高優先權，畢竟升頻到 DSD1024 其資料流會高達 100Mbps； 2. Roon -> HQPlayer 次優先，一些 24/192 的內容資料流率也會達 9Mbps； 3. NAS -> Roon 再次一小階，這是基於經驗上 Roon 的資料緩衝區較 HQPlayer 為 大，因此即使同等資料流率，NAS -> Roon 會有較大的容錯度。 優先權等級分出來之後，以 CBS350 來說，要先設計幾個 ACL 來攔截這些服務， 例如 HQPlayer 和 NAA 用 TCP port 43210 來傳輸，Roon -> HQPlayer 則是 TCP port 30000 的 http 服務；當然 NAS 的服務一般會走 SMB 但我個人偏好 NFS 給 HQPlayer（NFS 的 port 是 2049）；另除了 Roon 內網只能 IPv4，其餘服務都 改為 IPv6。 在 CBS350 上先建立 ACL，把 HQPlayer -> NAA 目的阜 IPv6 TCP 43210 和 NFS 來源阜 IPv6 TCP 2049 服務過濾出來： https://imgur.com/A4HlGLQ.jpg
https://imgur.com/bbZnGPv.jpg
接下來在 QoS Advanced 頁設定 Class Mapping https://imgur.com/9yWWAZq.jpg
https://imgur.com/6wCoJeI.jpg
到 Policy Table 那邊隨便創個抬頭 https://imgur.com/a2jpvE3.jpg
把需要分優先權的服務設定優先權（數字越大優先權越高） https://imgur.com/PbIvIBZ.jpg
最後把 policy 綁定在所需的孔 https://imgur.com/QmCEsji.jpg
我的 NAS 有設定 LAG 因此綁在 LAG 而不是 port https://imgur.com/fYUjW9U.jpg
播放音樂的同時打開 QoS 狀態，可以看到資料按照計畫分開優先權。GE1 是 HQPlayer server，NAS 給 HQPlayer 的 NFS 資料流調整為 3： https://imgur.com/QzoMrLi.jpg
GE2 是 NAA，HQPlayer 給 NAA 的資料流優先權為 5: https://imgur.com/eJf1pyC.jpg
Queue 1 在 802.1p 被定義為「背景」，很多是不重要的東西，因此封包尾巴被 切掉是無感的，保證所需的資料流在高優先權才是最重要的事。 由於網路服務項目眾多，這裡只挑兩個（HQP -> NAA & NFS）來做範例，其餘的 設定都是相同手法的。 :-) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.96.58 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Audiophile/M.1719741532.A.360.html ※ 編輯: elguapo (118.163.96.58 臺灣), 06/30/2024 18:02:47
推 herbertsurve: 厲害 很想多聊解網路優化。我目前僅走雙網路。ro07/01 08:22
→ herbertsurve: n至hqp 單獨ip單獨網卡。並且全走vm虛擬系統。交換07/01 08:22
→ herbertsurve: 器是sotm 時鐘外接。雙邊host端另外網路。這樣聲音07/01 08:22
→ herbertsurve: 就有明顯升級了07/01 08:22
推 herbertsurve: 串流網路資料全是音樂資料。控制及無關音樂數據走07/01 08:26
推 Chricey: 求推薦UC2，樓下請提供三家 07/06 02:39
→ herbertsurve: 另外網路07/01 08:26
能理解架構，我之前也是用VM跑HQP OS & ROCK，並用直連方式連NAA，可以省掉一個交換 器。 但4090 GPU實在太厚了，硬生生蓋掉一個PCIe，只能再回到從前… ※ 編輯: elguapo (42.79.92.5 臺灣), 07/01/2024 15:21:17
→ nebulaforest: 直上10G switch，解決頻寬擁塞問題 07/01 16:05
推 l98: 2.5 G 應該就行了吧 07/01 16:25
推 bt092001: 好奇一件事，這種乙太網路優化到物理實體層過到i2s，i2s 07/01 16:44
推 Kroner: 關節痛就老人病 07/01 16:44
→ bt092001: 解出來的資料完整性在邏輯分析儀上是否能看出什麼，或是 07/01 16:44
→ bt092001: 轉換在analog端SNR是否能看出什麼。 07/01 16:44
推 Amulet1: 感覺稍微有點複雜orz 07/01 18:37
推 louis0407: i2s的眼圖有機會更好，減少其他的插斷干擾應該能讓眼 07/02 20:06
推 Chricey: 有人用過中醫針灸治療關節痛的嗎？效果如何？ 07/02 20:06
→ louis0407: 圖更集中 07/02 20:06
→ bt092001: I2s 跟DAC 的filter 或是中繼的DSP 或是soc ，應該都有 07/05 11:14
→ bt092001: 自己的本地PLL，jitter 前後端應該是切開的，不會是音 07/05 11:14
→ bt092001: 質瓶頸才是，好奇資料的長相格式是否有不同？ 07/05 11:14
推 Kroner: 我也有過關節痛的經驗，真的超痛苦的啦！推薦去看醫生，早點處理比較不會拖延變嚴重。 07/05 11:14
→ bt092001: Re-timer系統應該不會卡jitter瓶頸 07/05 11:16
推 louis0407: 短距離下，data本身我想是不會有錯的，實際上如果資料 07/06 02:39
→ louis0407: 真的有錯，產生的也該是隨機爆音，而非什麼音質差異。 07/06 02:39
→ louis0407: 所以也不用考慮什麼演算法驗證，資料重送機制之類的， 07/06 02:39
推 Chricey: 想問一下有沒有關節痛的運動禁忌？怕動得更嚴重… 07/06 02:39
→ louis0407: 單純就是數位訊號品質是否能穿透FIFO PLL之類的護城河 07/06 02:39
→ louis0407: ，影響到系統後端類比路徑。長期以來這一直是爭議重點 07/06 02:39
→ louis0407: ，技術人大都會說不可能，然後拿教材出來佐證，重申數 07/06 02:39
→ louis0407: 位傳輸只有資料正確與否，其餘差異不會影響後端。 07/06 02:39
推 Kroner: 關節痛有沒有辦法完全根治啊？UC2聽起來像萬靈丹 07/06 02:39
→ bt092001: 資料不會傳錯是肯定，只是做了網路優化後，編碼的資料 07/09 05:34
→ bt092001: 內容是不是有可能不同，好奇的是這裡。 07/09 05:34