[Guida] Portare la latenza a 0

GUIDA - Portare la latenza a 0 tramite la sincronizzazione di jackd

Nota: questa guida non può esserti d'aiuto se devi lavorare con applicazioni live come:
-suonare strumenti virtuali live
-monitoring di software audio
-effetti live

Per tutto il resto (registrare, comporre,....) questa guida risolverà (si spera) i tuoi problemi di latenza: sarai in grado di compensare anche latenze paragonabili ai secondi.


Cosa ci serve?

-jackd
-ardour3

ardour DEVE essere alla versione 3 in quanto presenta un tool essenziale per la sincronizzazione.

A differenza di ardour2 la versione 3 presenta la possibilità di read-ahead [leggi davanti] e write-behind [scrivere dietro].


Cosa vuol dire?

Diciamo che abbiamo un assurda latenza di 10 secondi. Per registrare in overdubbing è necessario far ascoltare al musicista la traccia precedentemente registrata, in seguito registrare ciò che sta suonando. Se abbiamo una latenza di 10s in uscita il musicista ascolterà la traccia con 10 secondi in ritardo, e la latenza in entrata farà in modo che il suo suono sia registrato 20 secondi in ritardo sulla traccia.

Ardour3 cosa fa:
-read-ahead: quando viene riprodotta la traccia la linea di playhead verrà ritardata in modo che sia sincronizzata con l'ascoltatore e non con la traccia in se. Quando ardour riproduce il 10° secondo di audio il musicista starà per sentire le prime note. In contemporanea il playhead inizierà ad avanzare dal punto 00:00:00. Il tempo indicato dall'orologio di Ardour corrisponde al segnale audio che tu senti nelle casse (e non a dove Ardour legge i file dal disco).

-write-behind: questa opzione permette ad ardour3 di "registrare indietro", ovvero la DAW è in grado di registrare in un punto precedente al playhead di un valore di latenza. Tornando al nostro musicista che registra a 10s di latenza, quando le sue prime note arriveranno alla DAW il suonatore starà suonando una ventina di battute più avanti, la DAW starà riproducendo un punto che è al doppio della distanza, ma ardour3 è consapevole che il suono che sta registrando è in ritardo, quindi lo registra in una posizione antecedente al playhead (che ricordiamo è sincronizzato con l'ascoltatore e non con la DAW) di un valore di latenza: -10s

Questa è la parte teorica. E' però necessario impostare questi valori. Ardour3 legge e compensa automaticamente la propria latenza e quella di jackd, ma non conosce i valori di latenza di un sistema (sistema operativo, driver, bus, scheda audio,..).

Grazie a jack_iodelay possiamo misurare le latenze del nostro sistema, impostarle in jackd e farle leggere ad ardour3 che andrà a compensare e sincronizzare l'audio.


Come si fa?

Per prima cosa è necessario collegare fisicamente l'uscita della nostra scheda audio con l'ingresso attraverso un cavo audio. Se non avete un ingresso di linea è possibile collegare l'uscita all'ingresso microfonico previa disattivazione del preamplificatore interno. Lo potete fare da alsamixer - nella HDA è indicato come "mic boost".

Ora sarò schematico in quanto non c'è più niente da spiegare.
-Avviamo jackd da terminale o da interfaccia grafica con le nostre impostazioni;
-Apriamo un terminale e digitiamo

Codice:

jack_iodelay

si avvierà il programma e inizierà a stampare:

Codice:

$ jack_delay
capture latency  = 1024
playback_latency = 2048
Signal below threshold...
Signal below threshold...
Signal below threshold...

-Colleghiamo jack_iodelay tramite jack in questo modo: jack_delay out -> system in | system out -> jack_delay in
-Appariranno nel terminale delle stringhe del genere:

Codice:

3106.619 frames     64.721 ms total roundtrip latency
   extra loopback latency: 34 frames
   use 17 for the backend arguments -I and -O

La prima riga indica frame e ms di latenze del roundtrip completo, secondo l'equazione frame=ms*(frequenza di campionamento) [3106=64ms*48khz || 3106=0.064s*48000hz];
La seconda linea indica la latenza non dovuta a jackd, ovvero la latenza di sistema.
Infine la terza linea indica il valore di frame da usare per compensare la latenza del sistema.

N.B.: si usano i frame perchè hanno una precisione maggiore dei ms, sia perchè è un valore più alto, sia perchè il sistema lavora a frame e non a ms.

N.B.2: ardour3 compensa già la latenza di jack, la latenza da aggiungere è SOLO quella di sistema (34 per l'intero roundtrip, quindi 17 in entrata e 17 in uscita).

Ora aprite l'interfaccia di jack e nelle impostazioni inserite il numero di frame indicato per "Latenza I/O" in QjackCtl e "Driver->Extra latence" in Cadence.

Se avviate jackd da terminale dovete aggiungere questi due perametri: jackd ....  -In -On dove n indica il valore in frame. Nel mio caso:

Codice:

jackd -v -m -dalsa -dhw:0 -r96000 -p256 -n3 -H -M -Xseq -I17 -O17

Ora godetevi il vostro ardour3 completamente sincronizzato, anche per lavorare con alte latenze a vantaggio di un carico DSP veramente irrisorio e una qualità di registrazione nettamente superiore!!


Osservazioni:

1) Come è possibile vedere da alcune ricerche che avevo fatto prima di venire a conoscenza di jack_iodelay, http://www.linux-audio.org/t704-test-latenza-e-carico-dsp

Ardour3 sincronizza correttamente. Le latenze risultanti sono semplicemente i miei 34 frame di latenza del sistema:
0.3ms=34/96
0.7ms=34/48
0.8ms=34/44.1

2) jack_iodelay porta un buon carico DSP. lasciarlo lavorare per un quarto d'ora e verificarne gli xRun è un ottimo metodo per verificare la stabilità delle impostazioni scelte.

Spero che con questa guida la domanda non sia più: quanta latenza posso risparmiare?Ma, quanta DSP posso risparmiare?Nei limiti del disco rigido, però questo è un altro discorso

P.S.: leggere https://sites.google.com/site/as91linuxsite/home/audio/latenza per maggiori informazioni sulla latenza dei sistemi



Adesso vediamo come scegliere le proprie impostazioni per poter ottenere un sistema stabile, fluido e funzionale, privo di xRun.

Per prima cosa è ovvio che bisogna conoscere i limiti del proprio sistema: personalmente so che posso permettermi di avere un carico DSP minore del 2% quando jackd è avviato, a riposo. Ovviamente sistemi superiori/inferiori al mio avranno un limite. Se non lo conoscete già fate i vostri test e trovatelo.

Un kernel RT è d'obbligo in quanto rende più fluida la trasmissione di dati e abbassa notevolmente il carico DSP. Anche del 50%.
Inoltre il sistema deve essere ovviamente settato correttamente. Sul wiki di linux audio troverete ottime guide su come impostare il proprio sistema, su questo forum potete fare ogni tipo di domanda per risolvere i vostri dubbi.

La guida in inglese
La guida in italiano (incompleta)

Ovviamente troverete che con impostazioni differenti che portano alla stessa latenza avrete carichi DSP differenti.

Fatto ciò iniziate a lavorare con jack_iodelay. Ci sono due fattori che vi indicheranno se le vostre impostazioni stanno migliorando o peggiorando.

Per prima cosa dovete lavorare coi frame di latenza extra-roundtrip. Questo valore, come dette precedentemente, indica la latenza del sistema operativo (driver, processore, scheda audio,...). E' utile sottolineare che questo valore non potrà mai raggiungere lo 0, però avrà un suo picco di minimo. In questo punto il sistema lavora nel modo migliore possibile: tutti i dati vengono processati nel tempo necessario senza richiedere overhead. Il mio PC riesce ad arrivare ad un minimo di 35. Con kernel futuri magari riuscirò a trovare valori minori.

Lavorare con latenze di sistema superiori vuol dire caricare inutilmente il processore di lavoro, rischiare di avere xrun e una qualità audio inutilizzabile. Trovate le impostazioni che vi permettono ciò e segnatevele.

Ora osserviamo i risultati di jack_delay: quando verranno stampati solamente risultati identici vorrà dire che il sistema è stabile. Se i valori di latenza continuano a variare vuol dire che il processore non riesce a lavorare in modo fluido processando i dati nello stesso tempo.

Per assurdo il sistema potrebbe rispondere positivamente con impostazioni paradossali: il mio sistema lavora bene con impostazioni a 2ms di latenza e 8ms o superiori, ma inferiori al 256ms. Con 4ms e dintorni risulta molto instabile, la latenza di extra-roundtrip raggiunge i 229 frame e gli xRun sono esagerati. Con latenza superiore ai 256ms il server non ne vuole sapere nemmeno di partire.

Ora segnatevi tutti i dati e trovate le vostre personali impostazioni, fermate jackd e impostate i valori di latenza in entrata e in uscita necessari, godendovi il vostro sistema stabile senza xrun e virtualmente senza latenza!

PARTE 3 - Analisi e risultati

Ho fatto questo test col kernel general-pae, jack impostato a 2048 frame 48kHz e 3 periodi con una latenza di 128ms, 17 frame di latenza in entrata e in uscita, risultato di jack_iodelay:

Codice:

8226.172 frames    171.379 ms total roundtrip latency
 extra loopback latency: 0 frames
 use 0 for the backend arguments -I and -O

Ho iniziato a registrare una dopo l'altra un'onda, alla decima registrazione, non soddisfatto, ne ho fatte altre 10. Il risultato è questo - la linea di playhead è impostata a +1ms rispetto alla posizione iniziale:

Situazione in ingresso alla ventesima registrazione (click per ingrandire):



Situazione in uscita alla ventesima registrazione (click per ingrandire):


Come si può vedere non c'è latenza!

Ho bisogno di un chiarimento: quando faccio il collegamento jack_delay out -> system in | system out -> jack_delay in nel terminale mi appare questo:

Codice:

Signal below threshold...
Jack: JackClient::ClientNotify ref = 6 name = jack_delay notify = 18
Jack: JackClient::ClientNotify ref = 6 name = jack_delay notify = 18
new playback latency: [1024, 1024]
Signal below threshold...
Jack: JackClient::ClientNotify ref = 6 name = jack_delay notify = 18
new capture latency: [512, 512]
Jack: JackClient::ClientNotify ref = 6 name = jack_delay notify = 18
Signal below threshold...


Significa che il mio valore da mettere come numero di frame è 18?

Codice:

Jack: JackClient::ClientNotify ref = 6 name = jack_delay notify = 18

Queste stringhe indicano degli xrun

Codice:

Signal below threshold...

Indica che non entra un segnale audio abbastanza alto nella scheda audio: il loop non è chiuso. Ti basta semplicemente alzare il volume

Ho alzato il volume e si sente un fischio fastidioso ma il messaggio in jack rimane lo stesso. Mi sa che non ho compreso bene questo passaggio Per prima cosa è necessario collegare l'uscita della nostra scheda audio con l'ingresso. Se non avete un ingresso di linea è possibile collegare l'uscita all'ingresso microfonico previa disattivazione del preamplificatore interno. Lo potete fare da alsamixer - nella HDA è indicato come "mic boost". Ho una scheda audio usb esterna ed ho alzato i volumi di questa, alsamixer non c'è più sul pc (uso il ponte jack-pulseaudio). Grazie comunque per la risposta!

devo collegare fisicamente l'entrata a e l'uscita con un cavo jack-jack

Ho collegato l' uscita della scheda all' ingresso mic del pc, i volumi erano alzati ma non è cambiato niente. Non può derivare dal fatto che ho disinstallato alsamixer?

devi lavorare con uscita e ingresso della stessa scheda audio.

Se vuoi utilizzare due schede audio diverse le devi caricare su jack con "jack_load" e poi dalle connessioni connettere l'entrata di una con l'uscita di jack_delay, e l'uscita della seconda con l'entrata di jack_delay

Ok, ci sono riuscito, grazie mille per le risposte  

 

Aggiunto la parte 2 della guida e modificata la parte che babbo mi aveva fatto notare come "poco chiara"

EDIT: aggiunta PARTE 3 - Analisi e risultati

Ciao, ho provato ad usare jack_iodelay, ma quello che ottengo è questo

Codice:


  6169.101 frames    139.889 ms total roundtrip latency
 extra loopback latency: 25 frames
 use 12 for the backend arguments -I and -O
  6168.070 frames    139.866 ms total roundtrip latency
 extra loopback latency: 24 frames
 use 12 for the backend arguments -I and -O
  6167.035 frames    139.842 ms total roundtrip latency
 extra loopback latency: 23 frames
 use 11 for the backend arguments -I and -O
  6166.028 frames    139.819 ms total roundtrip latency
 extra loopback latency: 22 frames
 use 11 for the backend arguments -I and -O
  6165.130 frames    139.799 ms total roundtrip latency
 extra loopback latency: 21 frames
  6164.123 frames    139.776 ms total roundtrip latency
 extra loopback latency: 20 frames
 use 10 for the backend arguments -I and -O
  6163.224 frames    139.756 ms total roundtrip latency
 extra loopback latency: 19 frames
 use 9 for the backend arguments -I and -O
  6162.654 frames    139.743 ms total roundtrip latency
 extra loopback latency: 18 frames
 use 9 for the backend arguments -I and -O
  6161.013 frames    139.706 ms total roundtrip latency
 extra loopback latency: 17 frames
 use 8 for the backend arguments -I and -O
  6160.015 frames    139.683 ms total roundtrip latency
 extra loopback latency: 16 frames
 use 8 for the backend arguments -I and -O
  6158.111 frames    139.640 ms total roundtrip latency
 extra loopback latency: 14 frames
 use 7 for the backend arguments -I and -O
  6157.077 frames    139.616 ms total roundtrip latency
 extra loopback latency: 13 frames
 use 6 for the backend arguments -I and -O
  6156.777 frames    139.609 ms total roundtrip latency
 extra loopback latency: 12 frames
 use 6 for the backend arguments -I and -O


molto l'ho tagliato, in sostanza mi da un valore decrescente nel giro di qualche secondo.  


EDIT
Problema risolto probabilmente a causa dei volumi, ora mi da un valore fisso,  

EDIT2
Questo problema lo fa se uso 44100Hz anzichè 48000Hz  
Quindi con 48000Hz tutto ok, con 44100Hz no

Avviando jack_delay, con certe impostazioni di jack, mi stampa correttamente i valori di extra roundtrip che rimangono costanti durante tutta la sessione. Anche con impostazioni che aumentano notevolmente il carico DSP.
Questi numeri però sono diversi ad ogni riavvio di jack_delay. È una cosa normale?
Personalmente ritengo di no, in quanto tutta la procedura di aggiungere frame extra in input e output risulterebbe inutile, visto che andrebbe rifatta ogni sessione.
Aggiungo, inoltre, che le impostazioni di jack usate sono quelle a cui ho sempre lavorato senza problemi (512, 2 @ 44.1kHz) e il carico di DSP massimo con jack_delay attivo è circa 3,3%. Questo sia con kernel lowlatency sia con il kernel di as91.

non è affatto normale: con le stesse impostazioni, stessa macchina, stessa configurazione, i valori dovrebbero essere gli stessi ad ogni avvio