Latencia de bucle de audio: lo que el altavoz no muestra

La mayoría de los tests de audio solo comprueban si el sonido se reproduce y si el micrófono capta. Ninguno mide la latencia de ida y vuelta: el tiempo desde que un evento de audio entra por el micrófono hasta que la señal procesada sale por los altavoces. Este único número decide si un músico puede grabar con clic, si una videollamada se siente natural y si el audio espacial de los juegos es preciso. Un sistema puede pasar todas las comprobaciones de reproducción y aun así tener una latencia catastrófica, porque funcionalidad y sincronía son ejes separados. Esta guía explica cómo medir la latencia de ida y vuelta, qué significan los números y cómo reducirla.

Cada comprobación de hardware comienza igual. Auriculares nuevos, test de tono, confirmar que sale sonido, seguir adelante. Micrófono, hablar, ver saltar el medidor, seguir adelante. Estas dos pruebas confirman que la ruta de salida y la ruta de entrada funcionan. Ninguna mide la pregunta que realmente decide si tu equipo de audio puede con el trabajo real: ¿cuánto tarda un sonido en ir del micrófono a través del ordenador y salir por los altavoces?

Ese número es la latencia de ida y vuelta, y decide en silencio qué tareas puede manejar honestamente tu sistema:

• Grabar música. Tocar con clic o acompañamiento exige que tu propio sonido vuelva a tus oídos casi de inmediato. Por encima de unos cuarenta milisegundos de ida y vuelta, te desvías del ritmo, cada toma suena pesada y ningún ensayo lo arregla. Las interfaces de audio que comparten un controlador USB con otros dispositivos también pueden sufrir de contención de ancho de banda USB, lo que añade picos de latencia además de los retrasos del búfer.
• Mantener conversaciones. Las videollamadas solo se sienten naturales cuando la cadena de audio está ajustada. Un retardo excesivo produce eco, habla solapada y el ritmo entrecortado de una llamada por satélite.
• Jugar con audio espacial. El sonido posicional solo funciona si el audio llega sincronizado con lo que se ve. Cuando la ruta de audio va por detrás de la pantalla, los pasos y disparos se despegan de la acción en pantalla.

Tu test de altavoces y tu test de micrófono responden «¿funciona?». El test de latencia de bucle responde «¿qué tan rápido?». Esta página explica qué es la latencia de ida y vuelta, de dónde viene y cómo reducirla. Los números de aquí provienen de la experiencia general en muchas configuraciones de hardware y software: un setup ASIO real en un Focusrite Scarlett 2i2 da valores distintos que un códec Realtek integrado en Windows 11. Tus resultados varían según la interfaz, el controlador y la configuración del buffer.

El test de altavoz no mide latencia

Un test de altavoz reproduce un tono, un barrido o una canción por la ruta de salida y confirma que se produce sonido. Es una prueba de funcionalidad con resultado de aprobado o reprobado: cable conectado, controlador cargado, volumen no silenciado, conversor digital-analógico vivo. Si oyes el tono, la ruta de salida funciona. Nada más dice el test.

Un test de micrófono hace lo mismo para la dirección de entrada. Captura lo que dices, muestra un nivel y confirma que el micrófono, el preamplificador y el conversor analógico-digital funcionan. También aquí el resultado es aprobado o reprobado.

La medición de latencia es otro tipo de prueba. En lugar de preguntar si una señal puede cruzar una ruta, pregunta cuánto tarda el cruce. El procedimiento es simple: envía una señal conocida — un impulso, un clic, una ráfaga corta — por la salida, captúrala en la entrada y calcula la diferencia de tiempo entre enviar y recibir. Esa diferencia es la latencia de ida y vuelta, en milisegundos.

La distinción importa porque las dos mediciones son independientes. Un sistema puede pasar todas las comprobaciones de reproducción y aun así mostrar una latencia catastrófica. Los altavoces Bluetooth son el ejemplo clásico: reproducen un tono con fidelidad, el test de altavoz informa éxito, mientras el códec inalámbrico añade de cien a ciento ochenta milisegundos de retardo que ningún test de reproducción detecta jamás. Un tono que llega ciento cincuenta milisegundos tarde se reproduce técnicamente.

Por eso el supuesto habitual — «mis altavoces suenan bien, así que mi sistema de audio es bueno» — se desmorona en todo lo sensible al tiempo. Funcionalidad y sincronía son ejes separados. Antes de confiar en tu equipo para grabación, llamadas o juegos, necesitas el número que las pruebas de reproducción estructuralmente no pueden dar.

Observa los buffers llenarse

La latencia de ida y vuelta no es un único retardo. Es la suma de los retardos en cada etapa entre la cápsula del micrófono y la membrana del altavoz. Entender el camino te muestra dónde están escondidos tus milisegundos:

1. Buffer de entrada. El conversor analógico-digital muestrea continuamente, pero el sistema operativo entrega el audio en bloques. El controlador espera a que el buffer esté lleno antes de pasar los datos a la aplicación. A 48 kHz, un buffer de 128 muestras tarda 2,7 milisegundos en llenarse: tanto espera tu audio antes de que alguien lo procese. La mayoría de los sistemas mantienen dos o tres buffers en circulación. Calcula unos cinco a ocho milisegundos antes de que tu aplicación vea la primera muestra.
2. Conversión analógico-digital. El conversor necesita tiempo para muestrear, cuantificar y sincronizar. En hardware de consumo contribuye típicamente de uno a tres milisegundos; las interfaces dedicadas lo hacen mejor.
3. Programación del sistema operativo. El motor de audio despierta tu aplicación por temporizador, y despertarse está sujeto a la programación normal de hilos. En modo compartido, el sistema operativo también mezcla tu flujo con cualquier otra fuente de audio del sistema, lo que añade una pasada de procesamiento propia. Esta etapa contribuye desde unos milisegundos hasta veinte o más según la plataforma y la carga. Aquí es donde Linux con PipeWire puede superar a Windows — y donde un escritorio ruidoso puede disparar tu latencia silenciosamente.
4. Procesamiento de la aplicación. El software del lado receptor — una DAW, una cadena de efectos, un grafo de audio del navegador — procesa el bloque antes de pasarlo. Pequeño, pero parte de la suma.
5. Conversión digital-analógica. El espejo de la etapa dos, otros uno a tres milisegundos mientras la señal procesada se convierte en voltaje analógico.
6. Buffer de salida. Las muestras procesadas esperan en el buffer de salida hasta que el conversor está listo para reproducirlas: la matemática de buffers del lado de entrada se repite. En configuraciones típicas se añaden otros cinco a ocho milisegundos.

Sumando las etapas, la latencia de ida y vuelta en modo compartido en un ordenador normal suele estar entre treinta y sesenta milisegundos — los valores siguientes son ejemplos ilustrativos de hardware concreto, no especificaciones universales. En pruebas informales en un portátil estándar con Windows 11 con códec Realtek ALC897 integrado a 128 muestras de buffer, se observaron mediciones en modo compartido cerca del extremo superior de ese rango. Con una Behringer U-Phoria UM2 vía ASIO4ALL en el mismo hardware, la medición bajó a unos quince milisegundos. Son observaciones de una sola máquina sin condiciones controladas; sirven como indicadores de la brecha típica entre el modo compartido y la ruta ASIO, no como valores garantizados para tu hardware. Ningún controlador elimina el tiempo de conversión, pero la sobrecarga de buffers y programación que domina la suma se reduce drásticamente.

Un número, dos definiciones

El software de audio rara vez informa un único número. Abre los ajustes de una aplicación profesional y verás típicamente dos: latencia de entrada, el tiempo del micrófono a la aplicación, y latencia de salida, el tiempo de la aplicación a los altavoces. Controladores como ASIO informan ambos por separado, y el material de marketing cita a menudo el número que queda mejor.

La latencia de ida y vuelta es la suma de ambos más el propio tiempo de procesamiento de la aplicación. Un sistema que informa veinte milisegundos por lado tiene una ida y vuelta de unos cuarenta. Un usuario que lee «20 ms de latencia» y asume que ese es el retardo audible se equivoca por un factor de dos — y el error es común porque los valores por lado están en las hojas de especificaciones.

La distinción importa porque siempre percibes la ida y vuelta. Cuando un músico monitoriza su propia voz o instrumento, el sonido debe salir del micrófono, recorrer el sistema y volver a los auriculares antes de oírlo. Ese es el camino completo. Un valor por lado describe solo la mitad del viaje.

Por consistencia, todos los números de aquí se refieren a la latencia de ida y vuelta. Cuando compares tu medición con una especificación de producto o un benchmark, verifica siempre que ambos números describan el mismo tipo de viaje. Comparar una medición de ida y vuelta con una especificación por lado hace que tu sistema parezca el doble de lento de lo que es.

El sistema operativo decide antes que tú

El mismo micrófono, los mismos altavoces, el mismo cable dan latencias completamente distintas en diferentes sistemas operativos, porque cada plataforma enruta el audio por una pila de software distinta. La pila decide cuánta sobrecarga de buffers y programación se añade al inevitable tiempo de conversión.

Windows: modo compartido, modo exclusivo y ASIO

Windows ofrece tres caminos al hardware, cada uno con un perfil de latencia distinto:

• El modo compartido WASAPI es la ruta predeterminada de toda aplicación salvo que pida otra cosa (Microsoft Learn: WASAPI Shared Mode, 2023). Todo el audio se mezcla y se entrega con buffering conservador. La latencia de ida y vuelta habitualmente observada en sistemas típicos está entre treinta y dos y sesenta y cuatro milisegundos, según el tamaño del buffer y la carga — rangos habituales de experiencia, no valores garantizados. Web Audio, WebRTC y la reproducción multimedia toman caminos ligeramente distintos, pero todos empiezan en este mezclador común.
• El modo exclusivo WASAPI o ASIO evita el mezclador y da a una aplicación acceso directo al dispositivo, con la latencia cayendo típicamente a unos diez milisegundos en hardware típico (Microsoft Learn: WASAPI Exclusive Mode, 2023). Disponible para aplicaciones nativas que lo soliciten; los navegadores no pueden.
• ASIO es un protocolo de controlador que evita por completo la pila de audio de Windows y habla directamente con el hardware de la interfaz (Steinberg: ASIO Host and Driver Guide v2.3, 2021). Con una interfaz capaz, ASIO alcanza habitualmente de ocho a quince milisegundos, dependiendo los números exactos de la interfaz, la versión del controlador y la configuración del buffer. Los navegadores no pueden usarlo.

macOS: Core Audio

El framework Core Audio de Apple está bien optimizado, y las aplicaciones nativas alcanzan rutinariamente de ocho a veinte milisegundos de ida y vuelta con configuraciones de buffer razonables. El camino compartido es eficiente, por lo que incluso la latencia medida en el navegador suele ser mejor en macOS que en Windows. Sigue siendo mayor que el mínimo nativo porque el navegador no puede reclamar acceso exclusivo al dispositivo ni ajustar el buffer a sus necesidades.

Linux: ALSA, PulseAudio y PipeWire

La latencia en Linux es un objetivo móvil. ALSA, la interfaz de controlador de bajo nivel, es rápida pero específica de la aplicación. PulseAudio añadió históricamente una sobrecarga de buffers perceptible. PipeWire, el sucesor moderno, está diseñado para audio de baja latencia y puede igualar o superar a las otras plataformas cuando está configurado correctamente — los resultados varían mucho según la distribución y la configuración.

En la mayoría de las configuraciones, el navegador está limitado al camino compartido. No puede solicitar modos exclusivos, cargar controladores ASIO ni aumentar la prioridad de su hilo de audio. La latencia del audio del navegador suele estar así cerca del límite superior del modo compartido de tu plataforma — lo mejor que el camino cooperativo puede ofrecer en configuraciones estándar — mientras que el software nativo profesional está construido para romper ese límite cuando el hardware y los controladores lo permiten.

Qué significan realmente 60 milisegundos

Un número bruto en milisegundos no dice nada hasta que lo mapeas contra lo que quieres hacer. Los umbrales siguientes son orientación general, no estándares de certificación profesional; la idoneidad real depende de tu tarea, tu configuración de monitoreo y tu entorno auditivo. Cuatro zonas cubren el rango práctico:

• Por debajo de 20 ms — excelente. La producción musical profesional está cómoda aquí. Los músicos pueden grabar con clic, monitorizarse con efectos y tocar a tiempo porque el camino de retorno es prácticamente instantáneo. El audio espacial en juegos se mantiene sincronizado con la imagen.
• 20–60 ms — aceptable para la mayoría de los usos. Podcasts, videollamadas, juegos generales y grabación ocasional funcionan bien. El seguimiento musical de precisión sufre cerca del extremo superior: los intérpretes sienten que su propio feedback de sonido va ligeramente por detrás, y el trabajo de precisión se vuelve notablemente más difícil por encima de unos cuarenta milisegundos.
• 60–120 ms — problemático para producción, aceptable para uso casual. Karaoke, chat de voz y escucha están bien. Grabar con acompañamiento se vuelve realmente difícil, y en juegos el sonido empieza a despegarse de la acción, socavando las pistas espaciales de las que depende el audio espacial.
• Por encima de 120 ms — malo. El trabajo sensible al tiempo es prácticamente imposible. Las llamadas desarrollan eco audible, las actuaciones se sienten desconectadas y el audio espacial suena mal incluso en uso casual. Esta zona es el hogar natural del audio Bluetooth y de los sistemas en modo compartido mal configurados.

Los límites de zona son cuestión de criterio, pero la forma es fiable: la producción necesita los números más bajos, las conversaciones toleran más y la escucha casual tolera más todavía. Tu medición de ida y vuelta coloca tu sistema en exactamente una zona, y esa colocación te dice qué usos previstos se sentirán bien y cuáles trabajarán contra ti. Guarda el número — es tu punto de referencia para cualquier optimización de la siguiente sección.

Tres palancas: frecuencia, buffer, controlador

Tres controles deciden dónde se acumula la latencia en tu camino, y no tienen la misma potencia. Frecuencia de muestreo fija el rendimiento de la tubería — cuántas veces por segundo se mide el audio — más que el retardo directamente. Interactúa con el tiempo del buffer porque un buffer se mide en muestras: 128 muestras tardan 2,9 milisegundos a 44,1 kHz, pero solo 1,3 milisegundos a 96 kHz, así que el mismo tamaño de buffer representa duraciones distintas a diferentes frecuencias. El truco: una frecuencia más alta exige más procesamiento por segundo, lo que a menudo te obliga a subir el buffer para mantener la estabilidad, anulando la ganancia. Perseguir 96 o 192 kHz suele forzar un buffer más grande para mantener el flujo estable, lo que puede anular la ventaja teórica o hacer todo más lento. Trata la frecuencia como un ajuste de flujo de trabajo, típicamente 48 kHz, no como el control principal de la latencia. 48 kHz se convirtió en el estándar de facto para audio sincronizado con vídeo porque mapea limpiamente a las tasas de fotogramas de vídeo de 24, 25 y 30 fps — por eso la tubería profesional de audio y vídeo empieza ahí. Tamaño del buffer es la palanca principal de la latencia. Determina cuánto audio se acumula antes de procesarse y aparece dos veces en la ida y vuelta — una en el lado de entrada y otra en el de salida. Reducir el buffer a la mitad reduce a la mitad esa parte del retardo, pero también el tiempo que tiene el sistema para entregar cada bloque, lo que aumenta el riesgo de subdesbordamientos: clics, chasquidos y cortes. La matriz práctica a 48 kHz es así:

• 64 muestras — unos 8–12 ms de ida y vuelta en hardware capaz con ASIO o modo exclusivo. Las interfaces económicas suelen producir clics a este tamaño.
• 128 muestras — unos 12–20 ms. Un punto dulce habitual de ASIO para producción.
• 256 muestras — unos 20–35 ms. A menudo el tamaño estable más pequeño en modo compartido.
• 512 muestras — unos 35–60 ms. Seguro, pero perceptiblemente lento.
• 1024 muestras — unos 60–100 ms. Solo para streaming o reproducción donde la latencia no importa. El controlador fija el suelo. ASIO y el modo exclusivo permiten tamaños de buffer de 32 a 128 muestras; el modo compartido empieza más alto; los códecs Bluetooth añaden cien milisegundos o más antes de que los buffers siquiera cuenten. Ningún ajuste de buffer supera el mínimo del controlador — por eso el controlador es la primera palanca, no la última.

El navegador no es una DAW

Un navegador puede estimar la latencia de ida y vuelta con la Web Audio API (MDN: Web Audio API, 2024), que programa un impulso por la salida y captura la señal entrante en la entrada del micrófono. Una medición típica de bucle Web Audio en un portátil en modo compartido informa habitualmente 55–70 ms — un múltiplo del valor ASIO — una brecha que ilustra la contribución del camino compartido del navegador. El tiempo medido incluye el trayecto acústico por el aire, los transductores de altavoz y micrófono, la supresión de eco de la sala y toda la pila de audio del sistema. Esto se llama retardo acústico de ida y vuelta, y es el número relevante para llamadas basadas en navegador, karaoke y juegos en el navegador, pero no es lo mismo que la latencia de ida y vuelta ASIO que mide el software de audio profesional. Esta medición requiere un trayecto acústico real entre altavoz y micrófono; el control automático de ganancia, la reducción de ruido y la cancelación de eco pueden alterar la forma del impulso, mientras que la distancia al micrófono, las reflexiones de la sala y los ajustes de volumen afectan al resultado. Lo que el navegador no puede hacer es alcanzar el mejor caso del hardware. Debe usar el camino de audio compartido del sistema operativo, no puede reclamar acceso exclusivo al dispositivo, no puede cargar controladores ASIO ni controlar su tamaño de buffer de audio ni la prioridad de su hilo. La medición refleja por tanto el límite superior del modo compartido de tu plataforma, no el mínimo real del hardware. Ese límite es exactamente el número correcto para el trabajo basado en navegador. Las llamadas web, los juegos de navegador, el karaoke web y todo lo demás en una pestaña comparten todos el camino de audio del navegador a nivel del sistema operativo, con Web Audio, WebRTC y la reproducción multimedia diferenciándose en el detalle. Si el número medido en el navegador es bueno, cada caso de uso del navegador se sentirá bien. Si es malo, el software nativo quizá pueda salvarte — pero el navegador será típicamente más lento que el software nativo en el mismo hardware y configuración.

Seis formas de reducir la latencia

Aborda los problemas en orden de impacto y detente cuando tu número aterrice en una zona con la que puedas vivir:

1. Arregla el modo del controlador primero. Instala el controlador ASIO para tu interfaz de audio en Windows o cambia al modo exclusivo WASAPI. Es la palanca individual más grande y es gratis.
2. Reduce el tamaño del buffer. Baja de 512 a 256 a 128 a 64 muestras, probando cada ajuste hasta que aparezcan clics o chasquidos. Luego vuelve un paso al buffer más grande que siga limpio.
3. Comprueba la frecuencia de muestreo. Usa 48 kHz para música y edición de vídeo. Perseguir 96 o 192 kHz suele forzar un buffer más grande y acaba siendo más lento.
4. Cierra aplicaciones que compiten. El streaming, la grabación y las pestañas del navegador llenas roban tiempo de CPU al hilo de audio y causan subdesbordamientos con buffers pequeños.
5. Considera una interfaz de audio. El hardware dedicado trae mejores conversores, controladores ASIO reales y tamaños de buffer que el audio integrado no alcanza.
6. Prefiere conexiones con cable. Para todo lo sensible al tiempo, los auriculares con cable superan al Bluetooth por cien milisegundos o más, independientemente de todos los demás ajustes. Cada paso se combina. Cambiar de modo compartido a 512 muestras a ASIO a 128 muestras suele mover un sistema de cincuenta milisegundos a menos de veinte — la diferencia entre inutilizable y profesional.

Conclusión

Un test de reproducción confirma que tus altavoces funcionan. Un test de bucle confirma que funcionan a tiempo — y son preguntas distintas con respuestas distintas. Ejecuta el test de altavoces para validar la ruta de salida y el test de micrófono para la ruta de entrada. Ten en cuenta: este sitio no ofrece actualmente una herramienta dedicada de medición de latencia de bucle; el enfoque de la Web Audio API descrito requiere una implementación separada o configuración desde la consola del navegador. Úsalo para conocer el retardo acústico de ida y vuelta que decide si la grabación, la conversación y el audio espacial se sienten naturales en tu máquina.

Mide una vez y guarda el resultado. Por debajo de veinte milisegundos significa sincronía profesional. De veinte a sesenta cubre la mayor parte del trabajo cotidiano. Por encima de ciento veinte, cada tarea sensible al tiempo luchará contra ti, y la solución suele empezar por el controlador, no por el hardware. Si nunca has medido el número, estás adivinando en cada tarea de audio que depende de la sincronía.