[GUIDA] Come spingere al limite jackD

Grazie alla nuova formula che ho ricavato dagli studi sul server jackd (http://www.linux-audio.org/t786-guida-spiegazione-impostazioni-jackd-parte2-latenza)

Codice:

(frame per perdiodo)*periodi;  ovvero (frame per periodo)*(1 periodo + 1 buffer)=(frame per periodo)*[1 periodo + (periodi per buffer)]

Ho fatto nuovi studi che hanno portato a risultati carini. Ecco i risultati:

N.B.: riporto solo le impostazioni minime che non hanno portato xRun

L'impostazione con i frame di latenza minori e maggiori sono state:

fr/per	fr/sec	per/buff	lt_frame	lt_ms	lt_buff	Xrun 1 min	DSP
16	48	6	112	2,3333333333	2	0(0)	10,00%
64	192	6	512	2,6666666667	2	0(0)	6,00%

L'impostazione con i ms di latenza minori e maggiori sono state:

fr/per	fr/sec	per/buff	lt_frame	lt_ms	lt_buff	Xrun 1 min	DSP
32	192	6	224	1,1666666667	1	0(0)	20,00%
16	48	6	128	2,6666666667	2	0(0)	12,00%

L'impostazione con i carichi DSP minori e maggiori sono state:

fr/per	fr/sec	per/buff	lt_frame	lt_ms	lt_buff	Xrun 1 min	DSP
64	192	6	512	2,6666666667	1	0(0)	6,00%
16	192	24	416	2,1666666667	2	0(0)	28,00%

LEGENDA:
-fr/per: frame per periodo
-fr/sec: frame per secondo
-per/buff: periodi per buffer
-lt_frame: latenza totale in frame (esclusa la latenza di sistema ELL - "extraloop latency")
-lt_ms: latenza totale in millisecondi (esclusa la latenza di sistema ELL - "extraloop latency")
-lt_buff: tempo di riempimento di un buffer (il valore indicato da jackD)
-Xrun 1 min: numero di xRun dopo un minuto di test
-DSP: carico DSP

Da questi valori deduciamo subito che suddividendo il lavoro del server in più periodi, si ha un aumento del carico DSP che però non porta un aumento del numero di xRun.

La latenza in ms è data dalla (latenza in frame) / (frame per secondo).

La latenza in frame è data dalla formula espressa all'inizio dell'articolo.

Ovviamente la latenza in ms è deducibile direttamente dal valore in ms indicato da jackD trmite la formula:

Codice:

LT_jack * (1+1/n)

Con n = periodi per buffer.
Difatti, essendo la latenza di jackD il tempo di un buffer - avendo in entrata una latenza di 1 periodo e in uscita di un buffer (vedi il mio articolo linkato in alto), si ha il tempo del buffer in uscita sommato al buffer in entrata. Quello in entrata non è completo ma equivalente al valore inverso dei periodi per buffer (1/n).

Algebricamente:

Codice:

frame=(frame per periodo)*[1 periodo + (periodi per buffer)];
ms=frame/(frame per secondo);
LT_jackd=(frame per periodo)*(periodi per buffer)/(frame per secondo) =>
ms=frame*LT_jackd/[(frame per periodo)*(periodi per buffer)] =
(frame per periodo)*[1 periodo + (periodi per buffer)]*LT_jackd/[(frame per periodo)*(periodi per buffer)] =
[1 periodo + (periodi per buffer)]*LT_jackd/[(periodi per buffer)] =
[(1 periodo)/(periodi per buffer) + 1]*LT_jackd =
(1+1/n)*LT_jack

Questi risultati sono molto utili soprattutto per le schede USB, in quanto il driver di jackd aggiunge una latenza di un periodo alla latenza complessiva: aumentando il numero di periodi per buffer possiamo diminuire la latenza portando i frame per periodo a valori bassissimi come 16 o 32. Con questi valori non si ha un aumento superiore di 0.67ms.

Inoltre vorrei far notare che la latenza massima in ms corrisponde a 2.67 ms, con 2ms di latenza di buffer (quella di jackd) e 12% di carico DSP. La latenza minima raggiungibile - per il mio sistema, è di 2.53 ms, con 1ms di buffer, 64 192000 3.

L'altro valore per 1ms di buffer corrispondeva a 2.7ms con 32 96000 3

Vorrei aggiungere che questi due valori - che sono gli unici che mi portano una latenza minore di 3ms, sono inutilizzabili per più di 5 minuti sul mio sistema, mentre tutte queste impostazioni sono stabili:

Codice:

f/p f/s p/b lt_fr lt_ms lt_bf Xr DSP

64 192 6 448 2,3333333333 2 0(0) 10,00%
32 192 12 416 2,1666666667 2 0(0) 19,00%
16 192 24 400 2,0833333333 2 0(0) 23,00%
32 192 6 224 1,1666666667 1 0(0) 20,00%
32 96 6 224 2,3333333333 2 0(5) 10,00%
16 96 12 208 2,1666666667 2 0(0) 20,00%
16 48 6 112 2,3333333333 2 0(0) 10,00%


f/p: frame per periodo
f/s: frame per secondo
p/b: periodi per buffer
lt_fr: latenza in frame
lt_ms: latenza in ms
lt_bf: latenza di un buffer
Xr: numero di xRun
DSP: carico DSP medio

EDIT: vorrei farvi notare un caso particolare:

Codice:

32   192   3   128   0,6666666667   0,5   0(8138)   22,00%


questo non lo commento!

Complimenti!! Che trattato di ingegneria!!!

Ora vediamo di farti partire jackd e poi vediamo quanto possiamo spingerlo!

Penso che questo sia un grande passo avanti per chi utilizza linux per le applicazioni live, inoltre i valori in ms che ho espresso nel post sono assoluti, questo vuol dire che che comprendono la riproduzione e la registrazione.

In riproduzione si hanno rispettivamente questi valori:
-1,1666666667ms
-1,0833333334ms
-1,0416666667ms
-0,5833333334ms
-1,1666666667ms
-1,0833333334ms
-1,1666666667ms

e il caso speciale:
-0,3333333334ms

EDIT: piccolo errore mio: jackd divide il lavoro tra porte in entrata (capture) e porte in uscita (plyback) con un rapporto 1/n. Questo vuol dire che si crea una latenza in entrata di un periodo e in uscita di un buffer.

In frame:
(frame per periodo)*[1 periodo + (periodi per buffer)] =
-capture = (frame per periodo) * (1 periodo)
-playback = (frame per periodo) * (periodi per buffer)

Es.: con 16 frame per periodo, 6 periodi per buffer:
-capture = 16 * 1 = 16 frame
-playback = 16 * 6 = 96 frame
-tot = 16 + 96 = 112 frame

In ms si ha LT_jack * (1+1/n) =
-capture = LT_jackd * 1/n
-playback = Ltjackd * 1

Es.:
-capture = 2 * 1 = 0.333ms
-playback = 2 * 1/6 = 2 ms
-tot = 2.33 ms

Ricordiamo che la latenza indicata da jackd indica la latenza di buffer, quindi per trovare la latenza di un periodo dobbiamo trovare l'inverso del valore di periodi per buffer:

Codice:

n=periodi per buffer;
Lt_jackd=tempo di un buffer;
Tempo di un buffer = (tempo di un periodo) * (periodi per buffer) =>
Tempo di un periodo = (tempo di un buffer) / (periodi per buffer) =>
tempo di un periodo = Lt_jackd / n

  
https://sites.google.com/site/as91linuxsite/home/audio/come-spingere-al-limite-jackd

riesci ad aggiungere anche l'ultimo post?

as91 ha scritto:
Penso che questo sia un grande passo avanti per chi utilizza linux per le applicazioni live, inoltre i valori in ms che ho espresso nel sono assoluti, questo vuol dire che che comprendono sia la latenza in riproduzione e che quella in registrazione, infatti - come spiegato nell'altra guida, jackd divide il lavoro tra porte in entrata (capture) e porte in uscita (plyback) con un rapporto 1/n. Questo vuol dire che si crea una latenza in entrata di un periodo e in uscita di un buffer.

In frame:
(frame per periodo)*[1 periodo + (periodi per buffer)] =
-capture = (frame per periodo) * (1 periodo)
-playback = (frame per periodo) * (periodi per buffer)

Es.: con 16 frame per periodo, 6 periodi per buffer:
-capture = 16 * 1 = 16 frame
-playback = 16 * 6 = 96 frame
-tot = 16 + 96 = 112 frame

In ms si ha  LT_jack * (1+1/n) =
-capture = LT_jackd * 1/n
-playback = Ltjackd * 1

Es.:
-capture = 2 * 1 = 0.333ms
-playback = 2 * 1/6 = 2 ms
-tot = 2.33 ms

Ricordiamo che la latenza indicata da jackd indica la latenza di buffer, quindi per trovare la latenza di un periodo dobbiamo trovare l'inverso del valore di periodi per buffer:

Codice:

n=periodi per buffer;
Lt_jackd=tempo di un buffer;
Tempo di un buffer = (tempo di un periodo) * (periodi per buffer) =>
Tempo di un periodo = (tempo di un buffer) / (periodi per buffer) =>
tempo di un periodo = Lt_jackd / n

done

Interessante.
Hai validato i dati calcolati con delle misure?

Ciao,
Touch.

i dati sono tutti ricavati da misure, la formula è empirica, non calcolata, ovviamente è solo la latenza di jackd, al più si deve aggiungere quella di sistema.

La latenza che non dipende da jackd si suddivide equamente tra porte in ingresso ed in uscita (date le conoscenze attuali). Si hanno quindi 2 casi:
- scheda PCI, latenza fissa in base al sistema, solitamente sotto i 50 frame => a 44100 hz sono 1.13 ms da dividere in ingresso e in uscita (a 1:1 - 0.56 ms).
-scheda USB, latenza variabile in base alle impostazioni: il driver di jackd aggiunge della latenza pari ad un periodo alla latenza nominale di sistema. O di 24 ms, in base a quale sia il minore. Giocando con frame per periodo e periodi per buffer si può mantenere un valore di frame basso, limitando la latenza di sistema.

Per le schede firewire non ho dati da analizzare...

EDIT: comunque le formule e i perchè sono spiegati nel link all'inizio del post (precedente mio articolo)

Dunque se ho capito bene questi sono i valori che spingono la latenza a livelli estremamente bassi:

Codice:



f/p f/s p/b lt_fr lt_ms lt_bf Xr DSP
64 192 6 448 2,3333333333 2 0(0) 10,00%
32 192 12 416 2,1666666667 2 0(0) 19,00%
16 192 24 400 2,0833333333 2 0(0) 23,00%
32 192 6 224 1,1666666667 1 0(0) 20,00%
32 96 6 224 2,3333333333 2 0(5) 10,00%
16 96 12 208 2,1666666667 2 0(0) 20,00%
16 48 6 112 2,3333333333 2 0(0) 10,00%


Il mio sistema non regge valori di fotogrammi/periodo uguali o inferiori a 64, come potrei utilizzare i dati indicati in questa tabella? E' più per curiosità che lo chiedo, con 128 f/p, campionamento 192000 e 3 periodi/buffer (e kernel rt) ho un sistema parecchio stabile a 2ms di latenza e praticamente zero x-run

In effetti tu hai trovato il compromesso migliore: con quelle impostazioni hai 2.66 ms di latenza totale, mentre portando i frame a 64 e i periodi per buffer a 6 scenderesti a 2.33 ms, che non sarebbe un guadagno conveniente.

Queste indicazioni valgono per quando non riesci a scendere così tanto e/o se puoi scendere sotto i 64 frame