Jack vous oblige - l'utilisateur averti - à configurer le serveur pour déterminer la latence de traitement la plus faible possible pour votre machine. (La latence de traitement est le temps nécessaire au serveur pour déplacer des données vers / depuis les applications clientes, puis envoyer / recevoir le prochain "morceau" d'échantillons audio en dehors du système.) Jack fournira ces morceaux de données audio à temps, ou il échouera et vous donnera un tampon de sous-exécution (parfois appelé "abandon", ou pops et clics). Si Jack subit systématiquement des sous-exécutions, il vous appartient soit de redémarrer le serveur avec des paramètres différents, soit de modifier quelque chose dans les applications clientes pour les rendre plus efficaces afin que vous puissiez respecter vos délais audio. Étant donné que vos paramètres de serveur s'appliquent uniformément à tous les clients, Jack est très utile pour acheminer l'audio entre plusieurs applications audio et obtenir des résultats prévisibles . (C'est-à-dire, c'est comme brancher des "jacks" dans divers composants audio.)
Pulse est conçu pour minimiser le nombre de fois où l'audio est interrompu car le serveur ne respecte pas la date limite d'envoi / réception audio en dehors du système. Il essaie apparemment de le faire en choisissant un grand tampon pour les applications clientes qui ne demandent pas une faible latence de traitement , puis en "injectant" des échantillons dans ce tampon pour les applications clientes qui ont un délai plus tôt. S'il essaie d'injecter des échantillons si tôt qu'il manque une échéance et provoque un sous-dépassement, Pulse augmentera automatiquement le temps le plus court qu'il permettra à un client d'envoyer une mise à jour audio au serveur. Pulse docs état explicitement que ultra faible latency-- disent, moins de 10 ms de latence de traitement- n'est pas un objectif de conception. Étant donné que Linux lui-même (et probablement votre matériel) n'a pas été conçu pour la planification audio en temps réel, je serais enclin à les croire.
En termes de configuration utilisateur, Pulse est "léger". (On pourrait dire que Pulse a une faible latence de configuration , ce que malheureusement de nombreuses applications Linux Audio semblent ignorer.) En termes de complexité sous-jacente par rapport à Jack, Pulse est "gras".
Pour obtenir une réponse définitive sur ce qui est le plus rapide, il vous suffit d'obtenir un périphérique de bouclage et de mesurer la latence aller-retour sur votre propre système pour connaître la vérité. La latence aller-retour est le temps nécessaire à votre système pour traiter l'audio et recevoir ce qu'il a traité dans le système. Il existe des didacticiels en ligne qui expliquent comment procéder sous Linux. Cela vous donnera une idée de ce que vous recherchez réellement, c'est-à-dire la latence perçue - le temps qu'il faut entre le moment où vous déclenchez un événement (par exemple, le grattage des cordes d'une guitare) jusqu'au moment où vous entendez le son pour la première fois. qui en résulte (par exemple, entendre l'accord de guitare).
Enfin, gardez à l'esprit que Pulse et Jack se trouvent tous les deux au-dessus d'ALSA sur la plupart des distributions GNU / Linux. Je sais que tu ne demandes que Jack contre Pulse. Mais si vous utilisez une seule application audio pouvant se connecter directement à ALSA, il n'y a aucun moyen concevable que l'ajout de Pulse ou Jack vous obtienne une latence perçue inférieure à celle d'ALSA seul. En ce sens, Pulse et Jack sont tous deux "gros".
tldr; ALSA seul est le plus rapide, Jack est utile pour chaîner plusieurs applications audio et Pulse est probablement plus facile à utiliser lorsque vous ne vous souciez pas de la latence ultra faible. Ignorez toute documentation ou discussion qui utilise le terme latence sans expliquer de quel type de latence il s'agit. (Malheureusement, les documents officiels de Jack et les articles de blog de Lennart sur Pulse entrent dans cette catégorie.)
Remarque : Il peut y avoir des cas extrêmes où vous souhaitez utiliser une seule application audio et elle a une interface ALSA minable et une interface Jack décente. Dans ce cas, l'utilisation de Jack peut réduire la latence. Mais si nous parlons d'applications conçues pour minimiser la latence, ces cas devraient être rares. Mais connectez un périphérique de bouclage et testez mon hypothèse!