RTP-MIDI

Apple Computer introdujo RTP-MIDI como parte de su sistema operativo, Mac OS X v10.4 , en 2005. El controlador RTP-MIDI se accede 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 y el sistema de registro de RTP, pero utiliza un protocolo de gestión de sesiones dedicado; no sigue la propuesta de gestión de sesiones del RFC 4695. Este protocolo se muestra en Wireshark como "AppleMIDI" y fue documentado posteriormente por Apple .

Apple también creó una clase específica en su implementación de mDNS / Bonjour . Los dispositivos compatibles con esta clase aparecen automáticamente en el panel de configuración RTP-MIDI de Apple como participantes, lo que convierte al sistema MIDI de Apple en totalmente Plug & Play . Sin embargo, es posible introducir manualmente direcciones IP y puertos en este directorio para conectarse a dispositivos que no son compatibles con Bonjour.

Apple también introdujo la compatibilidad con 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 "Sesiones", que están disponibles como puertos MIDI en cualquier software, como secuenciadores o instrumentos virtuales, que utilice 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ó la primera implementación integrada de RTP-MIDI en diferentes productos, como interfaces MIDI o LTC . ^{[ 6 ]} Estos dispositivos cumplen con la implementación de AppleMIDI, utilizando el mismo protocolo de gestión de sesiones, para ser compatibles con otros dispositivos y sistemas operativos que utilizan este protocolo.

Inicialmente, la empresa desarrolló un controlador propietario para Windows XP , pero este se limitaba a la comunicación con sus dispositivos; no era posible conectar un PC con un ordenador Mac mediante dicho controlador. En 2012, se dejó de dar soporte a este controlador en favor del método estándar, cuando se lanzó el controlador rtpMIDI para Windows.

Kiss-Box anunció el lanzamiento en 2012 de una nueva generación de placas de CPU, denominadas "V3", que admiten las funcionalidades de iniciador de sesión. Estos modelos pueden establecer sesiones con otros dispositivos RTP-MIDI sin necesidad de un ordenador como punto de control.

Durante la feria NAMM 2013, la empresa canadiense iConnectivity presentó una nueva interfaz llamada iConnectivityMIDI4+, compatible con RTP-MIDI y que permite la conexión directa entre dispositivos USB y RTP-MIDI. Posteriormente, lanzaron otras interfaces compatibles con RTP-MIDI, como la mio4, la mio10 y la PlayAUDIO 12.

En 2010, Tobias Erichsen lanzó una implementación para Windows del controlador RTP-MIDI de Apple. ^{[ 7 ]} Este controlador funciona en XP , Vista , Windows 7 , Windows 8 y Windows 10 , versiones 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. Se puede usar para conectar una máquina Windows con una computadora Macintosh, así como con sistemas embebidos. Al igual que el controlador de Apple, el controlador de Windows crea puertos MIDI virtuales, que se vuelven visibles para 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.

El soporte RTP-MIDI para Linux se reactivó en febrero de 2013 tras un periodo de inactividad. La disponibilidad de controladores se anunció en algunos foros, basados ​​en el trabajo original de Nicolas Falquet y Dominique Fober. ^{[ 9 ] [ 10 ]}

También está disponible una implementación específica (pero incompleta) para la computadora Raspberry Pi , llamada raveloxmidi. ^{[ 11 ]} Consulte rtpmidid más adelante para obtener una implementación completa.

Una implementación completa de RTP-MIDI (incluido el sistema de registro) está disponible dentro de la distribución Ubuntu, en el paquete de software Scenic. ^{[ 12 ]}

Existe 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. Esta implementación también está disponible para ARM64, lo que significa que funciona en la Raspberry Pi.

En 2010, Apple incorporó compatibilidad total con CoreMIDI en sus dispositivos iOS, lo que permitió el desarrollo de aplicaciones MIDI para iPhone, iPad e iPod. Posteriormente, MIDI estuvo disponible a través del puerto dock mediante un controlador USB, lo que permitió la conexión de dispositivos MIDI USB utilizando el "Apple Camera Kit". También se pudo utilizar como receptor de sesiones RTP-MIDI a través de Wi-Fi.

Los dispositivos iOS no admiten la función 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 un ordenador Mac o Windows con el controlador RTP-MIDI activado, o un dispositivo RTP-MIDI integrado. La sesión RTP-MIDI aparece con el nombre "Network MIDI" en todas las aplicaciones CoreMIDI para iOS, y no se requiere ningún desarrollo específico para añadir compatibilidad con RTP-MIDI en la aplicación iOS. CoreMIDI virtualiza el puerto MIDI, por lo que el programador solo necesita abrir una conexión MIDI, independientemente de si el puerto está conectado a USB o RTP-MIDI.

Surgieron algunas quejas sobre el uso de MIDI por USB con dispositivos iOS, ^{[ 14 ]} ya que el iPad/iPhone debe suministrar energía al dispositivo externo. Algunos adaptadores MIDI USB consumen demasiada corriente para el iPad, lo que limita la corriente y bloquea el arranque 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, una implementación en JavaScript de RTP-MIDI, creada por J. Dachtera, está disponible como proyecto de código abierto. ^{[ 15 ]} El código fuente se basa en el protocolo de gestión de sesiones de Apple y puede funcionar como iniciador y receptor de sesiones.

Es posible implementar RTP-MIDI en Java en varias plataformas , en particular con la biblioteca 'nmj'. ^{[ 16 ]}

El proyecto WinRTP-MIDI ^{[ 17 ]} es una implementación de código abierto de la pila de protocolos RTP-MIDI bajo Windows RT . El código fue diseñado inicialmente para ser portable entre las distintas versiones de Windows, pero la última versión se ha optimizado 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, bajo el nombre de "biblioteca AppleMIDI". ^{[ 18 ]} El módulo de software puede ejecutarse en módulos Arduino con adaptador Ethernet integrado, como el Intel Galileo, o en el "Ethernet shield".

KissBox fabrica un módulo OEM RTP-MIDI, 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 (MIDIbox Operating System) que incluía soporte para 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 gestionara toda la pila de protocolos. Una primera versión beta se publicó la segunda semana de enero de 2014. ^{[ 19 ]} El primer software oficial se publicó 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 placas de aplicación MIDI.

Axoloti es un sintetizador de hardware de código abierto basado en un procesador ARM STM32F427. Este sintetizador es totalmente programable mediante un concepto de parche virtual, similar a Max/MSP , e incluye soporte MIDI completo. Se ha desarrollado una extensión de Node.js para permitir la conexión RTP-MIDI de Axoloti con cualquier dispositivo RTP-MIDI. ^{[ 20 ]} El hardware de 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 de Axoloti. El enfoque es el mismo que el descrito para Arduino y MIDIbox.

MIDIKit es una biblioteca de código abierto y multiplataforma 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. Los puertos RTP-MIDI se consideran dentro de MIDIKit como puertos complementarios (no dependen del controlador rtpMIDI), añadidos 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 controladores. Estos solo son necesarios cuando se desea que los puertos MIDI de red se comporten como puertos MIDI estándar. Por ejemplo, algunos objetos de Max/MSP y complementos VST se han desarrollado siguiendo esta metodología.

AVB es un conjunto de estándares técnicos que definen las 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 toda la red. RTP-MIDI es compatible de forma nativa con las redes AVB, como cualquier otro protocolo IP, ya que los conmutadores AVB (también conocidos como "conmutadores IEEE 802.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 entonces 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 temporal precisa a nivel de muestra de los eventos MIDI.

Las sesiones RTP-MIDI se encargan de crear una ruta virtual entre dos dispositivos RTP-MIDI y, desde el punto de vista de la aplicación, aparecen como un par MIDI IN/MIDI OUT. El RFC 6295 propone el uso de SIP (Protocolo de Iniciación 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, además, ofrece un servicio de sincronización de reloj.

Una sesión se crea siempre entre dos participantes, y solo entre dos, y se utiliza para detectar posibles pérdidas de mensajes entre ellos. Sin embargo, un controlador de sesión puede abrir varias sesiones en paralelo, lo que permite funciones como la división, la fusión o una matriz de conexiones distribuida. En el diagrama que se muestra aquí, el dispositivo 1 tiene dos sesiones abiertas simultáneamente: una con el dispositivo 2 y otra con el dispositivo 3. Para el usuario final, ambas sesiones en el dispositivo 1 se presentan como la misma interfaz MIDI virtual.

Un error común es la incongruencia 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, solo los datos MIDI son visibles a nivel de punto final. Para dispositivos con conectores MIDI 1.0 DIN, hay un punto final por cada 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 que utiliza la codificación de 32 bits de la clase USB MIDI puede representar hasta 16 puntos finales mediante el campo Identificador de cable. Un punto final se representa 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 se conecta 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 de un punto final determinado aparece como una sola para el gestor de sesiones remoto. Un gestor de sesiones remoto desconoce si el punto final al que está conectado está siendo utilizado por otras sesiones simultáneamente. Si hay varias sesiones activas para un punto final determinado, los diferentes flujos MIDI que llegan a dicho punto final se combinan antes de que los datos MIDI se envíen a la aplicación. En sentido contrario, los datos MIDI generados por una aplicación se envían a todos los gestores de sesiones conectados al punto final.

Los dispositivos RTP-MIDI pueden combinar diferentes flujos MIDI sin necesidad de ningún componente específico, a diferencia de los dispositivos MIDI 1.0 que requieren "combinadores MIDI". Como se puede observar en el diagrama, cuando un controlador de sesión se conecta a dos o más sesiones remotas, combina automáticamente los flujos MIDI provenientes de los dispositivos remotos, sin necesidad de ninguna configuración específica.

Los dispositivos RTP-MIDI pueden duplicar flujos MIDI de una sesión a cualquier número de sesiones remotas sin necesidad de un dispositivo compatible con "MIDI THRU". Cuando una sesión RTP-MIDI se conecta 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 ofrecen la función de "patchbay", que en MIDI 1.0 solo era posible mediante un dispositivo de hardware independiente. 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, generalmente en forma de matriz. El concepto de conexión "dinámica" contrasta con el uso clásico de las líneas MIDI 1.0, donde los cables se conectaban de forma "estática" entre dos dispositivos. En lugar de establecer la ruta de datos entre dispositivos mediante un cable, el patchbay se convierte en un punto central donde se conectan todos los dispositivos MIDI. El software del patchbay MIDI se configura para definir qué entrada MIDI corresponde a qué salida MIDI, y el usuario puede cambiar esta configuración en cualquier momento sin necesidad de desconectar los cables MIDI DIN.

Gracias al concepto de sesión, ya no se necesitan los módulos de hardware de "patchbay" con RTP-MIDI. Las sesiones son, por definición, rutas virtuales establecidas en la red entre dos puertos MIDI. No se requiere software específico para realizar las funciones de patchbay, ya que el proceso de configuración define con precisión los destinos de cada flujo MIDI generado por un dispositivo MIDI determinado. Estas rutas virtuales se pueden modificar en cualquier momento simplemente cambiando las direcciones IP de destino utilizadas por cada iniciador de sesión. La configuración de "patch" formada de esta manera se puede almacenar en memoria no volátil para que se regenere automáticamente al encender el sistema, pero también se puede modificar directamente, por ejemplo, con la herramienta de software RTP-MIDI Manager o con los paneles de control de los controladores RTP-MIDI, a nivel de RAM.

La apertura de una sesión comienza con una secuencia de invitación. El primer participante (el "Iniciador de la Sesión") envía un mensaje IN al puerto de control del segundo participante. Este responde enviando un mensaje OK si acepta abrir la sesión, o un mensaje NO si no acepta la invitación. Si se acepta una invitación en el puerto de control, la misma secuencia se repite en el puerto de datos. Una vez que se han aceptado las invitaciones en ambos puertos, la máquina de estados entra en la fase de sincronización.

La secuencia de sincronización permite que ambos participantes de la sesión compartan información relacionada con sus relojes locales. Esta fase posibilita compensar la latencia generada por la red y también admite el registro de la hora futura (véase la sección "Latencia" más adelante).

El iniciador de la sesión envía un primer mensaje (denominado CK0) al interlocutor remoto, indicando su hora local en 64 bits (tenga en cuenta que no se trata de una hora absoluta, sino de una hora relacionada con una referencia local, generalmente expresada en microsegundos desde el inicio del núcleo del sistema operativo). Esta hora se expresa con una  frecuencia de muestreo de 10 kHz (100 microsegundos por incremento). El interlocutor remoto debe responder a este mensaje con un mensaje CK1, que contenga su propia hora local en 64 bits. De esta forma, ambos interlocutores conocen la diferencia entre sus respectivos relojes y pueden determinar el desfase que deben aplicar a los campos Timestamp y Deltatime del 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 compensar un posible retraso provocado por un hilo de inicio lento, algo que puede ocurrir en 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 alguna de ellas se haya retrasado accidentalmente debido a una sobrecarga temporal de la red o a un pico de latencia en la activación de un hilo.

Esta secuencia debe repetirse cíclicamente, entre 2 y 6 veces por minuto, generalmente por el 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 la pérdida de comunicación con el interlocutor. Si un interlocutor no responde a varios mensajes CK0, se considerará que el interlocutor remoto está desconectado. En la mayoría de los casos, los iniciadores de sesión cambian su máquina de estados al estado de "Invitación" para restablecer la comunicación automáticamente en cuanto el interlocutor remoto se reconecta a la red. Algunas implementaciones, especialmente en ordenadores personales, también muestran un mensaje de alerta y ofrecen al usuario la opción de intentar una nueva conexión o cerrar la sesión.

El mecanismo de registro permite detectar la pérdida de mensajes MIDI y permite al receptor generar los datos faltantes sin necesidad de retransmisión. El registro almacena en memoria "imágenes MIDI" para los diferentes participantes de la sesión en distintos momentos. Sin embargo, no es necesario almacenar en memoria los datos de registro correspondientes a eventos recibidos correctamente por un participante. Cada participante envía cíclicamente al otro el mensaje RS, indicando el último número de secuencia recibido correctamente, es decir, sin intervalos entre dos números de secuencia. El emisor puede entonces liberar la memoria que contiene los datos de registro antiguos si es necesario.

Un participante de la sesión puede solicitar abandonarla en cualquier momento, lo que provocará el cierre de la sesión. Esto se realiza mediante el mensaje BY. Al recibir este mensaje, el participante cierra inmediatamente la sesión con el participante remoto que lo envió y libera todos los recursos asignados a dicha sesión. Este mensaje puede ser enviado por el iniciador de la sesión o por el receptor (el participante invitado). ^{[ 23 ]}

El tiempo de procesamiento de las aplicaciones suele estar estrictamente controlado, ya que las tareas MIDI se ejecutan con frecuencia en tiempo real. En la mayoría de los casos, la latencia proviene directamente de la latencia del hilo, que se puede obtener en un sistema operativo determinado, generalmente de 1 a 2 ms como máximo en Windows y Mac OS. Los sistemas con un núcleo en tiempo real pueden lograr resultados mucho mejores, de hasta 100 microsegundos. Este tiempo puede considerarse constante, independientemente del canal de comunicación (MIDI 1.0, USB, RTP-MIDI, etc.), ya que los hilos de procesamiento operan en un nivel diferente al de los hilos/tareas relacionados con la comunicación.

El tiempo de procesamiento de la pila IP es el más crítico, ya que el proceso de comunicación está bajo el control del sistema operativo. Esto se aplica a cualquier protocolo de comunicación, relacionado o no con IP, puesto 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 confundir los "sockets sin procesar" con el "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 procesar" es un socket que permite a una aplicación enviar cualquier paquete utilizando cualquier protocolo. La aplicación es entonces responsable de construir el telegrama siguiendo las reglas del protocolo, mientras que el "acceso directo" requeriría acceso a nivel de sistema, restringido al núcleo del sistema operativo. Un paquete enviado mediante un socket sin procesar puede sufrir retrasos por parte del sistema operativo si el adaptador de red está siendo utilizado por otra aplicación. Por lo tanto, un paquete IP puede enviarse a la red antes que un paquete relacionado con un socket sin procesar. Técnicamente hablando, el acceso a una tarjeta de red determinada se controla mediante "semáforos". ^{[ 26 ]}

Las pilas IP necesitan correlacionar las direcciones Ethernet (direcciones MAC) con las direcciones IP mediante un protocolo específico llamado ARP. Cuando una aplicación RTP-MIDI desea enviar un paquete a un dispositivo remoto, primero debe localizarlo en la red, ya que Ethernet no entiende conceptos relacionados con IP, para así crear la ruta de transmisión entre los enrutadores/conmutadores. Esto lo realiza automáticamente la pila 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. La pila IP puede entonces enviar el paquete RTP-MIDI. Los siguientes paquetes RTP-MIDI ya no necesitan la secuencia ARP, a menos que el enlace se inactive durante unos minutos, lo que borra la entrada ARP de la tabla de enrutamiento del remitente.

Esta secuencia ARP puede tardar unos segundos, lo que puede generar una latencia perceptible, al menos para el primer paquete RTP-MIDI. Sin embargo, la implementación de Apple resolvió este problema de forma elegante mediante el protocolo de control de sesión. Este protocolo utiliza los mismos puertos que el protocolo RTP-MIDI. La secuencia ARP se ejecuta durante la secuencia de inicio de sesión. Cuando la aplicación RTP-MIDI desea enviar el primer paquete, las tablas de enrutamiento del ordenador ya están inicializadas con las direcciones MAC de destino correctas, lo que evita cualquier latencia para dicho paquete.

Además de la secuencia ARP, la pila IP requiere cálculos para preparar las cabeceras de los paquetes, como la cabecera IP, la cabecera UDP y la cabecera RTP. Con los procesadores modernos, esta preparación es extremadamente rápida y solo tarda unos pocos microsegundos, lo cual es insignificante comparado con la latencia de la propia aplicación. Como se describió anteriormente, una vez preparado, un paquete RTP-MIDI solo puede sufrir retrasos al intentar llegar al adaptador de red si este ya está transmitiendo otro paquete, ya sea que el socket sea IP o "raw". Sin embargo, la latencia introducida a este nivel suele ser extremadamente baja, ya que los hilos del controlador encargados de los adaptadores de red tienen una prioridad muy alta. Además, la mayoría de los adaptadores de red tienen búferes FIFO a nivel de hardware, por lo que los paquetes pueden almacenarse para su transmisión inmediata en el propio adaptador de red sin necesidad de que el hilo del controlador se ejecute primero. Un método para ayudar a mantener la latencia relacionada con la "competencia por el acceso al adaptador" lo más baja posible es reservar el adaptador de red exclusivamente para la comunicación MIDI y utilizar un adaptador de red diferente para otros usos de red, como el intercambio de archivos o la navegación por Internet.

Los distintos componentes utilizados para transmitir paquetes Ethernet entre ordenadores, independientemente de los protocolos empleados, también introducen latencia. Todos los conmutadores de red modernos utilizan la tecnología de "almacenamiento y reenvío", en la que los paquetes se almacenan en el conmutador antes de enviarlos al siguiente. 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 aproximadamente 5,1 microsegundos en ser reenviado por cada conmutador. Una red compleja con 10 conmutadores en una ruta determinada introduce entonces una latencia de 51 microsegundos.

La latencia, sin embargo, está directamente relacionada con la carga de la red, ya que los conmutadores retrasan la transmisión de un paquete hasta que se transmite el anterior. Calcular o medir la latencia real introducida por los componentes de red puede ser una tarea compleja y requiere casos de uso representativos; por ejemplo, medir la latencia entre dos dispositivos conectados al mismo conmutador de red siempre arrojará resultados excelentes. Como se mencionó en la sección anterior, una solución para limitar la latencia introducida por los componentes de red es utilizar redes separadas. Sin embargo, esto es mucho menos crítico para los componentes de red que para los adaptadores de red en las computadoras.

Como se puede observar, la latencia exacta obtenida para un enlace RTP-MIDI depende de muchos parámetros, la mayoría de ellos relacionados con los propios sistemas operativos. Las mediciones realizadas por los distintos proveedores de RTP-MIDI arrojan tiempos de latencia que van desde unos pocos cientos de microsegundos para sistemas embebidos que utilizan sistemas operativos en tiempo real, hasta 3 milisegundos cuando se trata de ordenadores con sistemas operativos de propósito general.

La AES creó en 2010 un grupo de trabajo denominado SC-02-12H ^{[ 27 ]} con el fin de demostrar la capacidad de utilizar cargas útiles RTP en redes IP para aplicaciones de muy baja latencia. La propuesta preliminar publicada por el grupo en mayo de 2013 demuestra que es posible lograr la transmisión RTP para aplicaciones en directo con una latencia de tan solo 125 microsegundos.