O provável problema com sons de estalo no Ubuntu 24.04 é que a distribuição está migrando para o pipewire e executa um serviço de conversão do Pulse Audio, chamado pipewire-pulse .
O desafio é que muitos aplicativos não se comunicam diretamente com o piepewire, mas o fazem por meio do JACK e/ou especialmente do próprio pulso , portanto os dados de som precisam ser movidos por saltos adicionais.
O buffer de tempo padrão para pipewire-pulse é de 2,7 ms, o que significa que um aplicativo precisa ser capaz de preencher o conteúdo sonoro a cada 2,7 ms, caso contrário, o pipewire enviará ao dispositivo de áudio o que foi preenchido anteriormente e potencialmente alguns dados aleatórios, daí o estalo.
2,7 ms é um tempo bastante rigoroso, especialmente para aplicativos que não têm threads dedicados para áudio (provavelmente Proton/wine/jogos) e/ou quando executados em CPUs antigas - portanto, uma maneira de limitar o cracking é dizer ao pipewire-pulse para definir um buffer de tempo maior, embora adicionando um atraso ao momento em que o som é enviado ao dispositivo de áudio.
Para fazer isso, é necessário abrir o arquivo:
/usr/share/pipewire/pipewire-pulse.conf
E então localize, descomente e altere a configuração do item:
pulse.min.quantum = 128/48000 # 2.7ms
do valor 128para algo maior - deve-se tentar 256ou mesmo 512como um ponto de partida e se não houver estalos, deve-se deixar como está (observe que após salvar o arquivo, é preciso reiniciar o pipewire, pipewire-pulse via systemctl --user restart wireplumber pipewire pipewire-pulse).
O segredo é encontrar o menor número para que o estalo irritante não esteja presente (ou em um mínimo aceitável), porque se números maiores (como 1024) fizerem com que ocorra muito pouco estalo, eles adicionam um atraso ( 1024 / 48000 -> 21.333 ms).
CPUs mais lentas precisarão de números iguais 512ou maiores, ou ao usar vários softwares mantendo a CPU ocupada, é provável que um número como 1024ou mesmo 2048possa ser benéfico.
Observe que o estalo é 128/48000perceptível por padrão ( ) em um 5950x (32 núcleos/16 threads) com 64 GiB de RAM, portanto, é provável que seja muito mais perceptível em CPUs menos potentes.
Como observação lateral, não tenho certeza do porquê/como a Canonical/Ubuntu decidiu lançar essa configuração rigorosa, considerando quantos tópicos reclamando sobre estalos estão espalhados neste fórum e em outros.
O provável problema com sons de estalo no Ubuntu 24.04 é que a distribuição está migrando para o pipewire e executa um serviço de conversão do Pulse Audio, chamado pipewire-pulse .
O desafio é que muitos aplicativos não se comunicam diretamente com o piepewire, mas o fazem por meio do JACK e/ou especialmente do próprio pulso , portanto os dados de som precisam ser movidos por saltos adicionais.
O buffer de tempo padrão para pipewire-pulse é de 2,7 ms, o que significa que um aplicativo precisa ser capaz de preencher o conteúdo sonoro a cada 2,7 ms, caso contrário, o pipewire enviará ao dispositivo de áudio o que foi preenchido anteriormente e potencialmente alguns dados aleatórios, daí o estalo.
2,7 ms é um tempo bastante rigoroso, especialmente para aplicativos que não têm threads dedicados para áudio (provavelmente Proton/wine/jogos) e/ou quando executados em CPUs antigas - portanto, uma maneira de limitar o cracking é dizer ao pipewire-pulse para definir um buffer de tempo maior, embora adicionando um atraso ao momento em que o som é enviado ao dispositivo de áudio.
Para fazer isso, é necessário abrir o arquivo:
/usr/share/pipewire/pipewire-pulse.confE então localize, descomente e altere a configuração do item:
do valor
128para algo maior - deve-se tentar256ou mesmo512como um ponto de partida e se não houver estalos, deve-se deixar como está (observe que após salvar o arquivo, é preciso reiniciar o pipewire, pipewire-pulse viasystemctl --user restart wireplumber pipewire pipewire-pulse).O segredo é encontrar o menor número para que o estalo irritante não esteja presente (ou em um mínimo aceitável), porque se números maiores (como
1024) fizerem com que ocorra muito pouco estalo, eles adicionam um atraso (1024 / 48000 -> 21.333 ms).CPUs mais lentas precisarão de números iguais
512ou maiores, ou ao usar vários softwares mantendo a CPU ocupada, é provável que um número como1024ou mesmo2048possa ser benéfico.Observe que o estalo é
128/48000perceptível por padrão ( ) em um 5950x (32 núcleos/16 threads) com 64 GiB de RAM, portanto, é provável que seja muito mais perceptível em CPUs menos potentes.Como observação lateral, não tenho certeza do porquê/como a Canonical/Ubuntu decidiu lançar essa configuração rigorosa, considerando quantos tópicos reclamando sobre estalos estão espalhados neste fórum e em outros.