Audio con chasquidos en Windows 11: solucionar latencia sin comprar hardware nuevo

Qué son realmente los chasquidos: plazos perdidos, no “mal audio”

El audio en Windows es una canalización casi en tiempo real que corre sobre un sistema operativo de propósito general. Solo funciona porque los buffers ocultan la variación temporal: la aplicación escribe muestras de audio, el motor de audio las mezcla y el controlador alimenta el dispositivo. Si algo bloquea la CPU lo suficiente como para que el siguiente buffer no pueda entregarse a tiempo, lo oirás como:

• Chasquidos/pops: subejecuciones breves—muestras faltantes.
• Entrecortado (stutter): subejecuciones repetidas, o bucles de resincro en Bluetooth.
• Voz robótica/garble: deriva de reloj, remuestreo agresivo o pérdida de paquetes (común en Bluetooth).
• Cortes (dropouts): reinicios de dispositivo, eventos de energía USB o reinicios de controladores.

El término de ingeniería que verás en las herramientas es latencia DPC/ISR:

• ISR (Interrupt Service Routine): manejador rápido y de alta prioridad para una interrupción de hardware.
• DPC (Deferred Procedure Call): trabajo programado por una ISR para ejecutarse poco después, aún en prioridad elevada.

Si un controlador acapara tiempo de DPC—red, GPU, almacenamiento, ACPI, USB—el audio no puede ejecutarse cuando lo necesita. El uso de CPU puede estar en 10% y aún así oirás chasquidos, porque esto no es “rendimiento”. Es “latencia bajo contención”.

Idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla; la resiliencia proviene de diseñar y operar sistemas para tolerar y recuperarse de fallos.

La misma onda aquí. No buscamos perfección. Eliminamos los modos de fallo que convierten retrasos menores de planificación en artefactos audibles.

Guía rápida de diagnóstico (haz esto en orden)

Primero: clasifica el chasquido

1. ¿Solo en Bluetooth? Ve a Audio Bluetooth entrecortado.
2. ¿Solo en DAC/headset USB? Ve a USB y hubs.
3. ¿Solo en una app (Teams/Discord/juego/DAW)? Ve a Buffers a nivel de app.
4. ¿A nivel de sistema (YouTube + audio local + notificaciones)? Normalmente es DPC/controlador/energía.

Segundo: mide la latencia, no la intuyas

1. Ejecuta una herramienta de DPC (LatencyMon es la común) y reproduce el chasquido.
2. Si marca un controlador: no desinstales todo a ciegas. Confirma con alternancias dirigidas de dispositivos (ver tareas abajo).

Tercero: elimina los tres culpables principales en el orden más seguro

1. Plan de energía: cambia a un plan estable, desactiva la suspensión selectiva de USB y prueba.
2. Red: intenta desactivar Wi‑Fi temporalmente, luego desactiva offloads de NIC, después actualiza/retrocede el controlador.
3. GPU/controladores de audio HDMI: desactiva endpoints “NVIDIA/AMD High Definition Audio” no usados, actualiza el controlador GPU con instalación limpia.

Cuarto: fija un formato de audio conocido y bueno

1. Configura 48 kHz (o 44.1 kHz si tu flujo de trabajo es música) y 24 bits.
2. Desactiva mejoras, desactiva espacial, prueba modo exclusivo activado/desactivado según tu caso de uso.

Quinto: si es USB, trátalo como un bus, no como un cable

1. Mueve el DAC/headset a otro puerto (panel frontal vs trasero, controlador USB 2 vs USB 3).
2. Quita hubs/docks. Prueba conexión directa.
3. Desactiva la suspensión selectiva de USB y evita que Windows apague el dispositivo.

Para cuando el chasquido desaparezca: para. Más allá de ese punto está el tuning de culto: ediciones del registro y aplicaciones “optimizadoras de latencia” que a menudo empeoran las cosas.

Datos interesantes e historia breve (por qué sigue pasando)

• Antes el audio de Windows se mezclaba en kernel en versiones antiguas; Windows moderno movió la mezcla a modo usuario (WASAPI) por estabilidad y seguridad, pero los controladores siguen importando.
• Los picos de latencia DPC no son nuevos; han sido un dolor conocido desde al menos la era de Windows XP para usuarios de audio profesional.
• 48 kHz se volvió “por defecto” mayormente por estándares de vídeo/TV; muchas canalizaciones de audio en PC asumen 48 kHz incluso cuando las fuentes musicales son 44.1 kHz.
• ACPI y gestión de energía se volvieron más inteligentes (y más complejos) con los años, genial para baterías y ocasionalmente terrible para plazos de audio en tiempo real.
• El audio USB es isócrono: reserva ancho de banda y espera entrega oportuna; si el controlador host se retrasa, lo oyes de inmediato.
• Los controladores Wi‑Fi son ofensores frecuentes porque manejan ráfagas, transiciones de ahorro de energía y cargas de interrupciones intensas.
• Los controladores GPU pueden bloquear el sistema de maneras que no aparecen como “CPU alta” en el Administrador de tareas, porque el tiempo se pasa a IRQL elevado en DPC/ISR.
• El audio Bluetooth es con pérdida y con buffering; está diseñado para enmascarar caídas con búferes, pero Windows más interferencia de radio aún pueden causar artefactos audibles.
• Las “mejoras” son plugins DSP (APOs) insertados en la canalización; algunos tienen errores, otros añaden latencia y otros simplemente entran en conflicto con cambios de frecuencia de muestreo.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas están diseñadas para ejecutarse en una máquina normal con Windows 11 usando herramientas integradas. Uso PowerShell y utilidades estándar. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Tarea 1: Identifica tus endpoints de audio y su estado

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class AudioEndpoint | Select-Object Status,FriendlyName,InstanceId | Format-Table -AutoSize"
Status FriendlyName                                   InstanceId
------ ------------                                   ----------
OK     Speakers (Realtek(R) Audio)                    SWD\MMDEVAPI\{0.0.0.00000000}.{...}
OK     Headphones (USB Audio DAC)                     SWD\MMDEVAPI\{0.0.0.00000000}.{...}
OK     NVIDIA High Definition Audio                   SWD\MMDEVAPI\{0.0.0.00000000}.{...}

Significado: Ves cada endpoint de reproducción que Windows expone, incluidos audio HDMI/DP de GPUs.

Decisión: Si nunca usas “NVIDIA High Definition Audio” (o el equivalente AMD), planea desactivar ese endpoint para reducir la superficie de controladores.

Tarea 2: Lista los dispositivos reales de audio (controladores) detrás de los endpoints

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Sound,VideoAndGameControllers | Select-Object Status,FriendlyName,InstanceId | Format-Table -AutoSize"
Status FriendlyName                 InstanceId
------ ------------                 ----------
OK     Realtek(R) Audio             HDAUDIO\FUNC_01&VEN_10EC&DEV_...
OK     USB Audio DAC                USB\VID_1234&PID_5678\...
OK     NVIDIA Virtual Audio Device  ROOT\...

Significado: Estos son los controladores en modo kernel que pueden contribuir al comportamiento DPC.

Decisión: Si tienes múltiples pilas de audio (Realtek + USB + dispositivos virtuales GPU), simplifica: desactiva lo que no uses durante el diagnóstico.

Tarea 3: Comprobación rápida del plan de energía de la CPU (causa común de chasquidos)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Significado: “Equilibrado” frecuentemente permite ahorro de energía agresivo (especialmente en portátiles).

Decisión: Para pruebas, cambia a “Alto rendimiento” o “Ultimate Performance” (si está disponible). Si el chasquido desaparece, la causa raíz es la gestión de energía, no el “hardware de audio”.

Tarea 4: Cambiar a Alto rendimiento (prueba, no lo conviertas en permanente)

cr0x@server:~$ powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Significado: Indicas a Windows priorizar rendimiento y reducir estados de reposo.

Decisión: Vuelve a probar audio bajo tu carga peor (juego + Discord + navegador). Si es estable, luego afinaremos un plan personalizado en lugar de consumir batería para siempre.

Tarea 5: Comprueba la configuración de suspensión selectiva de USB

cr0x@server:~$ powercfg /qh SCHEME_CURRENT SUB_USB | findstr /i "Selective Suspend"
    USB selective suspend setting  (GUID: 2a737441-1930-4402-8d77-b2bebba308a3)
      Current AC Power Setting Index: 0x00000001
      Current DC Power Setting Index: 0x00000001

Significado: El índice 1 típicamente significa “Habilitado”.

Decisión: Si usas audio USB, desactiva la suspensión selectiva para el diagnóstico (especialmente en portátiles y docks).

Tarea 6: Desactivar suspensión selectiva de USB (AC + DC)

cr0x@server:~$ powercfg /setacvalueindex SCHEME_CURRENT SUB_USB 2a737441-1930-4402-8d77-b2bebba308a3 0
cr0x@server:~$ powercfg /setdcvalueindex SCHEME_CURRENT SUB_USB 2a737441-1930-4402-8d77-b2bebba308a3 0
cr0x@server:~$ powercfg /S SCHEME_CURRENT

Significado: Los puertos USB tienen menos probabilidad de ser gestionados para ahorro de energía en momentos inoportunos.

Decisión: Si esto arregla los chasquidos en un DAC/headset USB, mantenlo desactivado (o desactívalo solo en CA si te importa la batería).

Tarea 7: Encontrar riesgos de “apagar este dispositivo” en hubs/controladores USB

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class USB | Where-Object {$_.FriendlyName -match 'Hub|Controller'} | Select-Object Status,FriendlyName | Format-Table -AutoSize"
Status FriendlyName
------ ------------
OK     USB Root Hub (USB 3.0)
OK     Generic USB Hub
OK     USB xHCI Compliant Host Controller

Significado: Has listado la infraestructura de la que depende tu audio.

Decisión: Para hubs/controladores, revisa Administrador de dispositivos → pestaña Power Management y desmarca “Allow the computer to turn off this device to save power.” (No hay un interruptor CLI universal fiable para todos los controladores.)

Tarea 8: Identificar NICs (los controladores de red son villanos clásicos de DPC)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,InterfaceDescription,LinkSpeed | Format-Table -AutoSize"
Name   Status InterfaceDescription                     LinkSpeed
----   ------ --------------------                     ---------
Wi-Fi  Up     Intel(R) Wi-Fi 6E AX211                 1.2 Gbps
Ethernet Up   Realtek PCIe GbE Family Controller      1 Gbps

Significado: Ahora sabes qué adaptadores puedes probar desactivando temporalmente.

Decisión: Si el chasquido se correlaciona con actividad de red (descargas, llamadas en Teams), prueba primero con Wi‑Fi desactivado.

Tarea 9: Desactivar temporalmente Wi‑Fi para aislar el impacto del controlador

cr0x@server:~$ powershell -NoProfile -Command "Disable-NetAdapter -Name 'Wi-Fi' -Confirm:\$false"

Significado: Has eliminado una fuente mayor de interrupciones del sistema.

Decisión: Si el audio mejora inmediatamente, no necesitas un nuevo DAC. Necesitas corregir el controlador/configuración Wi‑Fi (actualizar/retroceder controlador, desactivar ahorro de energía, afinar offloads).

Tarea 10: Revisar fechas de instalación de controladores (buscar actualizaciones “útiles” recientes)

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceClass -in 'MEDIA','NET'} | Select-Object DeviceName,DriverVersion,DriverDate | Sort-Object DriverDate -Descending | Select-Object -First 10 | Format-Table -AutoSize"
DeviceName                           DriverVersion  DriverDate
----------                           -------------  ----------
Intel(R) Wi-Fi 6E AX211              23.40.0.4      2025-01-15
Realtek(R) Audio                     6.0.9652.1     2024-12-02
NVIDIA High Definition Audio         1.4.0.1        2024-11-20

Significado: Puedes correlacionar el inicio de los chasquidos con cambios de controladores.

Decisión: Si los chasquidos empezaron “recientemente”, esta lista suele hacer menos misterioso el “cuándo”.

Tarea 11: Inspeccionar salud de servicios de audio de Windows (raro, pero rápido)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Audiosrv,AudioEndpointBuilder | Format-Table -AutoSize Name,Status,StartType"
Name                 Status StartType
----                 ------ ---------
Audiosrv             Running Automatic
AudioEndpointBuilder Running Automatic

Significado: Si estos están detenidos o inestables, tienes un problema distinto a la latencia DPC.

Decisión: Si no están en Running, arregla el estado del servicio primero (y revisa el Visor de eventos para saber por qué se detuvo).

Tarea 12: Extraer logs de eventos del sistema relevantes para resets de audio/controladores

cr0x@server:~$ powershell -NoProfile -Command "wevtutil qe System /q:\"*[System[(Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 86400000]]]\" /f:text /c:40"
Event[0]:
  Log Name: System
  Source:   Kernel-PnP
  Level:    Error
  ...
  Message:  The device USB\VID_1234&PID_5678... was not migrated due to partial or ambiguous match.

Significado: Kernel-PnP, USB y errores de controladores en las últimas 24 horas suelen ser pistas clave para dropouts.

Decisión: Si ves desconexiones/reconexiones USB repetidas o errores de migración, céntrate en energía USB y puertos, no en ajustes de frecuencia de muestreo.

Tarea 13: Comprobar qué proceso está saturando la CPU en el momento del chasquido (chequeo de cordura)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 8 Name,Id,CPU,WorkingSet | Format-Table -AutoSize"
Name            Id    CPU WorkingSet
----            --    --- ----------
chrome        1040  812.4  950000000
dwm           1880  210.1  240000000
audiodg       1324   45.7   65000000

Significado: Esto no mide DPC, pero detecta escenarios obvios de “CPU realmente saturada” (una pestaña del navegador fuera de control).

Decisión: Si algo realmente está saturando CPU, arréglalo primero. Si la CPU parece bien, vuelve a cazar controladores por latencia.

Tarea 14: Confirmar que la presión de memoria no fuerza paging durante el audio

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Memory\Available MBytes','\Memory\Pages/sec' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -AutoSize"
Path                       CookedValue
----                       -----------
\Memory\Available MBytes        5120
\Memory\Pages/sec                 3

Significado: Memoria disponible muy baja más Pages/sec altos puede hacer que el sistema se detenga de forma impredecible.

Decisión: Si Available MB es mínimo y Pages/sec se mantiene alto durante el chasquido, cierra apps o arregla una fuga de memoria. (No es glamoroso. Funciona.)

Tarea 15: Capturar una traza corta de rendimiento para evidencia DPC/ISR (integrado)

cr0x@server:~$ wpr -start generalprofile
cr0x@server:~$ powershell -NoProfile -Command "Start-Sleep -Seconds 20"
cr0x@server:~$ wpr -stop C:\Temp\audio-latency.etl
WPR: Tracing session stopped.
WPR: Trace file saved to C:\Temp\audio-latency.etl

Significado: Has creado una traza ETL que puedes abrir en Windows Performance Analyzer para ver uso de CPU por DPC/ISR y qué controladores son responsables.

Decisión: Si LatencyMon no es concluyente (o quieres pruebas), esta traza es cómo dejar de discutir por sensaciones y empezar a señalar controladores específicos.

Triage de controladores: los sospechosos habituales y cómo probarlo

La mayoría de los incidentes de “chasquidos en Windows 11” no son el propio controlador de audio. El controlador de audio es el primero al que se culpa porque es el que puedes oír. Los ofensores habituales son:

• Controladores Wi‑Fi (tormentas de interrupciones, transiciones de ahorro de energía).
• Controladores GPU (picos DPC, endpoints de audio HDMI no usados).
• Controladores de almacenamiento (menos común ahora, pero ocurre con drivers RAID/filtrado extraños).
• ACPI / chipset (gestión de energía de plataforma, comportamiento del temporizador).
• Controladores de controladora USB (problemas del host controller, suspensión selectiva).
• APOs de “mejoras” de audio (plugins DSP de suites OEM).

Qué significa realmente “arreglar controladores”

“Actualizar el controlador” a veces es correcto y a veces es como crear un nuevo problema. En términos de producción: los controladores son módulos kernel; trátalos como despliegues riesgosos.

• Si los chasquidos empezaron después de una actualización de Windows u OEM: retroceder es una mitigación válida.
• Si usas un controlador muy antiguo: actualizar puede corregir bugs DPC conocidos.
• Si usas pilas de audio personalizadas de OEM en portátiles: el “controlador genérico más reciente” puede quitar ajustes OEM y romper detección de jack o arrays de micrófonos.

Desactiva lo que no usas (reduce el radio de impacto)

Los endpoints de audio no usados siguen cargando componentes y pueden ser sondeados. Desactivar endpoints HDMI de NVIDIA/AMD no usados es uno de los movimientos más seguros de “menos cosas en ejecución”.

La misma lógica aplica a “efectos” de audio OEM. Si no los necesitas explícitamente, desactiva las mejoras (lo haremos más adelante). Tus oídos quieren estabilidad, no una sala de conciertos virtual.

Broma #1: El chasquido de audio en Windows es solo tu PC intentando añadir percusión a tu lista de reproducción. No fue contratado, así que despídelo.

Gestión de energía: el generador silencioso de chasquidos

Ahorrar energía funciona dejando hardware dormir, aparcando núcleos de CPU y dejando que los relojes escalen hacia abajo. Cada transición tiene latencia. El audio odia picos de latencia más que un CPU un poco más lento.

Los ajustes que más importan

• Estado mínimo del procesador: demasiado bajo puede causar cambios de frecuencia rápidos y retrasos de activación.
• PCI Express Link State Power Management: puede introducir latencia de activación para dispositivos detrás de PCIe (incluyendo algunas rutas de audio).
• Suspensión selectiva de USB: puede poner tu dispositivo de audio o hub a dormir en el peor momento.
• Ahorro de energía del adaptador inalámbrico: intercambia batería por picos de latencia.

Mi regla con opinión

Si te importa el audio en tiempo real en un portátil Windows, crea un plan de energía dedicado “Audio”. Balanced es para hojas de cálculo. Alto rendimiento es para pruebas. Un plan personalizado es para vivir con él.

En entornos corporativos, “no podemos cambiar políticas de energía” es común. A menudo puedes: los ajustes de plan de energía por usuario suelen permitirse incluso cuando no puedes cambiar BIOS.

USB y hubs: donde “funciona bien” va a morir

El audio USB suele ser estable—hasta que no lo es. El problema principal: el audio es sensible al tiempo y las topologías USB son desordenadas. Tu “un cable” podría ser:

• un headset pasando por un hub del monitor,
• luego por un dock,
• luego a una controladora USB compartida con una webcam,
• mientras la suspensión selectiva intenta ahorrar 0.3 vatios,
• y un controlador está generando picos DPC.

Estrategia práctica de aislamiento USB

1. Conecta directamente al PC. Quita hubs/docks.
2. Prueba otro controlador. Los puertos traseros suelen diferir de los frontales; los puertos USB-C pueden estar en una controladora distinta.
3. Prefiere puertos USB 2 para algunos DACs si el fabricante lo recomienda. No es “más lento”; a veces es menos complejo.
4. Apaga la suspensión selectiva (Tarea 6).
5. Desactiva “Permitir que el equipo apague este dispositivo” para hubs/controladoras en el Administrador de dispositivos.

Qué no hacer

• No “arregles” los chasquidos comprando un hub alimentado al azar. Es una moneda al aire con cables extra.
• No asumas que un DAC USB es inmune a la latencia del sistema. El bus aún necesita servicio puntual.

Audio Bluetooth entrecortado: latencia con pasos extra

Bluetooth añade interferencia radio, negociación de códecs y buffering. Puede chasquear incluso cuando el audio por cable está bien. Diagnostica Bluetooth por separado; si no, perderás tiempo afinando el subsistema equivocado.

Modos de fallo comunes en Bluetooth

• Congestión en 2.4 GHz: Wi‑Fi, microondas, ruido USB 3 y dongles baratos luchan aquí.
• Toma del perfil manos libres (HFP/HSP): el headset cambia a modo HFP/HSP para usar el micrófono y la calidad baja, a veces con artefactos.
• Ahorro de energía: la radio duerme en momentos inoportunos.
• Pila de controladores: las pilas Bluetooth OEM varían mucho.

Qué ayuda realmente

• Usa Wi‑Fi en 5 GHz (o Ethernet) para reducir la contención en 2.4 GHz.
• Mueve la antena/dongle Bluetooth lejos de puertos/cables USB 3 (USB 3 puede generar ruido RF en la banda 2.4 GHz).
• En apps de comunicaciones, escoge el dispositivo correcto: los endpoints “Headset” vs “Headphones” importan.
• Actualiza controladores Bluetooth desde el OEM/proveedor del portátil si el sistema usa un combo Wi‑Fi/Bluetooth.

Broma #2: El audio Bluetooth es como una reunión improvisada sobre Wi‑Fi de hotel: funciona hasta que importa, y entonces inventa nuevas sílabas.

Ajustes de sonido de Windows que realmente importan

Los ajustes de sonido son donde la gente hace clic al azar hasta que el chasquido cambia. Hagamos menos clics, pero con intención.

Fija un formato predeterminado sensato

Elige una frecuencia de muestreo y mantenla consistente. Cambiar de formato frecuentemente puede provocar fallos en algunos controladores.

• Para Windows general + vídeo: 48 kHz, 24 bits.
• Para producción musical centrada en 44.1 kHz: 44.1 kHz, 24 bits, y mantén tu DAW alineado.

Desactiva mejoras y audio espacial (para diagnóstico)

Las mejoras son Audio Processing Objects (APOs). Pueden funcionar. También pueden ser todo el problema.

Para diagnosticar: desactiva mejoras y audio espacial. Si el chasquido para, vuelve a activar una característica a la vez—como un despliegue controlado, no un festival.

Modo exclusivo: entiende qué hace

El modo exclusivo permite a una app hablar directamente con el dispositivo, evitando el mezclador compartido. Eso puede reducir latencia y re-muestreo, pero también puede:

• provocar conflictos cuando varias apps quieren audio,
• exponer rutas de controlador con errores,
• hacer que los sonidos del sistema desaparezcan en momentos inoportunos.

Si estás solucionando chasquidos a nivel de sistema, prueba ambos: exclusivo activado y desactivado. Si eres usuario de DAW, exclusivo (o ASIO) suele ser correcto; para un “portátil de trabajo con Teams”, gana la estabilidad en modo compartido.

Buffering a nivel de app y DAW

Si el chasquido ocurre solo en una app, no culpes inmediatamente a Windows. Las apps eligen tamaños de buffer, frecuencias y a veces usan modo exclusivo sin pedir permiso.

Navegadores y apps de conferencia

• Teams/Zoom/Discord: pueden cambiar dispositivos, tomar rutas exclusivas y provocar cambios de perfil Bluetooth cuando se activa el micrófono.
• Navegadores: las opciones de aceleración por hardware pueden cambiar el comportamiento del controlador GPU e influir indirectamente en picos de latencia.

DAWs y audio profesional

Si usas un DAW:

• Empieza con un tamaño de buffer que priorice estabilidad (256–512 muestras) y reduce solo si grabas con monitorización en directo.
• Usa el controlador ASIO del fabricante cuando esté disponible; WASAPI en modo compartido no es la mejor herramienta para producción de baja latencia.
• Alinea la frecuencia de proyecto con la del dispositivo para evitar re-muestreo constante.

El audio profesional en Windows puede ser muy sólido. Solo exige que trates los cambios de controlador y energía como cambios de producción: de uno en uno, con un plan de reversión.

Tres mini-historias corporativas desde las trincheras de latencia

Incidente #1: la suposición equivocada (y una reunión cara)

Una empresa mediana desplegó portátiles con Windows 11 a un equipo de ventas. En una semana, llegaron quejas de liderazgo: “el audio chasquido en demos a clientes”. La suposición interna fue clásica: los altavoces integrados eran baratos, así que compren headsets. Compraron rápido. Llegaron las cajas. Los chasquidos persistieron.

TI montó una “sala de guerra” pequeña. El equipo reprodujo el problema de forma fiable: comparte pantalla, inicia una llamada y luego abre una descarga grande en segundo plano. El chasquido aparecía con puntualidad. El uso de CPU se mantenía bajo. Ese detalle importó; descartó “no hay suficiente potencia”.

Finalmente ejecutaron herramientas de latencia y vieron picos DPC vinculados al controlador Wi‑Fi. El detalle crítico: los portátiles estaban configurados con ahorro de energía inalámbrico agresivo para maximizar batería durante viajes. Buena intención, ambiente equivocado. Las demos no son un estudio de sueño.

La solución no fue un headset. Fue un cambio de política: desactivar el ahorro inalámbrico más agresivo en AC, actualizar el controlador Wi‑Fi a una versión estable y evitar que el SO apagara el adaptador durante la llamada. Los chasquidos desaparecieron. Los headsets pasaron a ser “opcionales” y la compra masiva se canceló discretamente.

La lección: el dispositivo de audio era inocente. El scheduler no fallaba. El comportamiento de interrupciones de un solo controlador bajo una carga específica era el dominio de fallo real.

Incidente #2: una optimización que salió mal (la batería gana, el audio pierde)

Otra organización—con muchos ingenieros y reuniones de vídeo—decidió estandarizar en ahorro energético. Empujaron ajustes para reducir consumo en background: estado mínimo de procesador más bajo, suspensión selectiva USB más agresiva y gestión de enlace PCIe. La vida de batería mejoró en los informes, lo que alegró a alguien del dashboard.

Luego la cola de helpdesk se llenó de artefactos de audio: pops, stutters, “voz de robot”, especialmente en quienes usaban altavoces USB y docks. El patrón era sutil: empeoraba tras haber estado inactivo un tiempo. ¿Primera llamada del día? Bien. ¿Segunda llamada después de comer? Caos.

El equipo asumió que los docks eran malos. Reemplazaron algunos. Seguía mal. Pensaron que los altavoces USB eran defectuosos. Reemplazaron algunos. Seguía mal. Aquí la “optimización” se vuelve “superstición cara”.

Eventualmente alguien correlacionó logs de eventos con los chasquidos: transiciones de energía de hubs USB y reinicios de dispositivo coincidían con el inicio de llamadas. La suspensión selectiva hacía su trabajo: dormir partes de la cadena USB. Pero cuando el tráfico de audio volvía, la latencia de activación y la reenumeración ocasional creaban dropouts.

La solución fue poco glamorosa: desactivar la suspensión selectiva para usuarios con audio USB en docks y afinar la energía diferente en AC vs batería. La vida de batería cayó un poco. El audio dejó de avergonzar a la gente. Los dashboards se volvieron menos verdes. Las transcripciones de reuniones fueron más precisas.

Incidente #3: la práctica aburrida que salvó el día (control de cambios para controladores)

Un pequeño grupo de TI con espíritu SRE soportaba un piso de trading donde el audio importaba para llamadas grabadas y cumplimiento. Tenían una regla: no actualizar controladores en el piso sin un anillo de staging. Sonaba burocrático hasta el día que dejó de serlo.

Windows Update ofreció un nuevo paquete de controladores GPU. En una flota normal encoges de hombros. En este piso, los controladores GPU estaban ligados a múltiples monitores, decodificación de vídeo y—sorpresa—endpoints de audio HDMI. Una máquina del anillo piloto tomó la actualización. En horas, el usuario piloto reportó pops intermitentes al mover ventanas entre monitores durante una llamada.

El equipo capturó una traza (WPR) y vio picos DPC vinculados al controlador GPU durante eventos de reconfiguración de pantalla. Revirtieron el controlador en la máquina piloto, validaron la estabilidad y bloquearon la actualización para el resto del anillo mientras probaban otra versión.

Sin heroísmos. Sin madrugadas. Solo un despliegue por etapas y una reversión. La práctica era aburrida, y por eso funcionó. El audio de producción se mantuvo limpio. Cumplimiento no llamó a nadie. El usuario piloto recibió un café y un poco de aprecio, que es lo más emocional que ese entorno permite.

Errores comunes: síntoma → causa raíz → solución

Chasquidos solo al descargar o en llamadas

• Síntoma: Pops de audio durante actividad de red; por lo demás bien.
• Causa raíz: Picos DPC del controlador NIC/Wi‑Fi, offloads, transiciones de ahorro de energía.
• Solución: Actualizar/retroceder controlador NIC, desactivar ahorro inalámbrico agresivo, probar con Wi‑Fi desactivado (Tarea 9), preferir Ethernet para llamadas.

Headset USB chasquea tras inactividad o al acoplar

• Síntoma: Primer audio tras inactividad chasquea; acoplar/desacoplar provoca dropouts.
• Causa raíz: Suspensión selectiva USB, gestión de energía de hubs, topologías de dock.
• Solución: Desactivar suspensión selectiva USB (Tareas 5–6), desactivar apagado en hubs, conectar el dispositivo directamente o a otro controlador/puerto.

Chasquidos tras actualizar el controlador GPU

• Síntoma: Pops al jugar, mover ventanas o cambiar monitores.
• Causa raíz: Picos DPC del controlador GPU; endpoints HDMI de audio no usados; overlays.
• Solución: Instalación limpia de un controlador GPU estable, desactivar endpoints de audio GPU no usados, reducir overlays, volver a probar con toggles de aceleración por hardware en la app.

Solo Bluetooth entrecorta; el cableado está bien

• Síntoma: Audio Bluetooth se corta; USB/3.5 mm limpio.
• Causa raíz: Interferencia en 2.4 GHz, cambio de perfil, ahorro de energía/driver Bluetooth.
• Solución: Usar Wi‑Fi 5 GHz, mover el dongle lejos del ruido USB 3, asegurar selección correcta de endpoint, actualizar controladores Bluetooth.

Chasquidos en una app específica

• Síntoma: DAW chasquea con buffer bajo; otras apps bien.
• Causa raíz: Buffer demasiado bajo, desajuste de frecuencia, conflicto de modo exclusivo.
• Solución: Aumentar buffer, alinear la frecuencia, usar ASIO, desactivar otras apps de audio, probar modo exclusivo.

Chasquidos con “mejoras” activadas

• Síntoma: Activar espacial/mejoras empeora los pops.
• Causa raíz: APO/DSP defectuoso, latencia de procesamiento adicional.
• Solución: Desactivar mejoras/espacial; si las necesitas, actualiza el software OEM y reactiva un efecto a la vez.

Chasquidos a pesar de CPU baja y “todo actualizado”

• Síntoma: El Administrador de tareas parece tranquilo; el audio sigue con pops.
• Causa raíz: Alto tiempo DPC/ISR (prioridad kernel), no visible como CPU de usuario.
• Solución: Mide con herramientas de latencia; aísla desactivando dispositivos temporalmente; usa una traza WPR (Tarea 15) para identificar el controlador.

Listas de verificación / plan paso a paso

Lista A: plan de 20 minutos “haz que pare”

1. Reproduce el chasquido a demanda (misma canción/vídeo, mismo volumen, misma carga).
2. Cambia al plan Alto rendimiento (Tarea 4). Vuelve a probar.
3. Desactiva suspensión selectiva USB (Tarea 6). Vuelve a probar (especialmente para audio USB).
4. Desactiva Wi‑Fi temporalmente (Tarea 9). Vuelve a probar con audio local.
5. Desactiva endpoints de audio no usados (audio HDMI GPU, dispositivos virtuales) en Administrador de dispositivos. Vuelve a probar.
6. Desactiva mejoras/espacial para el dispositivo de reproducción activo. Vuelve a probar.
7. Configura formato por defecto a 48 kHz 24-bit (o alinea con tu flujo). Vuelve a probar.
8. Si es Bluetooth: cambia a cableado para una prueba y confirma que es asunto de radio.

Lista B: estabilizar sin vivir en Alto rendimiento

1. Clona tu plan actual en un plan personalizado “Audio”.
2. En corriente alterna: sube el estado mínimo del procesador, desactiva suspensión selectiva USB, reduce el ahorro de enlace PCIe.
3. En batería: mantén valores sensatos, pero evita el ahorro inalámbrico más agresivo si atiendes llamadas con batería.
4. Documenta versiones de controladores estables (Wi‑Fi, GPU, audio, chipset).
5. Tras cada ciclo de Windows Update: valida de nuevo con una prueba de estrés de audio de 5 minutos.

Lista C: cuando necesitas pruebas (para TI, proveedores o tu yo futuro)

1. Captura una traza WPR durante el chasquido (Tarea 15).
2. Exporta logs de eventos del Sistema relevantes alrededor de las marcas de tiempo (Tarea 12).
3. Registra: dispositivo usado (USB/Bluetooth/interno), estado de energía (AC/DC) y red activa (Wi‑Fi/Ethernet).
4. Haz un cambio. Vuelve a probar. Lleva notas.

Preguntas frecuentes

1) ¿Por qué el audio chasquea cuando el uso de CPU es bajo?

Porque el problema suele ser latencia DPC/ISR, no carga media de CPU. Un controlador puede bloquear la planificación en tiempo real brevemente y causar subejecuciones de buffers.

2) ¿Es LatencyMon obligatorio?

No, pero es cómodo. También puedes usar trazas integradas WPR/WPA (Tarea 15) para ver comportamiento DPC/ISR e identificar controladores problemáticos.

3) ¿Debo desactivar “mejoras de audio”?

Para diagnóstico, sí. Las mejoras son componentes DSP que pueden añadir latencia o tener errores. Si desactivarlas arregla el problema, reactiva solo lo que realmente quieras.

4) ¿Qué frecuencia de muestreo debería usar: 44.1 kHz o 48 kHz?

Para Windows general y vídeo, 48 kHz suele ser lo menos sorprendente. Para producción musical centrada en 44.1 kHz, ajusta el dispositivo y el proyecto a 44.1 kHz para reducir re-muestreos.

5) ¿Comprar un DAC USB externo arregla siempre los chasquidos?

No. Puede mejorar ruido analógico y evitar un códec integrado malo, pero no arregla mágicamente la latencia DPC o problemas de gestión de energía USB.

6) ¿Por qué Bluetooth es peor que por cable?

Bluetooth añade interferencia radio, buffering de códecs y cambios de perfil (especialmente cuando el micrófono está activo). Las rutas por cable eliminan una clase entera de modos de fallo.

7) ¿Debería usar “Ultimate Performance”?

Úsalo como prueba. Si arregla los chasquidos, crea un plan personalizado que mantenga los ajustes específicos necesarios sin arruinar la batería permanentemente.

8) ¿Cuál es la forma más rápida de aislar el controlador culpable?

Desactiva dispositivos uno a la vez: Wi‑Fi, Bluetooth, endpoints de audio GPU no usados, docks/hubs. Si necesitas evidencia sólida, captura una traza WPR e inspecciona DPC/ISR por controlador.

9) Solo oigo chasquidos en juegos—¿qué pruebo primero?

Prueba estabilidad del controlador GPU (instalación limpia), desactiva overlays y confirma que el juego no fuerza un formato de audio raro. También revisa ajustes de energía—los portátiles para juegos adoran las transiciones de energía agresivas.

10) ¿El almacenamiento puede causar chasquidos de audio?

Menos común en sistemas modernos, pero sí: controladores filtro, drivers de cifrado o controladoras de almacenamiento defectuosas pueden crear picos de latencia. Si los logs de eventos muestran reinicios de almacenamiento, no los ignores.

Siguientes pasos (el estado estable y aburrido)

Si quieres audio sin chasquidos en Windows 11 sin comprar hardware, la jugada ganadora no es un ajuste mágico. Es un bucle disciplinado:

1. Reproduce el problema de forma fiable. Si no puedes reproducirlo, no lo puedes arreglar—solo lo reordenas.
2. Mide la latencia, no adivines. Usa herramientas de latencia o una traza WPR cuando haga falta.
3. Estabiliza la energía. Un plan personalizado “Audio” vence a “Alto rendimiento” permanente.
4. Simplifica controladores. Desactiva lo que no uses; actualiza o revierte al culpable.
5. Mantén USB simple. Puertos directos, sin ruleta de hubs, sin suspensión selectiva para audio USB.
6. Cambia una cosa a la vez. Estás depurando, no realizando un ritual.

Haz eso y los chasquidos desaparecen. Tu sistema se vuelve aburrido. Que, en operaciones, es el mayor cumplido.