Ajustes de latencia WASAPI: guía completa para audio de baja latencia

Inicio » Tutoriales » Ajustes de latencia WASAPI: guía completa para audio de baja latencia

Si trabajas con audio en tiempo real en Windows, tarde o temprano te topas con la pregunta: ¿ASIO o WASAPI? Muchos usuarios llevan meses grabando con ASIO en su DAW porque ofrece latencias de 4-5 ms, pero se encuentran con una pega importante: es un sistema muy cerrado, que acapara el dispositivo y complica usar a la vez el sonido del navegador, juegos o aplicaciones de comunicación.

Ahí es donde entra WASAPI. Es el modelo de audio nativo de Windows y, bien ajustado, puede ofrecer una latencia muy baja en modo compartido, permitiendo simultanear el audio del sistema y del DAW. El problema es que, si no se configura bien o si el hardware/driver no acompaña, puedes pasar de unos fluidos 4,6 ms con ASIO a cifras como 8/28 ms de latencia con WASAPI… y la diferencia se nota, y mucho, al grabar o tocar en directo.

Qué es la latencia de audio y por qué es tan crítica

Cuando hablamos de ajustes de latencia de audio WASAPI, en realidad estamos intentando controlar el retraso entre que se genera un sonido y lo oímos. Ese desfase se mide en milisegundos y, aunque parezca poco, afecta de forma directa a cómo tocas, hablas o juegas.

En el mundo del audio se suelen distinguir varios tipos de latencia que conviene tener claros para entender qué está pasando en tu sistema:

• Latencia de reproducción: tiempo que transcurre desde que una aplicación envía un búfer de audio a Windows hasta que lo escuchas por los altavoces o auriculares.
• Latencia de captura: tiempo que pasa desde que el micrófono capta el sonido hasta que esos datos llegan a la aplicación.
• Latencia de ida y vuelta (round-trip): suma de ambas. Es el retraso total desde que hablas o tocas un instrumento, la señal entra en el sistema, se procesa y vuelve a salir por los monitores.
• Latencia táctil‑aplicación: retraso entre pulsar una pantalla táctil y que el evento llegue a la app.
• Latencia táctil‑sonido: tiempo que pasa desde que tocas la pantalla hasta que suena algo; combina la latencia táctil y la de reproducción.

Para un músico, una latencia por encima de 10 ms empieza a ser molesta: la respuesta del instrumento deja de sentirse “pegada” y se vuelve incómodo tocar. Para streamers, podcasters o locutores, escucharse con retardo por los cascos genera una sensación rarísima que puede hacerte tropezar al hablar. Y para jugadores, sobre todo en shooters o juegos rítmicos, cada milisegundo cuenta para que la imagen y el sonido estén perfectamente sincronizados.

De ASIO a WASAPI: pros, contras y cambios de latencia

Durante años, la solución estándar en Windows para quien buscaba latencia mínima ha sido ASIO (Audio Stream Input/Output). Es un modelo de driver paralelo al sistema de audio de Windows que permite enviar datos directamente entre la aplicación y el controlador ASIO, normalmente en modo exclusivo, sin pasar por el motor de audio de Windows ni sus mezclas internas.

El resultado suele ser una latencia muy baja y estable, ideal para producción musical y directo, pero con varias pegas claras:

• Una vez la interfaz está en uso por ASIO, otras apps no pueden usarla con normalidad.
• Solo el software que implementa soporte ASIO puede aprovecharlo.
• No es la opción natural para juegos, navegadores o apps de videollamada.

Por eso muchos usuarios se plantean cambiar a WASAPI: es la API de audio nativa de Windows y está pensada para que todas las aplicaciones puedan compartir el dispositivo sin tener que recurrir a inventos raros. Sin embargo, el salto no siempre es sencillo:

• Con WASAPI en algunos sistemas aparecen configuraciones tipo 8 ms de salida / 28 ms de entrada, lo que hace que el round‑trip sea claramente superior al de ASIO.
• En otros casos, se descubre que WASAPI en modo exclusivo puede lograr latencias incluso menores que ASIO, pero en modo compartido aparecen distorsiones, glitches o artefactos.
• También entran en juego las limitaciones de formato, por ejemplo, interfaces que solo exponen 16 bits a Windows, mientras WASAPI parece forzar 24 bits y el diálogo de selección de profundidad de bits aparece bloqueado.

Todo esto hace que la transición de ASIO a WASAPI vaya más allá de cambiar un selector en el DAW: hay que entender cómo funciona la pila de audio de Windows, qué ha cambiado en Windows 10 y qué opciones ofrece Microsoft para exprimir al máximo la latencia en WASAPI sin renunciar a la flexibilidad.

AudioGraph y WASAPI: dos caminos hacia la baja latencia

En Windows 10 aparece una API específica para escenarios multimedia y de creación musical: AudioGraph. Su objetivo es que sea sencillo montar flujos complejos de audio (entradas, salidas, efectos, enrutados) sin pelearse con la baja latencia a bajo nivel, y está disponible en C++, C#, JavaScript y otros lenguajes del entorno UWP.

Para quien necesite afininar la respuesta del sistema, AudioGraph ofrece la propiedad AudioGraphSettings::QuantumSizeSelectionMode, que permite elegir el tamaño de los bloques de audio (quantum) que se procesan:

• SystemDefault: usa el tamaño de búfer estándar del sistema, típicamente alrededor de 10 ms.
• LowestLatency: fuerza el uso del tamaño de búfer mínimo admitido por el controlador, es decir, exprime al máximo la latencia posible.
• ClosestToDesired: intenta fijar el quantum a un número concreto de muestras especificado por la app o, si no se puede, al más cercano soportado por el driver.

Con un par de líneas se puede crear un gráfico de audio apuntando directamente a la latencia mínima posible para el dispositivo:

AudioGraph es, por tanto, ideal para nuevas aplicaciones que no necesiten un control extremo del pipeline. Pero si quieres ir al detalle, seguir usando la API Win32 clásica o apurar aún más la latencia, lo que toca es meter mano directamente a WASAPI y su interfaz moderna IAudioClient3.

IAudioClient3: afinando WASAPI para latencia mínima

Con Windows 10, Microsoft amplía WASAPI con la interfaz IAudioClient3, pensada justamente para poder ajustar de forma precisa la periodicidad del motor de audio y saber qué tamaños de búfer acepta el dispositivo en modo compartido.

Capacidades principales de IAudioClient3:

• Permitir que la aplicación consulte qué rangos de tamaños de búfer (periodos, en frames) son compatibles para un formato concreto.
• Obtener el formato actual y la periodicidad del motor de audio en modo compartido.
• Inicializar una secuencia de audio compartida con la periodicidad elegida por la app, en lugar de quedarse siempre con los 10 ms típicos.

En la práctica, esto se traduce en flujos más ajustados como este:

1. Activar la interfaz de audio por defecto (reproducción o captura) y obtener un IAudioClient3.
2. Configurar las propiedades del cliente de audio (categoría, opciones para evitar re‑muestreo, modo “raw” si se quiere saltar el procesado del OEM, etc.).
3. Llamar a GetMixFormat para conocer el formato por defecto del dispositivo.
4. Usar GetSharedModeEnginePeriod para descubrir el periodo por defecto, el periodo fundamental y los mínimos/máximos admitidos.
5. Escoger un periodo deseado (por ejemplo, algo cercano al mínimo) y llamar a InitializeSharedAudioStream para abrir el stream con ese búfer más pequeño.

Si el motor ya está corriendo con una periodicidad fijada por otra app, el sistema puede devolver errores indicativos para que consultes cuál es el periodo actual y te adaptes. También es posible abrir secuencias con formatos específicos, usando AUDCLNT_STREAMOPTIONS_MATCH_FORMAT para indicar que te interesa evitar que el motor vuelva a muestrear.

Además, Microsoft recomienda que las apps que trabajan con WASAPI combinen esto con la cola de trabajo en tiempo real (rt Work Queue) o con las colas de Media Foundation (por ejemplo, MFCreateMFByteStreamOnStreamEx), etiquetando los trabajos como “Audio” o “ProAudio”. De esta forma, Windows puede priorizar y aislar los hilos de audio frente a otros subsistemas cuando se trabaja con búferes muy pequeños.

Cómo y por qué Windows entra en “modo de audio de baja latencia”

Cuando habilitas un tamaño de búfer por debajo de cierto umbral para reproducción y captura, Windows entra en un modo especial pensado para proteger el streaming de audio frente a otros procesos que podrían interferir.

En ese modo, el sistema vigila y gestiona de forma prioritaria varios recursos:

• El hilo del motor de audio que se encarga de procesar los streams de baja latencia.
• Todos los hilos e interrupciones que el controlador haya registrado como críticos para el audio, mediante las nuevas DDIs.
• Los hilos de audio de las aplicaciones que usan AudioGraph o WASAPI con búferes pequeños, especialmente si comparten el mismo grafo de dispositivos (mismos modos de procesado).

En el caso de WASAPI, esta priorización se aplica sobre todo a elementos de trabajo en colas de tiempo real etiquetados como audio, en lugar de hilos creados “a mano” por cada aplicación. El objetivo es minimizar las interrupciones y los dropouts cuando operas al límite de lo que permite el hardware.

Cuando se detiene el streaming, Windows sale de ese modo reforzado y vuelve a su funcionamiento normal, ahorrando energía y evitando mantener la CPU constantemente activa sin motivo.

Drivers y hardware: el eslabón crítico de la latencia WASAPI

Por muy bien diseñada que esté la API, el factor decisivo sigue siendo el controlador de audio y el propio hardware. Windows 10 introduce varias extensiones para que los drivers declaren de forma explícita sus capacidades de baja latencia.

La clave está en que el driver pueda informar a Windows de:

1. El tamaño mínimo de búfer que admite de forma absoluta.
2. Restricciones adicionales de tamaño de búfer para cada modo de procesado de señal (por ejemplo, procesado “default”, “película”, “comunicación”…).
3. Qué parte del búfer está realmente disponible para leer o escribir en cada momento, sin que Windows tenga que hacer conjeturas.
4. Marcas de tiempo precisas basadas en el contador de rendimiento, para conocer exactamente la posición de reproducción o captura.

Todo esto se articula alrededor de propiedades como DEVPKEY_KsAudio_PacketSize_Constraints2, que deja a los drivers indicar fácilmente, por ejemplo, que pueden manejar un mínimo absoluto interno de 2 ms, pero que en el modo de procesado por defecto solo garantizan a nivel de sistema algo como 128 frames (unos 3 ms a 48 kHz).

En dispositivos con DSPs internos complejos, calcular bien estas marcas de tiempo y restricciones es delicado: hay que tener en cuenta los retardos añadidos por los algoritmos internos, por los buses de transporte entre el DSP y la RAM, o por la arquitectura del motor DMA. Si no se hace bien, las estimaciones de posición de flujo se desvían y se complican operaciones como la sincronización precisa de audio y vídeo.

Además, los fabricantes deben registrar sus recursos de streaming (interrupciones y hilos propios) con Portcls, de forma que Windows sepa qué debe proteger en escenarios de baja latencia. Para controladores HDAudio estándar, parte de ese trabajo lo hace el propio bus hdaudbus.sys, pero si el miniport crea sus propios hilos de procesado también debe registrarlos.

Cómo medir la latencia y probar controladores de baja latencia

Para saber si tus ajustes de latencia WASAPI están dando resultado, lo ideal es medir la latencia de ida y vuelta (round‑trip) con herramientas específicas. La idea es simple:

1. Una aplicación reproduce un pulso corto por los altavoces usando WASAPI o AudioGraph.
2. Un micrófono captura ese pulso.
3. La misma aplicación detecta el pulso recibido y calcula el retraso exacto entre salida y entrada.

Repitiendo la prueba con distintos tamaños de búfer puedes ver cómo cae (o no) la latencia real de tu sistema. Para poder utilizar intervalos pequeños (por ejemplo, entre 2,6 ms y 10 ms a 48 kHz), necesitas un driver que admita esos tamaños. El propio controlador HDAudio genérico de Microsoft, incluido en Windows 10 en adelante, se ha actualizado para soportar desde 128 muestras (≈2,66 ms @ 48 kHz) hasta 480 muestras (≈10 ms @ 48 kHz).

Si tu equipo está usando un driver de códec de terceros, puedes forzar el uso del driver HDAudio de Microsoft desde el Administrador de dispositivos:

• Abrir Administrador de dispositivos y localizar el dispositivo de audio que corresponde a tus altavoces internos.
• Entrar en las propiedades, pestaña Controlador y seleccionar Actualizar controlador.
• Elegir Buscar software de controlador en el equipo y luego Elegir en una lista de controladores disponibles.
• Seleccionar Dispositivo de High Definition Audio de Microsoft y confirmar, incluso si aparece una advertencia.
• Reiniciar si el sistema lo pide.

Así puedes comprobar si con el driver genérico mejora el comportamiento de WASAPI. Conviene apuntar qué driver tenías antes por si quieres volver a usar la configuración optimizada del fabricante del códec una vez termines las pruebas.

Latencia, calidad y consumo: por qué no todo debe ir al mínimo

Aunque la tentación natural es poner el búfer en el valor más bajo posible, esto no siempre es lo mejor para todos los casos. Trabajar con 1 ms de búfer implica que la CPU tendrá que despertarse cada milisegundo para rellenarlo o vaciarlo, lo que aumenta el consumo de energía de forma notable y acorta la autonomía en portátiles o tablets.

Por otro lado, muchas aplicaciones dependen de efectos de audio complejos: reverberaciones de calidad de estudio, cancelación de eco para videollamadas, reducción agresiva de ruido, procesados espaciales, etc. Todos esos APO añaden latencia inevitablemente, pero la ganancia en calidad o en inteligibilidad puede ser mucho mayor que el perjuicio por unos milisegundos extra.

En la práctica, cada tipo de app tiene sus prioridades:

• Un DAW o un instrumento virtual busca latencia mínima, incluso a costa de desactivar efectos globales y asumir un mayor consumo.
• Una app de vídeo o un reproductor multimedia suele priorizar fidelidad y compatibilidad con muchos formatos, aceptando latencias mayores que se corrigen con sincronización A/V.
• Una herramienta de comunicación quiere un equilibrio entre baja latencia, claridad de voz y robustez en redes irregulares.

Por eso Windows 10 no obliga a todas las apps a usar los nuevos modos de baja latencia: deja la decisión en manos del desarrollador y del usuario. De hecho, aunque el controlador soporte búferes pequeños, las aplicaciones seguirán usando por defecto unos 10 ms salvo que pidan expresamente otra cosa mediante AudioGraph o IAudioClient3.

WASAPI, ASIO, streaming y videojuegos: escenarios típicos

La teoría está muy bien, pero al final lo que importa es qué combinación de drivers y ajustes te da la menor latencia aceptable sin glitches para tu caso concreto. Varios escenarios habituales ayudan a verlo claro:

En producción musical, lo normal es usar una tarjeta con drivers ASIO dedicados. Estos drivers están orientados al trabajo en DAW con tamaños de búfer muy bajos, y cuando el equipo es potente y está limpio de procesos extraños, el rendimiento suele ser muy estable. El inconveniente es que ASIO no se lleva bien con el streaming general del sistema: ni OBS, ni los juegos, ni la mayoría de apps saben hablar ASIO, así que terminas en configuraciones complicadas o con varias interfaces.

En streaming de videojuegos la cosa cambia. Aquí necesitas mezclar audio del juego, tu voz por micrófono, alertas, música y la salida final hacia OBS o software similar. Como la mayoría de estas aplicaciones usan los controladores nativos de Windows (DirectSound/WASAPI), no puedes depender solo de ASIO. Además, si en Windows activas la opción “Escuchar este dispositivo” en un micrófono, el retorno que obtienes va a través del pipeline estándar, con su búfer de 10 ms o más y cualquier APO de por medio, provocando el retardo tan molesto que muchos han sufrido al probar su voz en Discord o similares.

Algo parecido ocurre en juegos competitivos: algunos títulos empiezan a aprovechar WASAPI de forma más directa y con modos experimentales de baja latencia, activados por variables de entorno. El caso de osu! lazer, por ejemplo, permite probar un backend WASAPI especial con la variable OSU_AUDIO_WASAPI_EXPERIMENTAL=1, y muchos usuarios han reportado mejoras en la respuesta a costa de tener que reajustar su offset universal en 10‑20 ms para compensar el nuevo pipeline.

En otros entornos, como podcasting o voice‑over con micrófonos USB usando WASAPI a 128 muestras, es habitual ver cifras teóricas de 2 ms de latencia que luego no se corresponden con la sensación real; siguen notándose retardos claros. En estos casos suele influir tanto el hardware interno del micro como el número de pasos de procesado y apps intermedias que añadimos: software de cambio de voz, routers virtuales de audio, mezclas adicionales, etc.

Cómo reducir la latencia de audio en Windows sin perder la cabeza

Con todo lo anterior en mente, la receta para controlar la latencia WASAPI pasa por revisar tanto la configuración del sistema como del hardware y de las aplicaciones:

• Actualizar drivers y sistema: asegurarse de que se usan drivers compatibles con las mejoras de Windows 10 o posteriores, especialmente si admiten los nuevos tamaños de búfer y la propiedad DEVPKEY_KsAudio_PacketSize_Constraints2.
• Reducir el tamaño del búfer desde el DAW o la aplicación, usando WASAPI en modo exclusivo o las nuevas APIs (IAudioClient3, AudioGraph) para seleccionar el periodo más bajo que el driver soporte de forma estable.
• Evitar cadenas de procesado innecesarias: cuantos más programas, efectos y conversiones intermedias metas (múltiples interfaces, conversión analógica‑digital‑analógica, software de routing…), más latencia vas acumulando.
• Elegir una buena interfaz de audio: algunas tarjetas e interfaces USB tienen tiempos internos de procesado mucho más largos que otras. Una interfaz con buen DSP puede mezclar fuentes y ofrecer monitorización casi instantánea, liberando al PC de tarea.

En el ámbito de interfaces optimizadas para streaming, por ejemplo, existen modelos con DSP dedicado que hacen la mezcla internamente (fuentes XLR, línea, óptico y hasta cinco canales procedentes del PC). Al no depender de la mezcla en software ni de la latencia del sistema operativo, se llegan a niveles del orden de 3 ms entre la entrada y la salida, prácticamente imperceptibles para el oído humano.

A esto se le añade que, si la mezcla se produce en la propia interfaz, la carga de CPU en el ordenador se reduce muchísimo, permitiendo que el software de control consuma menos del 1 % de CPU de media. Para streamers y creadores de contenido, este tipo de soluciones pueden cambiar radicalmente la experiencia, ya que permiten monitorización sin retardo, mezcla para el creador y mezcla distinta para el público, todo sin depender del comportamiento del stack de Windows.

Latencia perceptible, tasas de muestreo y profundidad de bits

Un detalle que muchas veces pasa desapercibido es que, además del tamaño de búfer, entran en juego parámetros como la frecuencia de muestreo y la profundidad de bits. La frecuencia de muestreo (habitualmente 44.100 Hz o 48.000 Hz) indica cuántas veces por segundo se “corta” la señal continua para crear una representación digital. Esas muestras se agrupan en búferes, y ahí es donde se acumula la latencia.

El punto clave es que el oído humano suele tolerar latencias de hasta 10 ms sin notarlo de forma consciente, pero por encima de esa cifra el retardo empieza a ser evidente y molesto, especialmente al monitorizar tu propia voz o al tocar un instrumento. De ahí que el objetivo para muchos músicos y streamers sea mantenerse por debajo de esos 10 ms de ida y vuelta siempre que sea posible.

En cuanto a la profundidad de bits (16, 24 bits, etc.), aunque está más relacionada con el rango dinámico y la calidad que con la latencia en sí, puede generar problemas de compatibilidad con WASAPI. Hay interfaces que solo exponen 16 bits en el panel de sonido de Windows, mientras algunas configuraciones de WASAPI parecen forzar 24 bits en ciertos modos, lo que puede desembocar en distorsiones si la combinación de formato seleccionado y capacidades reales del hardware no encajan.

Por eso, si al pasar a WASAPI en modo compartido experimentas audio seriamente distorsionado mientras el desktop suena bien, conviene revisar con lupa la combinación de frecuencia de muestreo y profundidad de bits elegida en el sistema y en la aplicación, y no descartar la posibilidad de limitaciones o bugs concretos del driver de tu interfaz.

Con este panorama, los ajustes de latencia WASAPI se convierten en algo más que mover un deslizador: implican entender cómo trabaja la pila de audio de Windows, qué ofrece cada API (AudioGraph, WASAPI tradicional, IAudioClient3, ASIO) y qué puede realmente tu hardware. Solo así puedes encontrar ese punto dulce donde el audio responda rápido, suene bien y el sistema siga siendo utilizable para todo lo demás sin volverte loco con chasquidos ni cortes.