[GUIDA] Spiegazione impostazioni jackd - Parte2 (Latenza)

Contenuti:
-Analisi dati;
-Studio preliminare dati;
-Risultati;
-Vero algoritmo della latenza di jackD;
-Conversione in ms della latenza.

Osservando i dati sulle latenze di jackd balza subito all'occhio che i numeri non sono casuali, ma periodici. Prima di tutto la latenza – da qui in poi mi riferirò ad essa sempre in frame, tranne indicazioni diverse - è direttamente proporzionale alla quantità di frame con cui viene riempito un buffer. Questo vuol dire che maggiore è il numero di frame per periodo e di periodi per buffer, maggiore sarà la latenza generata dal programma.

Per capire questo processo dobbiamo comprendere come funziona un loop di pacchetti. La scheda audio genera una serie di pacchetti dati dal campionamento di un segnale audio. Questi pacchetti, chiamati frame, sono ognuno di 32bit e vengono spediti a jackd con una frequenza variabile (44100 48000 96000 192000).

Jackd riceve questi pacchetti e li carica su buffer per farli processare.

E viceversa se si tratta di riproduzione.

In dettaglio analizzando un intero loop tramite script come jack_iodelay, è possibile distinguere varie fasi di latenza.

Userò due serie di dati differenti: la prima con le impostazioni di 32 frame per periodo e 3 perioodi per buffer, la seconda con 2048 frame per periodo. Lasciamo stare, per ora, i frame al secondo in quanto non sono vincolanti per la latenza, con un errore medio di 20 frame*.

Ecco di dati:

FRAME	PERIODI	BUFFER	FR/PER	FR/BUF	PER/FR	PER/BUF	BUF/FR	BUF/PER
163	5,094	1,689	32	96	0,031	3	0,01	0,33
8227	4,4017	1,339	2048	6144	4,8*10^-4	3	1,6*10^-4	0,33

-I frame di latenza sono dati da jack_iodelay, frame per periodo e periodi per buffer sono le impostazioni di jackd. I dati rimanenti sono stati calcolati.

Jack_iodelay ci da 2 informazioni: la latenza totale e la latenza di extra-loopback.
Il primo dato è di significato ovvio.
Il secondo dato indica la latenza che non è dovuta a jackd, ovvero la latenza dovuta da bus, driver e processore.

Nelle schede USB il valore di ELL (extra-loopback latency) varia in base alle impostazioni a causa dello script di jackd che aggiunge latenza equivalente di un periodo extra o di 24 ms, in base a quale sia minore. Ora però analiziamo i casi dove rimane costante.

Nel mio sistema la latenza di sistema equivale sempre a 35 frame, con un errore di 2 frame in base al carico DSP, bus overhead e dalla scheda audio. Ovviamente questo valore varia da sistema a sistema.

Ora abbiamo 163-35=128 frame di latenza non classificata nel primo caso e 8192 frame nel secondo caso.

*Sottratti questi valori abbiamo che per ogni impostazione jackd genera una latenza costante basata sulle impostazioni di frame. Per 32 fr/per e 3 per/buf la latenza totale ELL è sempre uguale a 128 frame. Con 2048 frame abbiamo una latenza costante di 8192 frame. Abbiamo trovato la causa dei 22 frame d'errore segnalati in precedenza.

Da una prima analisi possiamo dedurre che questo valore non classificato contenga la latenza di jackd, sottraiamola: per 32 fr/per jackd ha una latenza di 96 frame, mentre per i 2048 corrisponde a 6144 frame.

Abbiamo:
-128-96=32frame
-8192-6144=2048frame

Ovvero un periodo (vedi tabella).

Per ogni impostazione jackd porta una latenza di 3 periodi e rimangono vacanti 1 periodo di frame. Chiamiamo questi pacchetti “junk”: non appartengono ne alla scheda audio, ne a jackd ne alla cpu.

A questo punto ci troviamo in un vicolo cieco.

Recuperiamo quindi nuovi dati. “jack_lsp -l ” ci permette di conoscere la latenza di ogni porta in entrata e in uscita.

Ci viene detto che ci sono 32 e 2048 frame di latenza in entrata e 96 e 6144 frame in uscita per i due rispettivi esempi.

Abbiamo quindi 128 frame e 8192 frame sulle porte di jackd, ovvero i valori precedentemente trovati per la latenza totale senza la latenza di sistema.

Osservando questi due valori (e tutti gli altri usati per questo studio) si nota una costante: jackd impone una latenza di 1 periodo in entrata e di 1 buffer in uscita.

Risulta quindi sbagliato il valore di latenza nominale indicato dalla GUI di jackd? No, solo la lettura. Dalle tabelle risulta che quel valore in ms indica il tempo necessario al programma per riempire un buffer. Ovviamente in ms.

Ora siamo sulla strada giusta per comprendere la latenza di jackd:

ASSIOMA: jackd impone una latenza di un periodo in entrata e di un buffer in uscita.

Questo fa parte del codice, è stato deciso di farlo lavorare in questo modo, probabilmente per rendere più veloce il segnale in entrata.

L'utilizzo di periodi e buffer interi è sicuramente stata presa per poter sfruttare al massimo le potenzialità del programma.

Questo spiega anche perchè è preferibile usare valori di latenza multipli di 1.

Per calcolare la latenza basta sempicemente sommare i frame di un periodo e di un buffer. Con impostato 3 come periodi per buffer si ha un totale di 4 periodi, mentre con 2 periodi per buffer si ha un totale di 3 periodi.

La latenza nominale di jackd diventa quindi: (frame per perdiodo)*periodi; ovvero (frame per periodo)*(1 periodo + 1 buffer)=(frame per periodo)*[1 periodo + (periodi per buffer)].

Ora è necessario introdurre i frame per secondo. Questo valore non ha influenze sui frame di latenza, ma sulla velocità con cui questi vengono registrati dal buffer. Alti valori di frame per secondo velocizzano il processo, però aumentano leggermente il carico DSP e quindi la possibilità di xRun.

I frame per secondo usati da jackd sono differenti dalla frequenza di campionamento della scheda audio!

Tramite driver jackd prova ad impostare il valore di campionamento della scheda audio al medesimo valore impostato in jackd, se questo valore è impostabile solo meccanicamente ovviamente il software non può modificarlo.

A livello pratico immaginiamo di registrare a 48000 hz (frequenza della scheda audio). Questo vuol dire che ogni secondo vengono campionati 48000 pacchetti da 32bit ognuno. Ovvero 1536000 bit vengono inviati a jackd ogni secondo.

JackD riceve questi pacchetti e deve trasportali indirizzandoli.

Ora jackd lavora con un certo valore frame per periodo. Usiamo ancora 32 e 2048 fr/per.

Abbiamo detto che jackd impone che avvenga un periodo per i dati in ingresso. Jackd non invia i dati al processore finchè non è stato eseguito un intero periodo.

Ricordiamo che 48000 frame per periodo in jackd signifa che lui “trasporta” 48000 frame al secondo di pacchetti dal buffer.

1 periodo corrisponde a 32 o 2048 frame, in base ai due esempi. Nel primo caso l'intero processo impiega 0,67 ms mentre nel secondo il buffer viene processato solo dopo 42,67 ms

Ogni periodo porterà dai 1024 ai 65536 bit rendendo necessari 1500 cicli nel primo caso e 23,44 nel secondo. Il numero di cicli è quello che determina il carico DSP, e la probabilità di xRun

In uscita, invece, jackd pretende che venga riempito un intero buffer. Facendo un paio di calcoli risulta che i pacchetti non vengono inviati alla scheda audio fino a che non vengano compiuti 2/3/... periodi: 64/96 frame o 4096/6144, rispettivamente 1,3 ms 2 ms 85,3 ms 128ms.

La nostra scheda audio invia e campiona un pacchetto da 32 bit ogni 0,020 ms. Questo non aggiunge latenza, indica soltanto la frequenza con cui vengono prelevati o consegnati i singoli pacchetti.

Questo è anche il motivo per cui è possibile far lavorare jackd ad una frequenza di campionamento differente da quella della scheda audio. Proviamo con 192000 fr/sec.

Semplicemente ogni 0,020 ms viene aggiungo un pacchetto al periodo. A periodo pieno viene riempito il buffer. A buffer pieno viene trasmesso il tutto al processore. Quindi in 0,64 ms viene riempito il buffer di 32 frame, e in 40,96 ms se sono 2048. Una volta riempito abbiamo 0,16 ms, 10,67 ms per trasmettere i frame del buffer al processore. Essendo processi seriali i ms si sommano. È bene ricordarsi che i primi ms fanno parte della latenza naturale e non vengono sommati.

Se la scheda audio campiona a 192 kHz, invia un pacchetto ogni 0,0052ms. 32 ogni 0,16 ms e 2048 ogni 10,67 ms. In ogni caso a questo deve essere aggiunto il tempo necessario per trasportare i buffer.

Il fatto che sia necessario un periodo in entrata e un buffer in uscita ci permette di impostare jackd al meglio: possiamo sfruttare le impostazioni gestendo il rapporto tra latenza in entrata e in uscita (di jackd, non del sistema), e i carichi DSP per ognuna delle due fasi. Dimezzando i frame per periodo e raddoppiando i periodi avremo la stessa latenza in uscita, con un carico DSP diverso (maggiore o minore dipenderà dal sistema). In questo modo avremo anche ridotto la latenza in entrata. Impostando in modo opposto jackd aumenteremo la latenza in ingresso lasciando invariata quella in uscita, aumentando il carico DSP sulla porta di ingresso. Etc...

A presto la parte 3:

Codice:


[GUIDA] Spiegazione impostazioni jackd - Parte2 (USB)

Contenuti:
-

--latenza aggiunta per USB

-raw data

-nome
-funzionamento metafora birra
-distinzione con scheda audio, frequenza di campionamento scheda audiovs fqjackd

asynchronous mode