Embedded Files
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
Code:
jack_iodelay
si avvierà il programma e inizierà a stampare:
Code:
$ 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:
Code:
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:
Code:
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
PARTE 2 - Impostazioni e stabilità
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 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:
Code:
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
Situazione in uscita alla ventesima registrazione
Come si può vedere non c'è latenza!
Page updated
Google Sites
Report abuse