Jack wymaga od Ciebie - znającego się na rzeczy użytkownika - skonfigurowania serwera, aby określić najniższe możliwe opóźnienie przetwarzania dla twojego komputera. (Opóźnienie przetwarzania to czas, jaki zajmuje serwerowi przeniesienie danych do / z aplikacji klienckich, a następnie wysłanie / odbiór kolejnej „części” próbek audio poza systemem.) Jack dostarczy te fragmenty danych audio na czas lub zawiedzie i spowoduje niedopełnienie bufora (czasami nazywane „rezygnacją”) lub wyskakuje i klika). Jeśli Jack konsekwentnie jest niedopracowany, Twoim zadaniem jest albo zrestartować serwer z innymi ustawieniami, albo zmienić coś w aplikacjach klienckich, aby zwiększyć ich wydajność, abyś mógł dotrzymać terminów audio. Ponieważ ustawienia serwera dotyczą jednakowo wszystkich klientów, Jack jest bardzo przydatny do kierowania dźwięku między wieloma aplikacjami audio i uzyskiwania przewidywalnych rezultatów. (Tj. To jak podłączanie „gniazd” do różnych komponentów audio.)
Pulse ma na celu zminimalizowanie liczby wypadków dźwięku z powodu niespełniania przez serwer terminu wysyłania / odbierania dźwięku poza systemem. Najwyraźniej próbuje to zrobić, wybierając duży bufor dla aplikacji klienckich, które nie wymagają niskiego opóźnienia przetwarzania , a następnie „wstrzykując” próbki do tego bufora dla aplikacji klienckich, które mają wcześniejszy termin. Jeśli spróbuje wstrzyknąć próbki tak szybko, że przekroczy termin i spowoduje niedopełnienie, Pulse automatycznie wydłuży jak najkrótszy czas, umożliwiając klientowi przesłanie aktualizacji audio do serwera. Dokumenty Pulse wyraźnie stwierdzają, że bardzo niskie opóźnienie - powiedzmy, mniej niż 10 ms opóźnienia przetwarzania- nie jest celem projektowym. Biorąc pod uwagę, że sam Linux (i prawdopodobnie twój sprzęt) nie został zaprojektowany do planowania dźwięku w czasie rzeczywistym, chętnie w to uwierzę.
Jeśli chodzi o konfigurację użytkownika, puls jest „lekki”. (Można powiedzieć, że Pulse ma małe opóźnienie konfiguracji , co niestety wiele aplikacji Linux Audio najwyraźniej lekceważy.) Pod względem złożoności w porównaniu do Jacka, Pulse jest „gruby”.
Aby uzyskać ostateczną odpowiedź, która jest szybsza, wystarczy zdobyć urządzenie zwrotne i zmierzyć opóźnienie w obie strony w swoim systemie, aby poznać prawdę. Opóźnienie w obie strony to czas, w którym Twój system przetwarza dźwięk i odbiera to, co przetworzył z powrotem do systemu. Dostępne są samouczki online, które wyjaśniają, jak to zrobić w systemie Linux. To da ci wyobrażenie o tym, czego tak naprawdę szukasz, czyli o postrzeganym opóźnieniu - czasie, który upływa od momentu uruchomienia zdarzenia (np. Uderzenia struny gitary) do momentu pierwszego usłyszenia dźwięku powoduje to (np. usłyszenie akordu gitary).
Na koniec należy pamiętać, że zarówno Pulse, jak i Jack siedzą na szczycie ALSA w większości dystrybucji GNU / Linux. Wiem, że pytasz tylko o Jacka vs. Pulse. Ale jeśli używasz pojedynczej aplikacji audio, która może łączyć się bezpośrednio z ALSA, nie ma możliwego sposobu, aby dodanie Pulse lub Jacka zapewniło mniejsze opóźnienie niż sam ALSA. W tym sensie zarówno Pulse, jak i Jack są „grubi”.
tldr; Sam ALSA jest najszybszy, Jack jest przydatny do łączenia wielu aplikacji audio, a Pulse jest prawdopodobnie najłatwiejszy w użyciu, gdy nie obchodzi Cię bardzo małe opóźnienie. Zignoruj wszelką dokumentację lub dyskusje, które używają terminu latencja, nie wyjaśniając, jaki rodzaj latencji oznacza. (Niestety, zarówno oficjalne dokumenty Jack'a, jak i wpisy na blogu Lennarta o Pulse należą do tej kategorii).
Uwaga : mogą istnieć przypadki, w których chcesz użyć pojedynczej aplikacji audio i ma ona kiepski interfejs ALSA i przyzwoity interfejs Jacka. W takim przypadku użycie Jacka może obniżyć opóźnienie. Ale jeśli mówimy o aplikacjach zaprojektowanych w celu zminimalizowania opóźnień, przypadki te powinny być rzadkie. Ale podłącz urządzenie z pętlą zwrotną i sprawdź moją hipotezę!