Jack exige que você - o usuário experiente - configure o servidor para determinar a
O Pulse foi projetado para minimizar o número de vezes que o áudio é interrompido devido ao servidor não cumprir um prazo para envio / recebimento de áudio fora do sistema. Ele aparentemente tenta fazer isso escolhendo um buffer grande para aplicativos clientes que não requerem baixa latência de processamento , depois "injetando" amostras nesse buffer para aplicativos de clientes que possuem um prazo mais rápido. Se ele tentar injetar amostras tão cedo que não cumpra um prazo e cause um déficit, o Pulse aumentará automaticamente o menor tempo possível para que um cliente envie uma atualização de áudio para o servidor. Documentos de pulso afirmam explicitamente que a latência baixa ultra - digamos, menos de 10 ms de latência de processamento - não é uma meta de design. Dado que o próprio Linux (e provavelmente o seu hardware) não foi projetado para agendamento em tempo real de áudio, eu estaria apto a acreditar neles.
Em termos de configuração do usuário, o Pulse é "leve". (Pode-se dizer que o Pulse tem baixa latência de configuração , algo que infelizmente muitos aplicativos de áudio do Linux aparentemente desconsideram.) Em termos de sua complexidade subjacente em comparação com o Jack, o Pulse é "gordo".
Para obter uma resposta definitiva sobre o que é mais rápido, você só precisará obter um dispositivo de loopback e medir a latência de ida e volta em 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 é processado de volta no sistema. Existem tutoriais on-line que explicam como fazer isso no Linux. Isso lhe dará uma idéia do que você realmente quer, qual é a latência percebida - o tempo que leva do momento em que você dispara um evento (por exemplo, dedilhando as cordas de uma guitarra) no momento em que você ouvir o som resultante (por exemplo, ouvir o acorde da guitarra).
Finalmente, tenha em mente que tanto o Pulse quanto o Jack estão no 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 é possível que a adição do Pulse ou do Jack reduza a latência percebida em relação à ALSA. 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 ser usado quando você não se importa com latência ultrabaixa. Ignore qualquer documentação ou discussões que usem o termo latência sem explicar que tipo de latência significa. (Infelizmente, tanto os documentos oficiais de Jack quanto as entradas de Lennart no blog se enquadram nessa categoria.)
Nota : Pode haver casos extremos em que você deseja usar um único aplicativo de áudio e ele tem uma interface ALSA crummy e uma interface Jack decente. Nesse caso, usando Jack você pode obter menor 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!
