Кратко

  • Журнал восстановления не требует повторной передачи каждого потерянного пакета. Его задача — не оставлять в инструменте ошибки, которые могут сохраняться неопределённо долго.
  • Пропущенное начало ноты и пропущенная команда её завершения имеют разные последствия. Поздний удар иногда лучше не воспроизводить, хотя внутренние записи приёмника необходимо обновить.
  • Границы истории, паузы, подключение новых участников и местные алгоритмы определяют результат. Общий формат не превращает восстановление состояния в точную реконструкцию исполнения.

Пакет нашёлся, но его время уже прошло

Приёмник обнаружил разрыв в последовательности, изучил журнал следующего пакета и выполнил поправку. Затем пришёл старый пакет, который прежде казался потерянным. Теперь его команда может повторить действие, уже сделанное при восстановлении.

Для обычного представления о надёжной передаче это неудобный случай: недостающие данные наконец доступны, но их исполнение способно ухудшить результат. Описанный в RFC 4696 приёмник NMP выбирает безопасный для своего алгоритма путь — игнорирует пакеты, пришедшие не по порядку.

Это решение из руководства по реализации, опубликованного в ноябре 2006 года, а не требование навсегда выбрасывать любую опоздавшую информацию. Оно показывает более общий принцип. После исправления состояние приложения уже не обязано совпадать с состоянием, которое существовало до задержки. Полнота истории и правильность следующего действия могут расходиться.

Для музыки это особенно важно. Ноту недостаточно сыграть когда-нибудь: момент её появления входит в смысл исполнения. Возвращённая команда не возвращает этот момент.

Почему потеря одной команды может пережить саму потерю

MIDI передаёт символические указания инструменту, а не фрагменты записанной звуковой волны. Начать ноту, закончить её, изменить громкость — короткие сообщения меняют состояние синтезатора или программы. Дальнейшее звучание зависит от того, какие значения там остались.

В ноябре 2006 года RFC 4695 разделил нарушения исполнения на временные и неопределённо длительные. Потерянная команда NoteOn может оставить пробел: одна нота не прозвучит, но её отсутствие обычно не продолжается за пределами предусмотренной длительности. Потерянная NoteOff может оставить ноту звучать. А пропущенное изменение громкости канала способно сделать неверными все следующие ноты, даже если их пакеты придут без потерь.

Не всякая потеря NoteOff неизбежно создаёт бесконечный звук. Имеют значение огибающая, педаль, устройство инструмента и последующие команды. Однако протокол не может рассчитывать, что случайное будущее событие обязательно исправит старое состояние.

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

Нумерация помогает заметить проблему, но не знает, что звучит

RFC 3550, датированный июлем 2003 года, определяет общую основу RTP: порядковые номера, временные отметки, обозначение полезной нагрузки и наблюдение за приёмом. Сам RTP не гарантирует доставку, своевременность или порядок прихода.

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

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

В RFC 6295, заменившем спецификацию 2006 года в июне 2011-го, сохраняется основное требование: исполнение, восстановленное из потока через ненадёжный транспорт, не должно содержать неопределённо длительных нарушений. Это не обещание отсутствия любого слышимого сбоя. Исправление переводит потенциально незаканчивающуюся ошибку в ограниченную по времени.

Уже услышанное неверное звучание не исчезает. Но оно перестаёт определять, как инструмент будет играть дальше.

Журнал не обязан помнить каждый удар

Метод не опирается на повторную передачу всех исчезнувших пакетов. Он хранит сведения, необходимые для исправления состояния, начиная с контрольной точки. Если текущий пакет имеет номер I, а контрольная точка — C, история включает команды из C до I−1. Новые команды самого I в неё не входят.

Отсюда следует важное ограничение. Упоминание восстановления произвольного числа потерянных пакетов относится к потерям внутри охваченной истории. Оно не делает исправимым любой по длительности разрыв. Приёмник должен проверять, достаточно ли далеко назад простирается журнал.

Представление истории тоже не является полной летописью. Раздел N журнала защищает обычное чередование NoteOn и NoteOff для одной высоты. Он не перечисляет все прошлые начала нот. Более сложные наложения нескольких NoteOn требуют дополнительной поддержки раздела E. Схему, удобную для клавиатуры или ударных площадок, нельзя без оговорок переносить на все гитарные и духовые контроллеры.

Запись NoteOn в разделе N не содержит точного первоначального момента исполнения. Бит Y рекомендует сыграть ноту либо пропустить её. Это подсказка для текущего решения, а не обязательство воспроизвести любое обнаруженное прошлое событие.

Руководство 2006 года описывает приёмник, который может не выдавать поздний звук, но обновить свои записи восстановления так, словно команда была учтена. Так он поддерживает согласованность последующих действий, не добавляя лишнего удара в уже ушедшую долю.

Замолчавший музыкант может оставить звучащую ошибку

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

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

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

Примеры интервалов защитной отправки в руководстве не являются обязательным единым расписанием. Параметр guardtime в спецификации 2011 года задаёт максимальное расстояние между последовательными пакетами в единицах временных меток RTP. Приведённый там типичный диапазон также прямо назван ненормативным.

Кроме того, управление перегрузкой имеет приоритет перед желаемой частотой защиты. RFC 3551 объясняет обязанность разумного сосуществования с другими потоками общей сети. Желание быстрее закончить неверный звук не предоставляет неограниченный бюджет передачи. Дополнительные попытки исправления могут сами увеличить задержку и потери, если ухудшают перегрузку.

Сокращать прошлое можно лишь с оглядкой на участников

По умолчанию отправитель использует политику с обратной связью. Отчёты приёмников помогают сдвигать контрольную точку и уменьшать журнал. Обычно применяется наибольший расширенный номер принятого пакета из RTCP; допускается и иной согласованный механизм обратной связи.

Экономия предполагает, что приёмник выполняет положенные исправления. Сообщённый номер не свидетельствует о том, что слушателю понравилось исполнение или что ни одна нота не пропала. Он поддерживает ограниченное решение о том, какую историю ещё нужно переносить.

Новый участник создаёт отдельную проблему. Громкость канала могли изменить задолго до его подключения, а соответствующие сведения уже убрать из короткого журнала. Приёмник получает новые команды, но начинает с неверного старого значения. Узнав о нём, отправитель должен обеспечить начало без такой устойчивой ошибки, при необходимости вновь защитив текущие значения контроллеров.

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

Информационное руководство RFC 8088 в мае 2017 года выделило именно краткое представление состояния и сокращение журнала с помощью RTCP как интересные свойства RTP MIDI. Оно связывает их полезность с символическими средами, сильно зависящими от накопленного состояния. Это оценка подхода, а не измерение его рыночного распространения.

Исправление имеет акустические пределы

Даже команда завершения ноты не всегда означает немедленное молчание. Педаль удержания и последовательность её изменений влияют на результат. Журнал может не сохранять полный относительный порядок NoteOff и действий педали. Иногда приёмнику помогает собственная история; если её недостаточно, спецификация предпочитает избежать ошибочно удерживаемого звука, допуская краткий неприятный переход.

Руководство не скрывает и границы своего алгоритма. Пример NMP рассчитан на особые сетевые характеристики, ограниченный набор команд и работу без буфера воспроизведения. Сам документ отмечает, что последнее решение не полностью удовлетворяет упомянутому требованию совместимости о наличии буферной возможности.

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

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

Чего не доказывает опубликованный формат

Регистрация audio/rtp-midi в IANA даёт общий идентификатор, параметры и ссылки на спецификацию передачи MIDI в реальном времени. Она помогает сторонам распознавать формат, но не проверяет вместо них качество исполнения или свойства конкретной сети.

Редакция 2011 года исправила, в частности, рисунки, синтаксис и примеры настройки. Замечания авторов об отсутствии известных им проблем совместимости относятся к исправляемым ошибкам, а не ко всем существующим реализациям. Оценки зрелости отдельных применений, сделанные тогда, также нельзя выдавать за сегодняшнюю статистику.

Исторический результат точнее общего лозунга о надёжности. Для продолжения исполнения иногда нужно перестать догонять уже пропущенное и исправить то, что до сих пор действует. Журнал позволяет отделить эти задачи. Он возвращает инструменту возможность правильно продолжать, не притворяясь, будто вернул слушателю ушедшее время.