РТП-МИДИ

РТП-МИДИ

Международный стандарт	IETF RFC 4696.
Разработано	Калифорнийский университет в Беркли
Веб-сайт	www .миди .org /миди-статьи /rtp-миди-или-миди-по сети

RTP-MIDI (также известный как AppleMIDI) — это протокол для передачи MIDI- сообщений в пакетах транспортного протокола реального времени (RTP) по сетям Ethernet и Wi-Fi. Он полностью открыт и бесплатен (лицензия не требуется) и совместим как с областями применения LAN, так и с WAN. По сравнению с MIDI 1.0, RTP-MIDI включает в себя новые функции, такие как управление сеансами, синхронизация устройств и обнаружение потерянных пакетов с автоматической регенерацией потерянных данных. RTP-MIDI совместим с приложениями реального времени и поддерживает синхронизацию с точностью до сэмпла для каждого MIDI-сообщения.

История RTP-MIDI

В 2004 году Джон Лаззаро и Джон Вавжинек из Калифорнийского университета в Беркли провели перед AES презентацию под названием «Полезная нагрузка RTP для MIDI». В 2006 году документ был представлен в IETF и получил номер RFC 4695. Параллельно Лаззаро и Вавжинек опубликовали еще один документ, в котором подробно описывается практическая реализация протокола RTP-MIDI, особенно механизма журналирования.

RFC 4695 был устаревшим RFC 6295 в 2011 году. Протокол не изменился между двумя версиями документов RFC, последняя содержит исправление ошибок, обнаруженных в RFC 4695)

MMA ( Ассоциация производителей MIDI ) создала страницу на своем веб-сайте, чтобы предоставить основную информацию, связанную с протоколом RTP-MIDI.

AppleMIDI

Apple Computer представила RTP-MIDI как часть своей операционной системы Mac OS X v10.4 в 2005 году. Драйвер RTP-MIDI доступен с помощью значка сети в инструменте настройки MIDI/аудио. Реализация Apple строго соответствует RFC 4695 для полезной нагрузки RTP и системы журналирования, но использует специальный протокол управления сеансами; они не соответствуют предложению по управлению сеансами RFC 4695. Этот протокол отображается в Wireshark как «AppleMIDI» и позже был задокументирован Apple .

Apple также создала специальный класс в своей реализации mDNS / Bonjour . Устройства, соответствующие этому классу, автоматически появляются на панели конфигурации Apple RTP-MIDI в качестве каталога участников, что делает систему Apple MIDI полностью « Plug & Play ». Однако в этот каталог можно вручную ввести IP-адреса и порты для подключения к устройствам, которые не поддерживают Bonjour.

Apple также представила поддержку RTP-MIDI в iOS4, но такие устройства не могут быть инициаторами сеансов.

Драйвер RTP-MIDI от Apple создает виртуальные MIDI-порты с именем «Сессии», которые доступны как MIDI-порты в любом программном обеспечении, например секвенсерах или программных инструментах, с использованием CoreMIDI, где они отображаются как пара портов MIDI IN/MIDI OUT, например любой другой порт MIDI 1.0 или порт USB MIDI.

Реализации

Встроенные устройства

В 2006 году голландская компания Kiss-Box представила первую встроенную реализацию RTP-MIDI в различных продуктах, таких как MIDI или LTC . интерфейсы Эти устройства соответствуют реализации AppleMIDI, используя один и тот же протокол управления сеансами, чтобы быть совместимыми с другими устройствами и операционной системой, использующими этот протокол.

Проприетарный драйвер изначально был разработан компанией для Windows XP , но он был ограничен связью с их устройствами; с помощью этого драйвера невозможно было подключить ПК к компьютеру Mac. Поддержка этого драйвера была прекращена в 2012 году в пользу стандартного подхода, когда стал доступен драйвер rtpMIDI для Windows.

Kiss-Box объявила о выпуске в 2012 году нового поколения плат ЦП под названием «V3», которое поддерживает функции инициатора сеанса. Эти модели способны устанавливать сеансы с другими устройствами RTP-MIDI, не требуя использования компьютера в качестве точки управления.

На выставке NAMM 2013 канадская компания iConnectivity представила новый интерфейс под названием iConnectivityMIDI4+, который поддерживает RTP-MIDI и обеспечивает прямое соединение между устройствами USB и RTP-MIDI. С тех пор они разработали несколько других интерфейсов с поддержкой RTP-MIDI, включая mio4 и mio10, а также PlayAUDIO 12.

Окна

Тобиас Эриксен в 2010 году выпустил реализацию драйвера RTP-MIDI от Apple для Windows. Этот драйвер работает в XP , Vista , Windows 7 , Windows 8 и Windows 10 , 32- и 64-разрядных версиях. Драйвер использует панель конфигурации, очень похожую на панель Apple, и полностью соответствует реализации Apple. Затем его можно использовать для подключения компьютера Windows к компьютеру Macintosh, а также к встроенным системам. Как и драйвер Apple, драйвер Windows создает виртуальные MIDI-порты, которые становятся видимыми из любого MIDI-приложения, работающего на ПК. Доступ осуществляется через уровень mmsystem, как и все остальные MIDI-порты.

Линукс

Поддержка RTP-MIDI для Linux была возобновлена ​​в феврале 2013 года после периода простоя. На некоторых форумах было объявлено о наличии драйверов, основанных на оригинальной работе Николя Фальке и Доминика Фобера.

Также доступна специальная реализация для компьютера Raspberry PI, называемая raveloxmidi.

Полная реализация RTP-MIDI (включая систему журналирования) доступна в дистрибутиве Ubuntu, в пакете программного обеспечения Scenic.

Существует новая реализация rtpmidid, который легко интегрируется с секвенсором ALSA, позволяя использовать такие инструменты, как QjackCtl, для управления соединениями.

iOS

В 2010 году Apple добавила полную поддержку CoreMIDI в свои устройства iOS, что позволило разрабатывать MIDI-приложения для iPhone, iPad и iPod. Затем MIDI стал доступен через док-порт в виде USB-контроллера, что позволило подключать USB-MIDI-устройства с помощью «Apple Camera Kit». Он также был доступен в виде прослушивателя сеанса RTP-MIDI через Wi-Fi.

Устройства iOS не поддерживают функции инициирования сеанса, что требует использования внешнего инициатора сеанса в сети для открытия сеанса RTP-MIDI с iPad. Этим инициатором сеанса может быть компьютер Mac или компьютер Windows с активированным драйвером RTP-MIDI или встроенное устройство RTP-MIDI. Сеанс RTP-MIDI отображается под именем «Network MIDI» во всех приложениях CoreMIDI на iOS, и для добавления поддержки RTP-MIDI в приложение iOS не требуется никакой специальной разработки. MIDI-порт виртуализируется с помощью CoreMIDI, поэтому программисту просто нужно открыть MIDI-соединение, независимо от того, подключен ли порт к USB или RTP-MIDI.

Некоторые жалобы возникли на использование MIDI через USB с устройствами iOS. поскольку iPad/iPhone должен обеспечивать питание внешнего устройства. Некоторые USB-MIDI-адаптеры потребляют слишком большой ток для iPad, что ограничивает ток и блокирует запуск устройства, которое затем не отображается как доступное для приложения. Этой проблемы можно избежать за счет использования RTP-MIDI.

Javascript

С июня 2013 года реализация RTP-MIDI на языке Javascript, созданная Дж. Дахтерой, доступна как проект с открытым исходным кодом. Исходный код основан на протоколе управления сеансами Apple и может выступать в качестве инициатора и прослушивателя сеанса.

Ява

Возможны кроссплатформенные Java-реализации RTP-MIDI, в частности библиотека nmj.

WinRT

Проект WinRTP-MIDI представляет собой реализацию стека протоколов RTP-MIDI с открытым исходным кодом под Windows RT. Первоначально код был разработан для переносимости между различными версиями Windows, но последняя версия была оптимизирована для WinRT, чтобы упростить разработку приложений для Магазина Windows.

Ардуино

RTP-MIDI был доступен для платформы Arduino в ноябре 2013 года под названием «Библиотека AppleMIDI». Программный модуль может работать либо на модулях Arduino со встроенным адаптером Ethernet, например Intel Galileo, либо на «экране Ethernet».

KissBox производит OEM-модуль RTP-MIDI, плату внешнего коммуникационного процессора, которая подключается по SPI шине .

MIDIбокс

В декабре 2013 года два члена группы MIDIbox DIY начали работу над начальной версией MIOS (операционной системы MIDIbox), включая поддержку RTP-MIDI по быстрому каналу SPI. Чтобы упростить интеграцию, было решено использовать внешнюю плату сетевого процессора, обрабатывающую весь стек протоколов. Первая бета-версия была выпущена на второй неделе января 2014 года. Первое официальное программное обеспечение было выпущено в первую неделю марта 2014 года.

Протокол, используемый в канале SPI между процессором MIOS и сетевым процессором, основан на том же формате, что и USB, с использованием 32-битных слов, содержащих полное MIDI-сообщение, и был предложен в качестве открытого стандарта для связи между модулями сетевого процессора и Платы MIDI-приложений.

Аксолотль

Axoloti — это аппаратный синтезатор с открытым исходным кодом, основанный на процессоре ARM STM32F427. Этот синтезатор полностью программируется с использованием концепции виртуальных патчей, аналогичной Max/MSP, и включает полную поддержку MIDI. Расширение node.js было разработано, чтобы обеспечить RTP-MIDI-соединение Axoloti с любыми RTP-MIDI-устройствами. Аппаратное обеспечение Axoloti также может быть оснащено внешним сопроцессором RTP-MIDI, подключаемым через шину SPI, доступную на порту расширения ядра Axoloti. Подход такой же, как описанный для Arduino и MIDIbox.

MIDIKit Кроссплатформенная библиотека

MIDIKit — это кроссплатформенная библиотека с открытым исходным кодом, которая предоставляет унифицированный MIDI API для различных MIDI API, доступных на рынке (Core MIDI, Windows MME, Linux ALSA и т. д.). MIDIKit поддерживает протокол RTP-MIDI, включая систему журналирования. Порты RTP-MIDI рассматриваются в MIDIKit как дополнительные порты (они не зависят от драйвера rtpMIDI), добавленные к собственным системным MIDI-портам.

Беспилотное использование

Поскольку RTP-MIDI основан на UDP/IP, любое приложение может реализовать этот протокол напрямую, без необходимости использования каких-либо драйверов. Драйверы необходимы только в том случае, если пользователи хотят, чтобы сетевые порты MIDI отображались как стандартные порты MIDI. Например, некоторые объекты Max/MSP и плагины VST были разработаны в соответствии с этой методологией.

RTP-MIDI через AVB

AVB — это набор технических стандартов, которые определяют спецификации для потоковых сервисов с чрезвычайно низкой задержкой в ​​сетях Ethernet. Сети AVB способны обеспечить задержку до одного аудиосэмпла во всей сети.
RTP-MIDI изначально совместим с сетями AVB, как и любой другой протокол IP, поскольку коммутаторы AVB (также известные как «коммутаторы IEEE802.1») автоматически управляют приоритетом между аудио/видеопотоками в реальном времени и IP-трафиком. Протокол RTP-MIDI также может использовать возможности AVB в реальном времени, если устройство реализует полезную нагрузку RTCP, описанную в документе IEEE-1733. Приложения RTP-MIDI могут затем сопоставить временную метку «презентации», предоставляемую главными часами IEEE-802.1, с временной меткой RTP, обеспечивая распределение времени MIDI-событий с точностью до выборки.

Протокол

RFC 4695/RFC 6295 разделили реализацию RTP-MIDI на разные части. Единственным обязательным параметром, определяющим соответствие спецификации RTP-MIDI, является формат полезной нагрузки. Часть ведения журнала не является обязательной, но в пакетах RTP-MIDI должно быть указано, что у них есть пустой журнал, поэтому журнал всегда присутствует в пакете RTP-MIDI, даже если он пуст. Часть инициирования/управления сеансом носит чисто информационный характер. Он не использовался Apple, которая создала собственный протокол управления сессиями.

Формат заголовка

Формат заголовка RTP-MIDI

Раздел	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
RTP	0	V		П	Х	СС				М	Тип полезной нагрузки (ПТ)							Порядковый номер
	32	Временная метка
	64	Идентификатор источника синхронизации (SSRC)
	96	Идентификаторы содействующего источника (CSRC) (необязательно)
	…	…
MIDI-команды	…	Б	Дж	С	П	ТОЛЬКО…				Список MIDI-сообщений…
Журнал (опционально, в зависимости от флага J)	…	С	И	А	ЧАС	TOTCHAN				Порядковый номер пакета контрольной точки																Системный журнал (опционально)…
		Канальные журналы…

Сессии

Сеансы RTP-MIDI отвечают за создание виртуального пути между двумя устройствами RTP-MIDI и с точки зрения приложения выглядят как пара MIDI IN/MIDI OUT.RFC 6295 предлагает использовать SIP (протокол инициации сеанса) и SDP (протокол описания сеанса), но Apple решила создать собственный протокол управления сеансом. Протокол Apple связывает сеансы с именами, используемыми в Bonjour, а также предлагает услугу синхронизации часов.

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

Данный сеанс всегда создается между двумя и только двумя участниками, причем каждый сеанс используется для обнаружения потенциальной потери сообщений между двумя участниками. Однако данный контроллер сеансов может открывать несколько сеансов параллельно, что обеспечивает такие возможности, как разделение, слияние или распределенную коммутационную панель. На приведенной здесь диаграмме на устройстве 1 одновременно открываются два сеанса: один с устройством 2, другой с устройством 3, но два сеанса на устройстве 1 отображаются для конечного пользователя как один и тот же виртуальный MIDI-интерфейс.

Сессии и конечные точки

Распространенной ошибкой является несоответствие между конечными точками RTP-MIDI и сеансами RTP-MIDI, поскольку они оба представляют собой пару портов MIDI IN/MIDI OUT.

Конечная точка используется для обмена MIDI-данными между элементом (программным и/или аппаратным обеспечением), отвечающим за декодирование транспортного протокола RTP-MIDI, и элементом, использующим MIDI-сообщения. Другими словами, на уровне конечной точки видны только MIDI-данные. Для устройств с разъемами MIDI 1.0 DIN на каждую пару разъемов приходится одна конечная точка, например: 2 конечных точки для KissBox MIDI2TR, 4 конечных точки для iConnectivityMIDI4+ и т. д. Устройства, использующие другие каналы связи, такие как SPI или USB, предлагают больше конечных точек, например устройство использование 32-битного кодирования USB MIDI Class может представлять до 16 конечных точек с использованием поля идентификатора кабеля. Конечная точка представлена ​​на стороне RTP-MIDI парным портом UDP, когда используется протокол сеанса AppleMIDI.

Сеанс определяет соединение между двумя конечными точками. MIDI IN одной конечной точки подключается к MIDI OUT удаленной конечной точки и наоборот. Одна конечная точка может принимать несколько сеансов в зависимости от конфигурации программного обеспечения. Каждый сеанс для данной конечной точки отображается для обработчика удаленного сеанса как один. Обработчик удаленного сеанса не знает, используется ли конечная точка, к которой он подключен, одновременно другими сеансами. Если для данной конечной точки активны несколько сеансов, различные потоки MIDI, достигающие конечной точки, объединяются перед отправкой MIDI-данных в приложение. В другом направлении MIDI-данные, создаваемые приложением, отправляются всем обработчикам сеанса, подключенным к конечной точке.

Участники сессии AppleMIDI

Реализация AppleMIDI определяет два типа контроллеров сеансов: инициаторы сеансов и прослушиватели сеансов. Инициаторы сеанса отвечают за приглашение прослушивателей сеанса и отвечают за последовательность синхронизации часов. Инициаторы сеансов обычно могут быть прослушивателями сеансов, но некоторые устройства, например устройства iOS, могут быть только прослушивателями сеансов.

MIDI-слияние

Устройства RTP-MIDI могут объединять различные потоки MIDI без необходимости использования какого-либо специального компонента, в отличие от устройств MIDI 1.0, которые требуют «объединения MIDI». Как видно на схеме, когда контроллер сеанса подключается к двум и более удаленным сеансам, он автоматически объединяет MIDI-потоки, поступающие от удаленных устройств, не требуя какой-либо специальной настройки.

Разделение MIDI («MIDI THRU»)

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

Концепция распределенной коммутационной панели

Сеансы RTP-MIDI также могут предоставлять функцию «коммутационной панели», для которой требуется отдельное аппаратное устройство с подключениями MIDI 1.0. Коммутационная панель MIDI 1.0 — это аппаратное устройство, которое обеспечивает динамические соединения между набором MIDI-входов и набором MIDI-выходов, большую часть времени в форме матрицы. Концепция «динамического» соединения отличается от классического использования линий MIDI 1.0, когда кабели подключались «статически» между двумя устройствами. Вместо того, чтобы устанавливать путь передачи данных между устройствами в виде кабеля, коммутационная панель становится центральной точкой, к которой подключаются все MIDI-устройства. Программное обеспечение в патч-панели MIDI настроено на определение того, какой вход MIDI подключен к какому выходу MIDI, и пользователь может изменить эту конфигурацию в любой момент без необходимости отсоединять кабели MIDI DIN.

Аппаратные модули «patchbay» больше не нужны для RTP-MIDI благодаря концепции сеанса. Сеансы по определению представляют собой виртуальные пути, установленные в сети между двумя портами MIDI. Для выполнения функций коммутационной панели не требуется никакого специального программного обеспечения, поскольку процесс конфигурации точно определяет места назначения для каждого MIDI-потока, создаваемого данным MIDI-устройством. Затем можно в любой момент изменить эти виртуальные пути, просто изменив IP-адреса назначения, используемые каждым инициатором сеанса. Сформированная таким образом конфигурация «патча» может храниться в энергонезависимой памяти, чтобы позволить патчу автоматически реформироваться при включении питания установки, но их также можно изменить напрямую, например, с помощью программного инструмента RTP-MIDI Manager или с помощью Панели управления драйверами RTP-MIDI на уровне оперативной памяти.

Термин «распределенная коммутационная панель» возник из-за того, что различные устройства RTP-MIDI могут быть распределены географически по всей MIDI-настройке, в то время как патч-панель MIDI 1.0 заставляет различные MIDI-устройства физически располагаться непосредственно вокруг самого устройства коммутационной панели.

Протокол сеанса Apple

В документе RFC6295 предлагается использовать протоколы SDP (протокол описания сеанса) и SIP (протокол инициирования сеанса) для установления сеансов между партнерами RTP-MIDI и управления ими. Однако эти два протокола довольно сложно реализовать, особенно в небольших системах, особенно потому, что они не ограничивают ни один из параметров, перечисленных в дескрипторе сеанса, таких как частота дискретизации, которая, в свою очередь, определяет все поля, связанные с данными синхронизации как в заголовках RTP, так и в RTP. - MIDI-полезная нагрузка. Более того, документ RFC6295 предлагает использовать только эти протоколы, позволяя использовать любой другой протокол, что приводит к потенциальной несовместимости между поставщиками.

Apple решила создать свой собственный протокол, наложив на него все параметры, связанные с синхронизацией, например, частоту дискретизации. Этот протокол сеанса в программном обеспечении Wireshark называется «AppleMIDI». Для управления сеансом с помощью протокола AppleMIDI требуется два порта UDP, первый называется «Порт управления», второй — «Порт данных». При использовании в многопоточной реализации только порт данных требует потока «реального времени», другой порт может управляться потоком с обычным приоритетом. Эти два порта должны быть расположены в двух последовательных местах (n/n+1); первым может быть любой из 65536 возможных портов.

Нет ограничений на количество сессий, которые могут быть открыты одновременно на наборе портов UDP с протоколом AppleMIDI. Можно либо создать одну группу портов для каждого менеджера сеансов, либо использовать только одну группу для нескольких сеансов, что ограничивает объем памяти в системе. В этом последнем случае стек IP предоставляет ресурсы для идентификации партнеров по их IP-адресу и номерам портов. Эта функция называется «повторное использование сокетов» и доступна в большинстве современных реализаций IP.

Все сообщения протокола AppleMIDI используют общую структуру из 4 слов по 32 бита с заголовком, содержащим два байта со значением 255, за которыми следуют два байта, описывающие смысл сообщения:

Описание	Определение заголовка Wireshark	Значение поля (шестнадцатеричное)	Значение поля (символы)
Приглашение	APPLEMIDI_COMMAND_INVITATION	0x494e	IN
Приглашение принято	APPLEMIDI_COMMAND_INVITATION_ACCEPTED	0x4f4b	OK
Приглашение отклонено	APPLEMIDI_COMMAND_INVITATION_REJECTED	0x4e4f	NO
Закрытие сессии	APPLEMIDI_COMMAND_ENDSESSION	0x4259	BY
Синхронизация часов	APPLEMIDI_COMMAND_SYNCHRONIZATION	0x434b	CK
Синхронизация журналов	APPLEMIDI_COMMAND_RECEIVER_FEEDBACK	0x5253	RS
Битрейт	APPLEMIDI_COMMAND_BITRATE_RECEIVE_LIMIT	0x524c	RL

Эти сообщения управляют конечным автоматом, связанным с каждым сеансом. Например, этот конечный автомат запрещает любой обмен MIDI-данными до тех пор, пока сеанс не достигнет «открытого» состояния.

Последовательность приглашений

Открытие сеанса начинается с последовательности приглашений. Первый партнер сеанса («Инициатор сеанса») отправляет IN-сообщение в порт управления второго партнера. Они отвечают, отправляя сообщение ОК, если они согласны открыть сеанс, или сообщение НЕТ, если они не принимают приглашение. Если приглашение принято на порту управления, та же последовательность повторяется на порту данных. Как только приглашения будут приняты на обоих портах, конечный автомат переходит в фазу синхронизации.

Последовательность синхронизации

Последовательность синхронизации позволяет обоим участникам сеанса обмениваться информацией, относящейся к их локальным часам. Этот этап позволяет компенсировать задержку, вызванную сетью, а также поддерживать «отметку будущего времени» (см. раздел «Задержка» ниже).

Инициатор сеанса отправляет первое сообщение (с именем CK0) удаленному партнеру, сообщая его локальное время в 64 битах (обратите внимание, что это не абсолютное время, а время, связанное с локальной ссылкой, обычно выраженное в микросекундах с момента запуска ядро операционной системы). Это время выражается на основе тактовой частоты дискретизации 10 кГц (100 микросекунд на приращение). Удаленный партнер должен ответить на это сообщение сообщением CK1, содержащим свое местное время в 64 битах. Затем оба партнера узнают разницу между своими соответствующими часами и могут определить смещение, которое будет применяться к полям Timestamp и Deltatime в протоколе RTP-MIDI.

Инициатор сеанса завершает эту последовательность отправкой последнего сообщения под названием CK2, содержащего местное время, когда он получил сообщение CK1. Этот метод позволяет вычислить среднюю задержку сети, а также компенсировать потенциальную задержку, вызванную медленным запуском потока, которая может возникнуть в операционных системах, не работающих в режиме реального времени, таких как Linux, Windows или OS X.

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

Эта последовательность должна повторяться циклически, обычно от 2 до 6 раз в минуту, и всегда инициатором сеанса, чтобы поддерживать долговременную точность синхронизации за счет компенсации дрейфа локальных часов, а также для обнаружения потери партнера по связи. Партнер, не отвечающий на несколько сообщений CK0, должен считать, что удаленный партнер отключен. В большинстве случаев инициаторы сеанса переводят свой конечный автомат в состояние «Приглашение», чтобы автоматически восстановить связь, как только удаленный партнер повторно подключится к сети. Некоторые реализации, особенно на персональных компьютерах, также отображают предупреждающее сообщение и предлагают пользователю выбор между новой попыткой подключения или закрытием сеанса.

Обновление журнала

Механизм журналирования позволяет обнаруживать потерю MIDI-сообщений и позволяет приемнику генерировать недостающие данные без необходимости повторной передачи. Журнал хранит в памяти «MIDI-изображения» для разных партнеров сеанса в разные моменты. Однако бесполезно хранить в памяти данные журналирования, соответствующие событиям, правильно полученным партнером сеанса. Затем каждый партнер циклически отправляет другому партнеру сообщение RS, указывая последний порядковый номер, полученный правильно, другими словами, без какого-либо разрыва между двумя порядковыми номерами. При необходимости отправитель может затем освободить память, содержащую старые данные журнала.

Отключение партнера сессии

Партнер сеанса может в любой момент попросить покинуть сеанс, что в свою очередь закроет сеанс. Это делается с помощью сообщения BY. Когда партнер сеанса получает это сообщение, он немедленно закрывает сеанс с удаленным партнером, отправившим сообщение, и освобождает все ресурсы, выделенные для этого сеанса. Следует отметить, что это сообщение может быть отправлено инициатором сеанса или слушателем сеанса («приглашенным» партнером).

Задержка

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

Более того, RTP-MIDI, как описано в RFC 6295, содержит механизм компенсации задержки. Похожий механизм присутствует в большинстве плагинов, которые могут информировать хост о задержке, которую они добавляют к пути обработки. Затем хост может заранее отправить сэмплы в плагин, чтобы сэмплы были готовы и отправлялись синхронно с другими аудиопотоками. Механизм компенсации, описанный в RF6295, использует систему относительных временных меток, основанную на дельта-времени MIDI, как описано в разделе . Каждое MIDI-событие, передаваемое в полезных данных RTP, имеет ведущее значение дельты времени, связанное с текущим источником времени полезной нагрузки, определяемым полем Timestamp в заголовке RTP.

Каждое MIDI-событие в полезной нагрузке RTP-MIDI может быть строго синхронизировано с глобальными часами. Точность синхронизации напрямую зависит от источника синхронизации, определенного при открытии сеанса RTP-MIDI. В RFC 6295 приведены несколько примеров, основанных на часах дискретизации звука, чтобы получить точную временную метку MIDI-событий. Реализация RTP-MIDI от Apple, как и все другие связанные реализации, такие как драйвер rtpMIDI для Windows или встроенные системы KissBox, использует фиксированную тактовую частоту 10 кГц, а не частоту дискретизации звука. В этом случае точность синхронизации всех MIDI-событий для этих реализаций составляет 100 микросекунд.

Часы отправителя и получателя синхронизируются при запуске сеанса и поддерживаются синхронизированными в течение всего периода сеанса с помощью регулярных циклов синхронизации, контролируемых инициаторами сеанса. Этот механизм способен компенсировать любую задержку: от нескольких сотен микросекунд, как это наблюдается в приложениях локальной сети, до секунд. Например, он может компенсировать задержку, вызванную Интернетом, позволяя исполнять музыкальные произведения в реальном времени.

Однако этот механизм в основном предназначен для предварительно записанных MIDI-потоков, например, поступающих с трека секвенсора. Когда RTP-MIDI используется для приложений реального времени (например, управление устройствами с клавиатуры, совместимой с RTP-MIDI). ), для deltatime обычно установлено конкретное значение 0, что означает, что соответствующее MIDI-событие должно интерпретироваться сразу после его получения). В таком случае описанный ранее механизм компенсации задержки использовать невозможно.

Полученная задержка напрямую связана с различными сетевыми компонентами, участвующими в пути связи между устройствами RTP-MIDI:

• Время обработки MIDI-приложения
• Время обработки стека IP-коммуникаций
• Время пересылки пакетов сетевых коммутаторов/маршрутизаторов

Время обработки заявки

Время обработки приложения обычно строго контролируется, поскольку задачи MIDI чаще всего выполняются в реальном времени. В большинстве случаев задержка напрямую зависит от задержки потока, которую можно получить в конкретной операционной системе, обычно она составляет максимум 1–2 мс в системах Windows и Mac OS. Системы с ядром реального времени могут достичь гораздо лучших результатов — вплоть до 100 микросекунд. Это время можно считать постоянным, независимо от канала связи (MIDI 1.0, USB, RTP-MIDI и т. д.), поскольку потоки обработки работают на другом уровне, чем потоки/задачи, связанные со связью.

Время обработки IP-стека

Время обработки IP-стека является наиболее критичным, поскольку процесс связи находится под контролем операционной системы. Это относится к любому протоколу связи, независимо от того, связан ли он с IP или нет, поскольку большинство операционных систем, включая Windows, Mac OS или Linux, не обеспечивают прямой доступ к адаптеру Ethernet. В частности, распространенной ошибкой является объединение «необработанных сокетов» с «прямым доступом к сети»; сокеты являются точкой входа для отправки и получения данных по сети в большинстве операционных систем. «Необработанный сокет» — это сокет, который позволяет приложению отправлять любой пакет с использованием любого протокола. Затем приложение отвечает за создание телеграммы в соответствии с заданными правилами протокола, тогда как «прямой доступ» потребует доступа на уровне системы, который ограничен ядром операционной системы. Пакет, отправленный с использованием необработанного сокета, может быть задержан операционной системой, если сетевой адаптер в настоящее время используется другим приложением. Таким образом, IP-пакет может быть отправлен в сеть раньше пакета, относящегося к необработанному сокету. Технически говоря, доступ к данной сетевой карте контролируется «семафорами».

Стеки IP должны сопоставлять адреса Ethernet (MAC-адреса) и IP-адреса с использованием специального протокола с именем ARP. Когда приложение RTP-MIDI хочет отправить пакет на удаленное устройство, оно должно сначала найти его в сети, поскольку Ethernet не понимает концепции, связанные с IP, чтобы создать путь передачи между маршрутизаторами/коммутаторами. Это делается автоматически стеком IP путем отправки сначала запроса ARP (протокола распознавания адресов). Когда устройство назначения распознает свой собственный IP-адрес в пакете ARP, оно отправляет ответ ARP со своим MAC-адресом. Затем стек IP может отправить пакет RTP-MIDI. Следующие пакеты RTP-MIDI больше не нуждаются в последовательности ARP, если только канал не станет неактивным на несколько минут, что очистит запись ARP в таблице маршрутизации отправителя.

Эта последовательность ARP может занять несколько секунд, что, в свою очередь, может привести к заметной задержке, по крайней мере, для первого пакета RTP-MIDI. Однако реализация Apple элегантно решила эту проблему, используя протокол управления сеансом. Протокол сеанса использует те же порты, что и сам протокол RTP-MIDI. Затем последовательность ARP выполняется во время последовательности инициации сеанса. Когда приложение RTP-MIDI хочет отправить первый пакет RTP-MIDI, таблицы маршрутизации компьютера уже инициализируются правильными MAC-адресами назначения, что позволяет избежать задержки для первого пакета.

Помимо последовательности ARP, сам стек IP требует вычислений для подготовки заголовков пакетов, таких как заголовок IP, заголовок UDP и заголовок RTP. У современных процессоров эта подготовка происходит чрезвычайно быстро и занимает всего несколько микросекунд, что ничтожно мало по сравнению с задержкой самого приложения. Как описано ранее, после подготовки пакет RTP-MIDI может быть задержан только тогда, когда он пытается достичь сетевого адаптера, если адаптер уже передает другой пакет, независимо от того, является ли сокет IP или «необработанным». Однако задержка, возникающая на этом уровне, обычно чрезвычайно мала, поскольку потоки драйверов, отвечающие за сетевые адаптеры, имеют очень высокий приоритет. Более того, большинство сетевых адаптеров имеют буферы FIFO на аппаратном уровне, поэтому пакеты можно сохранять для немедленной передачи в самом сетевом адаптере без необходимости предварительного выполнения потока драйвера. Метод, позволяющий максимально снизить задержку, связанную с «конкуренцией за доступ к адаптеру», состоит в том, чтобы зарезервировать сетевой адаптер только для связи MIDI и использовать другой сетевой адаптер для других сетевых операций, таких как обмен файлами или просмотр Интернета.

Время маршрутизации сетевых компонентов

Различные компоненты, используемые для передачи пакетов Ethernet между компьютерами, независимо от используемых протоколов, также вызывают задержку. Все современные сетевые коммутаторы используют технологию «хранения и пересылки», при которой пакеты сохраняются в коммутаторе перед отправкой на следующий коммутатор. Однако время переключения чаще всего незначительно. Например, пересылка 64-байтового пакета в сети со скоростью 100 Мбит/с занимает около 5,1 микросекунды каждым сетевым коммутатором. Сложная сеть с 10 коммутаторами на заданном пути приводит к задержке в 51 микросекунду.

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

Ожидаемая задержка для приложений реального времени

Как видно, точная задержка, полученная для канала RTP-MIDI, зависит от многих параметров, большинство из которых связаны с самими операционными системами. Измерения, проведенные различными участниками RTP-MIDI, показывают время задержки от нескольких сотен микросекунд для встроенных систем, использующих операционные системы реального времени, до 3 миллисекунд, когда задействованы компьютеры, работающие под управлением операционных систем общего назначения.

Улучшение задержки (задержка менее миллисекунды)

AES . создала рабочую группу под названием SC-02-12H в 2010 году, чтобы продемонстрировать возможность использования полезных данных RTP в IP-сетях для приложений с очень низкой задержкой. Проект предложения, опубликованный группой в мае 2013 года, демонстрирует, что можно добиться потоковой передачи RTP для живых приложений со значением задержки всего 125 микросекунд.

Конфигурация

Другой наиболее распространенной проблемой, связанной с RTP-MIDI, является процесс настройки, поскольку физического подключения устройства к сети недостаточно для обеспечения связи с другим устройством. Поскольку RTP-MIDI основан на стеке протоколов IP, необходимо настроить различные уровни, участвующие в процессе связи, такие как IP-адрес и порты UDP. Для упрощения этой конфигурации были предложены различные решения, наиболее распространенным из которых является набор технологий « Нулевой конфигурации », также известный как Zeroconf.

RFC 3927 описывает общий метод автоматического назначения IP-адресов, который используется большинством продуктов, совместимых с RTP-MIDI. После подключения к IP-сети такое устройство может назначить себе IP-адрес с автоматическим разрешением конфликтов IP-адресов. Если устройство следует рекомендациям по назначению портов из спецификации RTP, с точки зрения сети устройство становится «Plug&Play». Тогда можно полностью создать сеть RTP-MIDI без необходимости определять какой-либо IP-адрес и/или номера портов UDP. Однако следует отметить, что эти методы обычно предназначены для небольших установок. Полной автоматизации конфигурации сети обычно избегают при больших установках, поскольку локализация неисправных устройств может оказаться сложной, поскольку не будет прямой связи между IP-адресом, выбранным системой Zeroconf, и физическим местоположением устройства. Минимальная конфигурация тогда будет заключаться в присвоении имени устройству перед его подключением к сети, что в этом случае аннулирует концепцию «настоящего Plug&Play».

Следует отметить, что концепция «нулевой конфигурации» ограничивается уровнями сетевой связи. Технически невозможно выполнить полную установку любого сетевого устройства (связанного с MIDI или нет) просто абстрагируя уровень адресации. Практический пример использования, иллюстрирующий это ограничение, — звуковой генератор RTP-MIDI, которым необходимо управлять с главной MIDI-клавиатуры, подключенной к интерфейсу RTP-MIDI. Даже если звуковой генератор и MIDI-интерфейс объединяют службы «нулевой конфигурации», они не могут сами знать, что им необходимо установить совместный сеанс, поскольку службы IP-конфигурации действуют на разных уровнях. Любая сетевая MIDI-система, независимо от протокола, используемого для обмена MIDI-данными (на основе IP или нет), требует обязательного использования инструмента конфигурации для определения обмена, который должен происходить между устройствами после их подключения к сети. . Этот инструмент конфигурации может быть внешним инструментом управления, работающим на компьютере, или быть встроенным в прикладное программное обеспечение устройства в виде меню конфигурации, если устройство интегрирует человеко-машинный интерфейс.

Совместимость с MIDI 2.0.

Ассоциация производителей MIDI объявила в январе 2019 года о значительном развитии протокола MIDI, получившего название MIDI 2.0. вступал в финальную фазу прототипирования.

MIDI 2.0 в значительной степени опирается на расширение MIDI-CI, используемое для согласования протокола (идентификация устройств MIDI 1.0 и MIDI 2.0 для обеспечения переключения протоколов). RTP-MIDI полностью поддерживает протокол MIDI-CI, поскольку он использует MIDI 1.0 System Exclusive даже на устройствах MIDI 2.0.

Эволюция протокола RTP-MIDI с включением MIDI 2.0 была представлена ​​MMA и в настоящее время обсуждается в рабочей группе MIDI 2.0. Расширенный протокол параллельно поддерживает формат данных MIDI 1.0 и MIDI 2.0 (MIDI 2.0 использует 32-битные пакеты, а MIDI 1.0 использует 8-битные пакеты).

Компании/проекты, использующие RTP-MIDI

• Apple Computer (драйвер RTP-MIDI, интегрированный в Mac OS X и iOS для всего спектра продуктов) — RTP-MIDI через Ethernet и Wi-Fi
• Yamaha (синтезаторы Motif, адаптер UD-WL01 ) - RTP-MIDI через Ethernet и Wi-Fi
• Behringer (панель управления X-Touch)
• KissBox (интерфейсы RTP-MIDI с MIDI 1.0, LTC, I/O и плагинами ArtNet, VST для дистанционного управления аппаратным синтезатором)
• Tobias Erichsen Consulting (Бесплатный драйвер RTP-MIDI для Windows/Утилиты)
• GRAME (драйвер Linux)
• HRS (распределение MIDI-таймкода по Ethernet/программное обеспечение синхронизации)
• iConnectivity (аудио и MIDI-интерфейсы с поддержкой USB и RTP-MIDI)
• Объединение технологий (Horus, Hapi, Pyramix, Ovation) — RTP-MIDI для управления LTC/MTC, MIDI DIN и MicPre.
• Zivix PUC (беспроводной интерфейс RTP-MIDI для устройств iOS)
• Arduino-AppleMIDI-библиотека
• MIDIбокс
• Cinara (MIDI-интерфейс с поддержкой USB и RTP-MIDI)
• McLaren Labs rtpmidi для Linux
• BEB (модули DSP для модульных синтезаторов на базе магистрали RTP-MIDI)
• Axoloti (Аппаратный синтезатор с открытым исходным кодом и возможностью подключения RTP-MIDI)