Ajustes de latencia WASAPI en Windows: guía completa

Si trabajas con audio en Windows, tarde o temprano te topas con la latencia de WASAPI y la eterna comparación con ASIO y WASAPI. Quien graba en un DAW, hace directos, juega online o produce música sabe que unos milisegundos de retraso pueden arruinar una toma, desincronizar una voz o convertir una partida en un suplicio.

En Windows 10 y versiones posteriores Microsoft ha dado un buen empujón a su pila de audio, y hoy es posible lograr latencias mucho más bajas con WASAPI en modo compartido o exclusivo, sin renunciar al audio del navegador ni a otras aplicaciones. La clave está en entender cómo funciona la pila, qué ha cambiado, qué límites marca el hardware y qué parámetros podemos tocar (como usuario o como desarrollador) para apurar esos milisegundos extra.

Qué es la latencia de audio y por qué importa tanto

Cuando hablamos de latencia de audio nos referimos al tiempo que pasa desde que se genera un sonido hasta que lo escuchas o lo recibe tu aplicación. Ese tiempo se mide en milisegundos y, aunque sobre el papel parece casi despreciable, en la práctica marca la diferencia entre una experiencia fluida y algo totalmente incómodo.

En producción musical y grabación, un instrumentista necesita escucharse prácticamente al instante mientras toca. Si cada nota tarda decenas de milisegundos en regresar por los auriculares, el cerebro empieza a pelearse con lo que oye y lo que siente, y mantener el ritmo se vuelve una odisea.

En streaming, podcasts y videollamadas, la latencia puede provocar desajustes entre el vídeo y el audio, ecos molestos y sensación de «hablar contra una pared». Tener la propia voz retrasada en los cascos unos cuantos milisegundos fuerza al hablante, provoca tropiezos y suena poco natural para quien escucha.

Para los gamers, especialmente en shooters, juegos competitivos o experiencias de VR, una respuesta de audio lenta significa perder pistas sonoras clave (pasos, disparos, alertas) o notar que la acción del mando y el sonido no van acompasados, lo que arruina la inmersión; para estos casos es útil aprender a medir la latencia en videojuegos y actuar en consecuencia.

En términos más técnicos, se suele distinguir entre latencia de reproducción, de captura, de ida y vuelta y latencias asociadas al tacto (por ejemplo, tocar la pantalla y oír una respuesta sonora). Todas ellas suman y conviene entenderlas para saber dónde se nos va el tiempo.

Tipos de latencia en la ruta de audio

Dentro de la pila de audio de Windows se usan varios conceptos para describir los retrasos en cada tramo del recorrido del sonido. No es solo una cuestión académica: cada tipo de latencia tiene causas distintas y maneras diferentes de mitigarse.

La latencia de reproducción es el retraso entre el momento en que la aplicación entrega un búfer de audio para reproducir y el instante en que lo oyes por los altavoces o auriculares. Aquí cuentan el tamaño de los búferes, la conversión de formato y los efectos que se apliquen en el camino.

La latencia de captura, por su parte, es el tiempo que tarda en llegar a la aplicación el audio capturado desde el micrófono. Va desde que el sonido entra en el transductor, pasa por la interfaz, el controlador y el motor de audio, hasta que el software puede leer ese bloque de datos.

La llamada latencia de ida y vuelta (round-trip) es la suma de ambas: capturar, procesar en la app y volver a reproducir en los altavoces. Es la que realmente manda en escenarios como monitorización en un DAW, donde tocas, la señal pasa por el ordenador y regresa a tus orejas.

En interfaces táctiles, además, se habla a menudo de latencia de toque a aplicación y de toque a sonido: el tiempo entre que pulsas la pantalla, se procesa el evento y el sistema responde con audio. Para instrumentos virtuales o apps creativas en tabletas o convertibles con Windows, esa cadena debe ser lo más corta posible.

Cómo está montada la pila de audio de Windows

Por debajo de WASAPI, ASIO y compañía, Windows tiene una pila de audio con un motor central que mezcla flujos, aplica efectos, reescala formatos y habla con los controladores. Entender ese camino ayuda a ver dónde se gana y se pierde latencia.

En el recorrido de reproducción, la aplicación escribe audio en un búfer expuesto por la API. El motor de audio de Windows lee esos datos, los procesa (incluyendo efectos en forma de APO, u objetos de procesamiento de audio) y, una vez listos, los vuelca a otro búfer que el controlador utilizará para enviar al hardware.

La latencia asociada a estos APO depende del procesamiento que hagan (ecualización, cancelación de ruido, efectos 3D, etc.). Cuanto más complejo sea el algoritmo y mayor sea el estado que necesita acumular, más muestras tendrá que guardar en colchón y mayor será el retraso.

Antes de Windows 10, el mero paso por el motor de audio añadía alrededor de 12 ms con datos en coma flotante y unos 6 ms con datos enteros en reproducción. Desde Windows 10, esa parte se ha optimizado drásticamente y queda en torno a 1,3 ms, independientemente del tipo de datos.

Después de procesar, el motor coloca el resultado en un búfer cuya longitud también tiene un impacto directo. En sistemas anteriores, ese búfer estaba fijado en unos 10 ms. En versiones modernas, es el controlador de audio el que puede declarar diferentes tamaños soportados y permitir valores más pequeños, de 2-3 ms, por ejemplo.

En captura sucede algo análogo, pero al revés: el hardware toma la señal del micrófono, puede aplicar efectos (AGC, cancelación de eco, etc.), el controlador vierte esos datos a un búfer y el motor de audio los recoge y procesa con sus propios APO antes de ponerlos a disposición de la aplicación.

El motor de audio, en versiones antiguas, añadía en captura unos 6 ms para datos en coma flotante y prácticamente 0 ms con enteros. Desde Windows 10, se ha reducido hasta hacer esa contribución prácticamente despreciable. Aun así, los búferes de la parte del controlador y el hardware siguen pesando en el total.

Existe además el modo exclusivo de la pila de audio. Si una app abre un endpoint en exclusivo, se salta el motor de mezcla y habla directamente con el búfer de hardware. Eso minimiza aún más la latencia, pero con la contrapartida de que ningún otro programa puede usar simultáneamente ese dispositivo de entrada o salida.

ASIO, modo exclusivo y por qué WASAPI ha mejorado tanto

Durante años, la forma habitual de lograr baja latencia en producción musical ha sido tirar de ASIO o dispositivos en modo exclusivo. Con ASIO, el DAW se comunica de forma casi directa con el driver del fabricante de la interfaz, sin mezclador del sistema por medio.

El problema es que ese enfoque tiene sus pegas: suele requerir controladores específicos de terceros, el software tiene que estar preparado para hablar con esa API y, en general, el audio del sistema (navegador, juegos, reproductores) queda fuera o hay que recurrir a apaños complejos para rutearlo.

En paralelo, el modo exclusivo de WASAPI daba algo similar: el flujo de la app va prácticamente directo al dispositivo. Pero de nuevo, el resto de aplicaciones se queda sin acceso en ese momento, y no es precisamente lo más cómodo cuando quieres mezclar DAW con vídeo de YouTube, Discord y demás.

Para no obligar a escoger entre latencia y flexibilidad, Microsoft mejoró la pila compartida de Windows 10 para bajar esa latencia incluso sin ir en exclusivo. El motor se hizo más ligero y, sobre todo, se añadió la posibilidad de negociar tamaños de búfer más pequeños entre la app y el driver.

A esto se suma un modo especial de gestión de recursos: cuando una aplicación empieza a trabajar con búferes muy cortos, Windows prioriza los hilos relacionados con ese flujo de audio y evita que otras tareas del sistema interrumpan el procesado en momentos críticos.

Ajustes de latencia WASAPI para usuarios de DAW y streaming

Desde el punto de vista del usuario final, WASAPI se presenta como una de las opciones de dispositivo de audio en muchos DAW y programas de grabación. En Reaper, por ejemplo, es frecuente ver comparaciones entre latencias de ASIO y WASAPI (tanto en modo exclusivo como en compartido).

En algunos casos, al cambiar de ASIO a WASAPI exclusivo, se consigue una latencia incluso menor que con el driver ASIO del fabricante, siempre que el hardware y el controlador de Windows estén bien ajustados. No es la situación más común, pero puede darse y, cuando sucede, es lógico que el usuario no quiera volver a ASIO.

Sin embargo, cuando se pasa a WASAPI compartido, pueden aparecer distorsiones, chasquidos o artefactos al reproducir o capturar audio del DAW, mientras el resto de sonidos del sistema (navegador, juegos) se escuchan sin problemas. Esto suele deberse a desajustes en formatos, a un búfer demasiado agresivo o a conversiones forzadas.

Uno de los conflictos típicos se da cuando el sistema fuerza al dispositivo a trabajar en un formato de profundidad de bits diferente al que soporta realmente la interfaz. Por ejemplo, WASAPI presentando 24 bits en el diálogo del DAW, mientras en el panel de sonido de Windows la tarjeta solo ofrece 16 bits en todas sus frecuencias de muestreo.

En estos casos, para evitar distorsiones en WASAPI compartido conviene revisar en las opciones de sonido de Windows la profundidad de bits y la frecuencia de muestreo configuradas como predeterminadas, y asegurarse de que el DAW use un formato compatible con lo que la interfaz realmente soporta.

En otros contextos, como grabar voz en off con un micrófono USB en aplicaciones sencillas o en herramientas como Audacity, WASAPI se utiliza sobre todo para capturar el propio audio del sistema o la salida del mezclador de Windows, más que para lograr la latencia mínimamente posible.

Latencia, búferes y percepción humana

La latencia suele medirse en milisegundos, y en la práctica se considera que por debajo de unos 10 ms el retraso es prácticamente imperceptible para la mayoría de las personas. Entre 10 y 20 ms se empieza a notar en tareas sensibles, y por encima de ahí se vuelve claramente molesto.

Cuando te escuchas a ti mismo por unos cascos mientras hablas, cualquier latencia superior a 10 ms empieza a generar esa sensación de «eco interno». Si sube a 30 o 40 ms, la mayoría de la gente se hace un lío, se frena al hablar o termina quitándose los auriculares.

Al mismo tiempo, las señales de audio digital se describen por frecuencia de muestreo (en Hz) y tamaño de búfer (en muestras). A modo de referencia, 44.100 Hz significa que la forma de onda se divide en 44.100 muestras por segundo; 48.000 Hz hace lo propio con 48.000 muestras, y así sucesivamente.

El búfer es una especie de pequeño almacén de datos por el que circula el audio. Cuanto más grande es, más margen de seguridad tienes frente a picos de CPU o interrupciones, pero a costa de sumar milisegundos a la latencia total. Si lo reduces demasiado, el sistema tiene que despertarse más a menudo para rellenarlo y está más expuesto a cortes o glitches.

Por eso, al configurar un dispositivo en un DAW o una app de streaming, el dilema habitual es elegir un tamaño de búfer que sea lo bastante bajo para que no se note el retraso, pero no tanto como para que empiecen los chasquidos o drops durante el trabajo real.

Cómo reducir la latencia de audio en Windows con WASAPI

Para mejorar la experiencia con WASAPI y, en general, con el audio en Windows, hay una serie de medidas que conviene aplicar o al menos revisar, tanto a nivel de hardware como de software y sistema.

Lo primero es asegurarse de que el hardware de audio (interfaz, tarjeta integrada, micrófonos USB) y sus controladores están correctamente instalados y actualizados. Muchos de los avances de baja latencia en Windows 10 dependen de DDIs y propiedades que solo están presentes en drivers modernos; para diagnosticar la latencia con LatencyMon y detectar problemas de controladores es una práctica recomendable.

En el ámbito musical, la norma sigue siendo usar interfaces con drivers ASIO de calidad cuando se trabaja con DAW, instrumentos virtuales o mezclas complejas. ASIO sigue ofreciendo un control fino sobre el tamaño de los búferes y suele ser estable si el PC está dedicado a audio y no se fuerza con overclock ni tareas pesadas en paralelo.

En streaming y juegos, sin embargo, ASIO se vuelve poco práctico porque la mayoría de aplicaciones (juegos, OBS, navegadores) tiran de los controladores nativos de Windows (DirectSound, WASAPI). Al mezclar estas fuentes, es preferible mantenerse en el ecosistema nativo del sistema operativo.

Una regla que rara vez falla es evitar encadenar más dispositivos y programas de los necesarios en el recorrido de la señal. Cada conversión analógico-digital, cada paso por un procesador de efectos o cada salto de una app a otra añade un poco de retraso y riesgo de desajustes.

Por ejemplo, no es lo mismo hablar a un micrófono XLR conectado a una interfaz dedicada con mezcla directa en hardware, que pasar por un micro USB, un cambiador de voz software, un enrutador virtual de audio y unos auriculares USB de gaming. En el segundo caso, la suma de pasos hace inevitable que la latencia se dispare.

Latencia y mejoras específicas en Windows 10 y posteriores

Microsoft no se ha limitado a pulir el motor de audio en Windows 10; también ha añadido mecanismos para que las aplicaciones y los controladores colaboren en la reducción de latencia de ida y vuelta sin sacrificar del todo la flexibilidad de la pila compartida.

En primer lugar, incluso sin cambiar código, muchas aplicaciones han visto una reducción de entre unos 4,5 y 16 ms en latencia de ida y vuelta respecto a Windows 8.1, simplemente por las optimizaciones internas del motor. Las que usan datos en coma flotante son las más beneficiadas.

En segundo lugar, si el sistema cuenta con controladores actualizados, estos pueden anunciar tamaños de búfer más pequeños de los clásicos 10 ms. Esto permite que aplicaciones que necesitan baja latencia negocien valores de 5 ms, 3 ms, 1 ms, etc., tanto en reproducción como en captura.

Como complemento, cuando una app empieza a operar con búferes muy pequeños, Windows activa un modo de gestión de recursos que da prioridad al subsistema de audio: protege los hilos del motor, del driver y de las apps marcadas como audio crítico para minimizar interrupciones y fallos.

Todo esto significa que, si desarrollas una app que requiere respuesta rápida, puedes apoyarte en la nueva infraestructura para conseguir latencias muy bajas sin renunciar a modo compartido, siempre que el hardware lo soporte.

AudioGraph: la API moderna para creación y multimedia

AudioGraph es la API de la Plataforma Universal de Windows pensada para escenarios interactivos y de creación musical con una capa de abstracción más amigable que lidiar directamente con WASAPI. Está disponible en C++, C#, JavaScript y otros lenguajes .NET.

Para objetivos de baja latencia, AudioGraph expone una propiedad llamada AudioGraphSettings::QuantumSizeSelectionMode, que permite indicar si queremos el tamaño de búfer por defecto del sistema, la latencia más baja posible o un valor concreto aproximado al deseado.

Se puede configurar para que el búfer use el tamaño predeterminado (alrededor de 10 ms), para que escoja el mínimo admitido por el controlador de audio, o para intentar acercarse al número de muestras deseadas por la app en cada quantum de procesamiento.

En los ejemplos oficiales se muestra cómo, con unas pocas líneas, se puede crear un grafo de audio orientado a mínima latencia simplemente seleccionando el modo LowestLatency. Esta opción internamente consulta qué tamaños soporta el dispositivo y elige el más agresivo posible sin salir de lo permitido.

AudioGraph se encarga también de gestionar internamente los hilos de audio de forma prioritaria, por lo que el desarrollador no tiene que marcar explícitamente MMCSS ni trabajar directamente con colas en tiempo real para beneficiarse del modo de baja latencia del sistema.

WASAPI e IAudioClient3: control fino de la periodicidad

Para quien necesite más control de bajo nivel, funcionalidades específicas o latencias incluso menores que las que logra AudioGraph, Microsoft amplió WASAPI con una nueva interfaz: IAudioClient3, derivada de la ya conocida IAudioClient2.

Esta interfaz añade métodos para consultar el formato y la periodicidad actual del motor de audio en modo compartido, obtener el rango de períodos permitidos para un formato dado y abrir flujos compartidos con una periodicidad concreta, en lugar de aceptar el valor por defecto.

En la práctica, esto permite que la app averigüe qué tamaños de búfer son legales (múltiplos de un periodo fundamental entre un mínimo y un máximo) y elija un valor concreto que equilibre estabilidad y latencia según sus necesidades.

Con IAudioClient3 también se puede indicar que el flujo use el formato especificado por la aplicación sin re-muestreo en el motor, siempre que el dispositivo soporte exactamente ese formato. Eso evita conversiones intermedias que pueden añadir complejidad y pequeños retrasos.

Además, Microsoft recomienda que las aplicaciones WASAPI que necesiten baja latencia creen sus tareas de procesamiento a través de la cola de trabajo en tiempo real (RT Work Queue) o de las colas de Media Foundation, etiquetándolas como «Audio» o «ProAudio» en vez de lanzar hilos propios sin coordinación.

Este etiquetado permite que Windows gestione de forma centralizada las prioridades y afinidades de esos hilos dentro de su modo especial de audio, reduciendo el riesgo de que otro subsistema los interrumpa en mitad del procesado de un búfer ajustado.

Mejoras necesarias en los controladores para baja latencia

La parte de software de usuario es solo la mitad de la historia. Para que un sistema realmente pueda trabajar con búferes de pocos milisegundos en condiciones, los controladores de audio también tienen que poner de su parte.

A partir de Windows 10, los drivers pueden declarar mediante propiedades específicas cuál es el tamaño mínimo absoluto de búfer que soportan en cada modo de procesamiento. Esta información incluye restricciones generales y limitaciones específicas para el modo por defecto, el modo cine, etc.

Por ejemplo, un controlador puede especificar que el mínimo absoluto sea 2 ms, pero que en el modo de procesamiento por defecto el tamaño efectivo sea de 128 muestras a 48 kHz (unos 3 ms). La pila de audio respeta estos límites y nunca tratará de bajar por debajo del mínimo indicado.

Más allá del tamaño de búfer, existen DDIs que facilitan que el controlador informe con precisión qué parte del búfer está libre o llena, proporcione marcas de tiempo exactas basadas en el contador de rendimiento y, en algunos escenarios, descargue datos más rápido que en tiempo real si ha acumulado información internamente.

Estas capacidades son especialmente útiles en diseños con DSP complejos o transportes de datos no triviales entre memoria y hardware, donde la posición del flujo y la latencia interna dependen de varios bloques intermedios. El cálculo de la marca de tiempo debe considerar esos retrasos fijos para que el sistema pueda alinear bien los datos.

Por último, para que Windows pueda proteger adecuadamente el subsistema de audio en escenarios de latencia muy baja, los drivers deben registrar sus recursos de streaming con PortCls: interrupciones y hilos propios que se usan para garantizar el flujo de datos.

Este registro se puede hacer al cargar el controlador o en tiempo de ejecución, y es obligatorio que todos los controladores de la cadena de streaming participen de una forma u otra. En pilas con bus HDAudio, por ejemplo, parte de ese trabajo lo hace el propio controlador de bus, mientras que el minipuerto registra sus propios hilos.

Herramientas y técnicas para medir latencia en Windows

Para saber si los ajustes de WASAPI y los cambios de controlador realmente están dando fruto, es habitual medir la latencia de ida y vuelta usando pulsos de prueba reproducidos por los altavoces y capturados por un micrófono. El software calcula el retardo entre la emisión y la recepción, y si observas microcortes conviene revisar cómo medir la latencia DPC específicamente.

Con esta metodología se pueden comparar distintos tamaños de búfer, modos de funcionamiento y versiones de driver, siempre que el dispositivo de audio admita los rangos de búfer pequeños necesarios. Si no, el sistema acabará recurriendo de nuevo a los 10 ms predeterminados; para análisis más profundo se puede aprender a analizar Windows a fondo con WPR/WPA.

En equipos con hardware HDAudio estándar, el controlador genérico de bandeja de entrada de Microsoft para HDAudio se ha actualizado para soportar tamaños de entre 128 muestras (unos 2,66 ms a 48 kHz) y 480 muestras (10 ms a 48 kHz). En algunos casos, instalar este driver genérico puede ser útil para pruebas.

El proceso pasa por abrir el Administrador de dispositivos, localizar el dispositivo que representa a los altavoces internos, y forzar la instalación del «High Definition Audio Device» de Microsoft en lugar del códec del fabricante. Tras un reinicio, el sistema usará ese driver genérico para ese endpoint.

Conviene anotar antes qué controlador estaba en uso para poder revertir el cambio si hace falta. Aunque el driver de Microsoft es útil para experimentar con tamaños de búfer pequeños, el del fabricante suele ofrecer una calidad de sonido o funciones específicas más ajustadas al hardware.

WASAPI, AudioGraph y diferencias de latencia práctica

Aunque ambas APIs se apoyan en el mismo motor de audio, en la práctica AudioGraph y WASAPI no siempre se comportan igual en términos de latencia, incluso usando los mismos tamaños de búfer subyacentes.

Por diseño, AudioGraph añade un búfer de latencia en el lado de captura para sincronizar reproducción y grabación. Esto simplifica muchísimo el código de la aplicación, porque garantiza que ambas rutas están alineadas, pero suma unos milisegundos adicionales.

En la ruta de reproducción, cuando el sistema usa tamaños de búfer superiores a unos 6 ms, AudioGraph puede introducir otro búfer de seguridad, de nuevo con la idea de ofrecer un modelo de programación estable y predecible a costa de un pelín de latencia extra.

WASAPI, en cambio, expone la ruta con menos abstracción. Eso implica más trabajo manual para el desarrollador, pero a cambio permite exprimir al máximo la reducción de latencia bajo ciertas condiciones, sobre todo en modo compartido de baja periodicidad y con IAudioClient3.

Además, a diferencia de AudioGraph, WASAPI permite gestionar con mayor detalle los efectos de captura, el uso de procesamiento sin procesar (raw) y la coordinación con otras APIs como Media Foundation, lo que abre la puerta a optimizaciones específicas en proyectos profesionales.

En todos los casos, la recomendación de Microsoft es clara: no usar el modo de procesamiento sin procesar a la ligera. Desactivar los efectos del OEM puede mejorar la latencia pero también puede llevar a señales menos optimizadas en reproducción o formatos de captura poco manejables para la app.

Si juntamos todas estas piezas, se ve que el camino para domar los ajustes de latencia de WASAPI pasa por conocer bien la pila de Windows, el comportamiento de tu hardware y las APIs disponibles. Solo así se pueden encontrar los puntos donde realmente se gana (o se pierde) cada milisegundo y ajustar la configuración a lo que necesita cada tipo de aplicación, sin sacrificar estabilidad ni calidad de sonido.