RTP-MIDI (también conocido como AppleMIDI) es un protocolo para transportar mensajes MIDI dentro de paquetes del Protocolo de transporte en tiempo real (RTP) a través de redes Ethernet y WiFi. Es completamente abierto y gratuito (no se necesita licencia) y es compatible tanto con los campos de aplicación LAN como WAN. En comparación con MIDI 1.0, RTP-MIDI incluye nuevas funciones como gestión de sesiones, sincronización de dispositivos y detección de paquetes perdidos, con regeneración automática de datos perdidos. RTP-MIDI es compatible con aplicaciones en tiempo real y admite sincronización con precisión de muestra para cada mensaje MIDI.
En 2004, John Lazzaro y John Wawrzynek , de UC Berkeley , hicieron una presentación frente a AES denominada "An RTP payload for MIDI". [1] En 2006, el documento se envió al IETF y recibió el número RFC 4695. [2] En paralelo, Lazzaro y Wawrzynek publicaron otro documento para brindar detalles sobre la implementación práctica del protocolo RTP-MIDI, especialmente el mecanismo de registro en diario. . [3]
RFC 4695 quedó obsoleto por RFC 6295 en 2011. El protocolo no ha cambiado entre las dos versiones de los documentos RFC, la última contiene la corrección de errores encontrados en RFC 4695) [4]
La MMA ( Asociación de Fabricantes MIDI ) ha creado una página en su sitio web con el objetivo de proporcionar información básica relacionada con el protocolo RTP-MIDI. [5]
Apple Computer introdujo RTP-MIDI como parte de su sistema operativo, Mac OS X v10.4 , en 2005. Se accede al controlador RTP-MIDI mediante el icono de Red en la herramienta de configuración MIDI/Audio. La implementación de Apple sigue estrictamente el RFC 4695 para la carga útil RTP y el sistema de registro en diario, pero utiliza un protocolo de gestión de sesiones dedicado; no siguen la propuesta de gestión de sesiones RFC 4695. Este protocolo se muestra en Wireshark como "AppleMIDI" y posteriormente fue documentado por Apple.
Apple también creó una clase dedicada en su implementación mDNS / Bonjour . Los dispositivos que cumplen con esta clase aparecen automáticamente en el panel de configuración RTP-MIDI de Apple como directorio de Participantes, lo que hace que el sistema MIDI de Apple sea completamente ' Plug & Play '. Sin embargo, es posible ingresar manualmente direcciones IP y puertos en este directorio para conectarse a dispositivos que no son compatibles con Bonjour.
Apple también introdujo soporte RTP-MIDI en iOS4, pero dichos dispositivos no pueden ser iniciadores de sesión.
El controlador RTP-MIDI de Apple crea puertos MIDI virtuales llamados "Sessions", que están disponibles como puertos MIDI en cualquier software, como secuenciadores o instrumentos de software, usando CoreMIDI, donde aparecen como un par de puertos MIDI IN/MIDI OUT como cualquier otro puerto MIDI 1.0 o puerto USB MIDI.
En 2006, la empresa holandesa Kiss-Box presentó una primera implementación integrada de RTP-MIDI, en diferentes productos como interfaces MIDI o LTC . [6] Estos dispositivos cumplen con la implementación AppleMIDI, utilizando el mismo protocolo de gestión de sesiones, para ser compatibles con los demás dispositivos y sistemas operativos que utilizan este protocolo.
Inicialmente, la empresa desarrolló un controlador propietario para Windows XP , pero estaba restringido a la comunicación con sus dispositivos; No fue posible conectar una PC con una computadora Mac usando este controlador. La compatibilidad con este controlador se abandonó en 2012 en favor del enfoque estándar cuando el controlador rtpMIDI para Windows estuvo disponible.
Kiss-Box anunció el lanzamiento en 2012 de una nueva generación de placas CPU, denominada "V3", que soportan las funcionalidades de iniciador de sesión. Estos modelos son capaces de establecer sesiones con otros dispositivos RTP-MIDI sin necesidad de un ordenador como punto de control.
Durante NAMM 2013, la empresa canadiense iConnectivity presentó una nueva interfaz denominada iConnectivityMIDI4+ que admite RTP-MIDI y permite el puente directo entre dispositivos USB y RTP-MIDI. Desde entonces, han seguido con varias otras interfaces compatibles con RTP-MIDI, incluidas mio4 y mio10, y PlayAUDIO 12.
Tobias Erichsen lanzó en 2010 una implementación para Windows del controlador RTP-MIDI de Apple. [7] Este controlador funciona en versiones XP , Vista , Windows 7 , Windows 8 y Windows 10 , de 32 y 64 bits. [8] El controlador utiliza un panel de configuración muy similar al de Apple y es totalmente compatible con la implementación de Apple. Luego se puede utilizar para conectar una máquina Windows con una computadora Macintosh, pero también con sistemas integrados. Al igual que con el controlador de Apple, el controlador de Windows crea puertos MIDI virtuales, que se vuelven visibles desde cualquier aplicación MIDI que se ejecute en la PC. El acceso se realiza a través de la capa mmsystem, como todos los demás puertos MIDI.
La compatibilidad con RTP-MIDI para Linux se reactivó en febrero de 2013 después de un período de inactividad. En algunos foros se ha anunciado la disponibilidad de controladores, basados en el trabajo original de Nicolas Falquet y Dominique Fober. [9] [10]
También está disponible una implementación específica para computadora Raspberry PI, llamada raveloxmidi. [11]
Una implementación completa de RTP-MIDI (incluido el sistema de registro) está disponible en la distribución de Ubuntu, en el paquete de software Scenic. [12]
Hay una nueva implementación, rtpmidid, [13] que se integra perfectamente con el secuenciador ALSA, permitiendo el uso de herramientas como QjackCtl para controlar las conexiones.
Apple agregó soporte completo CoreMIDI en sus dispositivos iOS en 2010, permitiendo el desarrollo de aplicaciones MIDI para iPhone, iPad y iPod. Luego, MIDI estuvo disponible desde el puerto de acoplamiento en forma de controlador USB, lo que permite la conexión de dispositivos MIDI USB utilizando el "Apple Camera Kit". También estaba disponible en forma de oyente de sesión RTP-MIDI a través de WiFi.
Los dispositivos iOS no admiten funciones de inicio de sesión, lo que requiere el uso de un iniciador de sesión externo en la red para abrir una sesión RTP-MIDI con el iPad. Este iniciador de sesión puede ser una computadora Mac o una computadora Windows con el controlador RTP-MIDI activado, o un dispositivo RTP-MIDI integrado. La sesión RTP-MIDI aparece bajo el nombre "Network MIDI" para todas las aplicaciones CoreMIDI en iOS y no se requiere ningún desarrollo específico para agregar soporte RTP-MIDI en la aplicación iOS. El puerto MIDI está virtualizado por CoreMIDI, por lo que el programador sólo necesita abrir una conexión MIDI, independientemente de si el puerto está conectado a USB o RTP-MIDI.
Surgieron algunas quejas sobre el uso del MIDI a través de USB con dispositivos iOS, [14] ya que el iPad/iPhone debe proporcionar alimentación al dispositivo externo. Algunos adaptadores USB MIDI consumen demasiada corriente para el iPad, lo que limita la corriente y bloquea el inicio del dispositivo, que luego no aparece como disponible para la aplicación. Este problema se evita mediante el uso de RTP-MIDI.
Desde junio de 2013, está disponible como proyecto de código abierto una implementación Javascript de RTP-MIDI, creada por J.Dachtera. [15] El código fuente se basa en el protocolo de gestión de sesiones de Apple y puede actuar como iniciador y escucha de sesiones.
Son posibles implementaciones Java multiplataforma de RTP-MIDI, particularmente la biblioteca 'nmj'. [dieciséis]
El proyecto WinRTP-MIDI [17] es una implementación de código abierto de la pila de protocolos RTP-MIDI en Windows RT. El código fue diseñado inicialmente para ser portátil entre las distintas versiones de Windows, pero la última versión ha sido optimizada para WinRT, con el fin de simplificar el diseño de aplicaciones para la Tienda Windows.
RTP-MIDI estuvo disponible para la plataforma Arduino en noviembre de 2013, con el nombre de "biblioteca AppleMIDI". [18] El módulo de software puede ejecutarse en módulos Arduino con adaptador Ethernet integrado, como Intel Galileo, o ejecutarse en el "escudo Ethernet".
KissBox produce un módulo RTP-MIDI OEM, una placa procesadora de comunicación externa, que se conecta a través de un enlace de bus SPI .
En diciembre de 2013, dos miembros del grupo MIDIbox DIY comenzaron a trabajar en una versión inicial de MIOS (sistema operativo MIDIbox) que incluía soporte RTP-MIDI a través de un enlace SPI rápido. Para simplificar la integración, se decidió utilizar una placa procesadora de red externa que maneje toda la pila de protocolos. Se lanzó una primera versión beta en la segunda semana de enero de 2014. [19] El primer software oficial se lanzó durante la primera semana de marzo de 2014.
El protocolo utilizado en el enlace SPI entre el procesador MIOS y el procesador de red se basa en el mismo formato que USB, utilizando palabras de 32 bits que contienen un mensaje MIDI completo, y se ha propuesto como un estándar abierto para la comunicación entre módulos de procesador de red y Tarjetas de aplicación MIDI.
El Axoloti es un sintetizador de hardware de código abierto basado en un procesador ARM STM32F427. Este sintetizador es totalmente programable utilizando un concepto de parche virtual, similar a Max/MSP, e incluye soporte MIDI completo. Se ha desarrollado una extensión node.js para permitir la conexión RTP-MIDI de un Axoloti con cualquier dispositivo RTP-MIDI. [20] El hardware Axoloti también puede equiparse con un coprocesador externo RTP-MIDI, conectado a través del bus SPI disponible en el puerto de expansión del núcleo Axoloti. El enfoque es el mismo que el descrito para Arduino y MIDIbox.
MIDIKit es una biblioteca multiplataforma de código abierto que proporciona una API MIDI unificada para las diversas API MIDI disponibles en el mercado (Core MIDI, Windows MME, Linux ALSA, etc.). MIDIKit admite el protocolo RTP-MIDI, incluido el sistema de registro en diario. Los puertos RTP-MIDI se consideran dentro de MIDIKit como puertos complementarios (no dependen del controlador rtpMIDI), agregados a los puertos MIDI nativos del sistema [21]
Dado que RTP-MIDI se basa en UDP/IP, cualquier aplicación puede implementar el protocolo directamente, sin necesidad de ningún controlador. Los controladores sólo son necesarios cuando los usuarios desean que los puertos MIDI en red aparezcan como un puerto MIDI estándar. Por ejemplo, algunos objetos Max/MSP y complementos VST se han desarrollado siguiendo esta metodología.
AVB es un conjunto de estándares técnicos que definen especificaciones para servicios de transmisión de latencia extremadamente baja a través de redes Ethernet. Las redes AVB pueden proporcionar latencias de hasta una muestra de audio en una red completa.
RTP-MIDI es compatible de forma nativa con redes AVB, como cualquier otro protocolo IP, ya que los conmutadores AVB (también conocidos como "conmutadores IEEE802.1") gestionan automáticamente la prioridad entre las transmisiones de audio/vídeo en tiempo real y el tráfico IP. El protocolo RTP-MIDI también puede utilizar las capacidades en tiempo real de AVB si el dispositivo implementa la carga útil RTCP descrita en el documento IEEE-1733. [22] Las aplicaciones RTP-MIDI pueden correlacionar la marca de tiempo de "presentación", proporcionada por el reloj maestro IEEE-802.1, con la marca de tiempo RTP, asegurando una distribución de tiempo de los eventos MIDI con precisión de muestra.
RFC 4695/RFC 6295 divide la implementación RTP-MIDI en diferentes partes. El único obligatorio, que define el cumplimiento de la especificación RTP-MIDI, es el formato de carga útil. La parte del registro en diario es opcional, pero los paquetes RTP-MIDI deberán indicar que tienen un diario vacío, por lo que el diario siempre estará presente en el paquete RTP-MIDI, incluso si está vacío. La parte de inicio/gestión de sesión es puramente informativa. Apple no lo utilizó, que creó su propio protocolo de gestión de sesiones.
Las sesiones RTP-MIDI se encargan de crear una ruta virtual entre dos dispositivos RTP-MIDI, y aparecen como un par MIDI IN/MIDI OUT desde el punto de vista de la aplicación. RFC 6295 propone utilizar SIP (Protocolo de inicio de sesión) y SDP (Protocolo de descripción de sesión), pero Apple decidió crear su propio protocolo de gestión de sesiones. El protocolo de Apple vincula las sesiones con los nombres utilizados en Bonjour y también ofrece servicio de sincronización de reloj.
Una sesión determinada siempre se crea entre dos, y sólo dos, participantes, y cada sesión se utiliza para detectar una posible pérdida de mensajes entre los dos participantes. Sin embargo, un controlador de sesión determinado puede abrir varias sesiones en paralelo, lo que permite capacidades como la división, la fusión o un patchbay distribuido. En el diagrama que se muestra aquí, el dispositivo 1 tiene dos sesiones abiertas al mismo tiempo, una con el dispositivo 2 y otra con el dispositivo 3, pero las dos sesiones en el dispositivo 1 aparecen como la misma interfaz MIDI virtual para el usuario final.
Un error común es la falta de coincidencia entre los puntos finales RTP-MIDI y las sesiones RTP-MIDI, ya que ambos representan un par de puertos MIDI IN/MIDI OUT.
Un punto final se utiliza para intercambiar datos MIDI entre el elemento (software y/o hardware) encargado de decodificar el protocolo de transporte RTP-MIDI y el elemento que utiliza los mensajes MIDI. En otras palabras, sólo los datos MIDI son visibles a nivel de punto final. Para dispositivos con conectores MIDI 1.0 DIN, hay un punto final por par de conectores, por ejemplo: 2 puntos finales para KissBox MIDI2TR, 4 puntos finales para iConnectivityMIDI4+, etc. Los dispositivos que utilizan otros enlaces de comunicación como SPI o USB ofrecen más puntos finales, por ejemplo, un dispositivo El uso de la codificación de 32 bits de USB MIDI Class puede representar hasta 16 puntos finales utilizando el campo Identificador de cable. Un punto final está representado en el lado RTP-MIDI mediante un puerto UDP emparejado cuando se utiliza el protocolo de sesión AppleMIDI.
Una sesión define la conexión entre dos puntos finales. La entrada MIDI de un punto final está conectada a la salida MIDI del punto final remoto y viceversa. Un único punto final puede aceptar varias sesiones, según la configuración del software. Cada sesión para un punto final determinado aparece como única para el controlador de sesión remota. Un controlador de sesión remota no sabe si el punto final al que está conectado está siendo utilizado por otras sesiones al mismo tiempo. Si hay varias sesiones activas para un punto final determinado, los diferentes flujos MIDI que llegan al punto final se fusionan antes de que los datos MIDI se envíen a la aplicación. En la otra dirección, los datos MIDI producidos por una aplicación se envían a todos los controladores de sesión conectados al punto final.
La implementación AppleMIDI define dos tipos de controladores de sesión: iniciadores de sesión y oyentes de sesión. Los iniciadores de sesión son responsables de invitar a los oyentes de la sesión y son responsables de la secuencia de sincronización del reloj. Los iniciadores de sesión generalmente pueden ser oyentes de sesión, pero algunos dispositivos, como los dispositivos iOS, solo pueden ser oyentes de sesión.
Los dispositivos RTP-MIDI pueden fusionar diferentes flujos MIDI sin necesidad de ningún componente específico, a diferencia de los dispositivos MIDI 1.0 que requieren "fusiones MIDI". Como se puede ver en el diagrama, cuando un controlador de sesión se conecta a dos o más sesiones remotas, fusiona automáticamente los flujos MIDI provenientes de los dispositivos remotos, sin requerir ninguna configuración específica.
Los dispositivos RTP-MIDI pueden duplicar transmisiones MIDI de una sesión a cualquier número de sesiones remotas sin necesidad de ningún dispositivo compatible con "MIDI THRU". Cuando una sesión RTP-MIDI está conectada a dos o más sesiones remotas, todas las sesiones remotas reciben una copia de los datos MIDI enviados desde la fuente.
Las sesiones RTP-MIDI también pueden proporcionar una función de "patchbay", que requiere un dispositivo de hardware independiente con conexiones MIDI 1.0. Un patchbay MIDI 1.0 es un dispositivo de hardware que permite conexiones dinámicas entre un conjunto de entradas MIDI y un conjunto de salidas MIDI, la mayoría de las veces en forma de matriz. El concepto de conexión "dinámica" contrasta con el uso clásico de líneas MIDI 1.0 donde los cables se conectaban "estáticamente" entre dos dispositivos. En lugar de establecer la ruta de datos entre dispositivos en forma de cable, el patchbay se convierte en un punto central donde se conectan todos los dispositivos MIDI. El software en el patchbay MIDI está configurado para definir qué entrada MIDI va a qué salida MIDI, y el usuario puede cambiar esta configuración en cualquier momento, sin necesidad de desconectar los cables MIDI DIN.
Los módulos de hardware "patchbay" ya no son necesarios con RTP-MIDI, gracias al concepto de sesión. Las sesiones son, por definición, caminos virtuales establecidos a través de la red entre dos puertos MIDI. No se necesita ningún software específico para realizar las funciones del patchbay ya que el proceso de configuración define con precisión los destinos para cada flujo MIDI producido por un dispositivo MIDI determinado. Entonces es posible cambiar en cualquier momento estas rutas virtuales simplemente cambiando las direcciones IP de destino utilizadas por cada iniciador de sesión. La configuración del "parche" formada de esta manera se puede almacenar en la memoria no volátil, para permitir que el parche se reforme automáticamente cuando se enciende la configuración, pero también se pueden cambiar directamente, como con la herramienta de software RTP-MIDI Manager o con el Paneles de control de drivers RTP-MIDI, a nivel de RAM.
El término "patchbay distribuido" proviene del hecho de que los diferentes dispositivos RTP-MIDI se pueden distribuir geográficamente por toda la configuración MIDI completa, mientras que el patchbay MIDI 1.0 obligaba a los diferentes dispositivos MIDI a ubicarse físicamente directamente alrededor del propio dispositivo patchbay.
El documento RFC6295 propone utilizar los protocolos SDP (Protocolo de descripción de sesión) y SIP (Protocolo de inicio de sesión) para establecer y gestionar sesiones entre socios RTP-MIDI. Sin embargo, estos dos protocolos son bastante difíciles de implementar, especialmente en sistemas pequeños, especialmente porque no limitan ninguno de los parámetros enumerados en el descriptor de sesión, como la frecuencia de muestreo, que define a su vez todos los campos relacionados con los datos de sincronización tanto en los encabezados RTP como en RTP. -Carga útil MIDI. Además, el documento RFC6295 sólo sugiere el uso de estos protocolos, permitiendo el uso de cualquier otro protocolo, dando lugar a posibles incompatibilidades entre proveedores.
Apple decidió crear su propio protocolo, imponiendo todos los parámetros relacionados con la sincronización como la frecuencia de muestreo. Este protocolo de sesión se denomina "AppleMIDI" en el software Wireshark. La gestión de sesiones con el protocolo AppleMIDI requiere dos puertos UDP, el primero se llama "Puerto de Control", el segundo se llama "Puerto de Datos". Cuando se utiliza dentro de una implementación multiproceso, sólo el puerto de datos requiere un subproceso en "tiempo real", el otro puerto puede ser controlado por un subproceso de prioridad normal. Estos dos puertos deben estar ubicados en dos ubicaciones consecutivas (n / n+1); el primero puede ser cualquiera de los 65536 puertos posibles.
No hay restricción en el número de sesiones que se pueden abrir simultáneamente en el conjunto de puertos UDP con protocolo AppleMIDI. Es posible crear un grupo de puertos por administrador de sesión o utilizar solo un grupo para múltiples sesiones, lo que limita la huella de memoria en el sistema. En este último caso, la pila de IP proporciona recursos para identificar socios a partir de su dirección IP y números de puertos. Esta funcionalidad se denomina "reutilización de sockets" y está disponible en la mayoría de las implementaciones de IP modernas.
Todos los mensajes del protocolo AppleMIDI utilizan una estructura común de 4 palabras de 32 bits, con un encabezado que contiene dos bytes con valor 255, seguido de dos bytes que describen el significado del mensaje:
Estos mensajes controlan una máquina de estados relacionada con cada sesión. Por ejemplo, esta máquina de estado prohíbe cualquier intercambio de datos MIDI hasta que una sesión alcance el estado "abierto".
La apertura de una sesión comienza con una secuencia de invitación. El primer socio de sesión (el "Iniciador de sesión") envía un mensaje IN al puerto de control del segundo socio. Responden enviando un mensaje OK si aceptan abrir la sesión, o con un mensaje NO si no aceptan la invitación. Si se acepta una invitación en el puerto de control, se repite la misma secuencia en el puerto de datos. Una vez aceptadas las invitaciones en ambos puertos, la máquina de estados pasa a la fase de sincronización.
La secuencia de sincronización permite a ambos participantes de la sesión compartir información relacionada con sus relojes locales. Esta fase permite compensar la latencia inducida por la red y también soportar el "futuro sellado de tiempo" (consulte la sección "Latencia" a continuación).
El iniciador de sesión envía un primer mensaje (llamado CK0) al socio remoto, indicando su hora local en 64 bits (tenga en cuenta que este no es un tiempo absoluto, sino un tiempo relacionado con una referencia local, generalmente dada en microsegundos desde el inicio de núcleo del sistema operativo). Este tiempo se expresa en un reloj de muestreo de 10 kHz (100 microsegundos por incremento). El interlocutor remoto debe responder a este mensaje con un mensaje CK1 que contiene su propia hora local en 64 bits. Luego, ambos socios conocen la diferencia entre sus respectivos relojes y pueden determinar el desplazamiento que se aplicará a los campos Timestamp y Deltatime en el protocolo RTP-MIDI.
El iniciador de la sesión finaliza esta secuencia enviando un último mensaje llamado CK2, que contiene la hora local en la que recibió el mensaje CK1. Esta técnica permite calcular la latencia promedio de la red y también compensar un posible retraso introducido por un hilo de inicio lento, que puede ocurrir con sistemas operativos que no son en tiempo real como Linux, Windows u OS X.
Apple recomienda repetir esta secuencia varias veces justo después de abrir la sesión, para obtener una mayor precisión de sincronización, en caso de que una de ellas se haya retrasado accidentalmente debido a una sobrecarga temporal de la red o un pico de latencia en la activación de un hilo.
Esta secuencia debe repetirse cíclicamente, normalmente entre 2 y 6 veces por minuto, y siempre por parte del iniciador de la sesión, para mantener la precisión de la sincronización a largo plazo mediante la compensación de la deriva del reloj local y también para detectar una pérdida del interlocutor de comunicación. Un socio que no responda múltiples mensajes CK0 considerará que el socio remoto está desconectado. En la mayoría de los casos, los iniciadores de sesión cambian su máquina de estado al estado "Invitación" para restablecer la comunicación automáticamente tan pronto como el socio distante se vuelve a conectar a la red. Algunas implementaciones, especialmente en computadoras personales, también muestran un mensaje de alerta y ofrecen al usuario la posibilidad de elegir entre un nuevo intento de conexión o cerrar la sesión.
El mecanismo de registro en diario permite detectar la pérdida de mensajes MIDI y permite al receptor generar datos faltantes sin necesidad de retransmisión. El diario mantiene en memoria "imágenes MIDI" de los diferentes compañeros de sesión en diferentes momentos. Sin embargo, es inútil mantener en la memoria los datos del diario correspondientes a los eventos recibidos correctamente por un socio de sesión. A continuación, cada socio envía cíclicamente al otro socio el mensaje RS, indicando el último número de secuencia recibido correctamente, es decir, sin ningún espacio entre dos números de secuencia. Luego, el remitente puede liberar la memoria que contiene datos antiguos del diario si es necesario.
Un compañero de sesión puede solicitar en cualquier momento abandonar una sesión, lo que a su vez cerrará la sesión. Esto se hace usando el mensaje BY. Cuando un socio de sesión recibe este mensaje, cierra inmediatamente la sesión con el socio remoto que envió el mensaje y libera todos los recursos asignados a esta sesión. Cabe señalar que este mensaje puede ser enviado por el iniciador de la sesión o por el oyente de la sesión (socio "invitado").
La preocupación más común acerca de RTP-MIDI está relacionada con problemas de latencia, una preocupación general con las estaciones de trabajo de audio digital, principalmente porque utilizan la pila IP. Sin embargo, se puede demostrar fácilmente que una aplicación o controlador RTP-MIDI correctamente programado no presenta mayor latencia que otros métodos de comunicación.
Además, RTP-MIDI, como se describe en RFC 6295, contiene un mecanismo de compensación de latencia. Se encuentra un mecanismo similar en la mayoría de los complementos, que pueden informar al host de la latencia que agregan a la ruta de procesamiento. Luego, el anfitrión puede enviar muestras al complemento con anticipación, de modo que las muestras estén listas y se envíen sincrónicamente con otras transmisiones de audio. El mecanismo de compensación descrito en RF6295 utiliza un sistema de marca de tiempo relativo, basado en el tiempo delta MIDI, como se describe en [23] Cada evento MIDI transportado en la carga útil RTP tiene un valor de tiempo delta principal, relacionado con el origen del tiempo de carga actual, definido por el Campo de marca de tiempo en el encabezado RTP.
Cada evento MIDI en la carga útil RTP-MIDI se puede sincronizar estrictamente con el reloj global. La precisión de la sincronización depende directamente de la fuente de reloj definida al abrir la sesión RTP-MIDI. RFC 6295 ofrece algunos ejemplos basados en un reloj de muestreo de audio, para obtener una marca de tiempo precisa de muestra de eventos MIDI. La implementación RTP-MIDI de Apple, al igual que todas las demás implementaciones relacionadas, como el controlador rtpMIDI para Windows o los sistemas integrados KissBox, utiliza una frecuencia de reloj fija de 10 kHz en lugar de una frecuencia de audio de muestreo. La precisión de sincronización de todos los eventos MIDI es entonces de 100 microsegundos para estas implementaciones.
Los relojes del emisor y del receptor se sincronizan cuando se inicia la sesión y se mantienen sincronizados durante todo el período de la sesión mediante ciclos de sincronización regulares, controlados por los iniciadores de la sesión. Este mecanismo tiene la capacidad de compensar cualquier latencia, desde unos pocos cientos de microsegundos, como se ve en las aplicaciones LAN, hasta segundos. Puede compensar la latencia introducida por Internet, por ejemplo, permitiendo la ejecución de piezas musicales en tiempo real.
Sin embargo, este mecanismo está diseñado principalmente para transmisiones MIDI pregrabadas, como la que proviene de una pista del secuenciador. Cuando se utiliza RTP-MIDI para aplicaciones en tiempo real (por ejemplo, controlar dispositivos desde un teclado compatible con RTP-MIDI [24] ), deltatime se establece principalmente en el valor específico de 0, lo que significa que el evento MIDI relacionado se interpretará lo antes posible. tal como se recibe). En tal caso de uso, no se puede utilizar el mecanismo de compensación de latencia descrito anteriormente.
La latencia que se puede obtener está directamente relacionada con los diferentes componentes de red involucrados en la ruta de comunicación entre los dispositivos RTP-MIDI:
El tiempo de procesamiento de la aplicación generalmente está estrictamente controlado, ya que las tareas MIDI suelen ser tareas en tiempo real. En la mayoría de los casos, la latencia proviene directamente de la latencia del subproceso que se puede obtener en un sistema operativo determinado, normalmente de 1 a 2 ms como máximo en sistemas Windows y Mac OS. Los sistemas con kernel en tiempo real pueden lograr resultados mucho mejores, hasta 100 microsegundos. Este tiempo se puede considerar constante, sea cual sea el canal de comunicación (MIDI 1.0, USB, RTP-MIDI, etc...), ya que los hilos de procesamiento están operando en un nivel diferente al de los hilos/tareas relacionados con la comunicación.
El tiempo de procesamiento de la pila de IP es el más crítico, ya que el proceso de comunicación pasa bajo el control del sistema operativo. Esto se aplica a cualquier protocolo de comunicación, relacionado con IP o no, ya que la mayoría de los sistemas operativos, incluidos Windows, Mac OS o Linux, no permiten el acceso directo al adaptador Ethernet. En particular, un error común es combinar "sockets sin formato" con "acceso directo a la red"; Los sockets son el punto de entrada para enviar y recibir datos a través de la red en la mayoría de los sistemas operativos. Un "socket sin formato" es un socket que permite a una aplicación enviar cualquier paquete utilizando cualquier protocolo. Luego, la aplicación es responsable de construir el telegrama siguiendo las reglas de protocolo dadas, mientras que el "acceso directo" requeriría un acceso a nivel de sistema que está restringido al núcleo del sistema operativo. El sistema operativo puede retrasar un paquete enviado mediante un socket sin formato si otra aplicación está utilizando actualmente el adaptador de red. Por lo tanto, se puede enviar un paquete IP a la red antes que un paquete relacionado con un socket sin formato. Técnicamente hablando, el acceso a una determinada tarjeta de red está controlado por "semáforos". [25]
Las pilas de IP necesitan correlacionar direcciones Ethernet (dirección MAC) y direcciones IP, utilizando un protocolo específico llamado ARP. Cuando una aplicación RTP-MIDI quiere enviar un paquete a un dispositivo remoto, debe ubicarlo primero en la red, ya que Ethernet no entiende conceptos relacionados con IP, para poder crear la ruta de transmisión entre los enrutadores/switches. Esto lo hace automáticamente la pila de IP enviando primero una solicitud ARP (Protocolo de reconocimiento de direcciones). Cuando el dispositivo de destino reconoce su propia dirección IP en el paquete ARP, envía una respuesta ARP con su dirección MAC. Luego, la pila de IP puede enviar el paquete RTP-MIDI. Los siguientes paquetes RTP-MIDI ya no necesitan la secuencia ARP, a menos que el enlace quede inactivo durante unos minutos, lo que borra la entrada ARP en la tabla de enrutamiento del remitente.
Esta secuencia ARP puede tardar unos segundos, lo que a su vez puede introducir una latencia notable, al menos para el primer paquete RTP-MIDI. Sin embargo, la implementación de Apple resolvió este problema de manera elegante, utilizando el protocolo de control de sesión. El protocolo de sesión utiliza los mismos puertos que el propio protocolo RTP-MIDI. La secuencia ARP luego tiene lugar durante la secuencia de inicio de sesión. Cuando la aplicación RTP-MIDI quiere enviar el primer paquete RTP-MIDI, las tablas de enrutamiento de la computadora ya están inicializadas con las direcciones MAC de destino correctas, lo que evita cualquier latencia para el primer paquete.
Además de la secuencia ARP, la pila IP en sí requiere cálculos para preparar los encabezados de los paquetes, como el encabezado IP, el encabezado UDP y el encabezado RTP. Con los procesadores modernos, esta preparación es extremadamente rápida y sólo lleva unos pocos microsegundos, lo que es insignificante en comparación con la latencia de la aplicación en sí. Como se describió anteriormente, una vez preparado, un paquete RTP-MIDI solo se puede retrasar cuando intenta llegar al adaptador de red si el adaptador ya está transmitiendo otro paquete, ya sea que el socket sea IP o "sin formato". Sin embargo, la latencia introducida en este nivel es generalmente extremadamente baja ya que los subprocesos del controlador a cargo de los adaptadores de red tienen una prioridad muy alta. Además, la mayoría de los adaptadores de red tienen buffers FIFO a nivel de hardware, por lo que los paquetes se pueden almacenar para su transmisión inmediata en el propio adaptador de red sin necesidad de ejecutar primero el subproceso del controlador. Un método para ayudar a mantener la latencia relacionada con la "competencia de acceso al adaptador" lo más baja posible es reservar el adaptador de red solo para comunicación MIDI y usar un adaptador de red diferente para otros usos de la red, como compartir archivos o navegar por Internet.
Los diferentes componentes utilizados para transmitir paquetes Ethernet entre las computadoras, cualesquiera que sean los protocolos utilizados, también introducen latencia. Todos los conmutadores de red modernos utilizan la tecnología "almacenar y reenviar", en la que los paquetes se almacenan en el conmutador antes de enviarlos al siguiente conmutador. Sin embargo, los tiempos de conmutación suelen ser insignificantes. Por ejemplo, un paquete de 64 bytes en una red de 100 Mbit/s tarda alrededor de 5,1 microsegundos en ser reenviado por cada conmutador de red. Una red compleja con 10 conmutadores en una ruta determinada introduce entonces una latencia de 51 microsegundos.
Sin embargo, la latencia está directamente relacionada con la carga de la red en sí, ya que los conmutadores retrasarán un paquete hasta que se transmita el anterior. El cálculo/medición de la latencia real introducida por los componentes de la red puede ser una tarea difícil e implicará casos de uso representativos; por ejemplo, medir la latencia entre dos dispositivos en red conectados al mismo conmutador de red siempre dará excelentes resultados. Como se dijo en el apartado anterior, una solución para limitar la latencia introducida por los componentes de la red es utilizar redes separadas. Sin embargo, esto es mucho menos crítico para los componentes de red que para los adaptadores de red de las computadoras.
Como se puede observar, la latencia exacta obtenida para el enlace RTP-MIDI depende de muchos parámetros, la mayoría de ellos relacionados con los propios sistemas operativos. Las mediciones realizadas por los diferentes actores RTP-MIDI dan tiempos de latencia desde unos pocos cientos de microsegundos para sistemas integrados que utilizan sistemas operativos en tiempo real, hasta 3 milisegundos cuando se trata de ordenadores que ejecutan sistemas operativos de propósito general.
La AES inició un grupo de trabajo llamado SC-02-12H [26] en 2010 para demostrar la capacidad de utilizar cargas útiles RTP en redes IP para aplicaciones de muy baja latencia. El borrador de propuesta emitido por el grupo en mayo de 2013 demuestra que es posible lograr transmisión RTP para aplicaciones en vivo, con un valor de latencia tan bajo como 125 microsegundos.
La otra preocupación más común relacionada con RTP-MIDI es el proceso de configuración, ya que la conexión física de un dispositivo a una red no es suficiente para asegurar la comunicación con otro dispositivo. Dado que RTP-MIDI se basa en una pila de protocolos IP, se deben configurar las diferentes capas involucradas en el proceso de comunicación, como la dirección IP y los puertos UDP. Para simplificar esta configuración se han propuesto diferentes soluciones, siendo la más común el conjunto de tecnologías "Zero Configuration", también conocido como Zeroconf.
RFC 3927 [27] describe un método común para asignar automáticamente direcciones IP, que utilizan la mayoría de los productos compatibles con RTP-MIDI. Una vez conectado a la red IP, dicho dispositivo puede asignarse a sí mismo una dirección IP, con resolución automática de conflictos de direcciones IP. Si el dispositivo sigue las recomendaciones de asignación de puertos de la especificación RTP, el dispositivo se convierte en "Plug&Play" desde el punto de vista de la red. Entonces es posible crear una red RTP-MIDI completamente sin necesidad de definir ninguna dirección IP y/o números de puerto UDP. Sin embargo, hay que tener en cuenta que estos métodos generalmente están reservados para configuraciones pequeñas. Generalmente se evita la automatización completa de la configuración de la red en configuraciones grandes, ya que la localización de dispositivos defectuosos puede volverse compleja, porque no habrá una relación directa entre la dirección IP seleccionada por el sistema Zeroconf y la ubicación física del dispositivo. Una configuración mínima sería entonces asignar un nombre al dispositivo antes de conectarlo a la red, lo que anula el concepto de "verdadero Plug&Play" en ese caso.
Hay que tener en cuenta que el concepto de "Configuración cero" está restringido a las capas de comunicación de la red. Es técnicamente imposible realizar la instalación completa de cualquier dispositivo en red (relacionado con MIDI o no) simplemente abstrayendo la capa de direccionamiento. Un caso de uso práctico que ilustra esta limitación es un generador de sonido RTP-MIDI que debe controlarse desde un teclado maestro MIDI conectado a una interfaz RTP-MIDI. Incluso si el generador de sonido y la interfaz MIDI integran los servicios de "Configuración Cero", no pueden saber por sí mismos que necesitan establecer una sesión juntos, porque los servicios de configuración IP actúan en diferentes niveles. Cualquier sistema MIDI en red, cualquiera que sea el protocolo utilizado para intercambiar datos MIDI (basado en IP o no), requiere el uso obligatorio de una herramienta de configuración para definir los intercambios que deben tener lugar entre los dispositivos después de su conexión a la red. . Esta herramienta de configuración puede ser una herramienta de gestión externa que se ejecuta en una computadora o estar integrada en el software de aplicación de un dispositivo en forma de menú de configuración si el dispositivo integra una interfaz hombre-máquina.
La Asociación de Fabricantes de MIDI anunció en enero de 2019 que una importante evolución del protocolo MIDI, denominada MIDI 2.0 [28], estaba entrando en la fase final de creación de prototipos.
MIDI 2.0 depende en gran medida de la extensión MIDI-CI, utilizada para la negociación de protocolos (identificación de dispositivos MIDI 1.0 y MIDI 2.0 para permitir la conmutación de protocolos). RTP-MIDI es totalmente compatible con el protocolo MIDI-CI, ya que utiliza MIDI 1.0 System Exclusive incluso en dispositivos MIDI 2.0.
Se ha presentado en el MMA una evolución del protocolo RTP-MIDI para incluir MIDI 2.0 y actualmente se está discutiendo en el grupo de trabajo MIDI 2.0. El protocolo mejorado admite formatos de datos MIDI 1.0 y MIDI 2.0 en paralelo (MIDI 2.0 usa paquetes basados en 32 bits, mientras que MIDI 1.0 usa paquetes basados en 8 bits)