Formato Windows Audio: frequência, resolução e carga
Nesta página
Resposta curta: no endpoint Realtek USB Audio investigado, o formato 48 kHz / 24-bit continuou a ser a escolha prática. A mudança para 96 ou 192 kHz não reduziu o período disponível do motor de áudio nem a estimativa da fila do XAudio2. A vantagem do 16-bit em CPU e o benefício de desativar os efeitos do sistema não foram confirmados.
Estado: medido num único sistema, não reproduzido noutro dispositivo. O resultado não pode ser transferido automaticamente para outro controlador de áudio, DAC ou build do Windows. O significado dos estados está descrito na metodologia de investigação.
O que foi verificado
Seção intitulada “ O que foi verificado”A investigação respondeu a quatro perguntas:
- O período do motor de áudio em shared-mode diminui quando a frequência aumenta?
- O 16-bit reduz a carga em relação ao 24-bit e ao 32-bit a 48 kHz?
- Desativar os efeitos de som do sistema produz uma redução de carga reproduzível?
- Como é que a alteração do endpoint rate se relaciona com o funcionamento interno do XAudio2 para uma fonte de 48 kHz?
A medição não verificou a qualidade do som, os FPS, a latência do jogo ou a latência física entre o sinal digital e o altifalante.
Âmbito da investigação
Seção intitulada “ Âmbito da investigação”| Parâmetro | Valor |
|---|---|
| Data da medição | 2026-08-20 |
| Windows | Windows 11 Pro 25H2, x64 |
| OS build | 26200.8655 |
| Processador | AMD Ryzen 7 7800X3D, 8 núcleos / 16 threads |
| Memória RAM | 32 GB |
| Dispositivo | Altifalantes, Realtek USB Audio |
| Controlador | Realtek USB Audio 6.4.0.2422 de 2025-08-07 |
| Formato inicial do dispositivo | 48 kHz, 24-bit PCM, stereo |
| Shared mix format | 48 kHz, 32-bit float, stereo |
| Efeitos iniciais | Ativados |
| Casos de teste | 17 traços, um traço por caso |
| Análise do traço | Cinco janelas consecutivas de 10 segundos |
O traço inicial registou o ramo do Windows build 26200 e os dados do dispositivo de áudio. A revision completa, a edition do Windows, o modelo do processador e a quantidade de memória foram adicionalmente lidos do mesmo computador em 2026-08-24. Entre a medição e o novo registo da configuração passaram quatro dias.
O identificador único do endpoint e os traços de sistema em bruto não são publicados.
Metodologia
Seção intitulada “ Metodologia”Os casos foram executados por ordem aleatória. Para cada um usaram-se 3 segundos de aquecimento, depois 52 segundos de traço de sistema e cinco janelas de análise de 10 segundos.
Foram verificados dois tipos de carga:
- um fluxo WASAPI estável em shared-mode para comparar frequência, profundidade de bits e efeitos;
- uma carga sintética de XAudio2 com 8, 32 ou 64 voices ativas e fontes de 44,1 ou 48 kHz.
O principal indicador do Windows Audio é o scheduler running time do processo audiodg.exe, expresso em milissegundos de trabalho por segundo. Separadamente, foram lidos os XAudio2 performance data, o número de glitches e as estatísticas de perda do traço.
As cinco janelas de um mesmo traço estão correlacionadas e são usadas apenas como dispersão descritiva. Não são cinco execuções independentes. A carga de fundo global do sistema variou, por isso a CPU da máquina inteira, os DPC absolutos e as ISR não foram usados para a conclusão final.
Período do motor de áudio
Seção intitulada “ Período do motor de áudio”| 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 |
O endpoint devolvia apenas o período de 10 ms. Os períodos de 5 ms e 2,5 ms não eram suportados pelo seu controlador. Aumentar a frequência aumentava o número de frames por período, mas não reduzia a duração do período.
Isto é uma propriedade da combinação concreta de dispositivo e controlador. A Microsoft indica que os tamanhos de buffer disponíveis são determinados pelo controlador de áudio, e a aplicação pode pedir as variantes suportadas através de IAudioClient3. Mais detalhes: Low Latency Audio.
Frequência e audiodg
Seção intitulada “ Frequência e audiodg”A tabela apresenta a mediana e o intervalo das cinco janelas dentro de um mesmo traço. A unidade мс/с mostra quantos milissegundos o processo audiodg.exe foi executado por um segundo de observação.
| Endpoint rate | audiodg, mediana | Intervalo das janelas |
|---|---|---|
| 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 |
Nesta série, 96 e 192 kHz não mostraram redução do tempo de audiodg.exe. Mas havia um traço por frequência, e a carga de fundo variou. A tabela não prova uma diferença universal de CPU entre frequências.
Profundidade de bits a 48 kHz
Seção intitulada “ Profundidade de bits a 48 kHz”| Formato do dispositivo | audiodg, mediana | Intervalo das janelas |
|---|---|---|
| 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 |
Os intervalos sobrepõem-se, e não há repetições independentes suficientes. Com esta série não se pode afirmar que a mudança para 16-bit produza uma redução de carga reproduzível.
Efeitos do sistema
Seção intitulada “ Efeitos do sistema”A 48 kHz / 24-bit, a mediana de audiodg.exe foi 4,23 ms/s com os efeitos ativados e 4,39 ms/s com os efeitos desativados. O valor médio mudou no sentido oposto por causa de uma janela mais alta no traço inicial.
Não foi estabelecida uma vantagem fiável da desativação dos efeitos. O resultado não é motivo para os desativar sem um problema concreto com um Audio Processing Object ou com o controlador.
XAudio2 e desalinhamento de frequência
Seção intitulada “ XAudio2 e desalinhamento de frequência”Para uma fonte fixa de 48 kHz e 32 voices, obtiveram-se os seguintes XAudio2 performance data:
| Endpoint rate | Audio cycles/s | Relativamente a 48 kHz | Estimativa da fila |
|---|---|---|---|
| 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 |
A Microsoft define AudioCyclesSinceLastQuery como os CPU cycles gastos pelo XAudio2 a processar áudio desde o pedido anterior. CurrentLatencyInSamples é a distância aproximada entre os últimos dados entregues ao controlador e os dados reproduzidos. Ver XAUDIO2_PERFORMANCE_DATA e IXAudio2::GetPerformanceData.
Aumentar o endpoint rate neste caso sintético aumentou o trabalho interno do XAudio2, mas praticamente não alterou a sua estimativa da fila. Foi obtido um único performance summary por variante, por isso os coeficientes descrevem esta execução e não são uma previsão universal para jogos.
Estabilidade das medições
Seção intitulada “Estabilidade das medições”Em todos os 17 traços registou-se:
- 0 audio glitches;
- 0 ETW events perdidos;
- 0 ETW buffers perdidos.
O que foi confirmado
Seção intitulada “ O que foi confirmado”- No endpoint investigado, o período disponível em shared-mode manteve-se em 10 ms a 44,1, 48, 96 e 192 kHz.
- Aumentar a frequência não reduziu a fila medida do XAudio2 no caso sintético.
- A vantagem do 16-bit no tempo de
audiodg.exenão foi confirmada. - A vantagem de desativar os efeitos do sistema não foi confirmada.
- 48 kHz / 24-bit corresponde ao formato inicial do dispositivo e não mostrou uma desvantagem prática face às variantes vizinhas.
O que não foi confirmado
Seção intitulada “ O que não foi confirmado”- O resultado não foi reproduzido noutro dispositivo de áudio ou build do Windows.
- A revision completa do Windows e a configuração geral do computador foram registadas quatro dias após a medição, e não dentro do traço inicial.
- Não foi medida a latência física do DAC, ADC, acústica ou input-to-sound.
- A qualidade do som e a audibilidade das diferenças não foram avaliadas.
- O impacto em jogos concretos, FPS e frametime não foi verificado.
- O contributo de um vendor APO individual não foi isolado.
- O efeito total exato na CPU não pode ser transferido para processadores com outro desempenho.
Limitações
Seção intitulada “Limitações”Os ETL em bruto não são publicados: contêm informações não relacionadas com o estado dos processos e do sistema. As tabelas acima foram selecionadas manualmente e não contêm o endpoint ID único, usernames, caminhos locais ou command lines.
A investigação e as ferramentas utilizadas pertencem ao programador do BoosterX, por isso o programador tem um interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas indicadas.
Conclusão prática
Seção intitulada “ Conclusão prática”Para o dispositivo investigado, é razoável manter 48 kHz / 24-bit e não desativar os efeitos do sistema sem um problema concreto diagnosticado. A escolha de 96 ou 192 kHz por causa de uma menor latência não é sustentada por esta investigação.
Isto não é uma configuração universal para todos os DAC e controladores. Um dispositivo que comunique um shared-mode period menor ou use outro percurso de áudio exige uma medição separada.
Restauro do estado
Seção intitulada “Restauro do estado”Após a conclusão, foram restaurados 48 kHz / 24-bit PCM e o estado inicial dos efeitos do sistema. Não ficaram sessões de traço ativas.
- Windows Performance Recorder — registo de eventos do sistema baseado em ETW.
- Windows 11 release information — correspondência da versão 25H2 com o ramo OS build 26200.
- Low Latency Audio — período do motor de áudio, papel do controlador e possibilidades de
IAudioClient3. - XAUDIO2_PERFORMANCE_DATA — valores de cycles, queue latency e glitches.
- IXAudio2::GetPerformanceData — obtenção dos XAudio2 performance data.
Investigação realizada: 2026-08-20. Fontes públicas e formulações verificadas: 2026-08-24.
Histórico de alterações
Seção intitulada “Histórico de alterações”- 2026-09-20: estrutura alinhada com a obrigatória — «Limitações» e «Restauro do estado» separados em secções próprias; separadores decimais e unidades de tempo alinhados com o estilo da série (vírgula, «ms»); adicionado o aviso sobre conflito de interesses.
- 2026-08-24: primeira publicação; publicadas as medições num único sistema, os limites de transferência do resultado e o restauro do estado.