Ethernet avb что это
Audio Video Bridging (AVB) - это общее название набора технических стандартов, которые обеспечивают улучшенную синхронизацию, малую задержку и надежность для коммутируемых сетей Ethernet . [3] AVB воплощает в себе следующие технологии и стандарты:
-
: синхронизация и синхронизация для приложений, чувствительных ко времени (gPTP); : пересылка и организация очереди для чувствительных ко времени потоков (FQTSS); -2010: протокол резервирования потока (SRP);
- IEEE 802.1BA-2011 : [4] Системы аудио-видео мостов (AVB);
- IEEE 1722-2011 транспортный протокол уровня 2 для чувствительных ко времени приложений (транспортный протокол AV, AVTP); а также
- IEEE 1722.1-2013 Протокол обнаружения, перечисления, управления и контроля устройств (AVDECC).
Поправки IEEE 802.1Qat и 802.1Qav были включены в базовый документ IEEE 802.1Q -2011, который определяет работу мостов управления доступом к среде (MAC) и виртуальных мостовых локальных сетей .
Первоначально AVB был разработан целевой группой Audio Video Bridging Института инженеров по электротехнике и электронике (IEEE) комитета стандартов IEEE 802.1 . В ноябре 2012 года группа задач Audio Video Bridging была переименована в группу задач Time-Sensitive Networking, чтобы отразить расширенный объем ее работы, которая заключается в «предоставлении спецификаций, которые позволят синхронизированные по времени потоковые сервисы с низкой задержкой через сети IEEE 802 ». [5] Дальнейшие усилия по стандартизации продолжаются в целевой группе IEEE 802.1 TSN.
Чтобы обеспечить взаимодействие между устройствами, реализующими стандарты AVB и TSN, AVnu Alliance разрабатывает сертификацию устройств для автомобильного, потребительского и профессионального рынка аудио и видео. [6]
Аналоговое аудио-видео (AV) оборудование исторически использовало односторонние одноцелевые соединения точка-точка. Даже цифровые стандарты AV, такие как S / PDIF для аудио и последовательный цифровой интерфейс (SDI) для видео, сохраняют эти свойства. Эта модель подключения приводит к появлению большого количества непонятных кабелей, особенно в профессиональных приложениях и высококачественном аудио. [7]
Попытки решить эти проблемы были основаны на многоточечных сетевых топологиях, таких как IEEE 1394 (FireWire), и включали адаптацию стандартных коммутируемых компьютерных сетевых технологий, таких как Audio over Ethernet и Audio over IP . К сожалению, профессиональные, домашние и автомобильные AV-решения стали использовать специализированные протоколы, которые не взаимодействуют между собой, или стандартные ИТ-протоколы, в то время как стандартные компьютерные сети не обеспечивали жесткого качества обслуживания со строгими временными параметрами и предсказуемой или ограниченной задержкой. [7]
Чтобы преодолеть эти ограничения, сети Audio Video Bridging передают несколько аудиовизуальных потоков через стандартные коммутаторы Ethernet (то есть мосты MAC ), соединенные в топологии иерархического дерева . AVB включает протоколы уровня 2 для резервирования полосы пропускания соединения и определения приоритетов сетевого трафика, что гарантирует точную синхронизацию и низкую задержку передачи для каждого потока. [7]
Тесная синхронизация между несколькими AV-потоками необходима для синхронизации губ между видео и связанными аудиопотоками, чтобы поддерживать синхронизацию нескольких динамиков с цифровым подключением по фазе в профессиональной среде (что требует точности 1 мкс), а также для предотвращения опоздания аудио- или видеопакетов. конечная точка, что приводит к пропаданию кадра видео и нежелательным сбоям звука, таким как треск или тишина. Задержка в наихудшем случае, включая буферизацию источника и назначения, должна быть низкой и детерминированной: задержка пользовательского интерфейса должна составлять около 50 мс, чтобы нажатие кнопки и результирующее действие воспринимались как происходящие мгновенно, и 2 мс для живого выступления или студийной работы. [7]
Аудио / видео мосты реализованы в виде коммутируемой сети Ethernet, которая работает, резервируя часть доступного Ethernet для AV-трафика. Архитектура AVB имеет три основных отличия:
- Точная синхронизация с использованием профиля Generalized Precision Time Protocol (gPTP) ( IEEE 802.1AS ), для AV-потоков с использованием приоритетов кадров ( IEEE 802.1Qav ) и тегов VLAN ( IEEE 802.1Q ), а также доступа с помощью протокола резервирования потока (IEEE 802.1Qat).
IEEE 802.1BA является зонтичным стандартом для этих трех основных технологий, который определяет конфигурации для конкретных приложений и рабочие процедуры для устройств в коммутируемых аудио-видео сетях.
Новые протоколы конфигурации уровня 2 работают с обратно совместимыми расширениями формата кадра Ethernet 802.1; такие минимальные изменения позволяют устройствам AVB сосуществовать и обмениваться данными в стандартных ИТ-сетях, однако только коммутаторы с поддержкой AVB и конечная точка могут резервировать сетевые ресурсы с контролем доступа и синхронизировать местное время с главными часами, что требуется для чувствительного ко времени трафика с низкой задержкой .
Трафик AVB реплицируется в многоадресном режиме с одним говорящим (инициатором потока) и несколькими слушателями. Пакеты AVB отправляются через равные промежутки времени в выделенных временных интервалах, предотвращая конфликты для AV-трафика. AVB гарантирует задержку 2 мс для трафика класса A и 50 мс для трафика класса B в течение максимум 7 переходов с периодом передачи 125 мкс для трафика класса A и 250 мкс для трафика класса B.
Сетевой временной домен IEEE 802.1AS включает в себя все устройства, которые обмениваются данными с использованием протокола gPTP. Гроссмейстер - это устройство, выбранное в качестве эталонных часов; спецификация 802.1BA требует, чтобы каждый говорящий и сетевой мост был совместим с грандмастером.
Протоколы управления каналом 802.3 и протоколы измерения задержки канала 802.1AS вычисляют двустороннюю задержку до конечной точки AVB; это должно быть лучше, чем задержка в наихудшем случае из алгоритма задержки однорангового узла 802.1AS.
Протоколы более высокого уровня могут использовать информацию часов 802.1AS для установки точного времени представления для каждого AV-потока.
ПЛАНИРОВАНИЕ СЕТИ
Что входит в состав готового решения? Прежде всего нужны коммутаторы с поддержкой AVB и устройства для конвертации звука (для цифрового или аналогового форматов) в Ethernet с поддержкой AVB. При этом протоколы AVB должны поддерживаться каждым задействованным устройством, то есть нужна сквозная поддержка AVB. В любом случае требуется грамотное планирование всей сети.
В зависимости от решаемых задач необходимо рассчитать количество потоков и необходимую пропускную способность. Так, на один звуковой канал (моно) требуется около 6 Мбит/с, если это несжатый звук. Зная количество потоков, можно определить, какие соединения потребуются (100 Мбит/с, 1, 10, 40 Гбит/с).
Если, например, в сети имеется 100 устройств, на которых необходимо воспроизводить один и тот же контент, и на каждое устройство направлять отдельный поток, то эти потоки займут всю доступную емкость. Однако, задействовав многоадресную рассылку, можно на один поток подключить даже 500 устройств.
Кроме того, сеть Ethernet налагает ограничение на дальность передачи. В случае медной проводки она составляет 100 м, а чтобы задержка не превышала 2 мс, в сети не должно быть более 7 транзитных узлов (для каналов 100 Мбит/с). Когда в сети используются гигабитные соединения, при тех же 7 транзитных узлах задержка будет составлять менее 1 мс.
Кирилл Жуков — системный инженер Extreme Networks.
Переход от прямых соединений к сетевым решениям для подключения профессионального аудиовизуального оборудования, начавшийся два десятилетия назад, набирает силу (особенно это касается звуковой техники). Открывающиеся возможности, в частности свободное перемещение устройств внутри помещения, привлекают все больше и больше сторонников.
Несмотря на определенную популярность решений с использованием специализированных коммутаторов, наибольшее распространение получили протоколы для передачи звука на базе IP (Audio over IP), поскольку они могут быть реализованы в существующей сетевой инфраструктуре. Сегодня используется более двух десятков подобных протоколов, как открытых, так и проприетарных. Наиболее популярным среди них является протокол Dante, разработанный австралийской компанией Audinate.
В случае аналоговых систем звуковое оборудование обычно соединяется кабелями напрямую: один канал — один кабель. Медные аудиокабели занимают много места, тяжелы и громоздки. Их подключение — трудоемкая и дорогостоящая процедура, которая, помимо прочего, чревата ошибками в крупных инсталляциях. В случае же AoIP по одному витопарному кабелю можно одновременно передавать данные десятков и сотен аудиоканалов.
Помимо сокращения объема работ и удешевления проекта в целом, применение AoIP обеспечивает и функциональные преимущества, в том числе возможность маршрутизации аудиосигналов на большие расстояния без ухудшения их качества. При этом маршрут передачи сигнала может быть скорректирован, по сути, щелчком мыши без внесения изменений в кабельную проводку. В свою очередь, отсутствие деградации сигнала позволяет отказаться от усилителей, которые необходимы для компенсации ослабления сигнала из-за электромагнитных помех, высокочастотного затухания и падения напряжения.
ОСОБЕННОСТИ АУДИО-ВИДЕО
Профессиональные аудиовидеосистемы (Audio Video System, AVS) должны обеспечивать студийное качество звука и видео, при этом они предъявляют высокие требования к уровню задержки, которая не должна превышать 2 мс. Чаще всего используется кодек без сжатия, для каждого канала выделяется отдельный кабель, соединение организуется по принципу «точка — точка», связь односторонняя, полудуплексная. При этом процесс коммутации подключений достаточно трудоемок, потому что каждый производитель реализует в выпускаемом им оборудовании свои разъемы и свои стандарты передачи (SDI для видео и S/PDIF для звука).
В результате при построении систем AVS на базе традиционных технологий приходится использовать большое количество устройств. Все они связаны между собой множеством кабелей, а для коммутации требуется весьма сложное и дорогостоящее оборудование. Причем это постоянная коммутация, то есть с одного и того же микрофона звук выводится на те же самые колонки — оборудование нельзя настраивать динамически.
Как изменится картина при использовании сети Ethernet? Количество необходимых кабелей и оборудования резко сократится. Так что же мешает перевести АВ-сигнал в сеть IP? Ведь давно уже существуют технологии передачи аудиовидеоконтента по сети: VoIP, IP-TV, различные методы кодирования, оцифровки и разбиения на кадры. Однако нельзя просто взять Ethernet-коммутаторы и поставить их в сеть АВ: стандартная технология Ethernet не позволяет обеспечить ни допустимую (не более 2 мс) задержку при прохождении сигнала через всю сеть, ни синхронизацию по времени и равномерный поток данных, ни гарантированную пропускную способность и автоматическое обнаружение устройств. Именно для решения этих проблем, без чего невозможно перевести весь АВ-трафик на Ethernet, и был разработан стандарт AVB.
DetNet
Рабочая группа IETF по детерминированным сетям (DetNet) работает над определением детерминированных трактов данных с границами задержки, потерь и вариаций задержки пакетов (джиттер), а также высокой надежностью. DetNet должна работать как над сегментами моста уровня 2, так и над сегментами с маршрутизацией уровня 3, полагаясь, когда это возможно, на взаимодействие с коммутаторами AVB / TSN. [18]
Одно из возможных применений DetNet - профессиональные аудио / видео системы, такие как производство музыки и фильмов, вещание, кино, живой звук и системы для больших площадок (стадионы, залы, конференц-центры, тематические парки, аэропорты, вокзалы и т. Д.). для публичного обращения, потоковой передачи мультимедиа и оповещения о чрезвычайных ситуациях. Заявленная цель состоит в том, чтобы обеспечить географически распределенную интранет на территории кампуса / предприятия для доставки контента с ограниченной низкой задержкой (10-15 мс). Единая сеть должна обрабатывать как аудио / видео, так и ИТ-трафик, с маршрутизацией уровня 3 поверх сетей QoS AVB, чтобы обеспечить совместное использование контента между сегментами AVB уровня 2 и обеспечить интеграцию IntServ и DiffServ с AVB, где это возможно. Неиспользованная зарезервированная полоса пропускания должна быть освобождена для трафика максимального усилия. Стек протоколов должен иметь возможность Plug-and-play сверху вниз, чтобы уменьшить ручную настройку и администрирование, позволять быстро изменять сетевые устройства и топологию сети. [19]
Крупномасштабные сети AVB, подобные тем, которые используются в вещательном центре ESPN SportsCenter «Digital Center 2», в котором размещены несколько отдельных студий, проложены с использованием оптоволоконных кабелей в тысячу миль и имеют пропускную способность десять Тбит / с для сотни тысяч сигналов, передаваемых одновременно; при отсутствии стандартного решения для соединения отдельных сегментов AVB требуется настраиваемый программно-определяемый сетевой маршрутизатор. [20] [21]
Работа над потоковой передачей аудио / видео началась в исследовательской группе IEEE 802.3re «Residential Ethernet » в июле 2004 года. [22] В ноябре 2005 года она была передана комитету IEEE 802.1, ответственному за стандарты межсетевого моста . [23]
Речь в сегодняшней заметке пойдет о принципиально новой технологии передачи профессионального цифрового AV — “Audio Video Bridging”.
В настоящее время все остальные технологии (CobraNET, EtherSound и др. ) являются проприетарными (читать- платными) или вообще связанными с Ethernet очень отдаленно.
AVB – это семейство протоколов разрабатываемых IEEE (тем же институтом что и стандартизовал сам Ethernet), т.е. не требующих никаких авторских отчислений.
Для тех кому лень читать, можно просто просмотреть презентацию, тем кому интересны детали и комментарии прошу под кат.
В современном мире ProAV до сих пор преобладают аналоговые подключения. Которые в свою очередь могут передать один поток по одному кабелю.
Такой подход приводит к тому что кабельная инфраструктура становиться избыточной и очень дорогостоящей, как на этапе инсталляции, так и в дальнейшем обслуживании.
А существующие проприетарные решения цифровизации (CobraNET, EtherSound и др.), не позволяют решить проблему кардинально (масштабирование, совместимость, …).
Но интерес рождает спрос, и такие гиганты ИТ индустрии как Broadcom, Cisco, Harman, Intel, Xilinx основали AVNU Alliance, в который уже сейчас входит 50 компаний.
Эта некоммерческая организация занимается развитием, продвижением, сертификацией на совместимость продуктов AVB.
Так как стандартизацией занимается IEEE 802.1, то неудивительно что принцип работы AVB, и DCB (Data Center Bridging) очень похож (разрабатывают соседние команды одной рабочей группы).
Семейство протоколов AVB включает в себя:
1. 802.1AS (Timing and Synchronization (gPTP) — Позволяет синхронизировать потоки с точностью до 0,5 мкс в пределах 7 хопов. Идея работы протокола взята из стандарта IEEE 1588v2
Для работы данного протокола необходима аппартная поддержка, так как на порту должны проставляться “time-stamp”,
Поэтому оборудование некоторых производителей использующих собственные ASICs не будут поддерживать AVBдаже после обновления софта.
2. 802.1Qav (Traffic Shaping) — Профилирование трафика, позволяет обеспечить работу в пределах максимальной задержки для пакетов “class А” (профи системы), и “class B” (пользовательские) — 2 и 50 мс соответственно, а также сглаживание трафика для устранения возможных потерь.
3. 802.1Qat (Stream Reservation Protocol (SRP) – Динамическое резервирование до 75 % ресурса линка для передачи потока. Используются два верхних профиля QoS
4. 802.1BA (Audio Video Bridging (AVB) Systems) — Определение устройств AVB и их идентификации в сети (скорость и дуплекс работы линка, поддержка 802.1 AS, вычисление задержки, подтверждение резервации ресурсов)
Остальные протоколы является не менее важными дополнениями для полноценной работы AVB систем
IEEE 1722, 1733 — Протоколы описывающие транспорт для сетей AVB
IEEE 1722.1* — Протокол для обнаружения, контроля, нумерации, устройств работающих по 1722
При этом только последний пока является Draft версией, остальные стандарты приняты.
Целостная система AVB состоит из следующий частей:
• Endpoint – являются по сути “AVB – gateway” которые осуществляют АЦП и ЦАП преобразования с необходимым форматированием, могут быть
a. Talker (микрофон, камера, микшер, …)
b. Listener (колонки, монитор, пульт, . )
c. Both (микшер, пульт, …)
• AVB Bridge – коммутатор поддерживающий AVB
• Controller – устройство или софт с помощью которого происходит обнаружение всех “Endpoint” и их потоков, отображение их оператору для принятия решения о их коммутации.
Ниже представлена блок-схема включений работающего стенда
Преимуществ от использования систем AVB очень много:
— никакого vendor-lock
— совместное использование AVB, и non-AVB устройств в одной сети
— увеличенная пропускная способность
— гибкое масштабирование
— стандартная СКС
— упрощенная инсталляция и траблшутинг
— использование РоЕ
— а также многое другое
В качестве обратной стороны медали, наверное стоит упомянуть то что для работы AVB-системы все потоки постоянно должны транслироваться в сеть.
Но учитывая низкую стоимость Ethernet транспорта, это не является большой проблемой. Особенно если учесть математику для пропускной способности одного линка:
– Each stereo / AES3 channel stream = ~8 MB / stream
1000 MB * 0.75 / ~8 MB
= ~94 streams (реально 97)
Так как актуальность данной темы не вызывает сомнения, то многие участники AVNU альянса уже выпустили коммерческие образцы AVB продуктов, количество реализованных проектов постоянно растет несмотря на молодость технологии.
Если коснутся сетевой части, то в данный момент на рынке доступны коммутаторы с поддержкой AVB от LABx, BSS/Netgear и Extreme Networks (наиболее полная линейка). Поэтому выбирая коммутаторы Extreme Networks вы инвестируете в будущее сети своей компании!
Audio Video Bridging позволяет устранить потенциальные проблемы при переводе профессионального АВ-контента в сеть Ethernet.
Процесс перехода на компьютерные технологии затронул практически весь медиарынок. За последние несколько десятилетий от традиционной телефонии почти ничего не осталось. Лишь в некоторых домах еще сохранилась проводка в виде «лапши», но на всех магистральных каналах провайдеры если не перешли, то активно осуществляют переход на VoIP. Аналогичный процесс наблюдается и в сфере телевидения — все чаще эта услуга предоставляется как IP-TV через Интернет, по сетям Ethernet и IP, что открывает доступ к более разнообразному контенту.
То же происходит и с видеонаблюдением. Прежде для этого строились отдельные сети и инфраструктура. Теперь повсеместно используются IP-видеокамеры, а сигнал от них передается по компьютерной сети на записывающее и воспроизводящее устройство. Почему же столь популярен переход с проприетарных, закрытых технологий на Ethеrnet? Причина в унификации. А что дает унификация? Ответ прост — экономию.
Одна перспективная область, где переход на использование компьютерной сети еще не состоялся, — это профессиональные аудиовидеосистемы. В них применяются достаточно закрытые технологии, собственные протоколы и, естественно, специализированная инфраструктура. Помимо студий звукозаписи, эти системы развертываются на больших объектах, где необходимо установить оборудование для звукового оповещения, доставки контента, показа видео. Речь идет о стадионах, концертных комплексах, конференц-залах, парках, отелях, аэропортах и студиях вещания.
Профессиональные аудиовидеосистемы — это совершенно особый мир. Мало кто из специалистов по ИТ разбирается в АВ настолько же хорошо, как, например, в сетях. У этих решений достаточно много нюансов. Первый и самый главный — качество доставки аудио- и видеоконтента. Технология Audio Video Bridging (AVB) позволяет устранить потенциальные проблемы, которые возникают при переводе профессионального АВ-контента в сеть Ethernet: обеспечить синхронизацию, резервирование полосы, равномерный поток данных и т. д. По оценкам аналитиков, у этого рынка большой потенциал — около 2 млрд долларов (при текущем объеме 100 млн долларов).
РАЗНОВИДНОСТИ АУДИО ПО СЕТИ
Системы AoIP позволяют передавать несжатые цифровые аудиосигналы по Ethernet/IP. В зависимости от того, на каком уровне они работают, протоколы делятся на три больших класса: физического, канального и сетевого уровней.
Протоколы физического уровня позволяют передавать сигнал от одного устройства к другому по обычным витопарным кабелям Категории 5е или лучше. К ним относятся такие протоколы, как AES50 компании Behringer или Roland Ethernet Audio Communication (REAC).
Протоколы канального уровня позволяют создать канал между двумя устройствами в сети. Первым протоколом этого класса был Cobra Net компании Cirrus Logic, который появился еще в 1996 году. Другим ее известным представителем является Ethersound.
IEEE был принят стандарт 802.1BA на Audio Video Bridging (AVB) (а также ряд сопутствующих стандартов). AVB разрабатывался таким образом, чтобы минимизировать необходимые изменения в сетевой инфраструктуре. Однако для сетевой трансляции видео и аудио профессионального качества все мосты (коммутаторы) на пути передачи сигнала должны поддерживать AVB.
С помощью протоколов сетевого уровня можно соединить множество устройств и обеспечить коммутацию сигналов между ними. Помимо Dante, таковыми являются проприетарный протокол Livewire, предложенный Axia Audio, и открытый протокол Ravenna от ALC NetworX. Первый широко используется телерадиовещательными компаниями. Второй послужил базисом при разработке AES67 (он появился позже, чем Dante, а у его создателей своеобразное чувство юмора: в Равенне находится могила Данте).
ОСНОВНЫЕ СТАНДАРТЫ И ТЕРМИНЫ
На самом деле AVB — это целая группа стандартов IEEE:
- 802.1BA описывает общую архитектуру системы AVB, в том числе автоматическое обнаружение и задание параметров устройств;
- 802.1AS отвечает за синхронизацию;
- 801.Qav расширяет 802.1Q в части обслуживания чувствительных ко времени потоков;
- 801.Qat дополняет 802.1Q протоколом резервирования потоков.
Для начала познакомимся с используемыми терминами. Все конечные устройства подразделяются на Talker, Listener и Endpoint. Talker, или говорящее устройство, передает контент в сеть. Listener, или слушатель, этот контент получает, или слушает. Endpoint, или собственно конечная точка, представляет собой любое устройство, которое может принимать и/или передавать трафик AVB. Таким образом, конечная точка может быть как передатчиком, так и приемником или обоими одновременно. Помимо этого, вводится понятие потока, под которым подразумевается поток медиаданных от передатчика и к приемнику. Стандарт AVB предусматривает возможность вещания с одного микрофона на несколько воспроизводящих устройств.
В качестве примера рассмотрим простую сеть (см. Рисунок 1), к которой подключено два источника звука (гитара и барабаны) и два потребителя звука (2 колонки). Любые музыкальные устройства — и гитара, и барабаны — издают аналоговые сигналы. Чтобы аналоговый сигнал попал в сеть, его нужно перевести в цифровой вид. А для передачи оцифрованного сигнала по сети специальные устройства — экспандеры и конвертеры — должны инкапсулировать его в протокол AVB. Соответственно, каждое аналоговое устройство снабжено экспандером, который как раз и конвертирует звук в цифровой вид. На выходе установлены другие два экспандера, конвертирующие цифровой звук обратно в аналоговый формат.
![]() |
Рисунок 1. Обнаружение и настройка AV-устройств. |
Чтобы экспандеры «знали», на какое конечное устройство направлять сигнал, необходим сервер управления, в данном примере это BIAMP Tesira. С его помощью оператор системы АВ производит настройку подключенных к сети устройств. Кроме того, система управления отвечает за обнаружение в сети подключенных устройств.
IEEE 1722 AVTP
IEEE Std 1722-2011 [8] для транспортного протокола аудио-видео уровня 2 (AVTP) определяет детали для передачи потоков IEEE 1394 / IEC 61883 и других AV-форматов, установки времени представления для каждого AV-потока и управления задержками в худшем случае. рассчитывается по протоколу gPTP.
РАЗНОВИДНОСТИ АУДИО ПО СЕТИ
Системы AoIP позволяют передавать несжатые цифровые аудиосигналы по Ethernet/IP. В зависимости от того, на каком уровне они работают, протоколы делятся на три больших класса: физического, канального и сетевого уровней.
Протоколы физического уровня позволяют передавать сигнал от одного устройства к другому по обычным витопарным кабелям Категории 5е или лучше. К ним относятся такие протоколы, как AES50 компании Behringer или Roland Ethernet Audio Communication (REAC).
Протоколы канального уровня позволяют создать канал между двумя устройствами в сети. Первым протоколом этого класса был Cobra Net компании Cirrus Logic, который появился еще в 1996 году. Другим ее известным представителем является Ethersound.
IEEE был принят стандарт 802.1BA на Audio Video Bridging (AVB) (а также ряд сопутствующих стандартов). AVB разрабатывался таким образом, чтобы минимизировать необходимые изменения в сетевой инфраструктуре. Однако для сетевой трансляции видео и аудио профессионального качества все мосты (коммутаторы) на пути передачи сигнала должны поддерживать AVB.
С помощью протоколов сетевого уровня можно соединить множество устройств и обеспечить коммутацию сигналов между ними. Помимо Dante, таковыми являются проприетарный протокол Livewire, предложенный Axia Audio, и открытый протокол Ravenna от ALC NetworX. Первый широко используется телерадиовещательными компаниями. Второй послужил базисом при разработке AES67 (он появился позже, чем Dante, а у его создателей своеобразное чувство юмора: в Равенне находится могила Данте).
AES67
Ближайшим соперником Dante является протокол Ravenna, он не столь популярен, но в некоторых областях применения является доминирующим. В отличие от Dante, это открытый протокол. Он поддерживает более широкий спектр форматов данных: разрядность 16, 24 и 32 бита и соответствующие частоты дискретизации. По одной и той же сети могут передаваться потоки с данными различных форматов. Если Dante для передачи трафика использует UDP/IP, то Ravenna — RTP, благодаря чему он может применяться для передачи не только аудио, но и видео.
Помимо Dante и Ravenna, на рынке имеется множество других протоколов. С ростом популярности транспорта AoIP отсутствие интероперабельности между ними стало проблемой для пользователей, в частности, это выражалось в вынужденной зависимости от решений одного вендора (и его партнеров) и в ограниченности выбора оборудования. Для обеспечения совместимости общество звукоинженеров (Audio Engineering Society, AES) разработало открытый стандарт AES67, который был опубликован в 2013 году.
AES67 содержит набор рекомендаций, которым должны следовать производители, чтобы их системы были совместимы между собой. Привлекательной чертой AES67 является, как это ни покажется странным, его ограниченная функциональность. По сути поддерживается только транспорт аудиопотоков по сети — стандарт призван обеспечить доставку аудио от отправителя получателю с наименьшими накладными расходами (наилучшей производительностью). Маршрутизация, мониторинг, обнаружение и контроль устройств и управление соединениями осуществляются внешними по отношению к нему средствами.
Чтобы гарантировать взаимопонимание получателя и отправителя, AES67 предъявляет минимальный набор требований, которым должно отвечать оборудование AoIP. Стандарт поддерживает разные показатели частоты дискретизации, разрядности, размера пакетов, а также разное количество каналов. Однако для большей совместимости используемые устройства должны поддерживать один основной формат обмена — так называемый опорный формат (pivot format): частоту дискретизации 48 кГц, два канала, разрядность 28 бит, пакеты с фрагментами длительностью 1 мс (48 сэмплов в каждом) (см. таблицу).
Целью разработки AES67 была не замена существующих протоколов, а обеспечение беспроблемного обмена аудиопотоками между различными устройствами и системами, их поддерживающими. Для минимизации задержки и передачи оцифрованного звука без искажений AES67 задействует существующие интернет-стандарты, а именно RTP для транспорта данных, PTPv2 для синхронизации, QoS для приоритетной доставки звукового трафика и SDP для обмена информацией о потоке между отправителем и получателем.
Протокол поддерживает как многоадресную рассылку (multicast), так и целевую одноадресную передачу (unicast). Первая позволяет максимально эффективно использовать пропускную сеть при наличии управляемых коммутаторов. Отправителю не надо генерировать отдельные аудиопотоки для каждого получателя: достаточно сделать это один раз — и аудиопоток будет доставлен всем адресатам. (Неуправляемые коммутаторы воспринимают многоадресный трафик как широковещательный и направляют его на все порты. При большом количестве аудипотоков это чревато перегрузкой сети.) В случае одноадресной передачи применяется протокол инициирования сеансов (Session Initiation Protocol, SIP).
Стандарт претерпел несколько редакций, последняя была опубликована в апреле этого года. Самое существенное изменение — Декларация о совместимости реализаций протокола (Protocol Implementation Conformance Statement, PICS). AES67 не определяет, каким образом должен быть реализован стандарт, каждый производитель может это сделать по-своему. Для PICS требуется заполнить проформу, где указывается, какие функции и опции реализованы. Как отмечается на сайте AES, PICS — «важный инструмент для обеспечения совместимости реализаций AES67».
Совместимость с AES67 обеспечивают многие производители, предлагающие собственные решения для построения сетей AoIP; в их числе Audinate (Dante), ALC NetworX (Ravenna), LiveWire (TelosAlliance) и др. Они реализуют функции обнаружения и контроля, которые намеренно не были включены в стандарт.
РЕЗЕРВИРОВАНИЕ ПОТОКОВ
Что происходит после определения задержек в сети? Когда оператор АВ-системы указывает, что звук от гитары и барабанов должен поступать на обе колонки, сервер управления информирует соответствующие экспандеры о том, что им нужно передавать звук такому-то и такому-то конечному оборудованию (его экспандерам). Затем в действие вступает протокол резервирования потоков (Stream Reservation Protoсol, SRP).
Это одно из самых важных добавлений в стандарт, так как оно позволяет гарантировать полосу для трафика. Причем речь идет не о гарантии средствами QoS, а о жестком выделении требуемой пропускной способности. До 75% пропускной способности интерфейса может быть отдано под AVB, а 25% оставлено для другого трафика, чтобы AVB не занимал весь канал.
В данном примере аудиопотоки идут напрямую от источников к устройствам воспроизведения, но на практике они, скорее всего, будут проходить через систему микширования.
Милан
В 2018 году Avnu Alliance объявил о миланской инициативе по продвижению совместимости устройств AVB, а также по сертификации и тестированию продуктов. [17]
Согласно спецификации требуется синхронизация носителя на основе AVTP CRF (эталонный формат тактовой частоты) и частота дискретизации 48 кГц (опционально 96 и 192 кГц); Формат аудиопотока основан на 32-битном стандартном аудиоформате AAF AVTP IEC 61883 -6 с 8 каналами на поток (опционально, 24- и 32-битный формат высокой емкости с 56 и 64 каналами). Резервирование обеспечивается двумя независимыми логическими сетями для каждой конечной точки и механизмом плавного переключения. [17]
AES67
AES67 основан на стандартном RTP через UDP / IP и протоколе точного времени IEEE 1588 (PTPv2) для синхронизации; совместимость с AVB / TSN может быть достигнута путем связывания информации синхронизации IEEE 802.1AS с данными полезной нагрузки AES67 PTPv2. [11] [12] [13] [14]
Реализация AES67 с функциональной совместимостью AVB была продемонстрирована на InfoComm 2016. [15] [16]
AES67
Ближайшим соперником Dante является протокол Ravenna, он не столь популярен, но в некоторых областях применения является доминирующим. В отличие от Dante, это открытый протокол. Он поддерживает более широкий спектр форматов данных: разрядность 16, 24 и 32 бита и соответствующие частоты дискретизации. По одной и той же сети могут передаваться потоки с данными различных форматов. Если Dante для передачи трафика использует UDP/IP, то Ravenna — RTP, благодаря чему он может применяться для передачи не только аудио, но и видео.
Помимо Dante и Ravenna, на рынке имеется множество других протоколов. С ростом популярности транспорта AoIP отсутствие интероперабельности между ними стало проблемой для пользователей, в частности, это выражалось в вынужденной зависимости от решений одного вендора (и его партнеров) и в ограниченности выбора оборудования. Для обеспечения совместимости общество звукоинженеров (Audio Engineering Society, AES) разработало открытый стандарт AES67, который был опубликован в 2013 году.
AES67 содержит набор рекомендаций, которым должны следовать производители, чтобы их системы были совместимы между собой. Привлекательной чертой AES67 является, как это ни покажется странным, его ограниченная функциональность. По сути поддерживается только транспорт аудиопотоков по сети — стандарт призван обеспечить доставку аудио от отправителя получателю с наименьшими накладными расходами (наилучшей производительностью). Маршрутизация, мониторинг, обнаружение и контроль устройств и управление соединениями осуществляются внешними по отношению к нему средствами.
Чтобы гарантировать взаимопонимание получателя и отправителя, AES67 предъявляет минимальный набор требований, которым должно отвечать оборудование AoIP. Стандарт поддерживает разные показатели частоты дискретизации, разрядности, размера пакетов, а также разное количество каналов. Однако для большей совместимости используемые устройства должны поддерживать один основной формат обмена — так называемый опорный формат (pivot format): частоту дискретизации 48 кГц, два канала, разрядность 28 бит, пакеты с фрагментами длительностью 1 мс (48 сэмплов в каждом) (см. таблицу).
Целью разработки AES67 была не замена существующих протоколов, а обеспечение беспроблемного обмена аудиопотоками между различными устройствами и системами, их поддерживающими. Для минимизации задержки и передачи оцифрованного звука без искажений AES67 задействует существующие интернет-стандарты, а именно RTP для транспорта данных, PTPv2 для синхронизации, QoS для приоритетной доставки звукового трафика и SDP для обмена информацией о потоке между отправителем и получателем.
Протокол поддерживает как многоадресную рассылку (multicast), так и целевую одноадресную передачу (unicast). Первая позволяет максимально эффективно использовать пропускную сеть при наличии управляемых коммутаторов. Отправителю не надо генерировать отдельные аудиопотоки для каждого получателя: достаточно сделать это один раз — и аудиопоток будет доставлен всем адресатам. (Неуправляемые коммутаторы воспринимают многоадресный трафик как широковещательный и направляют его на все порты. При большом количестве аудипотоков это чревато перегрузкой сети.) В случае одноадресной передачи применяется протокол инициирования сеансов (Session Initiation Protocol, SIP).
Стандарт претерпел несколько редакций, последняя была опубликована в апреле этого года. Самое существенное изменение — Декларация о совместимости реализаций протокола (Protocol Implementation Conformance Statement, PICS). AES67 не определяет, каким образом должен быть реализован стандарт, каждый производитель может это сделать по-своему. Для PICS требуется заполнить проформу, где указывается, какие функции и опции реализованы. Как отмечается на сайте AES, PICS — «важный инструмент для обеспечения совместимости реализаций AES67».
Совместимость с AES67 обеспечивают многие производители, предлагающие собственные решения для построения сетей AoIP; в их числе Audinate (Dante), ALC NetworX (Ravenna), LiveWire (TelosAlliance) и др. Они реализуют функции обнаружения и контроля, которые намеренно не были включены в стандарт.
IEEE 1722.1 AVDECC
IEEE Std 1722.1-2013 [9] - это стандарт, который позволяет обнаружение, перечисление, управление подключением и контроль AVB (AVDECC) устройств с использованием IEEE Std 1722-2011. AVDECC определяет операции по обнаружению добавления и удаления устройств, извлечению модели объекта устройства, подключению и отключению потоков, управлению устройством и статусом подключения, а также устройствам удаленного управления.
Службы более высокого уровня могут улучшить синхронизацию и задержку передачи мультимедиа, сопоставив идентификатор потока AVB с идентификаторами внутреннего потока и основывая внутренние временные метки на основных часах gPTP.
ПРОТОКОЛ DANTE
Протокол Dante представлен австралийской компанией Audinate в 2006 году. Это был далеко не первый протокол данного класса: Livewire появился в 2003 году, а Wheatnet IP — в 2005-м. Однако ни их предшественникам, ни последователям не удалось добиться того же успеха, что Dante. Его поддерживают свыше 400 производителей профессионального аудио-оборудования, и он интегрирован в более чем 1400 продуктов (см., например, рис. 1). По числу доступных продуктов Dante опережает конкурентов в несколько раз (см. рис. 2).
Поэтичное название протокола расшифровывается весьма прозаически: цифровое аудио по сети Ethernet (Digital Audio Network Through Ethernet, Dante). К тому же такое название не совсем верно отражает его природу (но чего не сделаешь ради красивого названия) — Dante относится к решениям сетевого уровня, а не канального (использует IP-пакеты).
Источник: ProTools Expert
Впрочем, этот протокол рассчитан на те же области применения, что и CobraNet и EtherSound. По сравнению с двумя последними он обеспечивал дополнительные преимущества: изначальную поддержку гигабитных скоростей, большее число каналов, меньшую задержку и автоматическую конфигурацию.
Dante удалось завоевать популярность не только за счет технических достоинств, но и благодаря принятой бизнес-модели и ориентации на более широкий рынок. В то время как конкурирующие протоколы были ориентированы на телерадиовещательный сегмент, Dante предназначался для использования с профессиональным аудиооборудованием в студиях звукозаписи, конференционных залах и переговорных, системах фоновой трансляции музыки и т. д.
Сам разработчик описывает Dante как «многоканальную цифровую сетевую технологию передачи несжатого звука с практически нулевой задержкой и точной синхронизацией». Под Dante, или сетью Dante, подразумевается не только протокол, но и решение для передачи оцифрованного звука по стандартным сетям Ethernet, куда входят аппаратное и программное обеспечение (физические и виртуальные звуковые карты, программный контроллер).
IEEE 1722 AVTP
IEEE Std 1722-2011 [8] для транспортного протокола аудио-видео уровня 2 (AVTP) определяет детали для передачи потоков IEEE 1394 / IEC 61883 и других AV-форматов, установки времени представления для каждого AV-потока и управления задержками в худшем случае. рассчитывается по протоколу gPTP.
ПРОТОКОЛ DANTE
Протокол Dante представлен австралийской компанией Audinate в 2006 году. Это был далеко не первый протокол данного класса: Livewire появился в 2003 году, а Wheatnet IP — в 2005-м. Однако ни их предшественникам, ни последователям не удалось добиться того же успеха, что Dante. Его поддерживают свыше 400 производителей профессионального аудио-оборудования, и он интегрирован в более чем 1400 продуктов (см., например, рис. 1). По числу доступных продуктов Dante опережает конкурентов в несколько раз (см. рис. 2).
Поэтичное название протокола расшифровывается весьма прозаически: цифровое аудио по сети Ethernet (Digital Audio Network Through Ethernet, Dante). К тому же такое название не совсем верно отражает его природу (но чего не сделаешь ради красивого названия) — Dante относится к решениям сетевого уровня, а не канального (использует IP-пакеты).
Источник: ProTools Expert
Впрочем, этот протокол рассчитан на те же области применения, что и CobraNet и EtherSound. По сравнению с двумя последними он обеспечивал дополнительные преимущества: изначальную поддержку гигабитных скоростей, большее число каналов, меньшую задержку и автоматическую конфигурацию.
Dante удалось завоевать популярность не только за счет технических достоинств, но и благодаря принятой бизнес-модели и ориентации на более широкий рынок. В то время как конкурирующие протоколы были ориентированы на телерадиовещательный сегмент, Dante предназначался для использования с профессиональным аудиооборудованием в студиях звукозаписи, конференционных залах и переговорных, системах фоновой трансляции музыки и т. д.
Сам разработчик описывает Dante как «многоканальную цифровую сетевую технологию передачи несжатого звука с практически нулевой задержкой и точной синхронизацией». Под Dante, или сетью Dante, подразумевается не только протокол, но и решение для передачи оцифрованного звука по стандартным сетям Ethernet, куда входят аппаратное и программное обеспечение (физические и виртуальные звуковые карты, программный контроллер).
СТОЛКНОВЕНИЕ ПРИОРИТЕТОВ
Если какой-нибудь пользователь начинает загружать из Интернета файл большого объема и скачивание занимает значительную пропускную способность какого-либо интерфейса, то полосу, выделенную для потоков AVB, этот трафик не сможет использовать. Однако при просмотре, например, потокового видео или в случае проведения ресурсоемкой телеконференции конкурирующий за полосу трафик тоже имеет высокий приоритет (см. Рисунок 2).
![]() |
Рисунок 2. Стандарт FQTSS распределяет пакеты по времени, обеспечивая равномерный, плавный поток пакетов AVB. |
Он обеспечивает своего рода формирование трафика (shaping), но не совсем обычное — на основе кредитных буферов. FQTSS распределяет пакеты по времени, то есть обеспечивает равномерный, плавный поток пакетов AVB, что исключает возникновение разницы в задержке, позволяя избежать джиттера.
ЗАКЛЮЧЕНИЕ
Первые протоколы AoIP появились больше двух десятков лет назад, однако только в последние несколько лет они получили признание в области профессионального аудио и видео. С каждым годом системы становятся все более функциональными — и при этом дешевеют. Как следствие, растет число профессионалов в области записи и воспроизведения звука, которые используют аудио поверх IP.
Стандартом де-факто в области профессионального аудио стал протокол Dante. Благодаря широкой поддержке производителей, пользователи получили возможность выбора из множества вариантов самых разнообразных моделей устройств. Однако использование такого проприетарного решения достаточно рискованно: отрасль может оказаться в зависимости от лицензионной политики одного вендора, столкнуться с проблемами в случае ухода компании с рынка и т. п.
Впрочем, рынок профессиональных решений AoIP пока находится в стадии становления. Об этом свидетельствует присутствие на нем множества различных экосистем, базирующихся на проприетарных протоколах. А значит, говорить об окончательном выборе в пользу какого-то конкретного протокола, наверное, преждевременно. К тому же, как показывает вся предыдущая история ИТ, выбор в пользу открытых подходов неизбежен: где-то он делается раньше, где-то — позже.
Как бы то ни было, в переходе на IP профессионалы в области аудио продвинулись намного дальше, чем их коллеги, занимающиеся видео. При этом следует отметить, что общество инженеров кино и телевидения (Society of Motion Picture and Television Engineers, SMPTE) разрабатывает пакет стандартов SMPTE ST 2110 Professional Media Over Managed IP Network с целью создания общего механизма для передачи профессионального аудио, видео и мультимедиа по управляемым сетям IP.
SMPTE 2110 — не первая попытка вещательной отрасли перевести производство на IP. В отличие от предшественников, SMPTE 2110 предусматривает раздельную передачу видео, аудио и вспомогательных данных (см. рис. 3). Такой подход обеспечивает гибкость, позволяя независимо маршрутизировать и обрабатывать отдельные потоки. Транспорт аудио по IP описывается в стандарте SMPTE ST 2110-30, который базируется на AES67 (с небольшими дополнениями).
Источник: Netinsight
Пока же SMPTE 2110 ограничен пределами локальных сетей. Ему, как и многочисленным разновидностям AoIP, еще предстоит выйти на широкие просторы Интернета.
Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»
IEEE 1733
IEEE Std 1733-2011 [10] определяет профиль протокола уровня 3 для приложений транспортного протокола реального времени (RTP) с форматом полезной нагрузки RTCP , который назначает идентификатор потока из SRP идентификатору источника синхронизации (SSRC) RTP и коррелирует RTP. отметки времени для времени представления с главными часами 802.1AS gPTP.
СИНХРОНИЗАЦИЯ
В большом помещении, например в концертном зале, колонки, воспроизводящие звук, находятся в разных его частях, и поэтому возникает проблема синхронизации. Необходимо сделать так, чтобы звук в эти колонки поступал в одно и то же время, иначе та, что находится ближе к источнику, будет воспроизводить его раньше, чем расположенная, скажем, за тремя коммутаторами, каждый из которых вносит определенную задержку при прохождении сигнала. Одновременность воспроизведения обеспечивает протокол синхронизации.
Как он работает? Во-первых, все устройства обмениваются определенными пакетами, проверяя, что каждое из них поддерживает протокол 802.1AS (это касается всех устройств, сертифицированных по стандарту AVB). Дальше, автоматически или путем настройки вручную, в сети выбирается так называемый гранд-мастер, который становится единственным и самым главным эталоном времени в сети. Это может быть любое сетевое устройство, в данном случае мы выбрали Biamp Tesira. Оно может «брать» время как из сети (с любого сетевого устройства по протоколу NTP), так и от какого-то внешнего источника (например, от установленных рядом атомных часов).
Этот гранд-мастер сообщает всем остальным устройствам, сколько сейчас времени, при этом протокол учитывает, что пакеты, идущие до конкретного экспандера, передаются по конкретному пути. Каждое устройство AVB на пути прохождения пакета записывает в пакете 802.1AS вносимую им задержку: условно говоря, коммутатор указывает, что на входящем интерфейсе 100 Мбит/с такая-то задержка, при прохождении трафика между двумя его портами задержка такая-то, на исходящем гигабитном интерфейсе, соответственно, задержка такая-то. Все задержки суммируются и отражаются в пакете 802.1AS. Таким образом, в поступившем на конечное устройство пакете содержится фактическая задержка при передаче по сети.
Как видим, устройства не только синхронизируют часы и получают информацию о точном времени, но и определяют задержку, вносимую любыми сетевыми узлами. Зная точное время и величину задержки на каждом этапе, можно рассчитать так называемое презентационное время, когда должен быть воспроизведен сигнал на всех получателях. Оно определяется исходя из самого худшего варианта прохождения сигнала от источника к устройству воспроизведения. Соответственно, звук с гитары отправляется на дальнюю колонку раньше, чем на ближнюю, поэтому на обе колонки он приходит одновременно.
Это одно из самых главных достижений группы стандартов AVB: обеспечение синхронизации по времени в сети Ethernet при предсказуемых задержках, благодаря чему достигается синхронное воспроизведение звука и видео.
ЗАКЛЮЧЕНИЕ
Первые протоколы AoIP появились больше двух десятков лет назад, однако только в последние несколько лет они получили признание в области профессионального аудио и видео. С каждым годом системы становятся все более функциональными — и при этом дешевеют. Как следствие, растет число профессионалов в области записи и воспроизведения звука, которые используют аудио поверх IP.
Стандартом де-факто в области профессионального аудио стал протокол Dante. Благодаря широкой поддержке производителей, пользователи получили возможность выбора из множества вариантов самых разнообразных моделей устройств. Однако использование такого проприетарного решения достаточно рискованно: отрасль может оказаться в зависимости от лицензионной политики одного вендора, столкнуться с проблемами в случае ухода компании с рынка и т. п.
Впрочем, рынок профессиональных решений AoIP пока находится в стадии становления. Об этом свидетельствует присутствие на нем множества различных экосистем, базирующихся на проприетарных протоколах. А значит, говорить об окончательном выборе в пользу какого-то конкретного протокола, наверное, преждевременно. К тому же, как показывает вся предыдущая история ИТ, выбор в пользу открытых подходов неизбежен: где-то он делается раньше, где-то — позже.
Как бы то ни было, в переходе на IP профессионалы в области аудио продвинулись намного дальше, чем их коллеги, занимающиеся видео. При этом следует отметить, что общество инженеров кино и телевидения (Society of Motion Picture and Television Engineers, SMPTE) разрабатывает пакет стандартов SMPTE ST 2110 Professional Media Over Managed IP Network с целью создания общего механизма для передачи профессионального аудио, видео и мультимедиа по управляемым сетям IP.
SMPTE 2110 — не первая попытка вещательной отрасли перевести производство на IP. В отличие от предшественников, SMPTE 2110 предусматривает раздельную передачу видео, аудио и вспомогательных данных (см. рис. 3). Такой подход обеспечивает гибкость, позволяя независимо маршрутизировать и обрабатывать отдельные потоки. Транспорт аудио по IP описывается в стандарте SMPTE ST 2110-30, который базируется на AES67 (с небольшими дополнениями).
Источник: Netinsight
Пока же SMPTE 2110 ограничен пределами локальных сетей. Ему, как и многочисленным разновидностям AoIP, еще предстоит выйти на широкие просторы Интернета.
Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»
Переход от прямых соединений к сетевым решениям для подключения профессионального аудиовизуального оборудования, начавшийся два десятилетия назад, набирает силу (особенно это касается звуковой техники). Открывающиеся возможности, в частности свободное перемещение устройств внутри помещения, привлекают все больше и больше сторонников.
Несмотря на определенную популярность решений с использованием специализированных коммутаторов, наибольшее распространение получили протоколы для передачи звука на базе IP (Audio over IP), поскольку они могут быть реализованы в существующей сетевой инфраструктуре. Сегодня используется более двух десятков подобных протоколов, как открытых, так и проприетарных. Наиболее популярным среди них является протокол Dante, разработанный австралийской компанией Audinate.
В случае аналоговых систем звуковое оборудование обычно соединяется кабелями напрямую: один канал — один кабель. Медные аудиокабели занимают много места, тяжелы и громоздки. Их подключение — трудоемкая и дорогостоящая процедура, которая, помимо прочего, чревата ошибками в крупных инсталляциях. В случае же AoIP по одному витопарному кабелю можно одновременно передавать данные десятков и сотен аудиоканалов.
Помимо сокращения объема работ и удешевления проекта в целом, применение AoIP обеспечивает и функциональные преимущества, в том числе возможность маршрутизации аудиосигналов на большие расстояния без ухудшения их качества. При этом маршрут передачи сигнала может быть скорректирован, по сути, щелчком мыши без внесения изменений в кабельную проводку. В свою очередь, отсутствие деградации сигнала позволяет отказаться от усилителей, которые необходимы для компенсации ослабления сигнала из-за электромагнитных помех, высокочастотного затухания и падения напряжения.
НАСТРОЙКА AVB НА КОММУТАТОРАХ
AVB изначально создавался таким образом, чтобы для его поддержки требовалось внести лишь минимальные изменения в стандарт Ethernet, в устройства, участвующие в организации сети Ethernet, и в настройки оборудования.
Формально, для того чтобы настроить AVB на коммутаторах, необходимо выполнить настройки следующих компонентов:
- VLAN;
- протокола резервирования полосы;
- шейпинга;
- синхронизации и т. д.
На первый взгляд, это сложно, но на коммутаторах Extreme Networks протокол AVB настраивается одной командой enable AVB ports all, за которой скрывается много внутренних команд, то есть это некая автонастройка, позволяющая коммутатору самостоятельно осуществлять синхронизацию, резервирование пропускной способности и другие действия.
Чтобы коммутатор Ethernet мог поддерживать AVB, в нем должна быть реализована аппаратная и программная поддержка. В коммутаторах Extreme аппаратная поддержка обеспечивается установленными в них чип-сетами, а программная — операционной системой. В настоящее время Extreme Networks — единственная компания, выпускающая коммутаторы корпоративного уровня с поддержкой AVB и одновременно POE и POE+. Для использования AVB никаких дополнительных лицензий приобретать не нужно.
РОЕ и РОЕ+ нужны для питания экспандеров, потому что колонки, микрофоны и другие системы могут располагаться где угодно. В огромном концертном зале колонка может находиться достаточно далеко от розетки, и ее подключение к сети Ethernet через экспандер требует подведения к нему электричества. Чтобы упростить инфраструктуру, в том числе электрическую, для питания таких устройств лучше задействовать РОЕ.
ТЕХНИЧЕСКИЕ ОСОБЕННОСТИ
Протокол предназначен для использования в сетях Ethernet на 100 Мбит/с и 1 Гбит/с. Теоретически по сети можно передавать неограниченное количество каналов — для этого достаточно добавить столько коммутаторов и сетевых карт, сколько требуется. Однако максимальное число каналов на конкретном порту ограничено его пропускной способностью.
Для 64 аудиоканалов с частотой дискретизации 48 кГц и разрядностью 24 бита необходима полоса шириной 74 Мбит/с. В результате на каждом 100-мегабитном порту может поддерживаться 48 двунаправленных аудиоканалов, а на гигабитном порту — до 512 двунаправленных аудиоканалов.
Типовая задержка в сети Dante составляет 1 мс. Как утверждает разработчик, такой показатель обеспечивается в сети с 10 транзитными коммутаторами при протяженности кабелей между ними до 100 м. В случае необходимости его можно настроить для каждого устройства в диапазоне от 150 мкс до 5 мс, однако при сверхмалых задержках возможны проблемы с производительностью.
Для качественного воспроизведения звука нужна синхронизация устройств. Среди сетевых устройств проводятся «выборы»: в итоге главным становится то, у которого синхронизация оказывается лучшей, а все остальные синхронизируются с ним. Для согласования используется протокол точного времени (Precision Time Protocol, PTP), так что расхождение не превышает нескольких микросекунд (до 1 мкс, по утверждению разработчика).
При отказе главного синхронизирующего устройства новое выбирается заново за доли секунды, это никак не сказывается на качестве звука. Каждое устройство имеет собственные часы. Поскольку локальные часы синхронизированы и процедура выбора длится недолго, рассинхронизации за это время не происходит. При полной потере синхронизации звук отключается, чтобы слушатели ничего не заметили.
ТЕХНИЧЕСКИЕ ОСОБЕННОСТИ
Протокол предназначен для использования в сетях Ethernet на 100 Мбит/с и 1 Гбит/с. Теоретически по сети можно передавать неограниченное количество каналов — для этого достаточно добавить столько коммутаторов и сетевых карт, сколько требуется. Однако максимальное число каналов на конкретном порту ограничено его пропускной способностью.
Для 64 аудиоканалов с частотой дискретизации 48 кГц и разрядностью 24 бита необходима полоса шириной 74 Мбит/с. В результате на каждом 100-мегабитном порту может поддерживаться 48 двунаправленных аудиоканалов, а на гигабитном порту — до 512 двунаправленных аудиоканалов.
Типовая задержка в сети Dante составляет 1 мс. Как утверждает разработчик, такой показатель обеспечивается в сети с 10 транзитными коммутаторами при протяженности кабелей между ними до 100 м. В случае необходимости его можно настроить для каждого устройства в диапазоне от 150 мкс до 5 мс, однако при сверхмалых задержках возможны проблемы с производительностью.
Для качественного воспроизведения звука нужна синхронизация устройств. Среди сетевых устройств проводятся «выборы»: в итоге главным становится то, у которого синхронизация оказывается лучшей, а все остальные синхронизируются с ним. Для согласования используется протокол точного времени (Precision Time Protocol, PTP), так что расхождение не превышает нескольких микросекунд (до 1 мкс, по утверждению разработчика).
При отказе главного синхронизирующего устройства новое выбирается заново за доли секунды, это никак не сказывается на качестве звука. Каждое устройство имеет собственные часы. Поскольку локальные часы синхронизированы и процедура выбора длится недолго, рассинхронизации за это время не происходит. При полной потере синхронизации звук отключается, чтобы слушатели ничего не заметили.
Читайте также: