¿Por qué se corta el sonido si el uso de CPU es bajo? — Razonar a partir del búfer y del plazo

Mientras escucha música, de vez en cuando el sonido se corta con un «clic». El Administrador de tareas muestra un uso de CPU de alrededor del 10 % y, aun así, lo único que no es estable es el audio. En un caso así, ¿por qué se corta el sonido aunque la CPU tenga margen?

Aunque el uso de CPU sea bajo, el sonido puede cortarse si la reposición de los siguientes datos de audio no llega a tiempo para su plazo. La razón es que los datos siguientes deben entregarse mientras se reproduce el audio que queda en el búfer. Que la reposición se retrase por esperas de datos o de bloqueos, por DPC/ISR en el procesador lógico necesario o por causas similares es algo que ocurre sin necesidad de agotar toda la CPU. Exclusive-Mode Streams, CPU Analysis

Sin embargo, el «clic» que se oye no basta por sí solo para afirmar que se trata de un underrun. La fuente de audio, la aplicación, los efectos de sonido o el dispositivo de salida, entre otros, también dan lugar a síntomas parecidos. Primero se compara con la misma fuente de audio cambiando las condiciones de una en una y devolviéndolas a su estado original; si aun así no se puede acotar la causa, se graba lo que ocurre antes y después del corte. Fix distorted or crackling audio in Windows

Este artículo aborda esa pregunta y las que la siguen: «¿basta con agrandar el búfer?» y «¿qué hay que comparar y qué hay que grabar para acotar la causa?». No pretende determinar la causa de una avería concreta solo a partir del uso de CPU o del sonido que se oye.

El ámbito es principalmente la salida de audio en Windows 11. Se comparan salidas integradas, por cable, USB, Bluetooth y otras; en el software de producción musical (DAW) se tratan también las comparaciones para los casos en que la aplicación o el controlador ofrecen un ajuste de búfer. No se cubre el diseño del sistema de grabación de audio en su conjunto ni el diagnóstico de la comunicación inalámbrica de cada dispositivo.

La explicación toma el modo compartido como ejemplo básico. La ruta real, el tamaño del búfer y el periodo de procesamiento varían según la aplicación, la API, el controlador y el dispositivo, y tampoco existe una pantalla de configuración del búfer común a todas las aplicaciones. Low Latency Audio

El uso de CPU, los 10 milisegundos restantes, los momentos de reposición y demás cifras que aparecen aquí son supuestos para la explicación. No son el informe de una medición en un PC concreto en el que se haya reproducido el fallo o comprobado una mejora. Las operaciones de la segunda mitad son procedimientos de comprobación que se realizan en el entorno del lector.

El mecanismo puede leerse en orden a partir de la siguiente sección, «Búfer de reproducción de audio». Las operaciones para investigar los cortes están en «Comparar las condiciones en que aparece el corte» y en «Grabar el corte con WPR».

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

Búfer de reproducción de audio

Guardar un archivo de música no basta para que suenen los altavoces. La aplicación prepara los datos de audio y los hace llegar al dispositivo de salida a través de Windows y del controlador. El búfer de reproducción de audio es la zona que almacena temporalmente los datos que se van a reproducir a continuación. Mientras el dispositivo reproduce los datos actuales, el lado que suministra prepara los datos siguientes y los repone. Rendering a Stream

flowchart TB
    accTitle: Acumular un poco de audio por adelantado y reproducirlo
    accDescr: Flujo en el que los datos de audio preparados se reponen en el búfer y, mientras avanza la reproducción en el dispositivo, se preparan los datos siguientes.
    A["Preparar el audio siguiente"] --> B["Reponer el búfer"]
    B --> C["Reproducir lo acumulado"]
    C -.->|"antes de agotarlo"| A

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

La figura 1 es un diagrama conceptual que solo muestra la relación entre reposición y consumo. No trata los distintos búferes de la ruta de audio real como si fueran físicamente una sola zona. Low Latency Audio

La función del búfer es absorber los pequeños desfases temporales entre quien prepara el audio y quien lo consume, para lograr una reproducción continua. Ahora bien, la capacidad del búfer y la cantidad de datos aún no reproducidos que contiene en este momento son cosas distintas. Que «tenga capacidad para 10 milisegundos» no significa que siempre queden 10 milisegundos de audio. Rendering a Stream

Aquí llamamos plazo de reposición a la restricción temporal de entregar los datos siguientes que hacen falta antes de agotar los que se están reproduciendo. El procesamiento de audio exige «haberlo tenido listo antes del momento en que debe sonar». No basta con «haberlo calculado al final». El estado en que el suministro no llega a tiempo y se agotan los datos por reproducir es un underrun, y da lugar a cortes y chasquidos. Aunque los datos lleguen después, el corte que ya se ha oído no se puede rellenar a posteriori. Exclusive-Mode Streams

Ruta de los datos de audio

En el modo compartido habitual, el motor de audio de Windows recibe los datos que prepara la aplicación de reproducción, mezcla varios sonidos y aplica efectos, y después los entrega al controlador y al dispositivo de salida. La aplicación de reproducción interviene tanto en la lectura de la fuente de audio como en el suministro al destino de salida, y el controlador y el dispositivo de salida llevan los datos al lado del dispositivo y los reproducen. Low Latency Audio

flowchart TB
    accTitle: Ruta de los datos de audio en modo compartido
    accDescr: El motor de audio mezcla los datos preparados por la aplicación de reproducción, les aplica efectos y los pasa al controlador, y el dispositivo de salida los reproduce.
    A["App de reproducción: prepara datos"] --> E["Motor de audio: mezcla y efectos"]
    E --> D["Controlador: lleva al dispositivo"]
    D --> O["Dispositivo de salida: reproduce"]

Figura 2: Ejemplo en modo compartido. El procesamiento y los búferes intermedios varían según la API y el dispositivo.

El propio dispositivo puede tener procesamiento o búferes, de modo que la latencia total no la determina solo el búfer de la aplicación. Esta explicación presupone la ruta del modo compartido y no significa que todas las API pasen por el mismo procesamiento. Low Latency Audio

Reposición con 10 milisegundos restantes

Supongamos que en el búfer quedan ahora 10 milisegundos de datos sin reproducir. Si la siguiente reposición llega a los 8 milisegundos, el audio continúa mientras aún queda algo; pero si no se puede reponer hasta los 12 milisegundos, en este ejemplo simplificado los datos se agotan al llegar a los 10 milisegundos.

flowchart TB
    accTitle: Con los mismos 10 milisegundos restantes, el resultado depende del momento de la reposición
    accDescr: Como supuesto para la explicación, con 10 milisegundos de datos por reproducir, una reposición a los 8 milisegundos llega a tiempo y una a los 12 milisegundos llega cuando ya se han agotado.
    A["Quedan 10 ms de audio"] --> B{"Siguiente reposición"}
    B -->|"a los 8 ms"| C["Sigue sonando"]
    B -->|"a los 12 ms"| D["Se agota a los 10 ms"]

Figura 3: Un ejemplo con el tiempo simplificado. No solo importa si se pudo reponer, sino cuándo.

Uso de CPU y retrasos en la reposición

El uso de CPU indica lo ocupada que estuvo la CPU durante un intervalo de tiempo. Mide algo distinto de si el procesamiento de audio pudo ejecutarse en el instante en que lo necesitaba. Aunque la CPU tenga margen durante la mayor parte de un segundo, si hay un solo intervalo de 12 milisegundos en el que no se puede reponer, ese único retraso puede cortar el sonido. La capacidad de procesamiento que sobra después no permite recuperar un instante de reproducción que ya ha pasado. CPU Analysis

flowchart TB
    accTitle: Margen medio y un único retraso de reposición
    accDescr: Aunque la CPU tenga margen durante la mayor parte de un segundo, si hay un solo intervalo de 12 milisegundos sin reposición, ese único retraso puede cortar el sonido.
    A["CPU con margen casi todo el segundo"] --> B["Una vez, 12 ms sin reponer"]
    B --> C["Ese único retraso corta el sonido"]

Figura 4: Aunque haya margen de media, el instante de reproducción que ya pasó no se recupera.

Lo que consume el tiempo disponible hasta el plazo no es solo el cálculo. También cuentan la espera hasta que el procesamiento empieza y la espera hasta que llegan los datos necesarios. Por eso, la pregunta de la investigación deja de ser solo «¿qué porcentaje de CPU había?» y pasa a ser «en el instante en que se cortó el sonido, ¿qué estaba esperando el audio siguiente?».

Esperas de datos y bloqueos

Supongamos que el procesamiento que prepara los datos de audio está esperando a que termine la lectura de un archivo. Lo mismo ocurre si espera un bloqueo que tiene otro procesamiento de la aplicación. El procesamiento que espera apenas usa la CPU, pero en el dispositivo la reproducción continúa y el audio restante va disminuyendo. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: La reproducción avanza incluso durante esperas que no usan la CPU
    accDescr: Mientras el procesamiento de audio espera datos o un bloqueo, ese procesamiento no usa la CPU, pero la reproducción avanza y el audio restante disminuye; si la reposición se retrasa, el búfer puede agotarse.
    A["El procesamiento de audio espera datos"] --> B["Ese procesamiento no usa CPU"]
    B --> C["Mientras, la reproducción avanza"]
    C --> D["Si la reposición tarda, se agota"]

Figura 5: No usar la CPU y haber terminado el trabajo necesario son cosas distintas.

DPC, ISR y el subproceso de audio

Una ISR es el procesamiento que atiende una interrupción procedente de un dispositivo. Un DPC es el mecanismo que aplaza el trabajo restante para que el procesamiento de la interrupción sea breve. Los DPC normales se ejecutan antes que los subprocesos normales del mismo procesador lógico, y mientras se ejecuta un DPC o una ISR normal, ese procesador lógico no puede ejecutar subprocesos normales. Introduction to DPCs, CPU Analysis

Aunque la CPU en su conjunto tenga margen, si estos se alargan o se repiten con frecuencia en la CPU que necesita el procesamiento de audio, el suministro puede retrasarse. La documentación de Microsoft sobre el análisis de rendimiento de audio y vídeo también menciona como posibles causas de cortes los DPC/ISR largos de controladores de red, almacenamiento, gráficos y otros. No necesariamente basta con investigar el dispositivo que emite el sonido. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Cuando la respuesta a un dispositivo retrasa la ejecución del audio
    accDescr: Si un DPC o una ISR normal se alarga en la CPU que necesita el procesamiento de audio, la ejecución del subproceso se retrasa y puede afectar al plazo de reposición.
    A["DPC/ISR en la misma CPU"] -->|"si se alargan"| B["El audio espera para ejecutarse"]
    B --> C["Se retrasa la reposición"]
    C --> D["Si se agota, se corta"]

Figura 6: El procesamiento ajeno al dispositivo que emite el sonido también puede afectar indirectamente a la reposición del audio.

No se puede trazar una línea común del tipo «si los DPC duran menos de tantos microsegundos, ningún PC tendrá cortes». Los valores de advertencia de la documentación de evaluación de rendimiento corresponden a sus condiciones de evaluación, y no se toman como criterio de seguridad desvinculado del plazo de reposición real y del margen del búfer. Results for the Streaming Media Performance Assessment

Tamaño del búfer y latencia de reproducción

En las mismas condiciones, acumular más audio por adelantado facilita absorber los retrasos temporales de reposición, pero el audio recién generado tiene que esperar detrás del que ya está acumulado. Una espera que es aceptable si solo se escucha música se nota como un desfase entre la acción y el sonido cuando se toca un teclado o cuando se procesa la voz del micrófono para escucharla uno mismo. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Margen del búfer y retraso de la respuesta
    accDescr: Acumular más audio por adelantado facilita absorber los retrasos temporales de reposición, pero también aumenta la espera hasta que se reproduce el audio nuevo.
    A["Acumular más audio por adelantado"] --> B["Absorbe mejor los retrasos"]
    B -->|"a cambio"| C["El audio nuevo espera detrás"]
    C --> D["El sonido llega tarde tras la acción"]

Figura 7: Aumentar el búfer es un ajuste que gana margen a cambio de rapidez de respuesta.

Ni «cuanto más pequeño, mejor rendimiento» ni «cuanto más grande, más acertado». Se busca un margen que evite los cortes conservando la rapidez de respuesta necesaria.

Aumentar el búfer crea margen frente a retrasos temporales del suministro. Si el suministro medio en sí no alcanza al consumo, agrandar un búfer finito solo alarga el tiempo hasta que se agota, y tampoco resuelve las desconexiones del dispositivo. Tampoco es una recomendación de que usar el modo exclusivo lo resuelva todo. Exclusive-Mode Streams

Audio de 480 fotogramas a 48 kHz

Un fotograma PCM es la unidad que agrupa las muestras de todos los canales que se reproducen en el mismo instante. Que el audio sea estéreo no significa que haya que duplicar el número de fotogramas para calcular el tiempo. La duración de audio que representa un número de fotogramas se obtiene con «número de fotogramas ÷ frecuencia de muestreo»: a 48 kHz, 480 fotogramas son 480 ÷ 48000 segundos, es decir, 10 milisegundos. Si se aumenta el número de fotogramas manteniendo los 48 kHz, también se alarga el tiempo de audio que se puede acumular. Rendering a Stream

Este tiempo es distinto de la latencia total desde que se pulsa una tecla hasta que se oye el sonido, porque también intervienen la aplicación, el controlador, el dispositivo y el tiempo de otros búferes y procesamientos. Los valores de configuración de una DAW también deben leerse comprobando la unidad y a qué búfer se refieren. Low Latency Audio

flowchart TB
    accTitle: Tiempo calculado a partir de los fotogramas y latencia total
    accDescr: Los 10 milisegundos que resultan de dividir 480 fotogramas entre 48000 son el tiempo que representa el búfer; al sumarle el procesamiento de la aplicación, el controlador, el dispositivo y otros se obtiene la latencia total desde la tecla hasta el sonido.
    A["480 ÷ 48000"] --> B["10 ms que representa el búfer"]
    B -->|"se suma otro procesamiento"| C["Latencia total de tecla a sonido"]

Figura 8: El tiempo calculado a partir de los fotogramas es solo una parte de la latencia total.

Comparar las condiciones en que aparece el corte

Primero se acota en qué combinación aparece el corte, y solo si hace falta se pasa a una grabación detallada. Lo que sigue es un procedimiento para comprobar la causa, no una lista de soluciones para aplicar todos los cambios de configuración a la vez.

Guarde su trabajo y, una vez terminadas las reuniones o grabaciones reales, haga las pruebas a un volumen que no resulte molesto para los oídos. Anote el destino de salida original, las mejoras de audio, los valores de búfer y demás, de forma que pueda volver al estado anterior. Omita los elementos cuyo ajuste no esté disponible y no modifique el registro ni nada parecido para hacer aparecer opciones de configuración.

1. Fije una misma fuente de audio corta y un tiempo de observación, y compruebe que el corte aparece en las condiciones originales.

   Anote la versión de Windows, el nombre y la versión de la aplicación, el dispositivo de salida, el tipo de conexión y la versión del controlador. Deje constancia también de la hora, la operación y el número de veces que se produjeron cortes. Si el corte no aparece en las condiciones originales, no lo dé por mejorado: vuelva a averiguar en qué condiciones aparece.

2. Elija una comparación de la tabla siguiente y reproduzca el audio cambiando solo esa condición.

   Condición que se compara	Qué se examina
   Fuente guardada en el equipo frente a reproducción por la red	Si solo ocurre al reproducir por la red. Si el formato o la ruta de procesamiento difieren aunque el contenido sea el mismo, anótelo también.
   La misma fuente reproducida en otra aplicación	Si se concentra en una aplicación concreta.
   Salida Bluetooth u otra frente a salida integrada o por cable	Si se concentra en una ruta de salida concreta.
   Mejoras de audio activadas o desactivadas	Si cambia en combinación con el procesamiento de efectos.
   Búfer actual de la DAW u otra aplicación frente a un valor un paso mayor	Si cambia al aumentar el margen de audio acumulado por adelantado. Si el retraso entre la acción y el sonido sigue siendo aceptable.

3. Si compara las mejoras de audio, desactívelas temporalmente en la salida afectada.

   En Windows, vaya a «Configuración» → «Sistema» → «Sonido», seleccione la salida afectada y, en los entornos donde esté disponible, desactive «Mejoras de audio». Si la pantalla o los elementos disponibles son distintos, consulte las indicaciones para esa versión o ese dispositivo. Fix distorted or crackling audio in Windows

4. Devuelva el ajuste modificado a su valor original y vuelva a probar con la misma fuente de audio y el mismo tiempo de observación.

   Ponga uno junto a otro los resultados de la «condición original», la «condición con un cambio» y la «condición restaurada». Los cambios que no surten efecto se devuelven a su estado original antes de pasar a otra comparación. Si se van cambiando combinaciones de ajustes sin parar, deja de saberse qué fue lo que tuvo efecto.

5. Si prueba a cambiar el controlador, hágalo después de confirmar la distribución oficial y el método de recuperación.

   Use Windows Update o la distribución oficial del fabricante del dispositivo, y anote la versión y la configuración antes y después del cambio. Compruebe de antemano si podrá volver atrás y, en los PC administrados, consúltelo con el administrador. Que el audio se reproduzca bien una vez justo después de actualizar no significa que esté resuelto: compruébelo con las mismas condiciones en que aparecía el corte. Fix distorted or crackling audio in Windows

El resultado que se busca es un registro que asocie síntoma y condiciones, del tipo «aparece con esta aplicación cuando se usa esta salida». Aunque se encuentre un ajuste que mejore la situación, eso se mantiene separado de haber determinado la causa.

flowchart TB
    accTitle: Comparación que cambia una condición y la restaura
    accDescr: Se comprueba el corte con la misma fuente de audio, se cambia una condición como la aplicación o la salida, y también se registra el resultado al restaurarla.
    A["Reproducir con la combinación original"] --> B["Cambiar una condición y reproducir"]
    B --> C["Restaurar y reproducir"]
    C --> D["Anotar condiciones y hora del corte"]

Figura 9: Más que una mejora puntual, se comprueba que condición y síntoma se corresponden de forma repetida.

Reproducibilidad antes y después de un cambio

«Se pudo atenuar el síntoma», «se pudieron acotar las condiciones» y «se identificó la causa raíz» son metas distintas. Registre la conclusión de acuerdo con lo que realmente se pudo observar.

flowchart TB
    accTitle: Tres resultados que indican relación con una condición
    accDescr: Si el corte aparece en las condiciones originales, mejora al cambiar una condición y vuelve a aparecer al restaurarla, es un indicio de relación con esa condición, pero se mantiene separado de la determinación de la causa.
    A["Aparece en la condición original"] --> B["Mejora al cambiar una"]
    B --> C["Reaparece al restaurar"]
    C --> D["Indicio de relación con esa condición"]

Figura 10: Aunque se den los tres resultados, lo que se obtiene no pasa de ser un indicio de relación.

Un uso de CPU bajo no demuestra que se hayan cumplido los plazos del audio. Al mismo tiempo, el mero hecho de que haya habido un corte no permite afirmar que la causa raíz fuera un retraso en la reposición. Compare la fuente de audio, el procesamiento de la aplicación, los efectos, la ruta de salida y demás, y juzgue dentro de lo que ha observado. Fix distorted or crackling audio in Windows

Cuando adopte una solución provisional, deje constancia de la configuración original, el cambio realizado, el tiempo de observación, si el problema volvió a aparecer y la latencia aceptable. Si la causa raíz sigue sin determinarse, anótelo también.

Grabar el corte con WPR

Esto se hace cuando la comparación de condiciones no basta para acotar la causa, o cuando se quiere investigar el procesamiento del lado del controlador. WPR es la herramienta para grabar, y WPA, la herramienta para analizar la línea temporal guardada. Prepare Windows Performance Toolkit, los permisos necesarios para grabar y un destino donde guardar el ETL. Si hay que instalar la herramienta y grabar en un PC administrado, pídaselo al administrador. Los nombres que aparecen en pantalla y los perfiles disponibles se comprueban en la versión instalada. Windows Performance Recorder

Un ETL puede contener nombres de proceso, rutas de archivo y otros datos. Antes de grabar, confirme las normas internas y con quién se va a compartir, y no lo adjunte tal cual en un lugar público. Si hay otra sesión de grabación en marcha, no la detenga por su cuenta: consúltelo con el responsable. WPR How-to Topics

1. Abra «More Options» en WPR y elija el perfil de grabación que se ajuste al objetivo.

   Entre los perfiles integrados están «Audio glitches» y «CPU usage». Elija una configuración que permita examinar las discontinuidades del audio y la actividad de la CPU. Compruebe en la versión instalada los perfiles disponibles, sus nombres y lo que recopilan, y no configure una grabación prolongada de todos los tipos. Built-in Recording Profiles

2. Inicie la grabación antes de provocar el corte.

   Si aparece una confirmación para detener una grabación existente, no continúe: cancele el inicio y consúltelo con el responsable. Iguale las condiciones con las del caso sin grabación y no descarte que la carga de la propia grabación altere el síntoma. WPR How-to Topics

3. Reproduzca el audio en las condiciones halladas en la comparación y anote la hora y la operación en que se cortó.

   Incluya también un breve tramo sin problemas antes y después del síntoma. Si en una grabación el corte no apareció, indíquelo expresamente y no la trate como una grabación que capturó la causa.

4. Cuando el corte se haya producido, termine la grabación con «Save» y guarde el archivo ETL.

   Con «Cancel» no se guarda. Anote el destino de guardado, las condiciones en que apareció el corte, si se grabó o no y si hubo advertencias de pérdida de eventos. En una grabación con pérdidas, los tramos que no se ven no se dan por normales. WPR How-to Topics

Con el archivo ETL y las notas de hora, operación y condiciones del corte, todo está listo para contrastarlos en WPA. Haber guardado la grabación no significa por sí solo que se hayan obtenido los eventos necesarios. El contenido se comprueba en la siguiente sección, «Ejecución y esperas en torno al corte».

flowchart TB
    accTitle: Tomar una grabación corta que incluya el corte
    accDescr: Se inicia la grabación con WPR, se provoca el síntoma y se anota la hora, y la grabación detenida y guardada se examina en WPA.
    A["Iniciar la grabación en WPR"] --> B["Provocar el corte en las mismas condiciones"]
    B --> C["Anotar hora y operación, y guardar"]
    C --> D["Ampliar en WPA el tramo del corte"]

Figura 11: No basta con el uso de CPU que se mira cuando el síntoma ya ha pasado; hace falta una grabación del intervalo en que se produjo.

Ejecución y esperas en torno al corte

Tenga a mano el ETL guardado y las notas con la hora en que apareció el corte. Lo que sigue es un punto de partida para la investigación en WPA. Si hace falta un análisis detallado con pilas y símbolos, pídaselo al administrador o a los desarrolladores, con cuidado en el manejo de la grabación.

1. Abra el ETL en WPA y, a partir de los eventos de audio capturados y de la hora del corte, amplíe el intervalo anterior y posterior al corte.

   Conserve también un tramo sin síntomas para comparar. No mire solo la clasificación de valores máximos: compare ajustando todo al mismo intervalo de tiempo.

2. En ese mismo intervalo, examine «DPC/ISR» y «CPU Usage (Precise)».

   Si faltan los datos necesarios, compruebe si el perfil permite obtenerlos y vuelva a grabar con WPR. Que no haya registro no es lo mismo que no haya habido problema. CPU Analysis, Built-in Recording Profiles

3. Distinga si los subprocesos relacionados con el audio estaban listos para ejecutarse pero esperando turno, o si estaban esperando datos u otra cosa.

   En el primer caso, compruebe si en los procesadores lógicos implicados se estuvieron ejecutando durante mucho tiempo DPC/ISR u otros procesamientos. En el segundo, siga con los eventos y las pilas obtenidos qué fue lo que liberó la espera. Como un subproceso en ejecución también puede verse interrumpido, no se limite al tiempo en Ready: superponga también los intervalos de DPC/ISR. CPU Analysis

4. Registre juntos la correspondencia temporal con el corte, las CPU implicadas y los resultados de cambiar las condiciones.

   No dé por causa a un dispositivo o controlador concreto solo por el nombre de módulo de un DPC/ISR largo. Puede que esté viendo un valor alto de otro momento o una parte común por la que pasan varios dispositivos.

flowchart TB
    accTitle: Examinar cómo se espera en el intervalo del corte
    accDescr: Se amplía el intervalo anterior y posterior al corte y se observa el estado del subproceso de audio. Si esperaba turno estando listo, se contrasta con los DPC e ISR de la misma CPU; si esperaba datos u otra cosa, se sigue el procesamiento que liberó la espera.
    A["Ampliar el tramo del corte"] --> B{"Estado del subproceso"}
    B -->|"esperando turno"| C["DPC/ISR"]
    B -->|"esperando datos"| D["Lo que liberó la espera"]

Figura 12: No se recogen solo los valores máximos: se leen superpuestos al intervalo en que el procesamiento de audio los necesitaba.

Si no se logra identificar la causa, la investigación se traspasa como no concluida. Se adjuntan las versiones del sistema operativo, la aplicación, el dispositivo y el controlador, los pasos para reproducir el fallo, los resultados antes y después de los cambios, la hora en que se produjo, el perfil de recopilación y si hubo advertencias de pérdida de eventos. El ETL se comparte, conforme a las normas internas, solo con quien se encargue de la investigación.

Lectura anticipada en aplicaciones de audio

Si desarrolla su propia aplicación de audio, diséñela para que el procesamiento que llena el búfer siguiente cumpla el plazo cada vez. WASAPI ofrece una forma de recibir mediante un evento el momento en que se puede procesar el búfer. Exclusive-Mode Streams

MMCSS es un mecanismo que asigna recursos de CPU a los subprocesos de procesamiento multimedia con restricciones de tiempo. No tiene funciones para preparar por adelantado los datos desde el disco ni para eliminar las esperas por bloqueos. Aunque se aproveche la asignación de MMCSS, sigue haciendo falta por separado un diseño que prepare los datos y reduzca las esperas. Multimedia Class Scheduler Service

flowchart TB
    accTitle: El ámbito del que se encarga MMCSS
    accDescr: MMCSS asigna recursos de CPU a los subprocesos de procesamiento con restricciones de tiempo, pero la preparación de los datos y la reducción de las esperas por bloqueos se resuelven con otro diseño.
    M["MMCSS: asigna recursos de CPU"] -.->|"hace falta aparte"| D["Preparar datos y reducir esperas"]

Figura 13: Asignar recursos de CPU y diseñar para que los datos lleguen a tiempo son trabajos distintos.

La pauta de diseño es separar el procesamiento que lee de archivos o de la red del que entrega el audio. La preparación cuya duración es difícil de prever se hace por adelantado, y para el intercambio se usa un búfer preasignado. En el lado del audio, todo se organiza para no tener que esperar respuestas de la interfaz de usuario, bloqueos largos ni escrituras de log síncronas.

flowchart TB
    accTitle: Separar la preparación de duración imprevisible del suministro de audio
    accDescr: Diseño en el que la lectura y otras tareas se hacen en un procesamiento anticipado y los datos preparados se pasan al procesamiento de audio a través de un búfer, para reducir las esperas largas justo antes del plazo.
    A["Preparar datos por adelantado"] --> B["Zona de intercambio preasignada"]
    B --> C["El audio entrega lo necesario"]
    C --> D["Suministro a la salida de audio"]

Figura 14: El trabajo que lleva tiempo se saca del momento justo antes de entregar el audio.

Si el lado que prepara se detiene mucho tiempo, las existencias se agotan incluso con esta separación. No se limite al tiempo medio de procesamiento: registre también, de una forma que no estorbe al procesamiento de audio, las ocasiones en que hubo procesamientos o esperas largos y el número de veces que no se pudo suministrar. Compruebe en la API o en el controlador el tamaño de búfer y el periodo que realmente se eligieron, y no dé por hecho que se adoptó tal cual el valor indicado. Rendering a Stream, Low Latency Audio

Tanto los ejemplos numéricos como los de diseño son ilustrativos: no son valores de configuración recomendados para un dispositivo concreto ni una garantía de que no habrá cortes en cualquier entorno.

Efecto de la prioridad en tiempo real

No se recomienda de forma general que el usuario cambie todo el reproductor a la prioridad «Tiempo real». Existe el riesgo de entorpecer otros procesos importantes, y elevar la prioridad de un subproceso normal no elimina las esperas por DPC/ISR ni por datos y bloqueos. En el desarrollo se usan mecanismos como MMCSS y un diseño que no introduzca esperas largas en el suministro de audio. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Esperas que persisten aunque se cambie a prioridad en tiempo real
    accDescr: Aunque el reproductor pase a prioridad en tiempo real, los subprocesos normales no pueden adelantar a los DPC e ISR de la misma CPU, las esperas de datos y bloqueos persisten y existe además el riesgo de entorpecer otros procesos importantes.
    A["Reproductor en prioridad en tiempo real"] --> B["No adelanta a DPC/ISR"]
    B --> C["Siguen las esperas de datos y bloqueos"]
    C --> D["Riesgo de entorpecer otros procesos"]

Figura 15: Aunque se suba la prioridad, persisten las esperas que retrasan la reposición del audio.

Artículos relacionados

• La «programación del procesador» de Windows y la configuración de servicios en segundo plano
• Diagnosticar con seguridad el disco al 100 % en Windows
• ¿Por qué RDP va lento si la conexión es rápida?

Referencias

• Microsoft Learn, Rendering a Stream. Suministro al búfer de reproducción, cantidad restante, tamaño real del búfer y definición del fotograma PCM.
• Microsoft Learn, Exclusive-Mode Streams. Momento del suministro al búfer y fallos de audio, equilibrio con la latencia y suministro controlado por eventos. No supone una recomendación general del modo exclusivo en sí.
• Microsoft Learn, Low Latency Audio. Ruta de audio de Windows; búferes, dispositivos, procesamiento de efectos y latencia; compromisos de la baja latencia.
• Microsoft Learn, CPU Analysis. Procesadores lógicos, estados Ready/Waiting de los subprocesos, relación entre DPC/ISR y ejecución de subprocesos, y análisis de CPU en WPA.
• Microsoft Learn, Introduction to DPCs. Mecanismo que mantiene breve el procesamiento de interrupciones y aplaza el trabajo restante a un DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR largos o frecuentes, suministro insuficiente de datos y fallos de audio. Los valores de advertencia de la evaluación no se generalizan como criterio de seguridad para todos los dispositivos.
• Microsoft Support, Fix distorted or crackling audio in Windows. Comprobación de las mejoras de audio, el formato, el controlador y otros aspectos.
• Microsoft Learn, Windows Performance Recorder. Grabación ETW, análisis con WPA y uso de Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options de WPR y perfiles integrados como Audio glitches y CPU usage.
• Microsoft Learn, WPR How-to Topics. Inicio de la grabación y guardado con Save, conflictos con sesiones existentes, y precauciones sobre la información personal y la pérdida de eventos.
• Microsoft Learn, Multimedia Class Scheduler Service. Asignación de recursos de CPU al procesamiento multimedia con restricciones de tiempo.
• Microsoft Learn, Scheduling Priorities. Prioridades de procesos y subprocesos, y precauciones sobre la prioridad en tiempo real.

Artículos relacionados

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

Temas relacionados

Estas son páginas de temas cercanos a este. A partir del artículo, puede pasar a los servicios relacionados y a otros artículos.

Servicios relacionados con este tema

Este artículo enlaza con las siguientes páginas de servicios. Puede empezar por una entrada cercana a su situación.

Preguntas frecuentes

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

¿Por qué se corta el sonido con un uso de CPU de alrededor del 10 %?

El audio tiene un plazo: los datos siguientes deben reponerse antes de que se agoten los que se están reproduciendo. Aunque el uso total de CPU sea bajo, la reposición puede no llegar a tiempo si en ese instante el procesamiento de audio no pudo ejecutarse o estaba esperando los datos que necesitaba. No todos los cortes se deben a esta causa, así que también hace falta comparar cambiando el dispositivo de salida o la aplicación.

¿Se solucionan los cortes agrandando el búfer de audio?

Cuando la reposición se retrasa de forma temporal, un búfer más grande puede absorber el retraso. Sin embargo, también aumenta la espera hasta que se reproduce el audio acumulado. No es un ajuste que llegue a resolver una falta continuada de capacidad de procesamiento ni las desconexiones del dispositivo. En las aplicaciones y controladores que permiten cambiarlo, anote el valor original y compare paso a paso.

¿Cuántos milisegundos de audio son 480 fotogramas a 48 kHz?

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

¿Es un controlador con DPC o ISR de ejecución larga el culpable de los cortes?

Es un candidato, pero la clasificación por tiempo de ejecución no basta para confirmarlo. Se contrasta 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 se concluye solo por el nombre del módulo que haya un fallo en un dispositivo o controlador concreto, y también se comprueban los resultados de cambiar las condiciones en que aparece el corte.

¿Mejora la situación si se pone el reproductor en prioridad en tiempo real?

No se recomienda de forma general. Elevar la prioridad de un subproceso normal no le permite adelantar a los DPC e ISR normales de la misma CPU, y tampoco hace desaparecer las esperas de datos o bloqueos. Los desarrolladores usan mecanismos como MMCSS y un diseño que no introduzca esperas, y los usuarios comparan primero las condiciones en que aparece el corte y la ruta 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, con especial solvencia en proyectos en los que perduran activos existentes y en investigaciones de fallos cuya causa cuesta ver.