## Dante vs Ravenna - audio networking w praktyce

Dwa światy, jeden kabel

Audio networking to temat, który dla większości realizatorów dźwięku brzmi jak „coś z IT”. I w pewnym sensie tak jest - przesyłamy audio przez te same kable i przełączniki, co ruch internetowy. Ale wymagania są diametralnie inne: zerowa tolerancja na opóźnienia, deterministyczne dostarczanie pakietów, synchronizacja z dokładnością do mikrosekund.

Pracuję z dwoma głównymi protokołami: Dante w Flightcore Studios i Ravenna (przez konwertery Merging Horus) w Filharmonii Narodowej. Oba robią to samo - przesyłają wielokanałowy audio cyfrowy po sieci Ethernet - ale podchodzą do tego inaczej.

Dante - ekosystem i pragmatyka

Dante, opracowany przez Audinate, to de facto standard w komercyjnych studiach nagrań i instalacjach live. Jego siła nie leży w przewadze technicznej nad konkurencją, lecz w ekosystemie.

Co działa dobrze

• Dante Controller - centralne zarządzanie routingiem audio z jednej aplikacji. Widać każde urządzenie w sieci, można przekierować dowolny kanał w kilka sekund.
• Kompatybilność - mikrofony Shure, konsolety Yamaha, stagebox-y od Allen & Heath, interfejsy Focusrite - wszystko mówi tym samym protokołem. W Flightcore mamy sprzęt od kilku producentów i wszystko łączy się bez problemów.
• Redundancja - dwa porty (primary/secondary) na każdym urządzeniu. Jeśli padnie przełącznik lub kabel na głównej ścieżce, audio przeskakuje na zapasową bez przerwy.

Ograniczenia

• Zamknięty protokół - Dante to rozwiązanie własnościowe Audinate. Licencje kosztują, a interoperacyjność z innymi protokołami (AES67, Ravenna) wymaga dedykowanego gateway’a lub urządzenia obsługującego oba standardy.
• Zależność od Dante Controller - bez tej aplikacji konfiguracja jest praktycznie niemożliwa. Na Linuksie nie działa natywnie, co komplikuje zarządzanie w środowiskach czysto linuksowych.
• Multicast i QoS - Dante wymaga poprawnie skonfigurowanego IGMP snooping na przełącznikach. Bez tego ruch multicast zaleje sieć, powodując jitter i trzaski. To nie wada protokołu samego w sobie, ale w praktyce wielu techników zapomina o konfiguracji sieciowej i potem szuka problemu w sprzęcie audio.

# Sprawdzenie IGMP snooping na przełączniku (przykład Linux bridge)
bridge -d link show | grep mcast
cat /sys/devices/virtual/net/br0/bridge/multicast_snooping

Ravenna - otwarty standard i precyzja

Ravenna, opracowana przez ALC NetworX, to otwarty protokół oparty na standardach AES67 i SMPTE ST 2110. W Filharmonii Narodowej pracuję z konwerterami Merging Horus, które używają Ravenny jako natywnego transportu.

Co wyróżnia Ravennę

• Otwartość - bazuje na otwartych standardach (AES67, PTP/IEEE 1588). Nie ma vendor lock-in, a interoperacyjność z innymi systemami AES67 jest wbudowana.
• Precyzja synchronizacji - PTP (Precision Time Protocol) w Ravennie oferuje synchronizację zegara z dokładnością poniżej mikrosekundy. Dla Merging Horus, który pracuje z rozdzielczościami do 384 kHz DXD i DSD256, to kluczowe.
• Elastyczność konfiguracji - Merging ANEMAN (Audio Network Manager) pozwala na bardziej granularne zarządzanie przepływami audio niż Dante Controller. Możesz definiować strumienie unicast i multicast niezależnie, kontrolować parametry każdego przepływu osobno.

Gdzie Ravenna przegrywa

• Ekosystem - zdecydowanie mniejszy wybór urządzeń niż w Dante. W segmencie studyjnym dominują Merging i kilku producentów broadcastowych. W live sound praktycznie nie istnieje.
• Krzywa uczenia - konfiguracja Ravenny wymaga głębszego zrozumienia sieci niż Dante. Trzeba ręcznie zarządzać domenami PTP, strumieniami, adresowaniem multicast. Dante ukrywa tę złożoność za prostym interfejsem drag-and-drop.
• Wsparcie techniczne - mniejsza społeczność, mniej materiałów szkoleniowych, mniejsze forum do szukania rozwiązań problemów.

MADI i AES/EBU - starsze protokoły wciąż w grze

W obu środowiskach - Flightcore i Filharmonia - wciąż używamy MADI (Multichannel Audio Digital Interface) i AES/EBU jako transportu punkt-punkt. MADI przez BNC lub optykę daje 64 kanały na jednym kablu, co w Filharmonii sprawdza się idealnie do połączeń między sceną a reżyserką.

AES/EBU to klasyka - dwa kanały na parze kabli, ale z precyzyjnym clockingiem i wysoką odpornością na zakłócenia. W studiach Flightcore używamy AES/EBU do podłączenia monitorów odsłuchowych, gdzie potrzebujemy deterministycznego, minimalnego opóźnienia bez narzutu sieciowego.

# Typowa konfiguracja interfejsów w studiu Flightcore
studio_a:
  dante: 64ch  # główny transport
  madi: 64ch   # backup / overflow
  aes_ebu: 2ch # monitoring odsłuchowy
  wordclock: BNC # synchronizacja zewnętrzna

Co wybieram i dlaczego

Nie ma jednej odpowiedzi. Kontekst decyduje:

• Studio komercyjne (Flightcore) → Dante. Ekosystem, kompatybilność sprzętu, łatwość dla zewnętrznych techników.
• Instytucja koncertowa (Filharmonia) → Ravenna/AES67 + MADI. Otwarte standardy, precyzja synchronizacji, długoterminowa niezależność od jednego dostawcy.
• Punkt-punkt, monitoring → AES/EBU lub MADI. Minimalny narzut, deterministyczne opóźnienie.

Kluczowa lekcja: protokół to narzędzie, nie religia. W Flightcore Dante działa bezproblemowo od otwarcia w 2023 roku. W Filharmonii Ravenna z Merging Horus daje precyzję, której Dante nie osiąga przy nagraniach w DXD. Oba rozwiązania wymagają porządnej infrastruktury sieciowej - i tu wracamy do Cat6A, zarządzalnych przełączników i dobrze skonfigurowanego QoS.

Protokół możesz zmienić. Źle poprowadzone kable zostają na lata.