Cyfrowe sieci audio-over-IP AVB, RAVENNA

Artykuł w numerze lutowym poświęciliśmy na przybliżenie konkretnych rozwiązań cyfrowych, wielokanałowych sieci audio – CobraNet, EtherSound i wypierającego je coraz śmielej protokołu Dante.

W tym numerze przyjrzymy się natomiast dwóm najnowszym, również coraz śmielej poczynającym sobie na rynku audio protokołom typu audio-over-IP – AVB i RAVENNA.

AVB

AVB, czyli Audio Video Bridging, jest to zestaw standardów technologicznych IEEE (Institute of Electrical and Electronics Engineers), przeznaczonych do przesyłania w czasie rzeczywistym sygnałów audio, wideo oraz innych przez sieć Ethernet.

Główną cechą wyróżniającą AVB na tle innych cyfrowych, wielokanałowych sieci audio – będącą jej największą zaletą – jest praca z zarezerwowaną częścią z całego dostępnego pasma przepustowego tylko dla „własnych” potrzeb, tzn. do przesyłania newralgicznych sygnałów, np. audio. Pakiety AVB są regularnie przesyłane w przydzielonych tylko dla nich slotach czasowych. W związku z tym, że część pasma jest zarezerwowana do tych celów, nie występują kolizje pakietów, a więc nie ma przerw i „dropów” w dźwięku transportowanym w ramach sieci AVB. Wszystkie węzły sieci pracują „pod dyktando” tego samego wirtualnego zegara. Pakiety AVB mają swój czas prezentacji, który określa kiedy dany pakiet ma być odtworzony. Dotyczy to nie tylko danych audio – pakiety AVB mogą zawierać dane różnego rodzaju. Nas jednak w tym momencie interesuje wykorzystanie sieci AVB do przesyłania dźwięku, toteż na tym głównie aspekcie się skupimy.

PROTOKÓŁ REZERWACJI STRUMIENIA

Jak wspomniałem, zasadniczą cechą AVB jest jej „umiejętność” dzielenia ruchu, który się odbywa na dwie grupy – przesyłanie danych w czasie rzeczywistych i pozostałych. Cały ruch w czasie rzeczywistym transmitowany jest w pakietach z częstotliwością 8 kHz, co oznacza że co każde 125 μs cały przesył w czasie rzeczywistym wysyła swoje dane. Pozostałe dane są transmitowane, jeśli nie ma więcej danych przesyłanych w czasie rzeczywistym – jeśli jednak zajmują one całe dostępne pasmo, cały pozostały ruch zostaje wstrzymany do czasu zwolnienia choćby części pasma. Jeśli zaś pasmo jest zbyt wąskie, aby przesłać wszystkie dane nie związane z transmisją w czasie rzeczywistym, występują opóźnienia w ich przesyle (rysunek 1).

Aby upewnić się, że do przesłania wszystkich danych w czasie rzeczywistym dysponujemy wystarczająco szerokim pasmem, wykorzystywany jest specjalny protokół, zajmujący się alokacją (przydzielaniem) dostępnego pasma.

Rysunek 2 prezentuje przykładową sieć AVB złożoną z dwóch switchy i czterech węzłów. Węzły A i D rezerwują dla siebie, aby przesłać między sobą strumień danych, niezbędne do tego pasmo (powiedzmy, 45 Mbit/s), zaś węzły B i C, aby się ze sobą bez problemów skomunikować, chcą sobie zarezerwować, dajmy na to, 20 Mbit/s. Wszystkie switche między węzłami (w naszym przypadku tylko dwa, ale może być ich oczywiście dużo więcej) muszą się upewnić, czy dostępne będzie odpowiednio szerokie pasmo, aby zapewnić bezpieczną transmisję zarówno dla pary AD, jak i BC, tj. muszą dysponować w naszym przypadku pasmem 65 Mbit/s. Jeśli urządzenia pracują w sieci 100-Megabitowej, dla transmisji pozostałych danych – np. internetowych, danych konfiguracyjnych itp. – pozostaje jedynie 35 Mbit/s. Jeśli będziemy chcieli przesłać dużą porcję tego typu danych z A do D, może nastąpić ich wstrzymanie lub opóźnienie na switchu X. Korzystanie z przydzielanego pasma pozwala AVB przesyłać dane z jednego punktu końcowego do drugiego punktu końcowego w 2-milisekundowym oknie czasowym. Aby spełnić to ograniczenie, AVB pozwala na nie więcej niż 7 „skoków”, z których każdy może wprowadzać maksymalnie 125-mikrosekundowe opóźnienie. Oznacza to, iż węzeł może transportować dźwięk z wymogiem, iż ma on być odtwarzany przez 2 ms „wprzód”, tak więc wszystkie próbki zostaną dostarczona na czas, aby być odtworzone w odpowiednim czasie.

Protokół przeznaczony do przydzielania pasma nazywa się Stream Reservation Protocol (SRP, IEEE 802.1Qat). Stanowi on fundamentalny element składowy AVB. Wszystkie węzły w systemie (switche i punkty końcowe) muszą suportować SRP i technologię kształtowania ruchu (shape traffic), aby móc wysyłać dane w czasie rzeczywistym z taktowaniem 8 kHz. Jeśli jeden z węzłów będzie „zwykłym” switchem ethernetowym, nie będzie on „potrafił” przesyłać priorytetowo danych wymagających przesyłu w czasie rzeczywistym, przez co może potencjalnie wprowadzać opóźnienia w przesyle tych danych albo – co gorsza – przerwy i zaniki audio.

PRECISION TIME PROTOCOL

Cały ruch sygnałów audio w AVB jest zsynchronizowany z globalnym zegarem, dzięki czemu producenci audio i konsumenci mogą odtwarzać i rejestrować dźwięk synchronicznie. Protokół PTP (Precision Time Protocol), powszechnie stosowany obecnie w sieciach komputerowych w celu zapewnienia synchronizacji zegara, implementuje zegar AVB.

PTP zakłada, że wszystkie węzły dysponują dobrym zegarem, opartym na krysztale kwarcu, o dokładności 25 ppm, co odpowiada 2 s na dzień. PTP, określony jako standard IEEE 802.1AS, jest drugim – po protokole przydzielania pasma – kluczowym elementem składowym AVB. Węzły PTP, która są połączone ze sobą za pomocą kabla ethernetowego, przesyłają między sobą regularne wiadomości, raportując czas i obliczając odchyłkę czasową między swoimi zegarami. Węzeł z najbardziej dokładnym czasem jest wybierany jako węzeł „master”. Wszystkie pozostałe szacują obliczają odchyłkę czasową w stosunku do zegara węzła „master”, pozwalając obliczyć lokalny zegar, który jest ściśle zsynchronizowany z zegarem „master”.

STRUMIENIE, KANAŁY, MÓWCY I SŁUCHACZE

AVB opera się na przesyłaniu danych. Jeśli tymi danymi są sygnały audio, strumień danych zawiera wiele (lub też tylko jeden) kanałów audio – mono, stereo lub w innych formatach, np. surround 5.1. Każdy pakiet AVB zawiera 125-mikrosekudnową porcję próbek wszystkich kanałów, które są częścią strumienia. Strumienie są wytwarzane przez „mówców” (talkers), czyli węzły, które wytwarzają dźwięk albo, inaczej, wpuszczają go do sieci. Może to być np. mikrofon, DVD lub laptop odtwarzający sygnał audio. „Słuchacze” to z kolei węzły, które „odsłuchują” lub pobierają przesyłany do nich sygnał( y) audio – mogą to być np. zestawy głośnikowe czy urządzenia rejestrujące.

Typowy system może składać się z np.
– Jednego „mówcy” (np. DVD) i sześciu „słuchaczy” (głośniki w systemie 5.1)
– Wielu mówców (np. mikrofonów) i zestawu głośników (jak w systemie konferencyjnym)
– Bardzo wielu mikrofonów (mówców) i innych źródeł dźwięku, sporej liczby głośników (słuchaczy) i konsolety mikserskiej (mówca/słuchacz w jednym)
– jak w klasycznym systemie nagłośnieniowym.

Nie ma narzuconej z góry maksymalnej czy minimalnej wielkości sieci AVB, są natomiast ograniczenia fizyczne i praktyczne. Jednym z nich jest ograniczenie wielkości strumienia (szerokości pasma) spowodowane możliwością przesłania sygnału przez kabel sieciowy – 100-megabitowa skrętka ethernetowa może przetransportować 9 stereofonicznych strumieni AVB (co daje nam w sumie 18 kanałów) lub pojedynczy strumień AVB składający się z maksymalnie 45 kanałów. Do wykrywania, numerowania i kontrolowania urządzeń i ich możliwości służy protokół IEEE 1722.1. Jest on odizolowany od rzeczywiście dostarczanych danych – hosty używają go wyłącznie do konfiguracji systemu.

DAISY-CHAIN

Z uwagi na to, iż w sieci AVB można używać tylko switchy suportujących tę technologię – a tych, póki co, nie ma za wiele i nie są niestety tanie – rozwiązania te mogą wydawać się dość kosztowne.

Jest na to jednak pewna rada – w niezbyt rozbudowanych aplikacjach można łączyć urządzenia obsługujące AVB łańcuchowo, czyli w tzw. układzie daisy-chain. Warunkiem niezbędnym do tego jest to, aby urządzenia miały dwa porty ethernetowe – A i B – co jednak jest normą w sprzęcie, który w technologię AVB jest wyposażony. A producentów, którzy wyposażyli w AVB swój sprzęt jest już „trochę” i z dnia na dzień ich przybywa. Możliwością pracy w AVB dysponują już urządzenia takich producentów jak Apple, AVID (VENUE S3L-X, którą szerzej opisujemy w tym numerze), BIAMP Systems (Tesira),

beyerdynamic (Quinta), BSS Audio (Soundweb London), Crown Audio (wzmacniacze z serii DCI ND), Meyer Sound (CAL, D-Mitri),

MOTU czy Presonus (konsolety StudioLive AI oraz RM).

Wróćmy do połączenia daisy-chain. W takim przykładowym połączeniu łańcuchowym (rysunek 3) laptop jest pierwszym węzłem sieci, podłączonym do węzła drugiego (głośnik), do jego portu A, który z kolei podaje sygnał z portu B do trzeciego węzła (mikrofon), a ten z kolei wchodzi sygnałem z portu B na czwarty węzeł sieci (kolejny głośnik), który jest węzłem końcowym.

Gdybyśmy jednak połączyli złącze B węzła czwartego z gniazdem A w laptopie, uzyskalibyśmy topologię „ring”, czyli redundancję w połączeniu takiej sieci. W takim też przypadku wszystkie węzły (lub – jeśli rozpatrujemy sieci z rysunku 3, bez zamknięcia ringu – tylko węzły 2 i 3) pracują w pewnym zakresie jako switche – sygnał może przez nie przechodzić dalej. Oczywiście węzły te mogą też „konsumować” lub nadawać sygnał z/do sieci, ale mogą też po prostu pełnić funkcję „podaj dalej”. Dzięki temu można zbudować sieć AVB bez konieczności stosowania switchy. Czegoś takiego w Dante niestety nie zrobimy – tam możemy jedynie połączyć dwa urządzenia, jeśli chcemy spiąć trzy, bez switcha się nie obejdzie. Z drugiej strony w Dante nie potrzebujemy specjalnych switchy, więc koszt „postawienia” sieci Dante nie odbiega od kosztów zwykłej sieci ethernetowej.

Wracając jeszcze raz do połączenia daisy-chain w sieci AVB musimy wiedzieć, że są tu jednak pewne ograniczenia. Po pierwsze, w przeciwieństwie do sieci ze switchami połączenie daisy-chain od pierwszego węzła do ostatniego wymaga przejścia sygnału przez wszystkie urządzenia w sieci. Mając sieć 100-megibitową z siedmioma węzłami połączonymi poprzez switch teoretycznie każdy węzeł może przesyłać dane w paśmie 100 Mbit/s. Gdybyśmy chcieli uzyskać to w połączeniu daisy-chain, pierwszy węzeł w sieci musiałby mieć przepustowość 700 Mbit/s. Na szczęście większość ruchu w sieci AVB jest typu multicast i tylko niewielka część tego ruchu jest adresowana do jednego tylko, konkretnego odbiorcy. Tak więc jeśli węzły w sieci daisy-chain „słuchają” tego samego strumienia, dodatkowy ruch w sieci jest niewielki.

Po drugie, w celu zagwarantowania maksymalnej latencji od jednego użytkownika końcowego do drugiego nie większej niż 2 ms standard AVB nie pozwala na stosowanie więcej niż siedmiu switchy w jednej sieci. To limituje też użycie nie więcej niż 7 urządzeń w sieci daisy-chain. Istnieją jednak dwa sposoby na obejście tego ograniczenia. Można albo zrezygnować z 2-milisekudnowej gwarancji latencji, albo stworzyć topologię mieszaną – daisy chain ze switchem. Pozwala to na zbudowanie całkiem nieźle rozbudowanej sieci, przy stosunkowo niewielkich kosztach (wymagających zakupu tylko jednego switcha AVB).

RAVENNA/AES67

RAVENNA jest rozwiązaniem przeznaczonym do dystrybucji w czasie rzeczywistym dźwięku wielokanałowego oraz innych sygnałów, 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 jego 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 3 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 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 niż 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-RAVENN’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 opera 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.

KTO WYGRA

Czy opisane w tym artykule protokoły/ systemy sieciowe są w stanie konkurować z królującym obecnie na rynku protokołem Dante i czy któryś z nich pozbawi w niedalekiej (albo dalszej) przyszłości Dante owego prymatu? A może wszystkie 3 będą zgodnie koegzystować, jak to już historia niejednokrotnie pokazywała? Czy może któryś z nich jednak odpadnie z wyścigu? Na dzień dzisiejszy AVB wydaje się być „o pół długości” przed RAVENNA, choć ten drugi wspierają (i implementują w swoich produktach) tacy producenci jak Lawo,

Genelec, Calrec, Riedel, Digigram, DirectOut, Orban czy Neumann/Sennheiser.

Z drugiej strony lista „biorców” technologii AVB jest równie imponująca – wystarczy jeszcze raz wymienić AVID, BIAMP, Apple, beyerdynamic, BSS Audio, Crown Audio, Meyer Sound, MOTU czy Presonus. Na pewno tak do jednej, jak i drugiej grupy dołączą jeszcze inni producenci.

Dużem plusem systemu RAVENNA może być jego zgodność ze standardem AES67 i otwartość technologii, choć z drugiej strony standaryzacja protokołu SuperMAC (AES50) nie za wiele pomogła w jego rozpropagowaniu i do dziś głównie urządzenia Midas/Behringer korzystają z tej technologii. AVB ma dobrze zaprojektowane zarządzanie priorytetami, dzięki czemu przesyłanie dźwięku na żywo jest bezpieczne, choć i RAVENNA w tej dziedzinie chwali się taką możliwością (zastosowanie tej technologii przez Lawo w jej urządzeniach broadcastowych daje dobre temu świadectwo). Przewagą RAVENNA nad AVB jest jeszcze fakt, iż jest to technologia w 100-procentach kompatybilna z KAŻDĄ siecią IP, nawet WAN, podczas gdy AVB wymaga używania „własnych” switchy.

Czas pokaże które podejście jest lepsze. Tak czy siak, rywalizacja zapowiada się bardzo ciekawie.

Piotr Sadłoń