Techrider.live

Dante 與 AES67:規劃可互通的音訊網路

閱讀約 9 分鐘 · 更新於 2026年10月3日 · 系統技術人員、AV 網路工程師、前場(FOH)與監聽工程師、廣播操作人員、製作經理、場館技術人員、整合商與巡演音訊團隊

比較 Dante 與 AES67 的差異,並規劃相容設備、RTP multicast 串流、PTPv2 時鐘、位址設定、測試與可回復的技術需求清單交接。

TL;DR — Dante 是完整的商用音訊網路平台;AES67 則是讓相容音訊 over IP 串流互通的標準。支援 Dante 的裝置可以和非 Dante 的 AES67 端點交換 AES67 RTP multicast 音訊,但把模式打開只是第一步。端點仍然需要相容的音訊格式、multicast 位址、PTPv2 時鐘、網路政策,以及經過測試的訂閱。除非設計明確需要 AES67 邊界,否則 Dante 對 Dante 的路由應維持原生 Dante。

Dante 和 AES67 解決的是不同規模的問題

Dante 和 AES67 常被拿來比較,好像它們是兩個可互換的產品。其實不是。

Dante 提供裝置探索、路由、時鐘同步、監看、設定,以及在受支援生態系中的媒體傳輸。AES67 定義的是專業音訊 over IP 系統之間交換無壓縮音訊串流的共同方式。它並不標準化這些串流周邊所有的控制、探索、安全性或管理功能。

問題DanteAES67
它是什麼?網路化媒體平台與生態系音訊傳輸互通標準
主要用途路由並管理相容的 Dante 端點在不同系統之間交換相容的 RTP 音訊
在互通邊界上的路由類型原生 Dante 或 RTP,取決於端點RTP multicast 音訊
時鐘需求原生路由使用 Dante 時鐘同步AES67 串流需要相容 PTPv2 時鐘同步
控制體驗Dante Controller 或受管理的 Dante 服務取決於產品與探索方式

因此,實務上的問題不是「哪一個贏?」而是「系統需要在哪裡設一個以標準為基礎的音訊邊界,以及那個邊界上的每一個設定由誰負責?」

在 Dante 系統內優先使用原生 Dante

當兩端都是 Dante 裝置時,即使啟用了 AES67 模式,它們通常仍會使用原生 Dante 傳輸通訊。啟用 AES67 不會把所有路由都轉成 AES67,也不會改善一般的 Dante 對 Dante 訂閱。

當原生路徑已經符合製作需求時,就使用原生路徑。它能保留預期中的 Dante 命名、路由、監看與復原流程。只有在相容的非 Dante 端點必須透過刻意設計的介面收發音訊時,才加入 AES67,例如跨越廣播、安裝式 AV、控台、DSP 或錄音邊界。

這個區分可以避免一個常見錯誤:只是因為每台設備都有互通選項,就去改動一個原本穩定的原生網路。

確認每個端點都支援所需模式

AES67 支援是裝置能力,不是每個網路埠都自動具備的保證。在推進演出前,請盤點:

  • 確切的產品與介面;
  • 已安裝的韌體與 Dante 軟體版本;
  • 支援的 RTP 或 AES67 模式;
  • 支援的取樣率、聲道數與封包格式;
  • multicast 位址限制;
  • PTPv2 時鐘選項與 domain 行為;
  • 切換模式是否需要重新啟動;
  • 非 Dante 端點如何宣告或接受該串流。

在目前版本的 Dante Controller 中,相容裝置會提供 RTP 或 AES67 設定控制。較舊的產品可能在位址、flow 或時鐘同步上有較窄的限制。請使用實際部署韌體對應的文件,而不要假設某一台裝置成功就代表整個機群都沒問題。

把 AES67 路由視為一條明確定義的 multicast flow

AES67 互通使用 RTP multicast flows。發送端會建立一條串流,包含音訊格式、目的 multicast 位址、UDP 埠與時序行為。接收端必須支援這些值,並加入同一條串流。

在建立訂閱前,先定義這條 flow:

Flow 欄位需要先協議什麼為什麼重要
發送端與聲道明確來源與聲道順序避免技術上有效、實際卻接錯的訊號
取樣率與編碼兩端都支援的單一格式避免音訊負載不相容
multicast 位址與埠核准、唯一、且在允許範圍內的值避免衝突與無聲接收
PTPv2 時鐘 domain相同且受支援的時序 domain讓封包與取樣時鐘保持對齊
接收端延遲該目的端可支援的值讓接收端有可用的封包緩衝
網路範圍VLAN、交換器、querier 與路由邊界決定 multicast 與時序能傳到哪裡

某些 Dante 實作只會在特定 multicast 範圍內接收 AES67 flows。即使訂閱看起來已接受,如果接收端設定的 RTP 前綴與發送串流不一致,音訊也可能不會通過。請記錄實際部署需求,不要照抄一個通用位址範例。

更大的 fanout 決策可參考 Dante 單播與 multicast。

把 PTPv2 時鐘同步當作獨立工作項目來做

AES67 依賴 PTPv2 時序。原生 Dante 網路有自己的時鐘選舉行為,因此互通設計必須明確建立相關裝置如何到達相容的 PTPv2 參考時鐘。

請確認:

  1. 哪一台裝置或時鐘有資格成為 AES67 時序 domain 的主導者;
  2. 每個參與端點使用的 PTP 版本與 domain 編號;
  3. Dante 裝置是使用自動還是手動的 AES67 時鐘設定;
  4. 是否有任何裝置在原生與 AES67 兩側之間橋接必要的時序行為;
  5. PTP event 與 general 訊息的 DSCP 與交換器處理方式;
  6. 若失去主導者、上行鏈路或任一端點,會發生什麼事。

不要假設肉眼看得到的裝置就共享一個可用時鐘。探索、控制與媒體時序是三個不同的檢查項目。Dante 時鐘主導者指南 說明了原生 Dante 的選舉機制;AES67 邊界仍然需要它自己的 PTPv2 驗證。

讓 multicast 保持在刻意設計的網路範圍內

AES67 串流不是把每個埠都淹滿的理由。先規劃 VLAN 與交換器路徑,再依照該設計設定 multicast 控制。

受管理的網路可能會使用 IGMP snooping,只把串流送到有接收需求的埠,並由一個正確配置的位置上的 querier 維持成員關係。具體政策屬於網路擁有者。請確認 PTPv2、必要時的探索機制,以及 RTP multicast 都能到達預定端點,且不會外溢到不相關的製作網路。

同時也要檢查雙向鏈路容量。multicast 雖然減少了發送端 fanout,但每一條承載它的鏈路仍然會消耗頻寬。Dante 網路交換器需求指南 涵蓋鏈路速度、QoS、EEE、計數器與驗收測試。

從靜音到復原,測試互通性

1. 先保存已知的原生基準狀態

匯出目前的 Dante 設定,並記錄時鐘、路由、取樣率、名稱、位址與交換器狀態。在啟用新的 RTP 模式之前,先保護好可正常工作的輸出。

2. 一次只設定一個邊界

只在受支援的端點上啟用所需模式。套用協議好的格式、multicast 前綴、延遲與 PTPv2 設定。若需要重新啟動,請等完成後再判斷結果。

3. 建立一條可辨識的測試 flow

先從少量聲道與明確可辨的測試來源開始。記錄它的聲道順序、multicast 位址、埠與發送端。避免一次建立多條匿名 flows。

4. 訂閱並檢查每一層

確認接收端已加入預定 flow、鎖定正確時鐘、沒有錯誤,並在預期輸出產生正確音訊。只有路由顯示成立,並不能證明媒體真的可聽、而且標示正確。

5. 套入接近實況的負載

將規劃中的原生 Dante 路由、AES67 串流與具代表性的共享流量一起跑。觀察時鐘狀態、延遲、封包錯誤、鏈路使用率、佇列與實際目的地。

6. 演練故障與回復

依序移除並恢復來源、接收端、時鐘主導者與相關網路鏈路。量測靜音與復原行為。最後,證明文件化的基準狀態可以被還原,而不需要臨場即興發明設定。

文件化互通邊界

技術需求清單應包含:

  • 使用 AES67 的營運理由;
  • 以裝置、埠與聲道列出的原生 Dante 與 AES67 端點;
  • 韌體與相容性負責人;
  • 音訊格式與聲道順序;
  • RTP multicast 位址、埠與允許範圍;
  • PTPv2 主導者、domain、優先序與備援;
  • VLAN、交換器、IGMP 負責人、QoS 與鏈路容量;
  • 接收端延遲與驗收證據;
  • 重新啟動、故障、備品與回復程序;
  • 被授權可修改兩側設定的技術人員。

不要把密碼或敏感的網路憑證放進公開的技術需求清單。請透過場地方核准的安全管道分享這些資訊。

數位音訊網路技術需求清單指南 說明了如何把這個邊界放進整體演出交接文件中。

Dante 與 AES67 檢查清單

  • 因為有明確命名的非 Dante 互通邊界,所以需要 AES67。
  • 每個端點與韌體版本都支援選定模式。
  • 取樣率、編碼、聲道順序、multicast 位址與埠都一致。
  • 已驗證 PTPv2 來源、domain、priority 與備援。
  • multicast 範圍、querier、QoS、EEE 與鏈路容量都已核准。
  • 路由通過正確音訊、滿載、故障與復原測試。
  • 原生 Dante 路由仍有文件記錄且可回復。
  • 技術需求清單中已寫明負責人與回復程序。

常見錯誤

把 AES67 當成完整控制系統。 它標準化的是可互通的媒體路徑,不是所有探索、路由、安全性或監看行為。

在每台 Dante 裝置上都啟用 AES67。 只有在已核准的非 Dante 邊界確實需要時,才啟用並設定它。

只檢查路由,沒檢查時鐘。 接收端即使能發現串流,若沒有相容的 PTPv2 時序,仍可能無法輸出穩定音訊。

不加判斷地複製 multicast 數值。 位址範圍、前綴、埠與裝置支援能力,都必須與實際端點和網路規劃一致。

只在空閒交換器上測一條串流。 驗收必須包含原生路由、預定的 AES67 負載、共享流量、故障與復原。

FAQ

Dante 和 AES67 有什麼差別?

Dante 是完整的網路化媒體平台,具備路由、探索、時鐘同步、監看與裝置設定。AES67 則是一個標準,讓相容的音訊 over IP 系統交換 RTP 音訊串流。

Dante 可以相容 AES67 嗎?

支援的 Dante 裝置可以和相容的非 Dante AES67 裝置互送與接收 AES67 音訊。相容性取決於裝置、韌體、音訊格式、multicast 設定與 PTPv2 配置。

AES67 需要用 multicast 嗎?

AES67 互通通常使用 RTP multicast 串流。發送端、接收端、交換器、VLAN、multicast 位址、埠與 IGMP 政策都必須符合同一套規劃。

AES67 一定要 PTPv2 嗎?

是。AES67 使用 PTPv2 進行媒體時鐘同步。參與端點必須共享相容的 PTPv2 配置與時序路徑。

Dante 和 AES67 互通要怎麼測試?

先確認能力與格式,再設定 PTPv2,建立一條已知的 RTP multicast flow,確認目的端有正確音訊,接著測試滿載、時鐘與鏈路中斷、端點回復與回復流程。

讓標準邊界保持可回復

把已核准的端點對照表、RTP flow、時鐘規劃、網路範圍、測試證據與回復方式,和其他演出文件一起保存。在 Techrider.live 中,請把它放在同一份技術需求清單裡,與舞台配置圖和輸入列表並列,邀請負責工程師編輯,然後在分享目前版本之前先儲存並檢查歷史紀錄。

相關文章