Compensación de latencia de ASIO4ALL: ajusta búfer y frecuencia

Qué controla la compensación de latencia de ASIO4ALL

ASIO4ALL enlaza un host ASIO con endpoints de audio WDM de Windows. El host solicita un búfer y el dispositivo, junto con su controlador, determina cómo se procesa. La compensación indica al host que una ruta de entrada o salida añade retraso. Es un dato de alineación, no un sustituto de un controlador estable, un cable USB correcto o una monitorización bien conectada.

Antes de cambiar ajustes separa tres medidas. El búfer indica cuántas muestras procesa el host en cada bloque; la frecuencia indica cuántas muestras pasan por segundo; la latencia de ida y vuelta también incluye convertidores, dispositivo, controlador, plugins y monitorización. Un búfer pequeño puede reducir una parte del retraso mientras Bluetooth, un hub USB saturado o el dispositivo nativo dominan el resultado.

Elige un búfer estable antes de perseguir menos latencia

Usa un proyecto corto y repetible con un instrumento o un archivo de audio. Selecciona exactamente los auriculares, altavoces, salida de interfaz o micrófono que usarás. 512 muestras es un punto de partida conservador. Si reproduce limpio, prueba 256 y después 128. El valor correcto es el más bajo que resiste tu trabajo real, no el más bajo que sobrevive cuando el ordenador está inactivo.

La referencia oficial de ASIO4ALL explica que un búfer menor suele reducir la latencia, pero que los chasquidos indican que la ruta necesita más tiempo. Un navegador, una videollamada, un cable virtual o una segunda DAW puede tomar el mismo endpoint WDM. Cierra esas aplicaciones durante la prueba para no confundir un conflicto de propietario con un límite del búfer.

1. Anota la base

   Escribe host, dispositivo, frecuencia, búfer, modo de monitorización y endpoints activos antes de tocar nada.

2. Abre el panel

   Elige ASIO4ALL v2 en la DAW y abre su panel desde la misma pantalla de audio.

3. Activa una ruta

   Enciende una salida conocida y la entrada necesaria. Deja HDMI, Bluetooth y dispositivos sin usar apagados.

4. Prueba un valor moderado

   Reproduce un proyecto sencillo a 512 o 256 muestras durante varios minutos; escucha clics y observa el medidor del host.

5. Baja paso a paso

   Prueba el siguiente valor solo cuando el anterior sea limpio; vuelve al último estable al oír un corte.

Iguala la frecuencia y estima el retraso real

La duración aproximada de un búfer es muestras divididas por muestras por segundo. A 48 kHz, 256 muestras son unos 5,3 ms; a 44,1 kHz son unos 5,8 ms. El host suele tener una parte de entrada y otra de salida, y el hardware añade tiempo, por lo que la ida y vuelta es mayor. Usa el cálculo para comparar ajustes, no para prometer una medición de micrófono a altavoz.

La documentación oficial recuerda que la latencia total no es lineal en todos los rangos. 512 muestras es un valor seguro y las zonas inferiores a 10 ms o 4 ms son referencias, no objetivos universales. Si el endpoint se vuelve inestable, una ruta limpia a 256 o 512 muestras es más útil que una cifra baja sin audio.

Usa con cuidado los controles de compensación

Latency Compensation In y Out parecen controles de rendimiento, pero comunican al host cuánto retraso debe contabilizar. El manual de ASIO4ALL para FL Studio recomienda dejarlos por defecto salvo que se haya medido la ruta con un cable de loopback. Un número mayor o menor no hace que el audio llegue antes; cambia la información temporal que recibe el host.

Si tienes una medición repetible, cambia un valor, reinicia el host si no actualiza el dispositivo y compara el desplazamiento grabado con la medición. Anota endpoint, frecuencia, búfer y versión del host. No copies un valor de un foro para otra interfaz ni edites el registro para forzar un búfer menor como primer arreglo.

• Deja In y Out en el valor inicial para reproducción y grabación normales.
• Mide una ruta de loopback real antes de escribir una compensación personalizada.
• Cambia un control cada vez y conserva la misma frecuencia y búfer para comparar.
• Reinicia el host cuando el valor mostrado no siga al deslizador o quede guardado en caché.
• Trata las ediciones de registro y los límites no documentados como experimentos avanzados con copia de seguridad.

Corrige chasquidos, silencio, cortes y deriva

Los chasquidos suelen indicar que el bloque no termina a tiempo. Sube el búfer un paso, cierra el audio del navegador y de las reuniones, desactiva endpoints extra y repite el mismo proyecto. Si desaparece, registra el valor estable y añade dispositivos uno por uno. No bajes la frecuencia ni la compensación para ocultar un underrun.

Un medidor silencioso no es un problema de latencia. Comprueba que el host usa ASIO4ALL v2, que el endpoint WDM hijo está encendido, que la pista o el master apuntan a él y que Windows no lo ha silenciado. Un estado rojo puede indicar que otra aplicación posee el dispositivo o que la frecuencia del proyecto no coincide.

La deriva o una voz duplicada suele venir de dos rutas de monitorización o de relojes distintos. Usa una sola monitorización, prefiere una salida con cable durante la prueba y evita combinar relojes sin necesidad. Si tu interfaz tiene un controlador ASIO actual, suele ser una primera opción más clara que un puente genérico.

Lista de comprobación de compensación de latencia de ASIO4ALL

Una buena configuración de latencia es una ruta documentada: registra host, endpoint, frecuencia, búfer, monitorización y salida física, y conserva el último valor limpio.

• El host usa ASIO4ALL v2 y el endpoint WDM necesario está activo.
• Una entrada y una salida conocidas pasan una prueba antes de añadir dispositivos.
• La frecuencia es compatible con el host y el endpoint.
• El búfer se probó de forma descendente y el último valor limpio está anotado.
• Latency Compensation In/Out queda por defecto salvo medición de loopback.
• Chasquidos, silencio, monitorización doble y deriva se diagnostican por separado.
• Se prefiere un controlador ASIO nativo actual cuando expone el hardware necesario.