¿Por qué se corta el audio si el uso de la CPU es bajo? — Pensarlo en términos de búferes y plazos

Está escuchando música y de vez en cuando se corta con un chasquido. Abre el Administrador de tareas y el uso de la CPU ronda el 10 %. El vídeo sigue reproduciéndose y el ratón se mueve con normalidad.

Dan ganas de preguntar: «con todo este margen, ¿reproducir audio es realmente demasiado pedir?»

Pero lo que el audio necesita no es solo la capacidad de despachar mucho trabajo deprisa. También necesita que el siguiente tramo de sonido esté listo antes de que se agote el que suena ahora. Este artículo sigue esa reposición tardía, el mecanismo que hay detrás de un corte típico.¹

Partimos de la escena de reproducir música en un PC. Las secciones 1 a 4 cierran la explicación del mecanismo, y de la sección 5 en adelante se reúnen los métodos de investigación. Se supone en todo momento una salida de audio en Windows 11, y las cifras son supuestos usados para explicar.

1. El audio suena mientras se guarda de reserva un poco de lo que viene

Un archivo de música guardado en el PC no hace sonar los altavoces por el mero hecho de estar ahí. La aplicación de reproducción prepara los datos de audio y los entrega, a través de Windows y del controlador, al dispositivo que produce el sonido. En el modo compartido habitual, el motor de audio de Windows mezcla por el camino varias secuencias y aplica efectos.²

Si el audio se entregara pieza a pieza justo cuando hace falta, el más mínimo retraso de procesamiento se reflejaría directamente en la reproducción. Por eso se guarda de antemano un poco de lo que se reproducirá a continuación. Ese lugar de retención temporal es el búfer. Mientras la reproducción avanza del lado del dispositivo, la aplicación y el procesamiento de audio lo reponen con los datos siguientes.³

flowchart TB
    accTitle: Almacenar un poco de sonido en el búfer y después reproducirlo
    accDescr: El flujo de reponer el búfer con datos de audio preparados y preparar los datos siguientes mientras la reproducción avanza del lado del dispositivo.
    A["Preparar los datos de audio siguientes"] --> B["Reponer el búfer"]
    B --> C["Reproducir el audio del búfer"]
    C -.->|"Antes de que se agote el resto"| A

Figura 1: Para que la reproducción continúe, la reposición tiene que seguir el ritmo del lado que consume el audio.

Supongamos que el búfer contiene ahora mismo 10 milisegundos de audio. Si la siguiente reposición llega dentro de 8 milisegundos, enlaza cuando todavía queda algo. Pero si no llega nada hasta dentro de 12 milisegundos, la reserva se agota en la marca de los 10 milisegundos.

flowchart TB
    accTitle: Los mismos 10 milisegundos restantes, distinto resultado según cuándo llegue la reposición
    accDescr: Como supuesto para explicar, se muestra que con 10 milisegundos de datos de reproducción restantes una reposición 8 milisegundos después llega a tiempo, mientras que una 12 milisegundos después llega tras el agotamiento.
    A["Ahora quedan 10 milisegundos"] --> B["Reposición 8 ms después"]
    B --> C["Enlaza mientras queda algo"]
    A --> D["Reposición 12 ms después"]
    D --> E["Reserva agotada a los 10 ms"]

Figura 2: Un ejemplo simplificado en términos de tiempo. Lo que importa no es solo si hubo reposición, sino cuándo.

Quedarse sin reserva porque el suministro de los datos de audio necesarios no llega a tiempo es un underrun. Provoca cortes, chasquidos y artefactos similares. Aunque los datos aparezcan tarde, un hueco ya oído no puede rellenarse después.¹

La reproducción de audio es un trabajo en el que «al final se calculó» no basta; lo que hace falta es «estaba listo cuando tenía que sonar».

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (5 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Por qué la reposición llega tarde aunque la CPU esté ociosa

Al oír esto, la reacción natural es: «entonces, si la CPU está ociosa, ¿por qué no reponer antes?»

Pero la cifra de uso de CPU no es un recuento de plazos de audio cumplidos. Lo ocupada que estuvo toda la CPU durante un intervalo y si el breve trabajo que repone el audio pudo ejecutarse en el momento necesario son dos cosas distintas. Una carga global baja no garantiza que al trabajo de audio le llegue el turno de inmediato cada vez.⁴

En los términos del ejemplo anterior, aunque haya margen durante la mayor parte de un segundo, un único tramo en el que la reposición no puede producirse durante 12 milisegundos agota los 10 milisegundos de audio que quedaban. El margen que exista más adelante en ese segundo no rescata esa única llegada tardía.

No un cálculo lento, sino la espera de una ocasión para ejecutarse

Supongamos que el código que prepara los datos de audio está esperando a que termine una lectura de archivo. O que espera un bloqueo que mantiene otro trabajo dentro de la aplicación. Mientras espera, ese código consume poca CPU. El audio que ya suena se sigue vaciando igualmente. Un suministro tardío de datos y un subproceso en espera se producen con independencia de que se agote la CPU.⁵⁴

flowchart TB
    accTitle: La reproducción avanza incluso durante un tiempo de espera que no consume CPU
    accDescr: La reproducción avanza mientras el procesamiento de audio espera datos o un bloqueo, de modo que el búfer puede vaciarse con el uso de CPU todavía bajo.
    A["El procesamiento de audio espera datos"] --> B["Ese trabajo no consume CPU"]
    A --> C["La reproducción continúa y lo que queda mengua"]
    C --> D["Una reposición tardía significa quedarse sin reserva"]

Figura 3: «No usar la CPU» no es lo mismo que «el trabajo necesario está hecho».

También dispositivos aparentemente ajenos al audio pueden retenerlo

Hay un segundo caso, en el que el turno no llega del lado de Windows.

Cuando llega una notificación de un dispositivo de red o similar, Windows ejecuta el código que atiende la interrupción. La breve primera parte de ese trabajo es la ISR, y el mecanismo que aplaza el resto del trabajo es el DPC. Mientras se ejecuta un DPC o una ISR corriente, esa CPU lógica no puede ejecutar subprocesos corrientes. El procesamiento de audio también está sujeto a ello.⁶⁴

Cuando ese trabajo se prolonga o se repite a menudo en la CPU en la que el audio necesita ejecutarse, la oportunidad de reponer el audio se desplaza hacia atrás. El material de Microsoft sobre análisis de rendimiento para audio y vídeo explica también que DPC e ISR largos procedentes de controladores de red, almacenamiento, gráficos y otros pueden causar fallos de audio.⁵

flowchart TB
    accTitle: Cuando responder a un dispositivo retrasa la ejecución del audio
    accDescr: Cuando un DPC o una ISR corriente se prolonga en la CPU que el procesamiento de audio necesita, la ejecución del subproceso se retrasa y el plazo de reposición puede verse afectado.
    A["DPC o ISR en la misma CPU"] -->|"Cuando se prolonga"| B["La ejecución del audio queda retenida"]
    B --> C["La siguiente reposición llega tarde"]
    C --> D["Un corte en cuanto se agota lo que queda"]

Figura 4: No solo el dispositivo que produce el sonido; el trabajo destinado a otros dispositivos puede tener un efecto indirecto.

Dicho de otro modo, un corte no es solo «la CPU es demasiado lenta para terminar el cálculo». El cálculo no puede empezar, o los datos que necesita no llegan. Esa espera también es tiempo arrancado al plazo del audio.

3. Entonces, ¿por qué no guardar sin más mucho audio de reserva?

Si la reposición llega un poco tarde, parece sensato guardar reserva suficiente para absorber ese retraso. Ese es exactamente el razonamiento que lleva a agrandar el búfer de audio.

En las mismas condiciones, guardar más audio por adelantado hace más llevaderos los retrasos breves de reposición. Pero ahora el audio recién producido espera detrás del audio ya guardado de reserva.¹²

Si solo escucha música, esperar un instante tras pulsar Reproducir quizá no le moleste. Cuando toca un teclado conectado al PC, o procesa su propia voz desde un micrófono y se escucha, esa espera se convierte en un desfase entre el gesto y el sonido.

flowchart TB
    accTitle: Margen del búfer y respuesta más lenta
    accDescr: Guardar más audio por adelantado facilita absorber los retrasos temporales de reposición, mientras que también crece la espera antes de que se reproduzca el audio nuevo.
    A["Guardar más audio por adelantado"] --> B["Los retrasos de reposición se absorben mejor"]
    A --> C["El audio nuevo espera detrás"]
    C --> D["Más demora del gesto al sonido"]

Figura 5: Aumentar el búfer es un ajuste que compra margen a costa de la capacidad de respuesta.

Los ajustes de búfer de 128, 256 y 512 que aparecen en el software de producción musical se refieren también a ese tiempo. En PCM, la unidad que agrupa las muestras de todos los canales en el mismo instante se llama fotograma. A 48 kHz, 480 fotogramas son 480 dividido entre 48000 segundos, es decir, 10 milisegundos de audio. A igual frecuencia de muestreo, cuantos más fotogramas, más largo es el tramo de audio que contienen.³

Lo que se ha contado aquí es la duración de audio que representa ese búfer. En la práctica hay también procesamiento en la aplicación, el controlador y el dispositivo, así que manténgalo aparte de la latencia total entre pulsar una tecla y oír la nota. Tampoco todas las aplicaciones de Windows comparten un único ajuste común de búfer; los tamaños que se pueden elegir varían asimismo con el dispositivo y el controlador.²

Así pues, menor no es más rendimiento, y mayor tampoco es la respuesta correcta. El ajuste consiste en conservar la capacidad de respuesta que necesita tomando a la vez margen suficiente para evitar los cortes.

4. Lo que el audio necesita es cumplir plazos, no velocidad media

Volvamos a la pregunta inicial.

El audio se corta con un uso bajo de CPU porque tener margen en la capacidad global de procesamiento y entregar a tiempo el siguiente tramo de sonido son dos cosas distintas.

El audio suena a partir de una pequeña cantidad guardada de reserva. Esa reserva se repone antes de agotarse. Una sola reposición tardía puede bastar para provocar un hueco, y aumentar la reserva aporta margen pero también alarga el tiempo hasta que se oye el audio nuevo.

Ese es el núcleo del mecanismo. También cambia la pregunta que uno se hace al investigar, de «a qué porcentaje estaba la CPU» a «en el instante en que el audio se cortó, qué estaba esperando el siguiente tramo de sonido». A partir de aquí viene la parte de investigación, para acotar un síntoma real.

5. Investigación: averigüe primero qué combinación se corta

Un chasquido que haya oído no acredita por sí solo el underrun descrito hasta aquí. El propio material de origen, el procesamiento de la aplicación, los efectos de audio, el dispositivo de salida y otros problemas producen síntomas parecidos. El material de resolución de problemas de Microsoft también incluye las mejoras de audio, el formato y los controladores entre las cosas que comprobar.⁷

No cambie ajustes en bloque al principio. Reproduzca la misma fuente breve durante aproximadamente el mismo tiempo y compare las diferencias una a una. Hágalo fuera de una reunión o una grabación en curso, después de guardar su trabajo, y a un volumen que no maltrate los oídos.

En ese orden, la queja de una línea «el audio se corta» puede concretarse lo bastante como para decir «se corta solo en esta aplicación, cuando se usa esta salida». Deshacer cada cambio y volver a probar también facilita distinguir si el síntoma simplemente no se dio por casualidad.

flowchart TB
    accTitle: Comparación que cambia una condición y luego la deshace
    accDescr: Confirmar la reproducción con la misma fuente, cambiar una condición como la aplicación o la salida y registrar también el resultado tras deshacerla.
    A["Reproducir con la combinación original"] --> B["Cambiar una condición y reproducir"]
    B --> C["Deshacer y reproducir"]
    C --> D["Registrar condiciones y horas de los cortes"]

Figura 6: Más que una mejora puntual, confirme que la condición y el síntoma coinciden de forma repetida.

Tenga en cuenta que cambiar la salida cambia también el controlador, los búferes y más. «Por cable no se corta» es una pista para investigar la ruta de salida, pero por sí sola no acredita el enlace inalámbrico como causa. Del mismo modo, una mejora al usar un búfer mayor es una pista de que más margen de tiempo ayudó; no prueba un defecto de un controlador concreto.

Para comparar las mejoras de audio, seleccione en Windows la salida en cuestión en Configuración > Sistema > Sonido y, donde esté disponible, desactive las mejoras de audio y vuelva a probar. Anote el ajuste original y restáurelo si no cambia nada. Obtenga los controladores de Windows Update o de la distribución oficial del fabricante del dispositivo, y registre las versiones antes y después del cambio.⁷

6. Investigación: grabe el instante del corte y amplíelo

Cuando comparar condiciones no acota nada, o cuando sospecha de un procesamiento del lado del controlador, grabe lo que ocurre en un intervalo breve. Windows Performance Recorder (WPR) realiza la grabación, y Windows Performance Analyzer (WPA) es la herramienta para examinar en detalle la línea de tiempo grabada.⁸

Inicie la grabación antes de reproducir el problema

En una máquina donde esté instalado el Windows Performance Toolkit, abra More Options en la ventana de WPR. Entre los perfiles integrados están Audio glitches y CPU usage. Partiendo del primero, elija una grabación que permita examinar las discontinuidades de audio junto con la actividad de la CPU. Compruebe los perfiles disponibles y sus nombres en la versión que haya instalado.⁹

Inicie la grabación y reproduzca después audio en las condiciones halladas antes. Anote las horas de los cortes y lo que estaba haciendo y, tras reproducir el síntoma, termine la grabación con Save para escribir el archivo ETL. Cancel no lo guarda. Incluir un poco de un tramo limpio le da una referencia de comparación. Si se le pide detener una grabación existente, cancele el inicio y consúltelo con la persona responsable, para no interrumpir otra investigación.¹⁰

flowchart TB
    accTitle: Hacer una grabación breve que incluya el corte
    accDescr: Iniciar una grabación en WPR, reproducir el síntoma y anotar la hora, después detener y guardar la grabación y examinarla en WPA.
    A["Iniciar la grabación en WPR"] --> B["Reproducir el corte en las mismas condiciones"]
    B --> C["Anotar la hora y las acciones, después guardar"]
    C --> D["Ampliar el intervalo circundante en WPA"]

Figura 7: Conserve el intervalo en que se produjo el síntoma, no el uso de CPU una vez pasado.

Un archivo ETL puede contener nombres de procesos, rutas de archivo y demás, así que siga las normas de su organización y compártalo solo con quienes lo necesiten. La grabación puede requerir privilegios o herramientas adicionales; en un PC de empresa, consulte a un administrador. Como la carga de la propia grabación puede alterar el síntoma, anote si había una grabación en curso. Prefiera una grabación breve ajustada a su objetivo antes que una larga con todos los proveedores activados. En una grabación que informe de eventos perdidos, no dé por sanos los intervalos que no puede ver.¹⁰

Qué ocurrió al mismo tiempo, en vez de una clasificación de cifras grandes

En WPA, amplíe la zona alrededor del corte usando los eventos de audio capturados y las horas anotadas. En ese mismo intervalo de tiempo, examine DPC/ISR y CPU Usage (Precise), que muestra la ejecución y las esperas de los subprocesos. Si faltan esos datos, compruebe si el perfil captura los eventos que necesita y vuelva a grabar. Una ausencia de registros no equivale a una ausencia de problema.⁴⁹

El punto de partida es ver si el subproceso relacionado con el audio estaba listo para ejecutarse pero esperaba su turno, o no podía ejecutarse porque esperaba datos o algo parecido. En el primer caso, busque DPC, ISR y similares que se prolongaran en esa CPU. En el segundo, rastree qué liberó la espera, con los registros y las pilas disponibles. Como un subproceso en ejecución también puede ser interrumpido, no se limite al tiempo Ready; superponga los intervalos en que se ejecutaron DPC e ISR.⁴

flowchart TB
    accTitle: Examinar cómo se esperó durante el intervalo del corte
    accDescr: Para el subproceso de audio en el intervalo considerado, separar la espera en estado listo de la espera sobre datos o similares y contrastar los registros correspondientes.
    A["El mismo intervalo alrededor del corte"] --> B["Listo para ejecutarse pero esperando turno"]
    A --> C["Esperando datos o similares"]
    B --> D["Contrastar el trabajo en la misma CPU"]
    C --> E["Rastrear qué liberó la espera"]

Figura 8: No entresaque solo los valores máximos; léalos superpuestos al intervalo en que el procesamiento de audio era necesario.

Aunque encuentre un DPC o una ISR largos, no mire el nombre del módulo y decida al instante «este controlador es el culpable». Puede estar viendo un valor grande de otro momento, o un componente compartido por el que pasan varios dispositivos. Combine la correspondencia temporal con el corte, las CPU implicadas y los resultados de cambiar condiciones, y pida al fabricante del dispositivo que lo investigue si hace falta.

Tampoco se puede trazar una línea universal del tipo «un DPC por debajo de tantos microsegundos nunca causa un corte en ningún PC». Los umbrales de advertencia de la documentación están condicionados por esa evaluación. No los use como prueba de aprobado o suspenso desligada del plazo real de reposición y del margen del búfer.⁵

7. Para desarrolladores: no lleve esperas largas al código que entrega el audio

Cuando es usted quien construye una aplicación de audio, el punto de partida es el mismo. El código que rellena el siguiente búfer tiene que cumplir todos los plazos.

WASAPI ofrece una forma de recibir, como evento, el momento en que se puede procesar un búfer. MMCSS, por su parte, facilita asignar tiempo de CPU a los subprocesos que hacen trabajo multimedia con restricciones de tiempo. Ninguno de los dos es, sin embargo, una magia que elimine las esperas. MMCSS tampoco le preparará por adelantado los datos de audio desde el disco.¹¹¹

El diseño adecuado consiste en separar el código que lee de archivos o de la red del código que entrega el audio. Realice por adelantado el trabajo cuyo comportamiento temporal es difícil de predecir, y use para la entrega un búfer reservado de antemano. Del lado del audio, dispóngalo de modo que no haga falta esperar una respuesta de la interfaz, un bloqueo largo, una escritura síncrona de registro o similares. Es una pauta de diseño para desacoplar las esperas de datos del plazo.

flowchart TB
    accTitle: Separar la preparación difícil de predecir del suministro de audio
    accDescr: Un diseño que realiza por adelantado las lecturas y trabajos análogos y pasa los datos preparados al procesamiento de audio a través de un búfer, reduciendo las esperas largas justo antes del plazo.
    A["Preparar datos en trabajo hecho por adelantado"] --> B["Zona de entrega reservada de antemano"]
    B --> C["Entregar al procesamiento de audio lo que necesita"]
    C --> D["Alimentar el destino de salida de audio"]

Figura 9: La cuestión no es eliminar el trabajo lento, sino sacarlo del instante previo a la entrega del audio.

Incluso con esa separación, la reserva se agota si el lado de la preparación se atasca mucho tiempo. Más allá del tiempo medio de procesamiento, registre las ocasiones en que el procesamiento o una espera se prolongaron y el número de fallos de suministro, de un modo que no perturbe el procesamiento de audio. Compruebe a través de la API o del controlador el tamaño de búfer y el periodo realmente elegidos, y no dé por hecho que «el valor que indiqué se adoptó tal cual».³²

Evite recomendar a los usuarios que pongan todo el reproductor en prioridad de tiempo real. Corre el riesgo de estorbar otros trabajos importantes, y elevar la prioridad de un subproceso corriente no resuelve los DPC, las ISR ni las esperas de datos.¹²⁴

8. Resumen: un uso bajo de CPU no es prueba de que se cumpliera el plazo del audio

Hay tres ejes para pensar los cortes: guardar audio de reserva, reponerlo antes de que se agote, y una reposición tardía significa un hueco. Incluso con un uso bajo de CPU, una espera en el momento que importa puede retrasar la reposición.

Empiece comparando aplicaciones y salidas con la misma fuente y, si eso sigue sin explicar nada, grabe el intervalo del corte. Pasar de «por qué, si la CPU tiene margen» a «qué estaba esperando en ese instante» pone a la vista lo siguiente que examinar.

Artículos relacionados

• Configuración de la programación del procesador en Windows y servicios en segundo plano
• Acotar con seguridad un disco de Windows al 100 %
• ¿Por qué RDP va lento en una conexión rápida?

Enlaces de referencia

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué se corta el audio cuando el uso de la CPU ronda solo el 10 %?

El audio tiene un plazo: los datos siguientes deben reponerse antes de que se agoten los que se están reproduciendo. Aun con un uso global de CPU bajo, la reposición puede incumplir ese plazo si el procesamiento de audio no pudo ejecutarse en ese instante o estaba esperando los datos que necesitaba. No todos los cortes tienen esta causa, así que hacen falta también comparaciones que cambien el dispositivo de salida y la aplicación.

¿Agrandar el búfer de audio soluciona los cortes?

Cuando la reposición se retrasa de forma puntual, un búfer mayor puede absorberlo. Pero también crece la espera antes de que se reproduzca el audio acumulado. No es un ajuste que resuelva una carencia sostenida de capacidad de procesamiento ni un dispositivo que se desconecta. En las aplicaciones y controladores donde se puede cambiar, anote el valor original y compare un paso cada vez.

A 48 kHz, ¿cuántos milisegundos de audio son 480 fotogramas?

Son 480 dividido entre 48000 segundos, es decir, 10 milisegundos. Un fotograma PCM es la unidad que agrupa las muestras de todos los canales en el mismo instante. Ese valor es la duración de audio que representa ese número de fotogramas, no la latencia total que incluye el dispositivo y la aplicación.

¿Es culpable de un corte un controlador con tiempos de ejecución de DPC o ISR largos?

Es un candidato, pero una clasificación basada solo en el tiempo de ejecución no lo resuelve. Contraste el intervalo en que se produjo el corte con las esperas del subproceso de audio y con la ejecución de DPC/ISR en la misma CPU. No concluya a partir de un nombre de módulo que un dispositivo o controlador concreto es defectuoso, y compruebe también los resultados de cambiar las condiciones de reproducción.

¿Mejora algo poner el reproductor en prioridad de tiempo real?

No como recomendación general. Elevar la prioridad de un subproceso corriente no permite adelantar a los DPC e ISR corrientes de la misma CPU, y no elimina las esperas sobre datos o bloqueos. Quien desarrolla debería usar mecanismos como MMCSS junto con un diseño que no introduzca esperas en la ruta de audio, mientras que los usuarios deberían comparar primero las condiciones de reproducción y las rutas de salida.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.