jack- impostazioni dopo un anno di utilizzo

ciao a tutti, scrivo questo post come frutto della mia esperienza, quella di chi mi ha aiutato e di tutti quelli che hanno scritto post riguardo jack e le sue impostazioni. Per prima cosa vorrei ringraziare tutti voi che continuate ad utilizzare linux e a sbattere la testa quando trovate qualche difficoltà, e tutti voi che continuate ad aiutare e riuscite ad avere la pazienza per continuare a spiegare le stesse cose, utente dopo utente.

Perchè scrivo questo post?molte delle guide su jack sono in inglese, altre ti spigano che devi usare certi tipi di settaggi definendoli "i migliori" senza spiegarti il perchè e il significato di ciò che stai andando a modificare, propinandoti delle specie di formule magiche... Io penso che non esista un settaggio ottimale, indipendentemente da scheda a scheda, ognuno deve trovare il suo provando e riprovando. Ecco la mia esperienza che mi ha portato al mio settaggio odierno.

All'inizio io lavoravo con kubuntu, lavoravo con 128 44.1 2 (fotogrammi/periodo, frequenza di campionamento, periodi/buffer), adattato a lavorare in RT, fino a che un giorno mi accorsi che non stavo sfruttando al massimo il mio SO. Passato ad ubuntu studio non riuscivo a raggiungere quella impostazione e così ho iniziato a rivoltare internet in cerca di informazioni. Ora lavoro con 64-96-3 con carico di sistema di 4.2% (misurata con htop) e latenza reale (misurata con lacencyTop) di 1.9 ms.

I miei passi sono stati:
-effettuare una scansione del sistema con lo script  http://wiki.linuxaudio.org/wiki/system_configuration#quickscan

L'output stampa la situazione della configurazione del sistema, ogni errore è affiancato ad un link della guida. In particolar modo ho apprezzato i suggerimenti sull: CPU scaling, swappiness, sincronizzazione IRQ della scheda audio e unbind dei conflitti IRQ, impostazione dei timer hardware.

a questo punto ero abbastanza soddisfatto, però preso dalla curiosità di vedere fino a che punto posso arrivare ho:
-compilato il mio kernel RT (si trovano molte guide su internet. Di base ho utilizzato quella di wiki.linuxaudio.org)
-disabilitato i servizi non necessari tramite lo script =>

SCRIPT:

-script per ritardare gli interrupt sulla scheda audio =>

SCRIPT:

Inoltre ho scoperto che jack lavora meglio con le periferiche USB hanno latenza multipla di 2, applicando questo alla scheda integrata riceve notevoli vantaggi sia diminuendo il carico di sistema sia la latenza.

Questa è la tabella delle latenze (solo quelle che si possono scrivere come potenza di 2)

TABLE:

Pur non essendo una scheda usb i vantaggi sono notevoli, lavorando con 64 96 3 ho carico di sistema di 4.2 e latenza reale di 1.9 ms. Nessun xRun in una sessione di almeno un'ora. Con 256 96 2 ho un carico di sistema del 15%, una latenza teorica di 5.33ms, una latenza reale di circa 102ms e il primo xrun dopo 5 minuti. Difatti si percepisce distintamente un ritardo tra suono in entrata e suono in uscita.

Cosa fanno queste impostazioni e miei consigli sulle impostazioni

La dimensione del buffer è secondo me l'impostazione più importante in quanto la più dinamica del programma.
Per ottenere una certa qualità bisogna necessariamente utilizzare o 96kHz o 192kHz.
Per poter ottenere una latenza tale che sia multipla di 2 bisogna necessariamente utilizzare 3 periodi per buffer. Un numero superiore aumenterebbe inutilmente la latenza.

A orecchio umano registrare a 96kHz o a 192kHz è indifferente. Io scelgo i 192kHz se prevedo che il suono debba effettuare molti passaggi che ne determinino il suo deterioramento (effetti, filtri,....).

Se devo lavorare senza aver bisogno della scheda audio (quindi senza dover registrare da fonte esterna) non mi preoccupo di tenere la latenza al minimo possibile: è inutile caricare la CPU inutilmente, rischiare xRun e lavorare con un suono facilmente deteriorabile. In questi casi lavorare con buffersize alti (1024 ad esempio) non è affatto un problema, anzi, personalmente lo consiglio.

Al contrario è ovvio che se dobbiamo registrare più tracce dall'esterno avremo bisogno di una bassa latenza.
Se utilizzo una scheda esterna a 4/6/8 in preferisco comunque non scendere sotto i 128 fotogrammi: una scheda multi-traccia registra le tracce impostando come latenza in ingresso la latenza maggiore delle tracce, ovvero sincronizza tutte le tracce sulla più lenta. Di contro una scheda del genere carica lavoro la CPU e il disco rigido (anche se ha dei chip di elaborazione interni). A questo punto si capisce che è meglio registrare con un po' di latenza che può essere facilmente rimossa (essendo tutte le tracce già sincronizzate tra loro).

I problemi si hanno quando si deve registrare con un numero limitato di ingressi (2 mono per una scheda integrata stereo, 3 se ha anche sia line-in stereo che mic-in mono). La mia esperienza registrando in sala è che se sei bravo puoi riallineare le tracce, ma è un lavoro che spesso ti farà infrangere il secondo comandamento.. Qui utilizzare una latenza bassa è estremamente consigliato. Il settaggio ottimale per avere la latenza minore è dato dall'esperienza (mentre sto scrivendo qui ho trovato un settaggio migliore rispetto l'ultimo che consideravo tale). Il mio consiglio è quelle di tenere sempre 3 periodi per buffer in quanto fa avvicinare notevolmente la latenza reale a quella teorica (utilizzare latenctTop per verificarla). Per cercare la latenza minima lascia lavorare il server jack con ardour che ti registra una traccia (senza clippare) da un lettore mp3 per circa 15-20 minuti. se non ci sono xrun prova ad abbassare la latenza, se riscontri uno o due xrun prova a modificare buffersize e frequenza di campionamento in modo da avere lo stesso valore di latenza (esempio: se sei a 64 96 prova a mettere a 128 196, o viceversa: il buffersize e direttamente proporzionale alla latenza, mentre il campionamento ne è inversamente proporzionale). Come dice  Stefano Droghetti nella sua nota guida: se gli xRun sono uno ogni quarto d'ora va bene, altrimenti cambia impostazioni!

Di sicuro questo non è tutto, ma la stanchezza di fine giornata rende difficile scrivere. comunque sia che abbiate consigli, sia che abbiate domande, siamo qua per condividere e aiutarci!

EDIT:

Ciao,
prima di tutto grazie per aveer condiviso le tue esperienze.

Mancano però alcuni dettagli molto importanti:
- processore / ram che stai utilizzando;
- tipo di scheda audio;
- versione del kernel e relative patch.

Mi permetto di dissentire su una frase: "se gli xRun sono uno ogni quarto d'ora va bene".
Se quell'xrun arriva mentre stai registrando, ti assicuro che NON va affatto bene, soprattutto se viene generato un glitch digitale che di fatto rovina la registrazione.
Va quindi trovato il punto di equilibrio nelle impostazioni per ottenere la latenza più bassa possibile, dove per punto di equilibrio intendo NESSUN xrun in lavorazione. Gli unici che possono essere non considerati sono quelli dovuti all'apertura/chiusura dei programmi.
Il sistema andrebbe poi testato non con una sola traccia in registrazione, ma con più tracce armate in rec ed i plugin che si prevede di utilizzare attivi.
Tuttavia se la necessità è quella di registrare una sola traccia, magari stereo, il tuo approccio al test è corretto.

Un ultimo appunto sulla latenza espressa da QJackctl, che va divisa per due, nel senso che considera interamente il processo HW>SW e SW>HW, quindi "2msec" significa "1msec" di latenza in registrazione + "1msec" di latenza in riproduzione.

Ciao,
Touch.

PS: Il suono in 2msec si propaga di circa 70cm, quindi quando suoni in un palco, con l'ampli a 5 metri, la latenza è ben superiore...

touchstyle ha scritto:
Mancano però alcuni dettagli molto importanti:
- processore / ram che stai utilizzando;
- tipo di scheda audio;
- versione del kernel e relative patch.

A riguardo mi era già venuto in mente un piccolo appunto: dalla mia esperienza (e quindi potrei anche essere in torto), la maggior parte dei problemi è causato da colli di bottiglia dovuti a CPU e kernel mal settati: la scheda audio è spesso innocente in quanto dovrebbe lavorare solo per convertire il segnale audio in entrata e in uscita da analogico a digitale e viceversa. La scheda audio con cui ho fatto le prove è quella integrata (una HDA Intel). Di conseguenza quando si lavora "internamente", ovvero da sequencer a DAW, o VST, etc. la scheda audio non dovrebbe essere sollecitata. Inoltre ho 4Gb di ram che non ho mai utilizzato oltre gli 800-1000Mb (20-25%). Al contrario il processore l'ho spinto fino al 99% (caso in cui si sono riscontrati xRun, multipli e decisamente proibitivi). Il mio processore è un intel core i3 330M che lavora con 4 cuori a 3M Cache, 2.13 GHz. Riguardo al kernel: io ho sperimentato il linux-image-3.2.0-60-generic-pae, il linux-image-3.2.0-59-lowlatency-pae, è il 3.2.54-rt77 compilato da me stesso (sia in modalità hard che soft). La differenza è notevole è attualmente mi rifiuto di usare il RT a meno che non devo registrare. Un altro fattore importante che viene trascurato è l'HD: anche se si riesce lavorare registrando grandi pacchetti a frenqueze di campionameno alto, se l'HD non è abbastanza veloce non riesce a star dietro ai programmi. Mi sono trovato ad avere una configurazione ottimale di jack, ma ottenere messaggi da rosegarden del tipo "la riproduzione è stata terminata in quanto il processo ha richiesto un carico eccessivo della CPU" o da ardour (messaggio rpeciso che mie ero segnato perchè mi aveva fatto ridere) :"Il disco di sistema sul tuo computer non è in grado di stare dietro ad Ardour. In specifico, non ha scritto i dati sul disco abbastanza velocemente da mantenere la registrazione.".

E' come una catena: è inutile avere un sacco di anelli forti se poi ne hai uno debolissimo, di conseguenza è inutile sovraccaricare il processore se il tuo disco rigido non riesce a registrare. E' anche per questo motivo che considero la ricerca della latenza minore un mito da sfatare: un sistema funziona al meglio se è equilibrato, e spesso per equilibrarlo bisogna sacrificare qualcosa.

touchstyle ha scritto:
Mi permetto di dissentire su una frase: "se gli xRun sono uno ogni quarto d'ora va bene".
Se quell'xrun arriva mentre stai registrando, ti assicuro che NON va affatto bene, soprattutto se viene generato un glitch digitale che di fatto rovina la registrazione.
Va quindi trovato il punto di equilibrio nelle impostazioni per ottenere la latenza più bassa possibile, dove per punto di equilibrio intendo NESSUN xrun in lavorazione. Gli unici che possono essere non considerati sono quelli dovuti all'apertura/chiusura dei programmi.

Purtroppo non posso che concordare: mi è già capitato di lavorare ore senza xRun e averne a bizzeffe registrando l'ultima di 8 traccie dalla durata di 2 minuti più e più volte perchè improvvisamente mi arrivare un clip solitario...voglia di lanciare il pc dalla finestra...  

Comunque ho detto 15-20 minuti perchè penso che al primo settaggio di jack devi sperimentare, mentre i settaggio finale è ovvio che lo si trova dopo decine di ore passate ad usarlo.

touchstyle ha scritto:Il sistema andrebbe poi testato non con una sola traccia in registrazione, ma con più tracce armate in rec ed i plugin che si prevede di utilizzare attivi.
Tuttavia se la necessità è quella di registrare una sola traccia, magari stereo, il tuo approccio al test è corretto.

Come sopra, avendo sperimentato i programmi anche in studio ho dovuto combattere contro un'impostazione che a prima vista sembrava adeguata, ma che in realtà si è rilevata tutt'altro che tale. E' sempre l'esperienza che ci deve portare a provare nuovi settaggi, e assolutamente per avere le prestazioni migliori non insistere sulla stessa.
Io lavoro generalmente con 3 canali mono in entrata (a meno che qualcuno non mi presti una scheda audio esterna   )

touchstyle ha scritto:
Un ultimo appunto sulla latenza espressa da QJackctl, che va divisa per due, nel senso che considera interamente il processo HW>SW e SW>HW, quindi "2msec" significa "1msec" di latenza in registrazione + "1msec" di latenza in riproduzione.

Questo non lo sapevo, è sono contento di essermelo sentito dire   

touchstyle ha scritto:
PS: Il suono in 2msec si propaga di circa 70cm, quindi quando suoni in un palco, con l'ampli a 5 metri, la latenza è ben superiore...

Il ritardo del segnale audio è lineare, non proporzionale, per esperienza (sono un fonico) so cosa vuoi dire e cosa intendi visto che a volte se ne deve aggiungere per compensare le distanze tra diffusori. A questo non ci avevo pensato in quanto stavo riflettendo sulla latenza che vien registrata dalla DAW in un contesto di studio di registrazione, dove ne serve poca per avere a pari livello il suono che viene inviato alle cuffie del musicista con la traccia che ne viene registrata. Inoltre l'orecchio umano non riesce a distinguere suoni se essi sono percepiti a meno di 0.1 secondi di distanza uno dall'altro: al di sopra si ha eco, al di sotto si ha riverbero. Tenendo conto che sotto i 4ms non viene percepita differenza dall'orecchio umano, mentre dai 4 ai 35/50 (ci sono ipotesi contrastanti) viene considerato che ci sia una percezione del riverbero come congiunto al suono originale.

La famosa "latenza 0" degli studi professionali consiste in 1.5ms (come mi hai fatto notare te prima 0.75 in entrata e 0.75 in uscita)

Inoltre il problema della latenza in riproduzione (oltre a quello che ho fatto notare in fase di registrazione) si ha se le varie fonti sonore sono discordanti tra di loro, cioè in differenza di fase. ovviamente se il basso e la chitarra differiscono anche solo di valori compresi tra i 5 e i 10ms l'orecchio umano capirà inconsciamente che c'è qualcosa che non va. Anche per questo consiglio di registrare senza doversi poi trovare successivamente a trascinare manualmente le tracce.

Un ultimo appunto su questo argomento: se si utilizzano più schede audio durante la registrazione, bisogna essere assolutamente certi che le latenze siano coordinate. A questo ci vengono in aiuto le impostazioni di jack "latenza in ingresso" e "latenza in uscita". Non stare attenti a questo piccolo particolare renderà inutile tutti i nostri sforzi per ottenere una bassa latenza in entrata.