Desvantagem de diminuir a latência de áudio

Quando o buffer é pequeno, ele se enche mais rapidamente e se esvazia mais rapidamente. É por isso que a latência diminui.

No entanto, os processos que colocam dados no buffer e retiram dados do buffer serão acionados com mais frequência. Portanto, você pode ver um consumo maior da CPU do seu computador pelo software de áudio quando torna o buffer muito pequeno. Em casos extremos, usar o sistema de áudio com um buffer pequeno pode fazer com que o outro software em seu computador responda mais lentamente, ou talvez "instável" ou "interrompido", onde alterna entre suave e congelado.

Um buffer pequeno também pode fazer com que o fluxo de áudio gagueje se o processo que coloca os dados de áudio no buffer não puder responder rápido o suficiente e o buffer ficar completamente vazio por breves momentos. O processo que está tirando os dados de áudio do buffer e passando-os pela saída para seus alto-falantes (ou fones de ouvido) ficará sem dados e haverá interrupções no som (geralmente chamadas de "quedas").

É difícil prever qual tamanho será "muito pequeno", então você pode ter que experimentar e ver qual compromisso oferece a menor latência sem afetar os fluxos de áudio e o restante do computador.

Seja qual for o seu aplicativo de som (A), seja qual for o servidor de som (B), seja qual for o driver da sua placa de som (C):

• (A) gravará (em seu próprio ritmo PA) as amostras em algum buffer,
• que (B) irá ler (no seu ritmo) para escrevê-los (no seu ritmo) em algum buffer,
• que o manipulador de interrupção da placa de som irá ler (em algum ritmo PC) no buffer muito pequeno de tamanho geralmente fixo da placa de som de hardware,
• que será lido pelo software incorporado para ecoar nas saídas de hardware em um ritmo muito preciso.

A partir dessa forma de trabalhar, você pode entender que:

• Simplesmente não há como (imediatamente) " definir a latência ". (como entendido sendo a quantidade de tempo decorrido desde a saída de uma amostra de (A) até a saída dessa amostra do hardware). Portanto… simplesmente não pode haver nenhuma "desvantagem em definir a latência realmente baixa"
• A necessidade de buffers se deve ao fato de que os diferentes componentes envolvidos no processo funcionam de forma assíncrona e, portanto, os tamanhos dos buffers devem levar em consideração que algumas (?) vezes algum componente upstream produzirá mais (ou menos) amostras do que o componente imediatamente seguinte será capaz de processar instantaneamente.

Do parágrafo imediatamente anterior, e no que diz respeito aos buffers, você pode entender que:

Se os buffers estiverem subdimensionados, já que é mais provável que sejam buffers circulares... é provável que você enfrente: estouros!
Isso significa amostras que nunca irão para a saída do hardware, o que se traduzirá em cliques audíveis.

Então sim! De fato, há uma desvantagem em diminuir os tamanhos dos buffers: saturações .

Claro que existem maneiras de reduzir esse risco de estouros: Ter os processos rodando: No ritmo certo!

Se você puder fazer com que os componentes downstream possam realizar seus trabalhos no tempo certo (ou em um ritmo maior ou igual ao do componente upstream), você poderá evitar o risco de saturações independentemente do tamanho do buffer.

• Isso começará garantindo que o irq seja encadeado e que a prioridade em tempo real do encadeamento do kernel associado à placa de som seja máxima.
• Isso deve ser seguido por qualquer servidor de som em execução em algum modelo de agendamento em tempo real com uma prioridade imediatamente inferior à do thread do kernel irq mencionado acima.
• E, eventualmente, executar o aplicativo upstream em um modelo de agendamento em tempo real também com uma prioridade menor que a do servidor de som.

Você também pode (com razão) considerar que o servidor de som com seus dois buffers é apenas caro (em termos de latência adicional) e possivelmente ... não serve para nada e ... pense em se livrar dele.