Jack verlangt, dass Sie - der sachkundige Benutzer - den Server so konfigurieren, dass die niedrigstmögliche Verarbeitungslatenz für Ihren Computer ermittelt wird. (Die Verarbeitungslatenz ist die Zeit, die der Server benötigt, um Daten zu / von den Client-Anwendungen zu verschieben und dann den nächsten "Block" von Audio-Samples außerhalb des Systems zu senden / zu empfangen.) Jack liefert diese Audiodatenblöcke entweder pünktlich oder es wird fehlschlagen und Sie erhalten einen Puffer-Unterlauf (manchmal als "Dropout" oder Knacksen und Klicken bezeichnet)). Wenn Jack ständig unterboten wird, müssen Sie entweder den Server mit anderen Einstellungen neu starten oder die Clientanwendungen so anpassen, dass sie effizienter sind und Sie Ihre Audio-Fristen einhalten können. Da Ihre Servereinstellungen für alle Clients einheitlich gelten, ist Jack sehr nützlich, um Audio zwischen mehreren Audioanwendungen zu routen und vorhersagbare Ergebnisse zu erzielen . (Das heißt, es ist wie das Anschließen von "Buchsen" an verschiedene Audiokomponenten.)
Pulse wurde entwickelt, um die Häufigkeit von Audioausfällen zu minimieren, da der Server eine Frist für das Senden / Empfangen von Audio außerhalb des Systems nicht einhält. Dies wird offensichtlich versucht, indem ein großer Puffer für Clientanwendungen ausgewählt wird, für die keine geringe Verarbeitungslatenz erforderlich ist , und anschließend für Clientanwendungen , für die eine kürzere Frist gilt, Beispiele in diesen Puffer "injiziert" werden. Wenn versucht wird, Samples so schnell einzuspeisen, dass eine Frist überschritten wird und ein Unterlauf auftritt, erhöht Pulse automatisch die kürzeste Zeit, die ein Client benötigt, um ein Audio-Update an den Server zu senden. In Pulse-Dokumenten wird ausdrücklich angegeben, dass die Latenzzeit extrem niedrig ist - beispielsweise weniger als 10 ms Verarbeitungslatenzzeit- ist kein gestalterisches Ziel. Angesichts der Tatsache, dass Linux selbst (und wahrscheinlich Ihre Hardware) nicht für die Echtzeitplanung von Audiodaten ausgelegt ist, würde ich ihnen eher glauben.
In Bezug auf die Benutzerkonfiguration ist Pulse "leicht". (Man könnte sagen, dass Pulse eine geringe Konfigurationslatenz hat , was leider viele Linux Audio-Apps anscheinend ignorieren.) In Bezug auf die zugrunde liegende Komplexität im Vergleich zu Jack ist Pulse "fett".
Um eine endgültige Antwort zu erhalten, die schneller ist, müssen Sie lediglich ein Loopback-Gerät erwerben und die Round-Trip-Latenz auf Ihrem eigenen System messen , um die Wahrheit zu erfahren. Die Round-Trip-Latenz ist die Zeit, die Ihr System benötigt, um Audiodaten zu verarbeiten und die verarbeiteten Daten wieder in das System zu übertragen. Es gibt Online-Tutorials, die erklären, wie dies unter Linux gemacht wird. Dadurch erhalten Sie eine Vorstellung davon, wonach Sie tatsächlich suchen. Dies ist die wahrgenommene Latenz - die Zeit, die vom Auslösen eines Ereignisses (z. B. Anschlagen der Saiten einer Gitarre) bis zum ersten Hören des Klangs vergeht das Ergebnis ist (z. B. das Hören des Gitarrenakkords).
Denken Sie zum Schluss daran, dass sowohl Pulse als auch Jack auf den meisten GNU / Linux-Distributionen auf ALSA sitzen. Ich weiß, Sie fragen nur nach Jack vs. Pulse. Wenn Sie jedoch eine einzelne Audioanwendung verwenden, die eine direkte Verbindung zu ALSA herstellen kann, ist es nicht vorstellbar, dass Sie durch Hinzufügen von Pulse oder Jack eine geringere wahrgenommene Latenz als bei ALSA alleine erhalten. In diesem Sinne sind sowohl Pulse als auch Jack "fett".
tldr; ALSA alleine ist am schnellsten, Jack ist nützlich, um mehrere Audioanwendungen zu verketten, und Pulse ist wahrscheinlich am einfachsten zu verwenden, wenn Sie sich nicht für extrem niedrige Latenz interessieren. Ignorieren Sie alle Dokumentationen oder Diskussionen, in denen der Begriff Latenz verwendet wird, ohne zu erläutern, welche Art von Latenz gemeint ist. (Leider fallen sowohl die offiziellen Jack Docs als auch Lennarts Blog-Einträge zu Pulse in diese Kategorie.)
Hinweis : Es kann Randfälle geben, in denen Sie eine einzelne Audioanwendung verwenden möchten und diese über eine bescheidene ALSA-Schnittstelle und eine anständige Jack-Schnittstelle verfügt. In diesem Fall können Sie mit Jack die Latenz verringern. Wenn es sich jedoch um Apps handelt , mit denen die Latenz minimiert werden soll, sollten diese Fälle selten auftreten. Aber schließen Sie ein Loopback-Gerät an und testen Sie meine Hypothese!