Sync a New Level of Show

В этой главе мы с вами познакомимся с различными протоколами, которые появились на фоне активного развития интерфейсов передачи данных. Некоторые из них базируются на уже хорошо нам известном протоколе MIDI, а некоторые были созданы с нуля для решения определенных задач синхронизации.

Благодаря тому, что интерфейс передачи MIDI полностью цифровой, то без особых изменений пакеты данных MIDI можно передавать через более современные и быстрые интерфейсы. Ассоциация MMA понимала, что MIDI стал довольно популярным стандартом для работы в разных индустриях, но при этом развитие этого стандарта упиралось в технические особенности физического серийного интерфейса, на котором базировался MIDI. И тогда MMA ассоциация начала смотреть в сторону других успешных технологий передачи данных, чтобы уйти от технических недостатков, которые накладывал старый интерфейс передачи данных. И по итогу на свет начали появляться новые технологии передачи MIDI.

RTP (Real-time Transport Protocol) — это протокол высокого уровня, который базируется на UDP, но при этом имеет свои преимущества, которые были специально разработаны для стриминга аудио и видео. Основная его особенность в том, что каждый пакет данных этого протокола имеет в заголовке абсолютное время отправки, которое может прочитать принимающее устройство и определить задержку и порядок доставки сообщений. Такие преимущества идеально подошли для MIDI, и в 2004 году на свет появилась первая версия протокола RTP-MIDI. Позже компания Apple включила этот протокол в состав своих операционных систем и активно дорабатывала его. И как следствие этого, протокол получил второе название Apple MIDI. Позже был написан отдельный драйвер для Windows и Linux, который также позволял использовать протокол в этих системах.

Так же, как и в случае с OSC, этот протокол базируется на физическом интерфейсе Ethernet, и как следствие, RTP-MIDI также наследует все преимущества этого интерфейса передачи данных. Соответственно, чтобы использовать протокол RTP-MIDI, так же как и с OSC, изначально необходимо поднять сеть, в которой будут находиться все наши сетевые клиенты. Как это сделать, мы уже узнали в главе «Концепт построения сетей».

Давайте теперь поговорим об идеологии этого протокола. В RTP — MIDI есть такое понятие, как «Сессия». «Сессия» — это виртуальная среда, к которой могут подключаться клиенты, для того чтобы обмениваться MIDI сообщениями. Для начала в сети должен быть тот, кто создаст эту сессию. Это может быть либо компьютер, либо другое устройство. Создатель сессии будет являться мастер устройством или, говоря терминологией RTP-MIDI, «Инициализатором сессии». После того как в сети будет создана сессия, другие клиенты могут к ней подключиться и стать участниками этой сессии. В сети может быть создано несколько сессий, и они могут работать независимо. Но при этом удобство заключается в том, что клиент сам может выбрать, к какой сессии ему необходимо подключиться. После того как клиент стал участником сессии, в операционной системе появляются виртуальные MIDI порты, которые могут использовать приложения для приема и передачи MIDI сигнала.

Одно из немаловажных преимуществ RTP-MIDI заключается в том, что на уровне этого протокола реализованы схемы разделения и смешивания MIDI сигналов (Split/Merge). Ниже представлена простейшая схема транспорта сообщений между разными участниками сессии, где видно, что устройство номер один является инициализатором сессии, к которому подключены другие участники сети. При отправлении MIDI сообщения с главного устройства (Device 1) это сообщение автоматически дублируется на все остальные клиенты. Но при этом, если сообщения отправят другие клиенты сессии (Device 2 и Device 3), то они будут получены только инициализатором сессии, т.е. устройством номер один. Эти сообщения автоматически будут соединены и направлены на его виртуальный MIDI IN порт.

Так как RTP-MIDI — это по сути лишь способ передачи MIDI через Ethernet, то все, что касается протокола MIDI, остается по-прежнему тем же самым, единственное, что отличается, это способ доставки MIDI сообщений. По этой причине предлагаю разобрать пример того, как создать RTP-MIDI сессию и как подключить к ней клиентов для обмена сообщениями. Чтобы в будущем вы сами для себя решали, использовать ли физические MIDI карты и коммутацию для работы и экспериментов или использовать сетевую альтернативу RTP-MIDI.

Ниже представлен список операционных систем и название программ, которые добавляют в систему возможность работы с протоколом RTP-MIDI.

Некоторые программисты, которые читают эту книгу, возможно, спросят, а где же Linux? Существуют библиотеки, которые позволяют интегрировать поддержку этого протокола во внутрь отдельной программы в момент разработки приложения программистами, эти библиотеки есть для всех операционных систем, в том числе и Linux. Приложения под Windows и Android были написаны программистами-энтузиастами, которые выложили свои программы в открытый доступ, за что им огромное спасибо.

Если вы пользователь устройств Apple, то вам ничего не нужно устанавливать, так как, как я уже говорил, RTP-MIDI уже интегрирован в системы MAC OS и iOS. А вот для других операционных систем нужно скачивать специальные драйверы и программное обеспечение.

Предлагаю создать сессию в системе MAC OS. Приложение для Windows выглядит абсолютно идентично с таким же интерфейсом и функционалом. Итак, чтобы открыть меню для работы с RTP-MIDI в MAC OS, зайдите в папку Applications и откройте приложение Audio MIDI Setup. Если перед вами откроется окно настроек аудио без окна MIDI, в панели меню откройте Window и в выпадающем меню нажмите на опцию Show MIDI Studio, и перед вами откроется окно, содержащее устройства MIDI.

Для работы с RTP-MIDI нам нужно нажать на иконку глобуса в верхнем правом углу. Давайте разберемся, что здесь к чему

Итак, чтобы создать новое подключение, необходимо:

1. Ниже раздела Sessions, с правой стороны окна настройки RTP-MIDI, необходимо указать номер порта, который будет использоваться для передачи и приема этого протокола. Как мы помним, RTP-MIDI использует низкоуровневый протокол UDP, а как следствие, для приема и передачи данных мы должны указать конкретный порт. По умолчанию RTP — MIDI использует порт 5004, но если этот порт уже занят каким-нибудь приложением, мы можем указать любой другой свободный порт.

2. Далее необходимо указать Local name, это имя виртуальной MIDI карты, которая будет использоваться в нашей системе. И также необходимо указать Bonjour name, это имя сессии, которую будут видеть клиенты в сети.

3. Теперь нужно активировать сессию, для этого необходимо поставить галочку напротив Enabled верхней части окна Session.

4. И также необходимо настроить правила безопасности, которые позволяют настроить права подключения к сессии. В нижней части окна настроек RTP-MIDI слева раскройте выпадающий список Who can connect to me: и выберите одну из опций. Так как клиенты сами могут подключаться в сессию, иногда нужно ограничить правила подключения.

5. Если необходимо добавить нового клиента, вручную нажмите кнопку ниже окна Directory и введите имя, адрес и порт клиента, который должен стать участником вашей сессии. В завершении, чтобы добавить клиентов в вашу сессию, выберите устройство в окне Directory и нажмите кнопку Connect. Если клиент успешно добавлен в сессию, он появится в окне Participants:

Список MIDI портов, сигнал с которых приложение RTP-MIDI может перенаправить в сессию

Хотел бы также упомянуть об очень удобной опции, которая позволяет перенаправить потоки MIDI c сессии на физическое устройство и наоборот. Для этого в правой нижней части программы, напротив Live routings, раскройте необходимый список оборудования на вход или выход и выберите MIDI порт, на который необходимо направить поток с сессии или, наоборот, отправить поток в сессию. В этом случае наш компьютер

выступает как конвертер, который преобразует между собой физический MIDI и сетевой RTP-MIDI.

Подводя итог всех особенностей протокола RTP-MIDI, можно сказать:

• Первая особенность, этот протокол абсолютно совместим со всеми MIDI протоколами, которые были разработаны для передачи через классический серийный интерфейс данных MIDI.

• Вторая, для работы с RTP-MIDI нет необходимости использовать MIDI карты для передачи сообщений MIDI, так как протокол был разработан для работы через локальную сеть, вам достаточно иметь любое устройство, которое имеет сетевую карту, для подключения к сети.

• Третья особенность вытекает из второй благодаря тому, что этот интерфейс работает через локальную сеть, он наследует все преимущества сетевых технологий передачи данных Ethernet, Wi-Fi и оптоволокна, одни из которых — дальность передачи и скорость сигнала, что является одним из недостатков классического интерфейса MIDI.

• И четвертая, в RTP-MIDI сессии уже реализована идеология соединения и разделения MIDI сигнала между клиентами, что также позволяет оказаться от использования специализированных MIDI сплиттеров и мерджеров.

Bluetooth уже довольно взрослая беспроводная технология, которая активно используется в мобильных устройствах. А так как в мобильных устройствах всегда уделяли внимание экономии ресурсов батареи, то на свет появилась новая, более усовершенствованная версия Bluetooth, которая намного умнее использует ресурсы мобильного устройства. И по итогу новая версия стала называться Bluetooth Low Energy или, сокращенно, BLE, также у него есть и второе название — Bluetooth SMART. Так как новый стандарт стал более привлекателен, производители стали активно внедрять новую технологию в свои устройства. MMA (MIDI Manufacturers Association) не стало исключением, в 2014 разработав новый протокол BLE-MIDI, передаваемый через Bluetooth Low Energy. И как следовало ожидать, компания Apple не заставила себя долго ждать и в этом же году объявила о поддержке протокола BLE-MIDI в своих вновь вышедших релизах операционных систем iOS 8 и OS X 10.10. В течение года компания Apple исправляла ошибки и дорабатывала этот протокол. И в 2015 году ассоциация MMA приняла все их изменения и утвердила финальную версию BLE-MIDI.

Теперь поговорим об особенностях BLE-MIDI. В отличие от RTP — MIDI, он не настолько функционален. К примеру, по этой технологии вы можете настроить подключение только между шестнадцатью устройствами. По причине того, что скорость Bluetooth не настолько велика. В сравнении с RTP-MIDI мы можем создать практически неограниченное количество сессий в одной системе, количество зависит от скорости нашей сети и мощности системы, на которой поднимаются сессии. И также Bluetooth имеет ограниченный радиус действия, до 10 метров прямой видимости. Но есть и плюсы, так же как и с RTP-MIDI, BLE-MIDI отправляет пакеты данных с абсолютными маркерами времени, что также обеспечивает синхронность приема пакетов данных. Также отличие BLE-MIDI подключения от других Bluetooth соединений в том, что BLE-MIDI использует отличную от стандартного Bluetooth систему передачи данных по радиоканалу, которая обеспечивает минимальные задержки на кодирование данных, передачу их по радиоканалу и декодинг для обеспечения максимальной скорости передачи данных между устройствами.

После этого всего вы можете задать вполне ожидаемый вопрос, для чего же тогда нужен BLE-MIDI, если у него столько недостатков по сравнению с RTP-MIDI? Ответ очень прост. Для работы с BLE-MIDI нам не нужно никакого дополнительного оборудования, не нужно создавать проводную или беспроводную сеть, мы просто включаем встроенный Bluetooth в устройстве, подключаемся к клиенту и начинаем работать. Это очень удобно, когда у нас нет необходимости в создании сложной системы синхронизации. К примеру, нам нужно просто с телефона отправить MIDI команды на компьютер, к которому привязаны определенные действия. Или нам нужно просто проверить нашу систему управления по MIDI, но у нас нет под рукой физически MIDI пульта, мы можем с эмулировать работу MIDI консоли с телефона, подключившись по BLE-MIDI.

Теперь об идеологии подключения BLE-MIDI. Хотя бы одно из BLE-MIDI устройств должно стать инициализатором подключения. В понятии BLE-MIDI это устройство должно начать «рекламировать» свое подключение, чтобы клиент мог его увидеть и подключиться. Как только клиент подключился к устройству, которое инициализировало подключение, мастер устройство перестает «рекламировать» свое подключение и спаривается с клиентом. Теперь устройства могут обмениваться сообщениями.

Также хочется упомянуть еще об одной особенности. Стандартные интерфейсы настройки подключения к Bluetooth устройствам по умолчанию не видят BLE-MIDI оборудование и его подключение. К примеру, когда мы на компьютере или на телефоне хотим подключить новое Bluetooth устройство, мы заходим в стандартное меню поиска новых устройств, находим в списке устройство и подключаем его.

На Apple устройствах через стандартное меню мы не сможем найти BLE-MIDI устройства, а на Windows и Android мы увидим устройство, но либо нам не удастся к нему подключиться, либо подключение через некоторое время будет обрываться. Дело в том, что BLE-MIDI подключения отличаются от стандартных устройств, и для его подключения нам нужно использовать дополнительные программы, которые могут распознавать BLE-MIDI. Обычно на смартфонах и компьютерах устанавливается дополнительный софт, который может обнаружить такие соединения и также создать виртуальные MIDI порты.

Как я уже говорил, Apple — первая компания, которая интегрировала BLE-MIDI в свои операционные системы. В MAC OS уже есть необходимое программное обеспечение, которое позволяет и «рекламировать» подключение, и также видеть и подключаться к BLE-MIDI устройствам. В iOS хоть такая поддержка и есть, но отдельного софта для работы с этим протоколом нет. Apple реализовала возможность подключения оригинальной библиотеки BLE-MIDI от Apple для интеграции работы с этим протоколом в приложениях. Это значит, что если производитель софта хочет открыть в своем приложении возможность работать с этим протоколом, то ему достаточно подключить стандартную библиотеку. В других системах, Windows, Android и Linux, для работы с этим протоколом нужно ставить дополнительное программное обеспечение, которое будет позволять видеть такие подключения и подключаться к ним с эмуляцией виртуальных MIDI портов. Хорошая новость в том, что таких приложений существует не одно, и пользователь сам может выбрать, с каким ему удобнее работать. Пример разных приложений и их возможностей мы разберем в главе «Программное обеспечение для работы с протоколами синхронизации».

А сейчас предлагаю посмотреть, как устроено приложение для работы с BLE-MIDI в MAC OS.

Чтобы попасть в настройки BLE-MIDI в MAC OS, так же, как и в случае с RTP-MIDI, нам нужно открыть окно MIDI Studio. Напомню, для этого нужно зайти в папку Applications и открыть приложение Audio MIDI Setup. Если перед вами откроется окно настроек аудио, без окна MIDI, в панели меню откройте Window и в выпадающем меню нажмите на опцию Show MIDI Studio. Перед вами откроется окно со всеми MIDI картами, которые подключены к системе, и также вы увидите иконки для доступа к дополнительным меню для работы с технологиями передачи MIDI.

Чтобы открыть меню настройки технологии BLE-MIDI, необходимо нажать на иконку Bluetooth в правой части панели управления.

Как мы видим, здесь все довольно просто. В поле NAME мы можем задать имя BLE-MIDI подключения, которое будут видеть остальные клиенты. Чтобы начать «рекламирование» своего подключения, достаточно нажать кнопку Advertise справа от поля ввода NAME. Ниже мы можем увидеть список устройств, которые также «рекламируют» свое подключение, и также тех клиентов, которые уже подключились к нам. Если мы хотим подключиться как клиент к серверу, нам нужно просто нажать на кнопку Connect напротив того устройства, к которому мы хотим подключиться.

Резюмируя особенности BLE-MIDI протокола, можно сказать:

• Основное предназначение BLE-MIDI — организация простой синхронизации между несколькими устройствами.

• BLE-MIDI — это исключительно беспроводная технология передачи MIDI сообщений, ограниченная дистанцией работы Bluetooth, в среднем это до 10 метров.

• Чтобы увидеть и подключить BLE-MIDI устройства, необходимо приложение, которое поддерживает работу с этим интерфейсом передачи данных.

• Пакеты данных, передаваемые по BLE-MIDI, имеют в заголовке маркеры времени, что позволяет принимающему устройству вычислить задержку на доставку и определить правильный порядок полученных пакетов данных.

• И также, благодаря технологии BLE-MIDI, сообщения поэтому протоколу передаются с минимальными задержками, что делает его вполне надежным и быстрым.

Протокол TCNet был создан в 2004 году программистами компании TC Supply. Основное направление этой компании — создание программных продуктов для синхронизации шоу систем с DJ оборудованием, поэтому по большей части весь функционал этого протокола опирается на потребности клубной сферы. Базируется этот протокол на технологии передачи данных Ethernet.

Несмотря на то, что этот протокол синхронизации имеет ряд преимуществ при работе с таймкодом в сравнении с SMPTE, в профессиональной концертной индустрии он широко не используется. Но при этом в клубной сфере это один из самых функциональных протоколов для синхронизации.

По своей сути этот протокол очень схож с RTP-MIDI. Он также работает через транспортный протокол UDP, также каждое устройство рекламирует себя в сети, в одной сети также может быть несколько мастер устройств, и также может быть множество клиентов, которые могут сами выбирать, данные с какого сервера получать.

Если говорить об отличиях, то так как TC Net не был принят ни одной из официальных ассоциаций, то единственная компания, которая поддержала этот протокол, была Pioneer, в сравнении с RTP-MIDI, которую по итогу модернизировала компания Apple, чьи изменения впоследствии были приняты двумя ассоциациями MMA и JMSC. И также компания Apple включила поддержку этого протокола в свои операционные системы, что несомненно явилось решающим фактором в популяризации этого протокола.

Но пожалуй, основное отличие этих двух протоколов в том, что RTP-MIDI передает данные серийного протокола MIDI, а TC Net работает полностью со своими собственными данными. С одной стороны, это плохо, потому что этот протокол полностью несовместим со старыми системами, а с другой стороны, такой протокол передачи данных синхронизации не зажат рамками возможностей старых технологий.

Итак, давайте более подробно разберем, что может протокол TC Net. Несмотря на название самого протокола, он передает информацию не только о таймкоде, но и дополнительно метаданные.

Timecode

Как и следовало ожидать, это более усовершенствованная версия классического SMPTE таймкода.

• Через TC Net можно передать несколько источников таймкода.

• Скорость таймкода может изменяться в пределах 0%—200%.

• Направление таймкода может быть как вперед, так и назад.

Media Information

TC Net может передавать текущую информацию о медиа данных с каждого DJ проигрывателя.

• Трек и аудио метаданные.

• BMP и скорость воспроизведения.

• Данные для построения волновой формы трека.

• Название трека, альбома, исполнителя, изображение обложки альбома.

• Служебные сообщения для управления сторонними программами.

В общей сети TC Net выделяются три типа устройств.

Master

Этот тип устройства может предоставлять в сеть таймкод и отправлять дополнительные мета данные и команды управления.

Slave

Этот тип устройств может принимать данные таймкода, мета данные и команды управления, при этом Slave тип устройств может отправлять только команды управления.

Repeater

Этот тип устройств может принимать и отправлять все данные синхронизации и управления.

Позже мы с вами еще вернемся к этому протоколу, когда будем обсуждать возможные варианты синхронизации DJ оборудования с шоу системами.

Скорее всего, вы уже не в первый раз слышите о такой компании, как Artistic License, и о протоколе передачи данных ArtNet, главная цель которого — передача данных серийного протокола DMX512 через сеть Ethernet. Но мало кто знает, что этот протокол также поддерживает передачу данных таймкода. Модификация протокола ArtNet для передачи таймкода называется ArtTimeCode, также многие для упрощения называют его ArtNet Timecode.

В отличие от предыдущего протокола, ArtNet Timecode передает только данные времени, но при этом он также поддерживает большие отклонения от скорости воспроизведения таймкода и его направления.

Технология передачи таймкода довольна проста и очень схожа с ArtNet протоколом.

• В сети есть только одно мастер устройство, которое может транслировать либо Broadcast, либо Unicast пакеты данных, все остальные клиенты принимают эти данные.

• Мастер устройство не знает, есть ли в сети хоть кто-то, кто может принять данные таймкода, и также мастер устройство никогда не узнает, если из сети пропал один из клиентов.

• В протоколе нет системы контроля корректности порядка доставленных пакетов данных, что не может гарантировать корректное время таймкода на конечном устройстве.

• Но из-за того, что этот протокол максимально прост, общее время задержки между мастер устройством и клиентом минимально.

Протокол ArtNet сейчас широко используется в шоу-индустрии, а вот его собрат ArtTimeCode из-за своих существенных недостатков так и не получил широкого применения в профессиональном оборудовании и программном обеспечении.

OSC Timecode появился из среды объектно-визуального программирования нодами (Node⁵). Как яркий пример такого программного обеспечения, можно привести VVVV и TouchDesigner. Так как протокол OSC очень прост в использовании, то очень часто программистами он используется для передачи кадров таймкода между компьютерами и своими серверами. Этот способ получил популярность по двум причинам.

• Для передачи такого таймкода не нужно никакого специализированного оборудования, наподобие звуковых и MIDI карт.

• Ноды (Node⁶) и библиотеки для работы с протоколом OSC присутствуют во всех подобных программных средах разработок. Для работы с другими протоколами синхронизации, базирующимися на технологии Ethernet, подобными RTP-MIDI, TCNet и ArtNet Timecode, программистам необходимо писать на низкоуровневом языке собственные ноды для расшифровки сообщений этих протоколов, что зачастую является большой проблемой, так как необходимо знать на более высоком уровне языки программирования. В случае с OSC подобного не требуется.

Так как OSC является протоколом синхронизации, в котором нет четкого определения самих сообщений, то производители программного обеспечения и оборудования сами определяют их формат. В принципе, любой программист, работая на любой платформе, может придумать свои собственные OSC сообщения для передачи данных синхронизации.

Если мы вспомним суть работы любого таймкода, изученного нами ранее, то увидим, что таймкод — это набор сообщений, передаваемых с определенной частотой, несущих в себе один кадр таймкода, который содержит абсолютное значение времени. В зависимости от протокола, с сообщением времени может передаваться дополнительная информация.

Кадр OSC Timecode представляет из себя одно OSC сообщение, где аргументом является беззнаковая переменная типа Int32, в которой хранится информация таймкода одного кадра. Адрес такого сообщения не регламентирован, в зависимости от каждого проекта или программиста, он может быть придуман произвольно. Самый распространенный и простой адрес — /timecode/. При необходимости использовать независимые источники тайм кода в адрес добавляют номер источника или устройства.

Хочу обратить внимание, что по сути OSC Timecode никак и никем не стандартизирован, поэтому и адреса, и даже форматы аргументов в OSC Timecode сообщениях могут различаться в зависимости от программы, особенно в кастомных. Поэтому информация в этой главе лишь для понимания сути этого протокола таймкода. Если вам придется работать с таким типом протокола, то обязательно уточняйте ключевые параметры таких OSC сообщений.

Audio Video Bridging (AVB), Dante, Multichannel Audio Digital Interface (MADI) — все это сетевые протоколы передачи несжатого многоканального цифрового аудиосигнала с минимальными задержками через сеть Ethernet.

Может возникнуть вопрос, каким образом эти цифровые аудио интерфейсы могут использоваться для синхронизации? Давайте вспомним один из самых старых интерфейсов LTC. Как мы уже разбирали, это цифровой протокол, передаваемый через аналоговый аудиоинтерфейс. Для его передачи мы можем воспользоваться оригинальным аналоговым звуковым трактом или его современными цифровыми модификациями. Своего рода, это возрождение старого стандарта в новом цифровом интерфейсе. Наподобие серийного интерфейса MIDI, который переродился в цифровой протокол RTP-MIDI.

Использование AVB/Dante/MADI протоколов для передачи LTC является спорным вопросом, так как кроме очевидных преимуществ есть также и ряд недостатков. Давайте выделим основные плюсы и минусы такого способа передачи LTC.

Преимущества:

• AVB/Dante/MADI использует технологии сети Ethernet, что позволяет передать цифровой сигнал по витой паре или оптическому кабелю на большие расстояния с минимальными задержками и потерями.

• Практически все профессиональные цифровые аудио пульты, звуковые карты, плееры и другое аудио оборудование работает с цифровым протоколом AVB, Dante или MADI.

• Существуют цифровые аудио драйвера AVB/Dante/MADI для компьютеров, которые позволяют в операционной системе транслировать аудио по цифровому протоколу, даже без наличия звуковых карт. Более того, Apple MAC OS по умолчанию может работать с AVB без установки дополнительных драйверов.

Недостатки:

• Используя AVB/Dante/MADI, возможно передать только LTC таймкод.

• При работе с LTC через оборудование, не предназначенное для этого, сложно контролировать корректность передачи сигнала.

• Для подключения физических клиентов LTC таймкода все равно необходимо аудио оборудование для конвертации AVB/Dante/MADI в аналоговый аудиосигнал.

• Для работы с AVB/Dante/MADI необходимы профессиональные знания для использования этих протоколов.

Много лет назад, когда существовал только интерфейс таймкода LTC, особого выбора не было, но сейчас, когда есть множество разных цифровых интерфейсов синхронизации, которые намного надежнее и функциональнее, игнорировать новые разработки и пытаться оживить устаревшие протоколы неразумно.

Когда стоит вопрос использования современных интерфейсов передачи данных в синхронизации, зачастую это обусловлено необходимостью передачи сигнала на большие расстояния, что не могут позволить себе интерфейс MIDI или LTC.

Конечно, можно проявить находчивость, потратить время на изучение протоколов AVB/Dante/MADI и передавать через них LTC, но я задам лишь один вопрос: зачем изобретать велосипед, если все уже летают на космических кораблях? Если все же встал вопрос передачи синхронизации на большие расстояния, куда рациональнее использовать RTP-MIDI, OSC или даже ArtNet Timecode и TCNet.