W poprzednim numerze powiedzieliśmy sobie co nieco o cyfrowej sieci audio-over-IP Ravenna/AES67. Jej bezpośrednim konkurentem do drugiego miejsca na podium (w kategorii popularności) – bowiem, póki co, niekwestionowanym liderem jest tutaj Dante – jest sieć AVB. Pora więc napisać co nieco i o niej.
AVB, czyli Audio Video Bridging, jest to zestaw standardów technologicznych IEEE (Institute of Electrical and Electronics Engineers), przeznaczonych do przesyłania sygnałów audio, wideo oraz innych w czasie rzeczywistym 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.
Jak wspomniałem, zasadniczą cechą AVB jest jej „umiejętność” dzielenia odbywającego się ruchu na dwie grupy – przesyłanie danych w czasie rzeczywistym 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ł 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ć miedzy 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ą dostarczone 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.
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óre 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ą 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”.
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.
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, BIAMP Systems, 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łemsieci, 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ć ze sobą dwa urządzenia, jeśli chcemy ze sobą 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 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).
Czy opisane w tym i poprzednim 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 na 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
