Contenuti:
-Definizione dei parametri
-Metafora per spiegare il funzionamento di jackd (base)
Ho deciso di iniziare questo srticolo con una spiegazionone, cercando di semplificarne la comprensione, sulle impostazioni di jackd, in quanto mi sono reso conto che c'è una grande confusione a riguardo.
Mi riferisco soprattutto alle 3 impostazioni: fotogrammi/periodo, campionamento, periodi/buffer.
La prima cosa da dire è che la prima è indipendente dalla seconda, mentre è fortemente legata alla terza.
Diamo un paio di definizioni:
-Un fotogramma è un pacchetto di informazioni. Nel caso dell'audio noi lavoriamo con pacchetti da 32 bit, quindi ogni fotogramma è composto da 32b di informazioni.
-secondo/millisecondo: la misura del tempo, millisecondo è la millesima parte del secondo
N.B.: in informatica si lavora in pacchetti, e non in secondi, la latenza è in realtà in frame e vedremo dopo che conseguenze ha questo fatto!
-campione, è un sinonimo di pacchetto, il campionamento è la frequenza di pacchetti registrati in un secondo
-periodo: è il tempo impiegato dal programma per compiere un certo numero di processi
-buffer: qui vengono registrati i dati. Una volta pieno i dati vengono inviati al processore.
Per spiegare meglio tutto questo ho pensato ad una gustosa metafora: immaginate che voi siate un corriere chiamata "jackd". Il vostro compito è quello di prendere le birre dal fornitore "scheda audio spa" e consegnarlo a "processore".
Come agite?
Allora voi andate a prelevare con dei furgoni (buffer). L'operaio carica sul furgone delle casse di birra, ognuna con 32 lattine di birra (frame a 32 bit). Il numero di periodi è il numero di viaggi che fa.
Ora combiniamo le cose:
-fotogrammi per periodo: quante casse di birra caricate ogni viaggio
-periodi per buffer: quanti viaggi fate verso ogni furgone
-fotogrammi per secondi: la velocità dei furgoni in relazione al numero di casse caricate.
Si può lavorare caricando una sola cassa di birra per furgone, con un solo viaggio (1 fr/s, 1 per/buf). Vantaggi: essendo la velocità fr/sec, pochi frame -> alta velocità: ci impieghi veramente poco a fare il viaggio
Svantaggi: tanti viaggi, veloci, consumano maggiori risorse (DSP) con un alto rischio di incidenti e perdita di pacchetti (xRun).
Al contrario puoi caricare ogni furgone con tante casse, ad esempio facendo 10 viaggi da 1000 casse ognuno, riempiendo ogni buffer con 10000 frame. Vantaggi: dovendo fare meno viaggi consumi meno DSP e rischi meno xRun
Svantaggi: impieghi molto tempo a trasportare 10000 frame
Un altro modo per vedere la situazione è pensare di riempire un lavandino con un secchio d'acqua. I frame per periodo ora indicheranno la quantità d'acqua di un secchio, i periodi il numero di secchiate e i frame per secondo il flusso dello scarico che verrà aperto quando avremo riempito il lavandino.
Prima ho scritto che i frame per periodo e i periodi per buffer erano le due opzioni legate, entrambe dichiarano quanti frame per buffer ci sono, la seconda opzione ti permette di poter riempire completamente un buffer, prima di processarlo, ottimizzando il lavoro
Parlando di velocità, i frame per secondo indicano quanto ci impiega un buffer ad essere portato a processo: le altre due opzioni dichiarano quanti frame ci devono essere, e questo non può cambiare. Di conseguenza esemplifichiamo che lavori a 10 frame a secondo. Se il buffer si riempie di 2 frame il viaggio dura 0.2 secondi. Se riempiamo il buffer di 20 frame ci impiega 2 secondi.
Latenza: la latenza consiste nel fatto che la scheda audio ci manda un certo numero di pacchetti al secondo. Jackd deve processare questi pacchetti. Il bus trasporta i pacchetti ad una velocità altissima, molti dicono sia prossima a quella della luce, anche il mio docente di fisica lo diceva, ma lui non era affidabile!
Cosa succede: prendendo i dati dell'ultimo esempio, jackd preleva dalla scheda audio e passa in buffer 10 pacchi al secondo (pacchi è il nome dei pacchetti dati, non sto più parlando di birra..). Il buffer successivamente verrà elaborato dal processore, però prima deve essere riempito. Se noi facciamo partire tantissimi buffer mettiamo sotto sforzo il sistema, ma l'elaborazione sarà quasi istantanea: il pacco arriva, si butta nel buffer, il buffer viene processato.
Se invece faccio riempire il buffer con moltissimi pacchetti si crea uno strozzo: il pacco arriva, lo carico, ne carico un altro, e un altro, e un altro,.....il processore si gira i pollici,....il buffer è pieno e lo faccio processare.
Forse è difficile capire come sia differente riempire il buffer di 2 frame e far durare il viaggio di 0.2 secondi o riempire il buffer di 20 frame e impiegarci 2 secondi.
Il fatto è che in 2 secondi trasporti 20 frame in ambedue le situazioni, ma essendo il viaggio pressoché immediato, nel primo caso l'attesa di pacchetti è solo di 0.2 secondi e tutti gli altri sono in coda a quello: nel momento che il primo buffer è processato, il secondo è già pronto a partire. Nel secondo caso vengono aspettati 2 secondi a far processare il buffer!
Un ultimo argomento di confusione: la frequenza di campionamento di jackd. I frame per secondo processati da jackd sono indipendenti dalla frequenza di campionamento della scheda audio!
La scheda audio campiona e invia dati in base alla sua frequenza di campionamento. Jackd riempie i buffer coi dati ricevuti dalla scheda audio e li manda al processore alla sua frequenza di campionamento. Hanno lo stesso nome perchè di per se sono la stessa cosa, ma sono due processi differenti.