Je vois un tas d'affirmations selon lesquelles Jack est plus rapide que Pulse et a moins de latence. Comment est-ce ainsi? Pourquoi Pulse s'appelle-t-il léger, et les gars de Jack l'appellent-ils gros ? Quelqu'un pourrait-il décomposer les composants internes de ces deux démons pour un profane ?
Réponse acceptée :
Jack vous demande, en tant qu'utilisateur averti, de configurer le serveur pour déterminer la latence de traitement la plus faible possible. pour votre appareil. (La latence de traitement est le temps qu'il faut au serveur pour déplacer les 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 buffer underrun (parfois appelé "dropout", ou pops et clics ). Si Jack subit constamment des sous-exécutions, il vous incombe soit de redémarrer le serveur avec des paramètres différents, soit de modifier quelque chose dans la ou les applications clientes pour les rendre plus efficaces afin que vous puissiez respecter vos délais audio. Étant donné que les paramètres de votre serveur s'appliquent uniformément à tous les clients, Jack est très utile pour router l'audio entre plusieurs applications audio et devenir prévisible résultats. (C'est-à-dire que c'est comme brancher des "prises" dans divers composants audio.)
Pulse est conçu pour minimiser le nombre de fois où l'audio est interrompu parce que le serveur ne respecte pas un délai pour envoyer/recevoir de l'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 "injecter" des échantillons dans ce tampon pour les applications clientes dont l'échéance est plus proche. S'il essaie d'injecter des échantillons si tôt qu'il manque une échéance et provoque une sous-utilisation, Pulse augmentera automatiquement la durée la plus courte pendant laquelle un client pourra envoyer une mise à jour audio au serveur. Les documents Pulse indiquent explicitement que ultra faible latence – disons, 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 programmation 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 , quelque chose que malheureusement de nombreuses applications Linux Audio ignorent apparemment.) En termes de complexité sous-jacente par rapport à Jack, Pulse est "gros".
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é. Latence aller-retour est le temps qu'il faut à votre système pour traiter l'audio et recevoir ce qu'il a traité dans le système. Il existe des tutoriels en ligne qui expliquent comment faire cela 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, gratter les cordes d'une guitare) et le moment où vous entendez pour la première fois le son qui en résulte (par exemple, entendre l'accord de guitare).
En relation :Est-il généralement plus rapide de sélectionner dans une table temporaire que de sélectionner dans une table réelle ?Enfin, gardez à l'esprit que Pulse et Jack reposent tous deux sur ALSA sur la plupart des distributions GNU/Linux. Je sais que vous ne posez que des questions sur Jack contre Pulse. Mais si vous utilisez une seule application audio qui peut se connecter directement à ALSA, il n'y a aucun moyen concevable que l'ajout de Pulse ou de Jack vous permette de réduire la latence perçue qu'ALSA seul. En ce sens, Pulse et Jack sont "gros".
tldr ; ALSA seul est le plus rapide, Jack est utile pour enchaîner plusieurs applications audio, et Pulse est probablement le plus simple à utiliser lorsque vous ne vous souciez pas de la latence ultra faible. Ignorez toute documentation ou discussion utilisant le terme latence sans expliquer de quel type de latence il s'agit. (Malheureusement, les documents officiels de Jack et les entrées 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 doivent être rares. Mais branchez un périphérique de bouclage et testez mon hypothèse !