Latencia de audio: medición del retraso de micrófono y altavoz

Publicado el 2026-04-13 8 min de lectura

Resumen (TL;DR)

Grabar una toma de guitarra acústica a través de mi vieja interfaz USB solía aterrizar en torno a 35 ms de latencia de ida y vuelta en los auriculares de monitoreo: suficiente para que cualquier frase rítmica se sintiera como caminar por arena mojada. Cambiar a un MOTU M2 con un driver ASIO correctamente configurado bajó eso al rango de 5 ms, y la misma toma pasó inmediatamente de “impracticable” a “natural”. El fenómeno no es un bug; es una realidad física medible llamada latencia de ida y vuelta (RTT). La RTT es la suma de cinco etapas: la señal del micrófono llenando un buffer de entrada, el software anfitrión procesando ese buffer, la señal procesada llenando un buffer de salida, el DAC convirtiéndola de vuelta a analógico, y el sonido final propagándose por el aire hasta tu oído (aproximadamente 1 ms por cada 34 cm). La parte ajustable vive mayoritariamente en el tamaño del buffer y el modelo de driver; ASIO, WASAPI Exclusive, Core Audio y JACK tienen cada uno mínimos típicos y límites de plataforma distintos. Esta guía explica cómo se suman esos componentes, por qué el compromiso tasa de muestreo/tamaño de buffer no es tan intuitivo como parece, y cómo medir la latencia real de extremo a extremo con un cable de loopback, un tono de prueba y un editor de audio, en vez de confiar en las afirmaciones de marketing de “1 ms”.

Antecedentes y conceptos

Entre un micrófono y un altavoz, un ordenador hace más de lo que la mayoría imagina. Un ADC muestrea la señal del micrófono a una tasa de muestreo elegida (comúnmente 48 kHz) y recoge las muestras en un buffer de entrada. Una vez que el buffer se llena —digamos, 128 muestras a 48 kHz, unos 2,67 ms de audio— el driver se lo entrega a la aplicación.

La aplicación (un DAW, un cliente de comunicación, un navegador) procesa el buffer, aplica efectos o codifica para transmisión por red, y escribe el resultado en un buffer de salida. Cuando el buffer de salida se llena, el DAC lo convierte en una señal analógica que sale por la salida de auriculares o de línea.

Luego está el mundo fuera del ordenador. El sonido viaja a aproximadamente 343 m/s a temperatura ambiente, lo que significa aproximadamente 1 ms por 34 cm. Los auriculares casi no añaden nada de esto; un altavoz de monitoreo al otro lado de la habitación añade unos pocos milisegundos encima de todo lo demás. Un par de monitores a 1,7 m de distancia de escucha contribuye aproximadamente 5 ms de pura propagación: invisible en la hoja de especificaciones pero presente en tus oídos.

Así que latencia de ida y vuelta = buffer de entrada + procesamiento + buffer de salida + DAC + propagación. Con la tasa de muestreo fija, buffers más pequeños reducen la latencia pero elevan la carga de CPU, porque el hilo de audio tiene que despertar más a menudo. Si el tamaño del buffer se especifica en muestras en vez de en tiempo, subir la tasa de muestreo acorta el mismo buffer de “N muestras” en milisegundos, pero las tasas de muestreo más altas también elevan el throughput y estresan los drivers de forma diferente, así que no es una forma gratis de reducir el retraso.

El modelo de driver se sitúa entre la aplicación y el hardware de audio y tiene sus propias características de latencia. En Windows, los caminos clásicos MME y DirectSound añaden buffering sustancial por compatibilidad; WASAPI Shared es más bajo pero aún mediado por el mixer; WASAPI Exclusive y ASIO saltan mucho de ese overhead. ASIO4ALL es un wrapper ASIO genérico que ayuda cuando no hay driver ASIO de fabricante disponible, pero no es sustituto de un verdadero driver ASIO de fabricante: la RTT medida en la misma Focusrite Scarlett 2i2 3rd Gen típicamente aterriza significativamente más baja con el driver oficial que con ASIO4ALL encima de WASAPI. En macOS, Core Audio ya está afinado para baja latencia como valor por defecto de plataforma. En Linux, los stacks JACK y PipeWire pueden alcanzar latencia muy baja una vez configurados, pero requieren programación de kernel en tiempo real para ser consistentes.

Comparación y datos

CriterioASIOWASAPI ExclusiveCore AudioJACK
PlataformaMayoritariamente WindowsSolo WindowsSolo macOSCentrado en Linux, existen ports multiplataforma
Latencia más baja típicaMuy baja, comúnmente en el rango de pocos milisegundosBaja cuando se usa en modo exclusivoBaja y estable en el rango de pocos milisegundosMuy baja bien configurada, con más complejidad de setup
Modelo de comparticiónDependiente del driver (típicamente exclusivo)Compartido o exclusivo; exclusivo es menor latenciaModo compartido bien afinado es el valor por defectoBasado en matriz de enrutamiento, multi-cliente

Los números exactos en milisegundos dependen fuertemente del hardware, driver y versión del SO, así que en vez de confiar en la línea de “1 ms de latencia” en una página de producto, mide tu propio sistema una vez para establecer una línea base. Interfaces asequibles como el MOTU M2 y la Focusrite Scarlett 2i2 3rd Gen pueden alcanzar latencia de ida y vuelta de un dígito en milisegundos emparejadas con un driver ASIO o Core Audio adecuado, pero el mismo hardware sobre un camino WASAPI de modo compartido en Windows o envuelto por ASIO4ALL típicamente rinde notablemente peor. Tu RTT real es el resultado conjunto de tres variables —interfaz, driver, tamaño de buffer— y asumir cualquiera de ellas aisladamente rara vez es preciso.

Escenarios reales

Escenario 1 — Actuación en vivo y monitoreo in-ear. Un cantante escuchando su propia voz por monitores in-ear sentirá un retraso de incluso unos pocos milisegundos como un problema de tempo. El objetivo aquí es RTT por debajo de 10 ms, lo que normalmente requiere tamaños de buffer bajos, un driver de baja latencia (ASIO en Windows, Core Audio en macOS) y —donde sea posible— el monitoreo directo por hardware de la interfaz, que salta el camino de software por completo para la señal de monitoreo. La perilla de monitor del panel frontal del MOTU M2 resuelve esto en un giro, y el interruptor “Direct” de la Scarlett 2i2 3rd Gen hace lo mismo.

Escenario 2 — Grabación de podcast. A menos que varios hosts se monitoreen entre sí en vivo, 50 a 100 ms de RTT suelen estar bien durante la sesión de grabación. La postproducción alinea las pistas de todos modos, y un buffer más grande mejora el margen de CPU, lo que a su vez reduce el riesgo de cortes en una grabación larga. Optimizar aquí para la menor latencia a menudo perjudica en vez de ayudar.

Escenario 3 — Videoconferencia. Las llamadas WebRTC basadas en navegador típicamente operan en un rango de aproximadamente 100 a 200 ms de extremo a extremo por la red, codificación y buffer de jitter encima de la latencia local de audio. Eso se sitúa cerca del límite donde el intercambio conversacional se siente natural; añadir auriculares Bluetooth con un códec antiguo puede empujarlo más allá de ese umbral, lo que es por lo que los participantes empiezan a hablar unos encima de otros.

Escenario 4 — Colaboración musical en línea. Intentar tocar música sincronizada con un socio remoto por internet es el extremo implacable de este espectro. Más allá de aproximadamente 25 a 30 ms de retraso unidireccional, mantener un tempo estable se vuelve difícil, y el internet típico de casa más el software de audio de consumo regularmente aterriza bien por encima. Plataformas dedicadas de colaboración de baja latencia existen específicamente para raspar cada milisegundo posible, y aun así generalmente requieren ethernet por cable, afinación cuidadosa del driver y proximidad física en el backbone de internet. Reconocer que un stack de videollamada de consumo es la herramienta equivocada para este trabajo suele ser el primer paso.

Errores comunes

“El audio Bluetooth siempre es de alta latencia.” El streaming clásico A2DP sí añade retraso significativo. Pero los códecs más nuevos LE Audio (LC3) y aptX Low Latency lo bajan considerablemente, lo que es un cambio de categoría en rendimiento sentido. Dos auriculares que ambos dicen “Bluetooth” pueden diferir dramáticamente según el códec que ellos y la fuente soporten. Para monitorear una sesión de grabación, sin embargo, el cableado sigue siendo la elección más segura.

“El audio USB siempre es mejor que el analógico.” El audio USB supera al analógico on-board cuando la interfaz tiene un buen DAC, preamps limpios y drivers estables. Los DAC USB baratos pueden en realidad ser peores por jitter, ruido y problemas de driver. “USB” por sí solo no implica calidad; la elección de componentes sí.

“Una tasa de muestreo de 192 kHz es menor latencia.” Contraintuitivo pero importante: si el buffer se especifica en tiempo (ms), subir la tasa de muestreo no reduce la latencia física. Solo cuando el buffer se fija en muestras una tasa de muestreo más alta significa menos milisegundos por buffer, a costa de más datos por segundo, más CPU y más estrés de driver. La baja latencia viene primariamente de buffers más pequeños y un mejor modelo de driver, no de una tasa de muestreo más alta.

“El monitoreo por software y el monitoreo por hardware se sienten igual.” No lo hacen. El monitoreo por software enruta la señal del micrófono por el camino del DAW —buffer de entrada, procesamiento de plugins, buffer de salida— y acumula RTT a lo largo del camino. El monitoreo por hardware en una interfaz de audio envía la señal del micro directamente a la salida de auriculares dentro de la interfaz, saltando el ordenador por completo para el camino de monitoreo. El intérprete se oye a sí mismo con latencia efectivamente cero, mientras el ordenador aún graba la pista para producción posterior. Muchas configuraciones mezclan los dos y culpan al tamaño del buffer de un retraso que el monitoreo por hardware eliminaría con un solo cambio de ajuste.

Lista de verificación

  1. Define el objetivo de RTT para tu caso de uso. Actuación en vivo: por debajo de 10 ms; grabación: 50 a 100 ms está bien; conferencia: 100 a 200 ms es realista.
  2. Elige el modelo de driver. En Windows, ASIO o WASAPI Exclusive; en macOS, Core Audio; en Linux, JACK o PipeWire. Los stacks por defecto de modo compartido (MME, WASAPI compartido por defecto) suelen tener la latencia más alta.
  3. Baja el tamaño del buffer incrementalmente hasta justo antes de que empiecen los cortes. Ese es el piso práctico de tu sistema.
  4. Haz una medición de loopback. Conecta la salida de la interfaz a su entrada con un cable, reproduce un tono de prueba y lee el retraso desde la forma de onda capturada en un editor de audio.
  5. Empareja la tasa de muestreo con la necesidad del proyecto. 48 kHz es típico para trabajo de video; 44,1/48 kHz para música. Sube por encima solo con una razón específica.
  6. Usa el camino de monitoreo sabiamente. Donde sea posible, usa la función de monitoreo directo de la interfaz para los oídos del intérprete, lo que hace la RTT de monitoreo efectivamente cero aunque el camino de grabación tenga varios milisegundos de latencia.

Herramienta relacionada

La herramienta de latencia de audio de Patrache Studio estima la latencia de ida y vuelta en el navegador, lo que facilita obtener una lectura aproximada sin comprar hardware. Para el cuadro más amplio de “latencia de entrada” en un contexto gaming, mira NKRO de teclado y latencia de entrada para gaming. Si estás afinando una configuración de videollamada donde el retraso de audio afecta al sync A/V, empareja esta guía con Diagnóstico de webcam: tasa de fotogramas, resolución e iluminación para entender la latencia del lado de la cámara que se apila encima del audio.

Referencias

Herramienta relacionada

diagno.patrache.studio/audio/latency/