Jack exige que você - o usuário experiente - configure o servidor para determinar a menor latência de processamento possível para sua máquina. (Latência de processamento é o tempo que o servidor leva para mover dados de / para os aplicativos clientes e depois enviar / receber o próximo "pedaço" de amostras de áudio fora do sistema.) Jack entregará esses pedaços de dados de áudio a tempo, ou ele falhará e causará uma falha no buffer (às vezes chamado de "abandono" ou pop e cliques) Se Jack estiver constantemente com falhas de desempenho, é seu trabalho reiniciar o servidor com configurações diferentes ou alterar algo nos aplicativos clientes para torná-los mais eficientes, para que você possa cumprir seus prazos de áudio. Como as configurações do servidor se aplicam uniformemente a todos os clientes, Jack é bastante útil para rotear o áudio entre vários aplicativos de áudio e obter resultados previsíveis . (Ou seja, é como conectar "tomadas" em vários componentes de áudio.)
O Pulse foi projetado para minimizar o número de vezes que o áudio cai devido ao servidor não cumprir um prazo para enviar / receber áudio para fora do sistema. Aparentemente, ele tenta fazer isso escolhendo um buffer grande para aplicativos clientes que não solicitam baixa latência de processamento e , em seguida, "injetando" amostras nesse buffer para aplicativos clientes com prazo mais curto. Se tentar injetar amostras tão cedo que perder um prazo e causar uma falha, o Pulse aumentará automaticamente o menor tempo possível para permitir que um cliente envie uma atualização de áudio ao servidor. Os documentos do Pulse afirmam explicitamente que a latência é extremamente baixa - digamos, menos de 10ms de latência de processamento- não é um objetivo de design. Como o próprio Linux (e provavelmente o seu hardware) não foi projetado para agendamento de áudio em tempo real, eu acreditaria neles.
Em termos de configuração do usuário, o Pulse é "leve". (Pode-se dizer que o Pulse possui baixa latência de configuração , algo que infelizmente muitos aplicativos de áudio do Linux aparentemente desconsideram.) Em termos de complexidade subjacente, em comparação com Jack, o Pulse é "gordo".
Para obter uma resposta definitiva e mais rápida, você só precisa obter um dispositivo de loopback e medir a latência de ida e volta no seu próprio sistema para saber a verdade. Latência de ida e volta é o tempo que o sistema leva para processar o áudio e receber o que foi processado de volta no sistema. Existem tutoriais online que explicam como fazer isso no Linux. Isso lhe dará uma idéia do que realmente está buscando, que é a latência percebida - o tempo que leva desde o momento em que você aciona um evento (por exemplo, tocando as cordas de um violão) até o momento em que você ouve o som pela primeira vez. que resulta (por exemplo, ouvir o acorde da guitarra).
Por fim, lembre-se de que Pulse e Jack estão no topo da ALSA na maioria das distribuições GNU / Linux. Eu sei que você está apenas perguntando sobre Jack vs. Pulse. Mas se você estiver usando um único aplicativo de áudio que possa se conectar diretamente ao ALSA, não há maneira concebível de que a adição de Pulse ou Jack apresente menor latência percebida do que o ALSA sozinho. Nesse sentido, tanto Pulse quanto Jack são "gordos".
tldr; Somente o ALSA é o mais rápido, o Jack é útil para encadear vários aplicativos de áudio e o Pulse é provavelmente mais fácil de usar quando você não se importa com latência ultra baixa. Ignore qualquer documentação ou discussão que use o termo latência sem explicar o tipo de latência. (Infelizmente, os documentos oficiais de Jack e as entradas de blog de Lennart sobre o Pulse se enquadram nessa categoria.)
Nota : Pode haver casos extremos em que você deseja usar um único aplicativo de áudio e ele possui uma interface ALSA ruim e uma interface Jack decente. Nesse caso, usar Jack pode reduzir a latência. Mas se estamos falando de aplicativos projetados para minimizar a latência, esses casos devem ser raros. Mas conecte um dispositivo de loopback e teste minha hipótese!