Por que o som corta mesmo com uso de CPU baixo? — Pensando em buffers e prazos

Você está ouvindo música e, de vez em quando, o som corta com um estalo. O Gerenciador de Tarefas mostra o uso de CPU em torno de 10%, e mesmo assim só o áudio fica instável. Nesse caso, por que o som corta se a CPU tem folga?

Mesmo com o uso de CPU baixo, o som pode cortar se o reabastecimento dos próximos dados de áudio não cumprir o prazo. Isso porque os próximos dados precisam ser entregues enquanto o áudio que restou no buffer ainda está sendo reproduzido. Atrasos no reabastecimento causados por esperas por dados ou por locks, por DPCs/ISRs na CPU lógica necessária e por outros fatores acontecem mesmo sem que a CPU como um todo seja usada ao máximo. Exclusive-Mode Streams, CPU Analysis

No entanto, só pelo estalo que se ouve não é possível afirmar que houve um underrun. A fonte de áudio, o aplicativo, os efeitos de áudio, o dispositivo de saída e outros fatores também podem causar sintomas parecidos. Primeiro, com a mesma fonte de áudio, compare mudando uma condição de cada vez e voltando-a ao original; se ainda assim não conseguir restringir a causa, grave o que acontece antes e depois do corte. Fix distorted or crackling audio in Windows

Este artigo trata dessa dúvida e das que vêm em seguida: “basta aumentar o buffer?” e “o que comparar e o que gravar para restringir a causa?”. O artigo não pretende determinar a causa de uma falha específica apenas pelo uso de CPU ou pelo som que se ouve.

O foco é principalmente a saída de áudio no Windows 11. Comparamos saídas como a integrada, com fio, USB e Bluetooth e, em softwares de produção musical (DAW), tratamos também a comparação quando o aplicativo ou o driver oferece uma configuração de buffer. O projeto de toda a cadeia de captura de áudio e o diagnóstico da comunicação sem fio de cada dispositivo não são tratados de forma abrangente.

Nas explicações, usamos o modo compartilhado como exemplo básico. O caminho real, o tamanho do buffer e o período de processamento variam conforme o aplicativo, a API, o driver e o dispositivo, e não existe uma tela de configuração de buffer comum a todos os aplicativos. Low Latency Audio

O uso de CPU, os 10 milissegundos restantes, os momentos de reabastecimento e outros valores mostrados aqui são suposições para fins de explicação. Não são um relato de medições que tenham reproduzido o problema ou confirmado uma melhora em um PC específico. As operações da segunda metade são procedimentos de verificação para você executar no seu próprio ambiente.

O mecanismo pode ser lido em ordem a partir da próxima seção, “Buffer de reprodução de áudio”. As operações para investigar os cortes estão em “Comparar as condições em que o som corta” e “Gravar os cortes com o WPR”.

No diagrama, uma linha contínua indica uma relação que sempre se aplica e uma linha tracejada indica uma relação condicional (as condições aparecem em cada relação, na página de detalhes). A lista completa das relações (5 no total, com evidências e grau de certeza) e as definições dos principais conceitos estão reunidas na página de detalhes do mapa de conhecimento (em japonês). Dados: JSON-LD / Turtle

Buffer de reprodução de áudio

Ter um arquivo de música salvo não faz o alto-falante tocar. O aplicativo prepara os dados de áudio e os entrega ao dispositivo de saída por meio do Windows e do driver. O buffer de reprodução de áudio é uma área que armazena temporariamente os dados que serão reproduzidos em seguida. Enquanto o dispositivo reproduz os dados atuais, o lado que fornece os dados prepara os próximos e reabastece o buffer. Rendering a Stream

flowchart TB
    accTitle: Armazenar um pouco do áudio à frente antes de reproduzir
    accDescr: Fluxo em que os dados de áudio preparados reabastecem o buffer e, enquanto o dispositivo avança na reprodução, os próximos dados são preparados.
    A["Preparar o próximo áudio"] --> B["Reabastecer o buffer"]
    B --> C["Reproduzir o áudio armazenado"]
    C -.->|"Antes de acabar"| A

Figura 1: Para a reprodução continuar, o reabastecimento precisa acompanhar o lado que consome o áudio.

A Figura 1 é um diagrama conceitual que mostra apenas a relação entre reabastecimento e consumo. Ela não trata os vários buffers do caminho de áudio real como uma única área física. Low Latency Audio

O papel do buffer é absorver pequenas diferenças de tempo entre o lado que prepara o áudio e o lado que o consome, mantendo a reprodução contínua. Mas a capacidade do buffer e a quantidade de dados ainda não reproduzidos que estão nele agora são coisas diferentes. “Ter capacidade de 10 milissegundos” não significa que sempre restam 10 milissegundos de áudio. Rendering a Stream

Aqui, chamamos de prazo de reabastecimento a restrição de tempo de entregar os próximos dados necessários antes que os dados em reprodução se esgotem. O processamento de áudio precisa “ficar pronto até o momento de tocar”. “Conseguir calcular no fim” não basta. O estado em que o fornecimento não chega a tempo e os dados para reproduzir acabam é o underrun, que leva a cortes no som e a cliques. Mesmo que os dados cheguem atrasados, não é possível preencher depois uma interrupção que já foi ouvida. Exclusive-Mode Streams

Caminho dos dados de áudio

No modo compartilhado comum, o mecanismo de áudio do Windows recebe os dados preparados pelo aplicativo de reprodução, mistura vários sons e aplica efeitos e, então, os repassa ao driver e ao dispositivo de saída. O aplicativo de reprodução participa tanto da leitura da fonte de áudio quanto do fornecimento ao destino de saída, e o driver e o dispositivo de saída levam os dados até o dispositivo e os reproduzem. Low Latency Audio

flowchart TB
    accTitle: Caminho dos dados de áudio no modo compartilhado
    accDescr: O mecanismo de áudio mistura e aplica efeitos aos dados preparados pelo aplicativo de reprodução e os repassa ao driver; o dispositivo de saída os reproduz.
    A["Aplicativo: prepara os dados"] --> E["Mecanismo de áudio: mistura e efeitos"]
    E --> D["Driver: leva ao dispositivo"]
    D --> O["Dispositivo de saída: reproduz"]

Figura 2: Exemplo do modo compartilhado. O processamento e os buffers intermediários variam conforme a API e o dispositivo.

O dispositivo também pode ter processamento e buffers próprios, então a latência total não é determinada apenas pelo buffer do lado do aplicativo. Esta explicação pressupõe o caminho do modo compartilhado e não significa que todas as APIs passam pelo mesmo processamento. Low Latency Audio

Reabastecimento com 10 milissegundos restantes

Suponha que restem agora no buffer 10 milissegundos de dados ainda não reproduzidos. Se o próximo reabastecimento vier daqui a 8 milissegundos, ele chega enquanto ainda há dados e o som continua; mas, se não for possível reabastecer antes de 12 milissegundos, neste exemplo simplificado os dados acabam no instante de 10 milissegundos.

flowchart TB
    accTitle: Com os mesmos 10 milissegundos restantes, o momento do reabastecimento muda o resultado
    accDescr: Como suposição para fins de explicação, mostra que, com 10 milissegundos de dados restantes, um reabastecimento após 8 milissegundos chega a tempo, e um após 12 milissegundos chega depois de os dados acabarem.
    A["Restam 10 ms"] --> B{"Próximo reabastecimento"}
    B -->|"Após 8 ms"| C["O som continua"]
    B -->|"Após 12 ms"| D["Acaba em 10 ms"]

Figura 3: Exemplo com o tempo simplificado. Importa não só se o reabastecimento aconteceu, mas quando aconteceu.

Uso de CPU e atraso no reabastecimento

O uso de CPU mostra o quanto a CPU esteve ocupada em um intervalo de tempo. Isso é diferente de saber se o processamento de áudio conseguiu executar no instante em que precisava. Mesmo que a CPU tenha folga durante a maior parte de um segundo, se houver um único trecho de 12 milissegundos em que não seja possível reabastecer, esse único atraso pode cortar o som. A capacidade de processamento que sobra depois não recupera um momento de reprodução que já passou. CPU Analysis

flowchart TB
    accTitle: Folga média e um único atraso no reabastecimento
    accDescr: Mesmo que a CPU tenha folga durante a maior parte de um segundo, se houver um único trecho de 12 milissegundos sem reabastecimento, esse único atraso pode cortar o som.
    A["CPU com folga quase o segundo todo"] --> B["Uma vez, 12 ms sem reabastecer"]
    B --> C["Essa única vez corta o som"]

Figura 4: Mesmo com folga média, um momento de reprodução que já passou não pode ser recuperado.

Não é só o tempo de cálculo que consome o prazo. Também contam a espera até o processamento começar e a espera até os dados necessários chegarem. Por isso, a pergunta da investigação também muda: não apenas “quantos por cento de CPU havia?”, mas “no instante em que o som cortou, o que o próximo áudio estava esperando?”.

Esperas por dados e locks

Suponha que o processamento que prepara os dados de áudio esteja esperando a leitura de um arquivo terminar. O mesmo vale quando ele espera um lock mantido por outro processamento dentro do aplicativo. O processamento que espera quase não usa CPU, mas, do lado do dispositivo, a reprodução continua e o áudio restante vai diminuindo. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: A reprodução avança mesmo durante esperas que não usam CPU
    accDescr: Enquanto o processamento de áudio espera dados ou locks, ele não usa CPU, mas a reprodução avança e o restante diminui; se o reabastecimento atrasar, o buffer pode se esgotar.
    A["O áudio espera os dados"] --> B["Essa espera não usa CPU"]
    B --> C["A reprodução continua"]
    C --> D["Se atrasar, o estoque acaba"]

Figura 5: Não usar CPU não é o mesmo que ter terminado o trabalho necessário.

DPC, ISR e threads de áudio

A ISR é a rotina que responde a uma interrupção vinda de um dispositivo. O DPC é o mecanismo que adia o restante do trabalho para manter curto o tratamento da interrupção. Um DPC comum é executado antes das threads comuns na mesma CPU lógica e, enquanto um DPC comum ou uma ISR estiver em execução, essa CPU lógica não pode executar threads comuns. Introduction to DPCs, CPU Analysis

Mesmo que a CPU como um todo tenha folga, se eles se prolongarem ou forem frequentes na CPU de que o processamento de áudio precisa, o fornecimento pode atrasar. Um documento da Microsoft sobre análise de desempenho de áudio e vídeo também aponta DPCs/ISRs longos de drivers de rede, armazenamento, gráficos e outros como possíveis causas de cortes no som. Nem sempre basta investigar apenas o dispositivo que emite o som. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Quando responder a dispositivos atrasa a execução do áudio
    accDescr: Se DPCs ou ISRs comuns se prolongarem na CPU de que o processamento de áudio precisa, a execução da thread atrasa, o que pode afetar o prazo de reabastecimento.
    A["DPC e ISR na mesma CPU"] -->|"Se demorarem"| B["O áudio espera para executar"]
    B --> C["O próximo reabastecimento atrasa"]
    C --> D["Se acabar, o som corta"]

Figura 6: O processamento de dispositivos que não emitem som também pode afetar indiretamente o reabastecimento do áudio.

Não é possível traçar uma linha comum do tipo “se o DPC ficar abaixo de tantos microssegundos, nenhum PC terá cortes no som”. Os valores de alerta do documento de avaliação de desempenho valem para as condições daquela avaliação, e não os usamos como critério de segurança desvinculado do prazo real de reabastecimento e da folga do buffer. Results for the Streaming Media Performance Assessment

Tamanho do buffer e latência de reprodução

Nas mesmas condições, armazenar mais áudio antecipadamente facilita absorver atrasos temporários no reabastecimento, mas o áudio recém-gerado passa a esperar atrás do áudio já armazenado. Uma espera que é aceitável para quem só ouve música faz a defasagem entre a ação e o som incomodar quando se toca um teclado ou quando se processa a voz do microfone para ouvi-la você mesmo. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Folga do buffer e atraso na resposta
    accDescr: Armazenar mais áudio antecipadamente facilita absorver atrasos temporários no reabastecimento, mas também aumenta a espera até um novo som ser reproduzido.
    A["Armazenar mais áudio antes"] --> B["Absorve melhor os atrasos"]
    B -->|"Em troca"| C["O som novo espera na fila"]
    C --> D["Mais atraso da ação ao som"]

Figura 7: Aumentar o buffer é um ajuste que cria folga em troca da rapidez de resposta.

Não é “quanto menor, melhor o desempenho”, nem “quanto maior, mais certo”. O objetivo é garantir folga suficiente para não cortar, preservando a rapidez de resposta necessária.

Aumentar o buffer é um ajuste que cria folga para atrasos temporários no fornecimento. Se o próprio fornecimento médio não acompanha o consumo, aumentar um buffer finito apenas adia o momento em que ele se esgota, e também não resolve desconexões do dispositivo. Tampouco é uma recomendação de que usar o modo exclusivo resolve tudo. Exclusive-Mode Streams

Áudio de 480 frames a 48 kHz

Um frame PCM é a unidade que reúne as amostras de todos os canais reproduzidas no mesmo instante. Não é porque o áudio é estéreo que se dobra o número de frames para calcular o tempo. A duração de áudio representada por um número de frames é obtida por “número de frames ÷ taxa de amostragem”: 480 frames a 48 kHz são 480 ÷ 48000 segundos, ou seja, 10 milissegundos. Mantendo 48 kHz e aumentando o número de frames, o tempo de áudio que pode ser armazenado também aumenta. Rendering a Stream

Esse tempo é diferente da latência total entre pressionar uma tecla e ouvir o som, porque também há o tempo do aplicativo, do driver, do dispositivo e de outros buffers e processamentos. Ao ler os valores de configuração de uma DAW, confira também a unidade e a qual buffer eles se referem. Low Latency Audio

flowchart TB
    accTitle: Tempo calculado a partir do número de frames e latência total
    accDescr: Os 10 milissegundos obtidos dividindo 480 frames por 48000 são o tempo representado pelo buffer; somando o processamento do aplicativo, do driver, do dispositivo e outros, chega-se à latência total da tecla ao som.
    A["480 ÷ 48000"] --> B["10 ms representados pelo buffer"]
    B -->|"Somam-se outros processamentos"| C["Latência total da tecla ao som"]

Figura 8: O tempo calculado a partir do número de frames é só uma parte da latência total.

Comparar as condições em que o som corta

Primeiro, restrinja as combinações em que o problema ocorre e só avance para uma gravação detalhada se for necessário. Os passos a seguir servem para confirmar a causa; não são uma lista de soluções para aplicar todas as mudanças de configuração de uma vez.

Salve seu trabalho, termine reuniões e gravações de áudio importantes e só então faça os testes, com um volume que não canse os ouvidos. Anote o destino de saída original, os aprimoramentos de áudio, os valores de buffer e outros itens, para poder voltar atrás. Pule os itens cuja configuração não é oferecida e não altere o Registro nem outros recursos para fazer a opção aparecer.

1. Defina uma mesma fonte de áudio curta e um tempo de observação e confirme que o problema ocorre nas condições originais.

   Registre a versão do Windows, o nome e a versão do aplicativo, o dispositivo de saída, o tipo de conexão e a versão do driver. Anote também o horário, a operação e o número de vezes em que o som cortou. Se o problema não ocorrer nas condições originais, não conclua que houve melhora; volte a verificar as condições em que ele ocorre.

2. Escolha uma comparação da tabela a seguir e reproduza o áudio mudando apenas essa condição.

   Condição a comparar	O que verificar
   Fonte de áudio salva no computador vs. reprodução pela internet	Se ocorre só na reprodução pela internet. Se o formato ou o caminho de processamento forem diferentes, mesmo com o mesmo conteúdo, registre isso também.
   A mesma fonte de áudio em outro aplicativo	Se se concentra em um aplicativo específico.
   Saída Bluetooth ou similar vs. saída integrada ou com fio	Se se concentra em um caminho de saída específico.
   Aprimoramentos de áudio ativados vs. desativados	Se muda em combinação com o processamento de efeitos.
   Buffer atual da DAW ou similar vs. um valor um nível maior	Se muda ao aumentar a folga armazenada antecipadamente. Se o atraso entre a ação e o som também é aceitável.

3. Para comparar os aprimoramentos de áudio, desative temporariamente a configuração na saída em questão.

   Em “Configurações” → “Sistema” → “Som” do Windows, selecione a saída em questão e, onde estiver disponível, desative “Aprimoramentos de áudio”. Se a tela ou os itens disponíveis forem diferentes, consulte as orientações para a sua versão e o seu dispositivo. Fix distorted or crackling audio in Windows

4. Volte a configuração alterada ao original e teste de novo com a mesma fonte de áudio e o mesmo tempo de observação.

   Coloque lado a lado os resultados das “condições originais”, da “condição com uma mudança” e das “condições restauradas”. Desfaça as mudanças sem efeito antes de passar para outra comparação. Se você continuar mudando combinações de configurações, não saberá o que surtiu efeito.

5. Se for testar uma troca de driver, faça isso só depois de confirmar a distribuição oficial e o método de recuperação.

   Use o Windows Update ou a distribuição oficial do fabricante do dispositivo e registre a versão e as configurações antes e depois da mudança. Confirme antes se é possível voltar atrás e, em PCs gerenciados, consulte o administrador. Não considere o problema resolvido só porque o áudio tocou bem uma vez logo após a atualização; confirme com as mesmas condições em que o problema ocorria. Fix distorted or crackling audio in Windows

O resultado que se busca é um registro que associe o sintoma às condições, como “ocorre com este aplicativo, usando esta saída”. Mesmo que encontre uma configuração que melhore a situação, trate isso separadamente da confirmação da causa.

flowchart TB
    accTitle: Comparação mudando uma condição e voltando ao original
    accDescr: Confirma-se o problema com a mesma fonte de áudio, muda-se uma condição, como o aplicativo ou a saída, e registra-se também o resultado ao voltar ao original.
    A["Tocar na combinação original"] --> B["Tocar mudando uma condição"]
    B --> C["Tocar após restaurar"]
    C --> D["Anotar condição e horário do corte"]

Figura 9: Mais do que uma melhora isolada, confirme que condição e sintoma se correspondem de forma repetida.

Reprodutibilidade antes e depois da mudança

“Conseguir conter o sintoma”, “conseguir restringir as condições” e “conseguir identificar a causa raiz” são pontos de chegada diferentes. Registre a conclusão de acordo com o que foi possível observar.

flowchart TB
    accTitle: Três resultados que indicam relação com a condição
    accDescr: Se o problema ocorre nas condições originais, melhora ao mudar uma condição e volta ao restaurar, isso é uma pista de relação com essa condição, mas é tratado separadamente da confirmação da causa.
    A["Ocorre no original"] --> B["Melhora com uma mudança"]
    B --> C["Volta ao restaurar"]
    C --> D["Pista de relação com a condição"]

Figura 10: Mesmo com os três resultados, o que se obtém é apenas uma pista de relação.

Um uso de CPU baixo não é prova de que os prazos do áudio foram cumpridos. Ao mesmo tempo, o simples fato de ter havido um corte também não permite dizer que a causa raiz foi um atraso no reabastecimento. Compare a fonte de áudio, o processamento do aplicativo, os efeitos, o caminho de saída e outros fatores, e julgue dentro do que foi observado. Fix distorted or crackling audio in Windows

Ao adotar uma solução alternativa provisória, registre a configuração original, o que foi alterado, o tempo de observação, se o problema voltou ou não e a latência aceitável. Se a causa raiz ainda não estiver confirmada, registre isso também.

Gravar os cortes com o WPR

Faça isto quando a comparação de condições não bastar para restringir a causa, ou quando for investigar o processamento do lado do driver. O WPR é a ferramenta usada para gravar, e o WPA, para analisar a linha do tempo salva. Prepare o Windows Performance Toolkit, as permissões necessárias para gravar e um local para salvar o ETL. Para instalar as ferramentas e gravar em um PC gerenciado, peça ao administrador. Confira os nomes exibidos e os perfis disponíveis na versão instalada. Windows Performance Recorder

Um ETL pode conter nomes de processos, caminhos de arquivos e outras informações. Antes de gravar, confira as regras internas da empresa e com quem a gravação será compartilhada, e não a anexe como está em locais públicos. Se outra sessão de gravação estiver em execução, não a interrompa por conta própria; consulte o responsável. WPR How-to Topics

1. Abra “More Options” no WPR e selecione o perfil de gravação adequado ao objetivo.

   Entre os perfis padrão estão “Audio glitches” e “CPU usage”. Escolha uma configuração que permita investigar as descontinuidades do áudio e o comportamento da CPU. Confira na versão instalada os perfis disponíveis, os nomes exibidos e o que é coletado, e não configure a gravação de todos os tipos por um longo período. Built-in Recording Profiles

2. Inicie a gravação antes de reproduzir o problema.

   Se aparecer uma confirmação para interromper uma gravação existente, não prossiga: cancele o início e consulte o responsável. Mantenha as condições iguais às do teste sem gravação e não descarte a possibilidade de que a carga da própria gravação altere o sintoma. WPR How-to Topics

3. Reproduza o áudio nas condições encontradas na comparação e anote o horário do corte e a operação realizada.

   Inclua também um pouco de trecho sem problemas antes e depois do sintoma. Se o problema não ocorrer durante a gravação, deixe isso explícito e não trate essa gravação como se tivesse capturado a causa.

4. Depois que o problema ocorrer, encerre a gravação com “Save” e salve o arquivo ETL.

   Com “Cancel”, nada é salvo. Anote o local onde salvou, as condições em que o problema ocorreu, se houve gravação e se houve aviso de perda de eventos. Em uma gravação com perdas, não considere normais os trechos que não aparecem. WPR How-to Topics

Com o arquivo ETL e as anotações sobre horário, operação e condições do corte em mãos, está tudo pronto para fazer a correlação no WPA. Ter salvo a gravação não garante, por si só, que os eventos necessários foram capturados. Verifique o conteúdo na próxima seção, “Execução e esperas em torno do corte”.

flowchart TB
    accTitle: Fazer uma gravação curta que inclua o corte
    accDescr: Inicia-se a gravação no WPR, reproduz-se o sintoma anotando o horário, e a gravação interrompida e salva é examinada no WPA.
    A["Iniciar gravação no WPR"] --> B["Reproduzir o corte nas mesmas condições"]
    B --> C["Anotar horário e operação e salvar"]
    C --> D["Ampliar o trecho no WPA"]

Figura 11: Olhar o uso de CPU depois que o sintoma passou não basta; é preciso uma gravação do trecho em que ele ocorreu.

Execução e esperas em torno do corte

Tenha em mãos o ETL salvo e as anotações com o horário em que o problema ocorreu. O que segue é o ponto de partida da investigação no WPA. Se for necessária uma análise detalhada que envolva pilhas e símbolos, tome cuidado com o manuseio da gravação e peça ajuda ao administrador ou aos desenvolvedores.

1. Abra o ETL no WPA e, com base nos eventos de áudio capturados e no horário do problema, amplie o trecho antes e depois do corte.

   Mantenha também um trecho sem sintoma para comparação. Não olhe apenas o ranking de valores máximos; compare alinhando o mesmo intervalo de tempo.

2. No mesmo intervalo, verifique “DPC/ISR” e “CPU Usage (Precise)”.

   Se os dados necessários não estiverem lá, verifique se o perfil é capaz de capturá-los e volte à gravação no WPR. Não haver registro não é o mesmo que não haver problema. CPU Analysis, Built-in Recording Profiles

3. Distinga se as threads relacionadas ao áudio estavam prontas para executar, mas esperando a vez, ou se estavam esperando dados ou algo semelhante.

   No primeiro caso, verifique se DPCs/ISRs ou algo semelhante ficaram muito tempo em execução nas CPUs lógicas envolvidas. No segundo, rastreie o que liberou a espera usando os eventos e as pilhas capturados. Como uma thread em execução também pode ser suspensa por uma interrupção, não se limite ao tempo em Ready: sobreponha também os trechos de DPC/ISR. CPU Analysis

4. Registre juntos a correspondência de horário com o corte, as CPUs envolvidas e os resultados ao mudar as condições.

   Não confirme um dispositivo ou driver específico como causa só pelo nome do módulo de um DPC/ISR longo. Você pode estar olhando um valor alto de outro momento ou uma parte comum pela qual passam vários dispositivos.

flowchart TB
    accTitle: Examinar o tipo de espera no trecho do corte
    accDescr: Amplia-se o trecho antes e depois do corte para ver o estado da thread de áudio. Se ela estava pronta, esperando a vez, compara-se com os DPCs e ISRs da mesma CPU; se esperava dados ou algo semelhante, rastreia-se o que liberou a espera.
    A["Ampliar o trecho do corte"] --> B{"Estado da thread"}
    B -->|"Esperando a vez"| C["DPC e ISR"]
    B -->|"Esperando dados"| D["O que liberou a espera"]

Figura 12: Não pegue só os valores máximos; leia-os sobrepostos ao trecho em que o processamento de áudio era necessário.

Se não for possível identificar a causa, repasse a investigação como não confirmada. Inclua as versões do sistema operacional, do aplicativo, do dispositivo e do driver, os passos para reproduzir o problema, os resultados antes e depois das mudanças, o horário da ocorrência, o perfil de coleta e se houve aviso de perda de eventos. Compartilhe o ETL, conforme as regras internas, apenas com quem for responsável pela investigação.

Leitura antecipada em aplicativos de áudio

Se você desenvolve seu próprio aplicativo de áudio, projete-o para que o processamento que preenche o próximo buffer cumpra o prazo todas as vezes. O WASAPI oferece uma forma de receber, por meio de um evento, o momento em que o buffer pode ser processado. Exclusive-Mode Streams

O MMCSS é o mecanismo que distribui recursos de CPU para threads de processamento multimídia com restrições de tempo. Ele não tem a função de preparar antecipadamente dados do disco nem de eliminar esperas por locks. Mesmo usando a distribuição do MMCSS, ainda é necessário um projeto à parte para preparar os dados e reduzir as esperas. Multimedia Class Scheduler Service

flowchart TB
    accTitle: O que cabe ao MMCSS
    accDescr: O MMCSS distribui recursos de CPU para threads de processamento com restrições de tempo, mas a preparação dos dados e a redução das esperas por locks são feitas por outro projeto.
    M["MMCSS: distribui recursos de CPU"] -.->|"Também necessário"| D["Preparar dados e reduzir esperas"]

Figura 13: Distribuir recursos de CPU e projetar para que os dados cheguem a tempo são trabalhos diferentes.

A diretriz de projeto é separar o processamento que lê de arquivos ou da rede do processamento que entrega o áudio. Faça antecipadamente as preparações cuja duração é difícil de prever e use buffers pré-alocados para a passagem dos dados. Do lado do áudio, estruture o código para que ele não precise esperar respostas da interface, locks longos nem escritas síncronas em log.

flowchart TB
    accTitle: Separar preparações de duração imprevisível do fornecimento de áudio
    accDescr: Projeto em que a leitura e tarefas semelhantes são feitas por um processamento antecipado e os dados preparados são passados ao processamento de áudio por meio de um buffer, reduzindo esperas longas logo antes do prazo.
    A["Preparar dados antecipadamente"] --> B["Área de passagem pré-alocada"]
    B --> C["Áudio repassa o necessário"]
    C --> D["Fornecer à saída de áudio"]

Figura 14: Tire o trabalho demorado de perto do momento da entrega do áudio.

Se o lado da preparação parar por muito tempo, o estoque se esgota mesmo com essa separação. Registre, de um modo que não atrapalhe o processamento de áudio, não só o tempo médio de processamento, mas também as ocasiões em que houve processamentos ou esperas longas e o número de vezes em que não foi possível fornecer os dados. Confirme pela API ou pelo driver o tamanho de buffer e o período realmente escolhidos, e não suponha que o valor especificado foi adotado tal como pedido. Rendering a Stream, Low Latency Audio

Tanto os exemplos numéricos quanto os exemplos de projeto são para fins de explicação; não são valores de configuração recomendados para um dispositivo específico nem garantia de que o som não cortará em qualquer ambiente.

Efeito da prioridade em tempo real

Não recomendamos, como regra geral, que o usuário mude o player inteiro para a prioridade “Tempo real”. Há o risco de atrapalhar outros processamentos importantes e, mesmo elevando a prioridade de uma thread comum, não se eliminam os DPCs/ISRs nem as esperas por dados e locks. No desenvolvimento, usam-se mecanismos como o MMCSS e um projeto que não leve esperas longas para o fornecimento de áudio. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Esperas que continuam mesmo com prioridade em tempo real
    accDescr: Mesmo colocando o player em prioridade em tempo real, as threads comuns não passam à frente dos DPCs e ISRs da mesma CPU, as esperas por dados e locks continuam, e há ainda o risco de atrapalhar outros processamentos importantes.
    A["Player em prioridade de tempo real"] --> B["Não passa à frente de DPC e ISR"]
    B --> C["Esperas por dados e locks continuam"]
    C --> D["Risco de atrapalhar outros processos"]

Figura 15: Mesmo elevando a prioridade, as esperas que atrasam o reabastecimento do áudio continuam.

Artigos relacionados

• “Agendamento do processador” no Windows e a configuração de serviços em segundo plano
• Diagnosticar com segurança o disco a 100% no Windows
• Por que o RDP fica lento se a conexão é rápida?

Referências

• Microsoft Learn, Rendering a Stream. Fornecimento de dados ao buffer de reprodução, quantidade restante, tamanho real do buffer e definição de frame PCM.
• Microsoft Learn, Exclusive-Mode Streams. Momento do fornecimento ao buffer e falhas de áudio, equilíbrio com a latência e fornecimento orientado a eventos. Não recomenda o modo exclusivo em si como regra geral.
• Microsoft Learn, Low Latency Audio. O caminho de áudio do Windows, buffers, dispositivos, processamento de efeitos e latência, e as contrapartidas da baixa latência.
• Microsoft Learn, CPU Analysis. CPUs lógicas, estados Ready/Waiting das threads, relação entre DPC/ISR e a execução de threads, e análise de CPU no WPA.
• Microsoft Learn, Introduction to DPCs. O mecanismo que encurta o tratamento de interrupções e passa o restante do trabalho para um DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPCs/ISRs longos ou frequentes, falta de fornecimento de dados e falhas de áudio. Os valores de alerta da avaliação não são generalizados como critério de segurança para todos os dispositivos.
• Microsoft Support, Fix distorted or crackling audio in Windows. Verificação dos aprimoramentos de áudio, do formato, do driver e de outros itens.
• Microsoft Learn, Windows Performance Recorder. Gravação ETW, análise com o WPA e uso do Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options do WPR e perfis padrão como Audio glitches e CPU usage.
• Microsoft Learn, WPR How-to Topics. Início da gravação e salvamento com Save, conflitos com sessões existentes e cuidados com informações pessoais e perda de eventos.
• Microsoft Learn, Multimedia Class Scheduler Service. Distribuição de recursos de CPU para processamento multimídia com restrições de tempo.
• Microsoft Learn, Scheduling Priorities. Prioridades de processos e threads e cuidados relativos à prioridade em tempo real.

Artigos relacionados

Artigos recentes que compartilham as mesmas tags. Aprofunde seu conhecimento com temas próximos.

Tópicos relacionados

Páginas de tópicos próximos a este tema. A partir do artigo, você pode seguir para serviços relacionados e outros artigos.

Serviços ligados a este tema

Este artigo se conecta às páginas de serviço abaixo. Escolha a porta de entrada mais próxima.

Perguntas frequentes

Reunimos as perguntas mais comuns, em consultas, sobre o tema deste artigo.

Por que o som corta se o uso de CPU está em torno de 10%?

O áudio tem um prazo: os próximos dados precisam ser reabastecidos antes que os dados em reprodução se esgotem. Mesmo com o uso total de CPU baixo, o reabastecimento pode não chegar a tempo se, naquele instante, o processamento de áudio não conseguir executar ou estiver esperando dados necessários. Nem todo corte no som tem essa causa, e também é preciso comparar trocando o dispositivo de saída e o aplicativo.

Aumentar o buffer de áudio resolve os cortes no som?

Quando o reabastecimento atrasa temporariamente, um buffer maior pode absorver o atraso. Por outro lado, também aumenta a espera até que o áudio armazenado seja reproduzido. Não é uma configuração que resolva uma falta contínua de capacidade de processamento nem desconexões do dispositivo. Em aplicativos e drivers que permitem alterá-lo, anote o valor original e compare um nível de cada vez.

Quantos milissegundos de áudio são 480 frames a 48 kHz?

São 480 ÷ 48000 segundos, ou seja, 10 milissegundos. Um frame PCM é a unidade que reúne as amostras de todos os canais no mesmo instante. Esse valor é a duração de áudio representada por esse número de frames, não a latência total incluindo o dispositivo e o aplicativo.

Um driver com tempos de execução de DPC ou ISR longos é o culpado pelos cortes no som?

Ele é um candidato, mas o ranking de tempos de execução, por si só, não permite confirmar. Compare o trecho em que o corte ocorreu com as esperas da thread de áudio e com a execução de DPC/ISR na mesma CPU. Não conclua só pelo nome do módulo que há um defeito em um dispositivo ou driver específico; verifique também os resultados ao mudar as condições em que o problema ocorre.

Colocar o player em prioridade de tempo real melhora a situação?

Não recomendamos isso como regra geral. Elevar a prioridade de uma thread comum não a faz passar à frente dos DPCs e ISRs comuns na mesma CPU, nem elimina as esperas por dados ou locks. Desenvolvedores usam mecanismos como o MMCSS e um projeto que não introduza esperas; usuários começam comparando as condições em que o problema ocorre e o caminho de saída.

Perfil do autor

Página de perfil do autor do artigo.

Go Komura

Representante da KomuraSoft LLC

Atua principalmente com desenvolvimento de software para Windows, consultoria técnica e investigação de falhas, com especial força em projetos em que ativos existentes permanecem e em investigações de falhas cuja causa é difícil de enxergar.