[心得] 第三層交換器 QoS 於音訊網路的應用

喇音

960


本文僅討論數據交換如何進一步最佳化並強化資料整體性,做完後的音質是否改善
則是 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
herbertsurve1樓厲害 很想多聊解網路優化。我目前僅走雙網路。ro 07/01 08:22
herbertsurve2樓n至hqp 單獨ip單獨網卡。並且全走vm虛擬系統。交換 07/01 08:22
herbertsurve3樓器是sotm 時鐘外接。雙邊host端另外網路。這樣聲音 07/01 08:22
herbertsurve4樓就有明顯升級了 07/01 08:22
herbertsurve5樓串流網路資料全是音樂資料。控制及無關音樂數據走 07/01 08:26
herbertsurve6樓另外網路 07/01 08:26
能理解架構,我之前也是用VM跑HQP OS & ROCK,並用直連方式連NAA,可以省掉一個交換 器。 但4090 GPU實在太厚了,硬生生蓋掉一個PCIe,只能再回到從前…
nebulaforest7樓直上10G switch,解決頻寬擁塞問題 07/01 16:05
l988樓2.5 G 應該就行了吧 07/01 16:25
bt0920019樓好奇一件事,這種乙太網路優化到物理實體層過到i2s,i2s 07/01 16:44
bt09200110樓解出來的資料完整性在邏輯分析儀上是否能看出什麼,或是 07/01 16:44
bt09200111樓轉換在analog端SNR是否能看出什麼。 07/01 16:44
Amulet112樓感覺稍微有點複雜orz 07/01 18:37
louis040713樓i2s的眼圖有機會更好,減少其他的插斷干擾應該能讓眼 07/02 20:06
louis040714樓圖更集中 07/02 20:06
bt09200115樓I2s 跟DAC 的filter 或是中繼的DSP 或是soc ,應該都有 07/05 11:14
bt09200116樓自己的本地PLL,jitter 前後端應該是切開的,不會是音 07/05 11:14
bt09200117樓質瓶頸才是,好奇資料的長相格式是否有不同? 07/05 11:14
bt09200118樓Re-timer系統應該不會卡jitter瓶頸 07/05 11:16
louis040719樓短距離下,data本身我想是不會有錯的,實際上如果資料 07/06 02:39
louis040720樓真的有錯,產生的也該是隨機爆音,而非什麼音質差異。 07/06 02:39
louis040721樓所以也不用考慮什麼演算法驗證,資料重送機制之類的, 07/06 02:39
louis040722樓單純就是數位訊號品質是否能穿透FIFO PLL之類的護城河 07/06 02:39
louis040723樓,影響到系統後端類比路徑。長期以來這一直是爭議重點 07/06 02:39
louis040724樓,技術人大都會說不可能,然後拿教材出來佐證,重申數 07/06 02:39
louis040725樓位傳輸只有資料正確與否,其餘差異不會影響後端。 07/06 02:39
bt09200126樓資料不會傳錯是肯定,只是做了網路優化後,編碼的資料 07/09 05:34
bt09200127樓內容是不是有可能不同,好奇的是這裡。 07/09 05:34
更多心得
[心得] 京東edifier免運檔期被索收超材費事件
[心得] 幾條網路線的聽感
[心得] MBL C41 串流DAC分享
[心得] 2024年中退燒,周邊升級總集篇
[心得] 初燒與當fyne小郵差心得
[心得] Cambridge EVO 150 綜擴
[心得] ProAc tablette 10 管機心得
[心得] Audiophonics HPA S400et D類擴小感