Jack richiede all'utente, l'utente competente, di configurare il server per determinare la latenza di elaborazione più bassa possibile per la propria macchina. (La latenza di elaborazione è il tempo impiegato dal server per spostare i dati da / verso le applicazioni client e quindi inviare / ricevere il successivo "blocco" di campioni audio all'esterno del sistema.) Jack consegnerà quei blocchi di dati audio in tempo, oppure fallirà e ti darà un buffer underrun (a volte chiamato "dropout", o pop e click). Se Jack ottiene costantemente underrun, il tuo compito è riavviare il server con impostazioni diverse o modificare qualcosa nelle applicazioni client per renderle più efficienti in modo da poter rispettare le scadenze audio. Poiché le impostazioni del tuo server si applicano in modo uniforme a tutti i client, Jack è abbastanza utile per instradare l'audio tra più applicazioni audio e ottenere risultati prevedibili . (Cioè, è come collegare "jack" a vari componenti audio.)
Pulse è progettato per ridurre al minimo il numero di interruzioni dell'audio a causa del mancato rispetto da parte del server di una scadenza per l'invio / la ricezione dell'audio all'esterno del sistema. Apparentemente tenta di farlo scegliendo un buffer di grandi dimensioni per le applicazioni client che non richiedono una bassa latenza di elaborazione , quindi "iniettando" campioni in quel buffer per le applicazioni client che hanno una scadenza prima. Se tenta di iniettare campioni così presto da non rispettare una scadenza e causare un superamento, Pulse aumenterà automaticamente il minor tempo possibile e consentirà a un client di inviare un aggiornamento audio al server. I documenti Pulse dichiarano esplicitamente che una latenza ultra bassa, ad esempio meno di 10 ms di latenza di elaborazione- non è un obiettivo di design. Dato che Linux stesso (e probabilmente il tuo hardware) non è stato progettato per la programmazione in tempo reale dell'audio, sarei propenso a crederci.
In termini di configurazione dell'utente, Pulse è "leggero". (Si potrebbe dire che Pulse ha una bassa latenza di configurazione , qualcosa che sfortunatamente molte app di Linux Audio sembrano ignorare.) In termini di complessità sottostante rispetto a Jack, Pulse è "grasso".
Per ottenere una risposta definitiva su quale è più veloce, devi solo ottenere un dispositivo di loopback e misurare la latenza di andata e ritorno sul tuo sistema per conoscere la verità. La latenza di andata e ritorno è il tempo impiegato dal sistema per elaborare l'audio e ricevere ciò che è stato elaborato nel sistema. Ci sono tutorial online che spiegano come farlo sotto Linux. Questo ti darà un'idea di ciò che stai effettivamente cercando, ovvero la latenza percepita - il tempo necessario dal momento in cui attivi un evento (ad esempio, strimpellando le corde di una chitarra) al momento in cui senti il suono per la prima volta che risulta (ad esempio, sentire l'accordo della chitarra).
Infine, tieni presente che sia Pulse che Jack sono in cima ad ALSA sulla maggior parte delle distribuzioni GNU / Linux. So che stai solo chiedendo di Jack vs. Pulse. Ma se stai utilizzando una singola applicazione audio che può connettersi direttamente ad ALSA, non è immaginabile che l'aggiunta di Pulse o Jack ti riduca una latenza percepita inferiore rispetto a ALSA da sola. In tal senso, sia Pulse che Jack sono "grassi".
TLDR; Il solo ALSA è il più veloce, Jack è utile per concatenare più applicazioni audio e Pulse è probabilmente il più facile da usare quando non ti interessa la latenza ultra bassa. Ignora qualsiasi documentazione o discussione che utilizzi il termine latenza senza spiegare che tipo di latenza si intende. (Sfortunatamente, sia i documenti ufficiali di Jack che i post sul blog di Lennart su Pulse rientrano in questa categoria.)
Nota : potrebbero esserci casi limite in cui si desidera utilizzare una singola applicazione audio e ha un'interfaccia ALSA scadente e un'interfaccia Jack decente. In tal caso, l'utilizzo di Jack potrebbe ridurre la latenza. Ma se stiamo parlando di app progettate per ridurre al minimo la latenza, questi casi dovrebbero essere rari. Ma collegare un dispositivo di loopback e testare la mia ipotesi!