RAVENNA jest rozwiązaniem przeznaczonym do dystrybucji dźwięku wielokanałowego oraz innych sygnałów w czasie rzeczywistym, bazującym na środowiskach sieciowych IP. Wykorzystując standardowe protokoły i technologie sieciowe RAVENNA może pracować w istniejącej infrastrukturze sieciowej. Wydajność i przepustowość są skalowalne, adekwatnie do możliwości architektury istniejącej sieci. Przeznaczona pierwotnie do zastosowań broadcastowych RAVENNA spełnia wszystkie wymagania związane z tą branża, oferując m.in. niską latencję, pełną transparentność sygnału i wysoką niezawodność. W przeciwieństwie do większości innych istniejących rozwiązań sieciowych RAVENNA to otwarty standard technologiczny, bez polityki licencyjnej. Zainteresowane strony są zapraszane do udziału w działaniach rozwojowych standardu. ALC NetworX, które zajmuje się tym działaniem, może pochwalić się współpracą z wieloma znanymi firmami z branży Pro-Audio, co zaowocowało sporą liczbą dostępnych obecnie na rynku produktów z technologią RAVENNA.
Bardzo ważną cechą rozwiązania RAVENNA jest jej pełna kompatybilność ze standardem AES67 High-performance streaming audio-over-IP interoperability. AES67 jest pewnym „podzbiorem” w ramach technologii RAVENNA. Konsekwencją tego jest to, iż AES67 będzie profilem operacyjnym RAVENNA, co pozwoli wszystkim produktom supportującym tę technologię na bezproblemową współpracę z urządzeniami kompatybilnymi z technologią AES67 innych producentów. Jednakże technologia RAVENNA sięga daleko poza to, co zdefiniowane jest w standardzie AES67, oferując rozszerzone możliwości funkcjonalne i wydajnościowe.
TECHNOLOGIA
RAVENNA, jako rozwiązanie sieciowe, bazujące na IP, opiera swoje działania na trzeciej lub wyższej warstwie modelu OSI. IP może być transportowane przez dowolną sieć LAN i służy jako warstwa podstawowa do komunikacji w połączeniach sieciowych WAN (w tym przez Internet). Strumieniowanie danych – jako naturalna konsekwencja wyboru sieci IP – odbywa się w sieci RAVENNA z wykorzystaniem protokołu RTP (real-time transport protocol). W przypadku RAVENNA jest to konkretnie RTP/AVP over UDP razem z RTCP (real-time transport control protocol). Daje to możliwość przesyłania dowolnego strumienia RAVENNA przez wszystkie połączenia WAN oparte na protokole IP. Podstawowymi formatami „zawartości” strumienia audio są sygnały 16- i 24-bitowe o częstotliwości próbkowania 48 kHz, przy dowolnej liczbie kanałów. Teoretycznie pozwala to na podłączenie się do strumienia RAVENNA i monitorowanie jego zawartości przez standardowe media playery. Oczywiście formaty danych audio nie ograniczają się tylko do tych podstawowych – mogą być zupełnie dowolne, w związku z tym, że RTP ma zdefiniowany ogromny wybór formatów dla audio i wideo. Możliwe jest nawet dodanie specyficznych rozwiązań tych formatów, zachowując cały czas pełną kompatybilność z RTP (np. AES3 czy 32-bitowy zmiennoprzecinkowy). Strumieniowanie danych możliwe jest zarówno w trybie unicast, jak i multicast, zapewniając elastyczność w celu dopasowania do różnych wymagań w różnorakich zastosowaniach. Unicast jest preferowany w sytuacjach, gdy pewien strumień powinien być dostarczony do jednego adresata lub gdy struktura sieci lub aplikacja wyklucza stosowanie trybu multicast (np. w większości połączeń WAN).
Z drugiej strony multicast pozwala na na efektywne wykorzystanie zasobów sieciowych oraz szybsze przełączanie pomiędzy dostępnymi strumieniami w sytuacjach, gdy pewien strumień będzie adresowany do różnych lokalizacji w sieci. Odbiornik można podłączyć do dowolnego istniejącego strumienia poprzez protokół RTSP/SDP – obsługiwany przez większość popularnych odtwarzaczy multimedialnych. Podczas gdy RTSP jest używany do sterowania komunikacją pomiędzy odbiorcą a nadawcą, SDP zawiera wszelkie istotne informacje na temat jednego lub większej liczby strumieni, takich jak nazwa strumienia, format przesyłanych danych, liczba kanałów, informację dostępu itp. Chociaż protokół SDP systemu RAVENNA zawiera kilka specyficznych rozszerzeń (np. informacje na temat domeny zegara i synchronizacji), każdy odtwarzacz multimedialny nie supportujący protokołu RAVENNA w dalszym ciągu może otrzymywać i odtwarzać strumień danych sieci RAVENNA, ignorując jej specyficzne rozszerzenia.
KONFIGURACJA URZĄDZEŃ I ICH WYKRYWANIE
Aby „uczestniczyć” w sieci opartej na protokole IP, urządzenie musi mieć swój unikalny adres IP. Mając już adres urządzenie musi „ogłosić światu”, czyli poinformować inne węzły sieci RAVENNA o swoim istnieniu – tak aby mogły one się z nim komunikować – informując jednocześnie o dostępności oferowanych przez siebie usług. To zgłaszanie się i wykrywanie nowych urządzeń w sieci umożliwia protokół DNS-SD. W celu wsparcia szerokiego zakresu środowisk aplikacji RAVENNA obsługuje dwie różne metody konfiguracji, zgłaszania i wykrywania nowych urządzeń – w sieciach zarządzanych usługi DHCP i DNS są przeważnie zarządzane i kontrolowane przez administratora sieci. W mniejszych sieciach, w których przeważnie serwery DHCP/DNS nie są dostępne, stosuje się mechanizmy „bezobsługowe”, tzn. takie, w których przydzielanie IP oraz zgłaszanie i wykrywanie nowych urządzeń działa w pełni automatycznie.
SYNCHRONIZACJA I QoS
Choć proste strumieniowanie w sieci możliwe jest bez żadnej synchronizacji, w profesjonalnych aplikacjach audio ścisła synchronizacja pomiędzy wszystkimi urządzeniami i strumieniami jest absolutnie konieczna. RAVENNA stosuje synchronizację pomiędzy wszystkimi węzłami sieci w oparciu o kolejny protokół stosowany w sieciach IP – EEE1588-2008 (Precision Time Protocol – czasami nazywany PTPv2). PTPv2 zapewnia synchronizację lokalnych zegarów z dokładnością do pojedynczych nanosekund w odniesieniu do zegara nadrzędnego – pod warunkiem wszakże, iż wszystkie switche w sieci suportują ten protokół. Jednak nawet bez natywnego wsparcia PTPv2 osiągana precyzja synchronizacji – w zależności od wielkości sieci i wykorzystania jej przepustowości – będzie więcej nie wystarczająca do osiągnięcia dokładnej synchronizacji próbek dla każdego węzła sieci. Synchronizacja na poziomie próbek może być też osiągalna w sieci WAN, jeśli lokalne zegary są zsynchronizowane z GPS-em, jako wspólną dziedziną czasową. RAVENNA umożliwia rozprowadzanie każdego wymaganego zegara dla mediów cyfrowych. Pozwala to na korzystanie z różnych zegarów w tej samej sieci równocześnie, np. na podróżowanie po jednej sieci strumieni taktowanych zegarem 44.1, 48, 96 i 192 kHz w tym samym czasie i bez jakichkolwiek wzajemnych zależności.
W tej samej sieci mogą się pojawić też strumienie o nominalnie tej samej częstotliwości próbkowania, ale odnoszącej się do różnych zegarów odniesienia. Dystrybucja zegara mediów cyfrowych jest niezależna od wszelkich danych i strumieni przepływających przez sieć. Z uwagi na to, że razem z protokołem RAVENNA w jednej sieci mogą współistnieć inne usługi, należy zapewnić priorytet dla ruchu danych RAVENNA w sieci. Dla sieci opartych na IP zdefiniowanych jest kilka schematów QoS (Quality of Service). Obecnie najpopularniejszym mechanizmem zapewniającym różne poziomy serwisowania usług dla warstwy 3 i wyższych, który jest stosowany w szerokim zakresie współcześnie oferowanych switchy, jest DiffServ. Działa on na zasadzie klasyfikacji ruchu, w której każdy pakiet danych jest umieszczany w ograniczonej liczbie klas ruchu, a nie różnicowania ruchu sieciowego na podstawie wymagań dla indywidualnego strumienia. Każda klasa ruchu może być zarządzana w innych sposób, zapewniając preferencyjne traktowanie dla zapewnienia wyższego priorytetu transferu w sieci. Również w obrębie samej sieci RAVENNA istnieją różne priorytety przypisane do różnych klas ruchu – najwyższy priorytet otrzymuje ruch związany z synchronizacją, zaraz za nim każdy ruch związany z transferem danych w czasie rzeczywistym, natomiast przesyłanie danych sterujących i konfigurujących będzie miało priorytet najniższy. Każdy ruch nie-RAVENNA’owy otrzyma najniższy (standardowy) priorytet.
LATENCJA
RAVENNA oferuje bardzo elastyczny schemat latencji, od bardzo małych (ułamki milisekund) do na tyle dużych, aby „przystawały” do ograniczeń infrastruktury WAN. W przeciwieństwie do innych rozwiązań RAVENNA nie wymusza ustawienia jednej wartości latencji dla całego systemu – opóźnienie propagacji może być regulowane indywidualnie dla każdego strumienia i zależy od szeregu czynników:
– infrastruktury sieci – z racji tego, że RAVENNA opiera się na protokole IP, praktycznie każda struktura sieciowa oparta na tym protokole nadaje się do wykorzystania dla RAVENNA. Tak więc szybkość transportu i wielkość latencji są bezpośrednio uzależnione od parametrów podstawowej infrastruktury sieciowej. Choć RAVENNA może pracować w obrębie sieci Fast Ethernet (100 Mbitów/s), zaleca się korzystanie z sieci Gigabitowej (przynajmniej dla połączeń szkieletowych).
– współczynnik pakietyzacji – jeśli próbki są grupowane w pakiety przed ich wysłaniem do sieci, to liczba próbek przypadających na pakiet bezpośrednio wpływa na latencję w tejże sieci (mniej próbek w pakiecie = mniejsze opóźnienie). RAVENNA pozwala nawet na pakietowanie typu jedna próbka na kanał, co z jednej strony daje minimalną latencję, jednak z drugiej prowadzi do zwiększenia wykorzystania przepustowości, kosztem liczby strumieni.
– jitter sieciowy – choć pakiety zawierające dane użytkowe są wytwarzane i wprowadzane do sieci w stosunkowo stabilnym izochronicznym tempie, zwykle mają tendencję do docierania do punktu docelowego z przerwami, pod wpływem konkurencyjnego ruchu na drodze poprzez sieć. Jest to kompensowane przez bufor fluktuacji (jitter buffer) po stronie odbiornika, który musi być na tyle duży, aby uwzględnić maksymalną oczekiwaną zmienność opóźnienia. W celu zminimalizowania negatywnego wpływu ruchów zakłócających RAVENNA wspiera stosowanie schematów QoS sieci IP. Korzystanie ze wspomnianego już DiffServ jest wysoce zalecane, ponieważ protokół ten jest obsługiwany przez większość zarządzanych switchy i wymaga tylko umiarkowanego administrowania nimi.
– korelacja pomiędzy strumieniami.
– obróbka na wejściu/wyjściu sieci – urządzenia pracujące w sieci przeważnie „dokładają” do ogólnej latencji w sieci swoje opóźnienie propagacji sygnału, wynikające z jego obróbki (konwersja A/D, D/A, przetwarzanie w DSP itp.), które przyczynia się do zwiększenia latencji z jednego końca sieci do drugiego. W niektórych konfiguracjach ta latencja, związana z konkretnym urządzeniem końcowym, może być brana pod uwagę przy obliczeniach latencji strumieniowych, w przypadku skorelowanego, jednoczesnego odtwarzania różnych strumieni.
Jak już wspomniałem, latencja może być skonfigurowana niezależnie dla każdego strumienia. Jednakże w celu uproszczenia konfiguracji latencji w setupie RAVENNA’y można zaprogramować gotowe ustawienia (presety) – np. mała, średnia, duża – z których można wybrać opóźnienie dla każdego pojedynczego strumienia. Odpowiednie parametry mogą być ustawione przez projektanta systemu lub administratora sieci. W 2017 roku firma Audinate wypuściło obsługę AES67 w swoich produktach Dante Brooklyn II, Dante Broadway, Dante PCIe, Dante MY-16, Dante HC i Dante IP Core. Tym samym produkty te mogą wysyłać strumienie audio do innych produktów innych niż Dante, które używają standardu AES67.
