Formato de Windows Audio: frecuencia, profundidad de bits y carga

Respuesta breve: en el endpoint Realtek USB Audio investigado, el formato 48 kHz / 24-bit siguió siendo la elección práctica. El cambio a 96 o 192 kHz no redujo el período disponible del motor de audio ni la estimación de la cola de XAudio2. La ventaja de 16-bit en CPU y el beneficio de desactivar los efectos del sistema no se confirmaron.

Estado: medido en un solo sistema, no reproducido en otro dispositivo. El resultado no puede trasladarse automáticamente a otro controlador de audio, DAC o compilación de Windows. El significado de los estados se describe en la metodología de investigaciones.

Qué se comprobó

La investigación respondía a cuatro preguntas:

1. ¿Disminuye el período del motor de audio en modo compartido al aumentar la frecuencia?
2. ¿Reduce 16-bit la carga respecto a 24-bit y 32-bit a 48 kHz?
3. ¿Produce la desactivación de los efectos de sonido del sistema una reducción reproducible de la carga?
4. ¿Cómo se relaciona el cambio de endpoint rate con el funcionamiento interno de XAudio2 para una fuente de 48 kHz?

La medición no comprobó la calidad del sonido, los FPS, la latencia del juego ni la latencia física entre la señal digital y el altavoz.

Ámbito de la investigación

Parámetro	Valor
Fecha de medición	2026-08-20
Windows	Windows 11 Pro 25H2, x64
OS build	26200.8655
Procesador	AMD Ryzen 7 7800X3D, 8 núcleos / 16 hilos
Memoria RAM	32 GB
Dispositivo	Altavoces, Realtek USB Audio
Controlador	Realtek USB Audio 6.4.0.2422 del 2025-08-07
Formato de dispositivo original	48 kHz, 24-bit PCM, estéreo
Shared mix format	48 kHz, 32-bit float, estéreo
Efectos originales	Activados
Casos de prueba	17 trazas, una traza por caso
Análisis de traza	Cinco ventanas consecutivas de 10 segundos

La traza original registró la rama de Windows build 26200 y los datos del dispositivo de audio. La revisión completa, la edición de Windows, el modelo del procesador y el volumen de memoria se leyeron adicionalmente del mismo equipo el 2026-08-24. Entre la medición y el registro repetido de la configuración transcurrieron cuatro días.

El identificador único del endpoint y las trazas del sistema en bruto no se publican.

Metodología

Los casos se ejecutaron en orden aleatorio. Para cada uno se usaron 3 segundos de calentamiento, luego 52 segundos de traza del sistema y cinco ventanas de análisis de 10 segundos.

Se comprobaron dos tipos de carga:

• un flujo WASAPI estable en modo compartido para comparar frecuencia, profundidad de bits y efectos;
• una carga sintética de XAudio2 con 8, 32 o 64 voices activos y fuentes de 44,1 o 48 kHz.

El indicador principal de Windows Audio es el scheduler running time del proceso audiodg.exe, expresado en milisegundos de trabajo por segundo. Por separado se leyeron los XAudio2 performance data, el número de glitches y las estadísticas de pérdidas de traza.

Las cinco ventanas de una misma traza están correlacionadas y se usan solo como dispersión descriptiva. No son cinco ejecuciones independientes. La carga de fondo total del sistema variaba, por lo que el CPU de toda la máquina, los DPC absolutos y las ISR no se usaron para la conclusión final.

Período del motor de audio

Endpoint rate	Frames	Período
44,1 kHz	441	10,0 ms
48 kHz	480	10,0 ms
96 kHz	960	10,0 ms
192 kHz	1920	10,0 ms

El endpoint devolvía solo un período de 10 ms. Los períodos de 5 ms y 2,5 ms no eran compatibles con su controlador. El aumento de la frecuencia incrementaba el número de frames por período, pero no reducía la duración del período.

Esta es una propiedad de la combinación concreta de dispositivo y controlador. Microsoft indica que los tamaños de buffer disponibles los determina el controlador de audio, y la aplicación puede solicitar las variantes compatibles mediante IAudioClient3. Más información: Low Latency Audio.

Frecuencia y audiodg

En la tabla se muestra la mediana y el rango de cinco ventanas dentro de una misma traza. La unidad мс/с indica cuántos milisegundos se ejecutó el proceso audiodg.exe por cada segundo de observación.

Endpoint rate	audiodg, mediana	Rango de ventanas
44,1 kHz	4,34 ms/s	4,24–4,86 ms/s
48 kHz	4,23 ms/s	4,20–5,63 ms/s
96 kHz	4,77 ms/s	4,72–5,70 ms/s
192 kHz	5,19 ms/s	5,07–5,94 ms/s

En esta serie, 96 y 192 kHz no mostraron una reducción del tiempo de audiodg.exe. Pero para cada frecuencia había una sola traza, y la carga de fondo variaba. La tabla no demuestra una diferencia de CPU universal entre frecuencias.

Profundidad de bits a 48 kHz

Formato de dispositivo	audiodg, mediana	Rango de ventanas
16-bit	4,07 ms/s	4,03–4,35 ms/s
24-bit	4,23 ms/s	4,20–5,63 ms/s
32-bit	4,20 ms/s	4,16–4,64 ms/s

Los rangos se solapan, y las repeticiones independientes son insuficientes. Con esta serie no se puede afirmar que el cambio a 16-bit produzca una reducción reproducible de la carga.

Efectos del sistema

A 48 kHz / 24-bit, la mediana de audiodg.exe fue de 4,23 ms/s con los efectos activados y de 4,39 ms/s con los efectos desactivados. El valor medio cambiaba en la dirección opuesta debido a una ventana más alta en la traza original.

No se estableció una ventaja fiable de desactivar los efectos. El resultado no es motivo para desactivarlos sin un problema concreto con el Audio Processing Object o el controlador.

XAudio2 y desajuste de frecuencia

Para una fuente fija de 48 kHz y 32 voices se obtuvieron los siguientes XAudio2 performance data:

Endpoint rate	Audio cycles/s	Respecto a 48 kHz	Estimación de cola
44,1 kHz	25 116	2,31×	37,28 ms
48 kHz	10 870	1,00×	37,27 ms
96 kHz	55 574	5,11×	37,18 ms
192 kHz	87 016	8,00×	37,18 ms

Microsoft define AudioCyclesSinceLastQuery como los CPU cycles que XAudio2 gasta en procesar audio después de la solicitud anterior. CurrentLatencyInSamples es la distancia aproximada entre los últimos datos entregados al controlador y los datos que se están reproduciendo. Véase XAUDIO2_PERFORMANCE_DATA e IXAudio2::GetPerformanceData.

El aumento del endpoint rate en este caso sintético incrementó el trabajo interno de XAudio2, pero prácticamente no cambió su estimación de cola. Para cada variante se obtuvo un solo performance summary, por lo que los coeficientes son una descripción de esta ejecución, no un pronóstico universal para juegos.

Estabilidad de las mediciones

En las 17 trazas se registró:

• 0 audio glitches;
• 0 eventos ETW perdidos;
• 0 buffers ETW perdidos.

Qué se confirmó

• En el endpoint investigado, el período disponible en modo compartido se mantuvo en 10 ms a 44,1, 48, 96 y 192 kHz.
• El aumento de la frecuencia no redujo la cola medida de XAudio2 en el caso sintético.
• La ventaja de 16-bit en tiempo de audiodg.exe no se confirmó.
• La ventaja de desactivar los efectos del sistema no se confirmó.
• 48 kHz / 24-bit corresponde al formato original del dispositivo y no mostró una desventaja práctica frente a las variantes cercanas.

Qué no se confirmó

• El resultado no se reprodujo en otro dispositivo de audio o compilación de Windows.
• La revisión completa de Windows y la configuración general del equipo se registraron cuatro días después de la medición, no dentro de la traza original.
• No se midió la latencia física de DAC, ADC, acústica o de entrada a sonido.
• No se evaluó la calidad del sonido ni la audibilidad de las diferencias.
• No se comprobó el impacto en juegos concretos, FPS ni frametime.
• No se aisló la contribución de un vendor APO concreto.
• El efecto exacto total sobre la CPU no puede trasladarse a procesadores de otro rendimiento.

Limitaciones

Los ETL en bruto no se publican: contienen información no relacionada sobre el estado de procesos y del sistema. Las tablas anteriores están seleccionadas manualmente y no contienen el endpoint ID único, usernames, rutas locales ni command lines.

La investigación y las herramientas utilizadas pertenecen al desarrollador de BoosterX, por lo que el desarrollador tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones pueden verificarse con los datos abiertos y las fuentes públicas enumeradas.

Conclusión práctica

Para el dispositivo investigado es razonable dejar 48 kHz / 24-bit y no desactivar los efectos del sistema sin un problema concreto diagnosticado. La elección de 96 o 192 kHz en busca de menor latencia no está respaldada por esta investigación.

Esto no es una configuración universal para todos los DAC y controladores. Un dispositivo que informe un período en modo compartido menor o use otra ruta de audio requiere una medición aparte.

Restauración del estado

Tras finalizar, se restauraron 48 kHz / 24-bit PCM y el estado original de los efectos del sistema. No quedaron sesiones de traza activas.

Fuentes

• Windows Performance Recorder — registro de eventos del sistema basado en ETW.
• Windows 11 release information — correspondencia de la versión 25H2 con la rama de OS build 26200.
• Low Latency Audio — período del motor de audio, papel del controlador y posibilidades de IAudioClient3.
• XAUDIO2_PERFORMANCE_DATA — valores de cycles, queue latency y glitches.
• IXAudio2::GetPerformanceData — obtención de XAudio2 performance data.

Investigación realizada: 2026-08-20. Fuentes públicas y formulaciones verificadas: 2026-08-24.

Historial de cambios

• 2026-09-20: estructura ajustada a la obligatoria — «Limitaciones» y «Restauración del estado» separadas en secciones propias; separadores decimales y unidades de tiempo ajustados al estilo de la serie (coma, «ms»); añadido el descargo de responsabilidad sobre el conflicto de intereses.
• 2026-08-24: primera publicación; publicadas las mediciones en un solo sistema, los límites de traslación del resultado y la restauración del estado.