Funzionamento su stream

Come analizzato nel paragrafo 2.5.2, la callback riceve da PortAudio il buffer audio da riempire con i frame in uscita (per ora, ignoriamo il buffer con i frame in ingresso, provenienti da dispositivi esterni). Indipendentemente dal fatto che l’orchestra sia ciclante o meno, l’elaborazione che produ- ce tali frame, procede iterando (con un ciclo for) sui frame stessi contenuti nel buffer audio in usci- ta.

In modo del tutto analogo, il passaggio al funzionamento su stream, necessario per applicare il pattern pipeline, richiede che la callback (o chi per lei) generi uno stream di frame di lunghezza pari alla dimensione del buffer audio, che alimenti la pipeline di element equivalente all’elaborazione sequenziale, costruita per mezzo dell’ordinamento parziale definito dalla (5). Inoltre, occorre che ogni frame nello stream generato al fondo (nell’ultimo stadio) della pipeline venga copiato nel cor- rispondente posizione del buffer audio in uscita.

Per ora, il problema della lunghezza dello stream non rappresenta un problema cruciale, mentre per la copia dei frame nel buffer audio, supporremo che ci sia uno stadio finale che incapsula il buffer audio in uscita, con la responsabilità di copiare ogni frame ricevuto nel buffer stesso. Tale ipotesi è del tutto lecita, e non danneggia in nessun modo la progettazione, che elabora una visione ancora

sufficientemente astratta del problema. Questo stadio aggiuntivo, che chiamiamo OutLR, sostituisce la funzione outLR, che d’altronde poteva essere considerata come un element.

Un’altra questione da considerare, sono i dati contenuti in ciascuno elemento nello stream. Infatti, non possiamo ridurci all’ipotesi che ogni element riceva in ingresso un singolo frame x, ne applichi la funzione interna f, e passi in uscita il frame risultante dal calcolo di f(x). In altre parole, non pos- siamo ipotizzare che ogni element riceva un singolo segnale in ingresso, e produca un singolo se- gnale in uscita.

Inoltre, considerando sempre un generico instrument I, nel passaggio dal grafo GI (la patch, che de-

scrive la forma interna della computazione di I) ad una pipeline PI equivalente ad I, alcuni dati (se-

gnali) dovranno poter fluire tra gli stadi che separano due element legati da una relazione padre-fi- glio in GI, senza che tali stadi intermedi applichino su tali dati alcuna trasformazione.

Per esempio, considerando ancora la patch in figura 1.3, una pipeline equivalente che operi un op- portuno passaggio dei dati lungo lo stream, è rappresentato in figura 3.2: ad ogni element/generato- re della patch, corrisponde uno stadio nella pipeline; a tali stadi si aggiunge OutLR, che, come già

OutRL Audio Buf

fer … Osc2 Env1 1.0 1/d

+

×

< osci ( envi (1.0, 1/d) ∗ M, M ) + C, envi (1.0, 1/d) >

< osci ( osci ( envi (1.0, 1/d) ∗ M, M ) + C, envi (1.0, 1/d) ) >

detto, copia i frame generati nel buffer in uscita. Ciascuno stadio calcola una funzione interna: cia- scuna funzione interna ha dei parametri ben definiti, a cui può essere associato un valore singolo, o uno stream di valori. Per esempio, in figura 3.2, lo stadio Osc1 (così come Osc2) calcola la funzione

interna osci ( ampl, freq ), parametrica rispetto all’intensità ampl e alla frequenza freq. Inoltre, spesso

una funzione interna è parametrica rispetto al numero di invocazioni i: in tal caso, esso figura come pedice del nome della funzione, come appunto nel caso della funzione interna di Osc1. Osc1 riceve

l’intensità sotto forma di stream di valori dallo stadio che lo precede nella pipeline, mentre il para- metro relativo alla frequenza è impostato (dall’esterno) come un singolo valore M. Nel caso dello stadio Env2, entrambi i suoi parametri sono associati a singoli valori; ad ogni modo, esso riceve in

ingresso un segnale aggiuntivo, che si limita ad inserire nello stream, applicandovi la sola funzione identità. Nello stream in uscita, Env2 accoda quindi al dato dello stream in ingresso il valore attual-

mente calcolato dalla propria funzione interna envi ( 1.0, 1/d ). Lo stream in ingresso allo stadio suc-

cessivo, Osc2, risulta quindi scomponibile in due flussi di dati distinti, che Osc2 associa ai suoi para-

metri in ingresso: il primo dato nello stream (quello corrispondente al valore originariamente calco- lato dallo stadio dell’operatore +) è associato alla frequenza, mentre il valore calcolato da Env2 è as-

sociato all’intensità. Il frame risultante dall’applicazione della funzione interna di Osc2 a tali para-

metri in ingresso è infine ricopiato dallo stadio terminale OutRL nel buffer audio che incapsula. Le difficoltà implementative, che si colgono dall’esposizione di questo semplice esempio, riguarda- no l’impatto della particolare forma interna della computazione sulle modalità di gestione degli output sugli input tra un modulo e l’altro, come si è verificato nell’esempio in figura 3.2 per il mo- dulo Env2. Occorrerà trovare una soluzione che agevoli l’utente nella costruzione delle pipeline,

3.8.1.2.1. Valutazione ideale delle prestazioni

Quali sono i vantaggi derivanti dall’introduzione del parallelismo, sotto forma di pipeline, nell’ela- borazione interna di un instrument?

Siano le seguenti quantità:

• Sia T il tempo medio di elaborazione degli element utilizzati nell’intero processo di rendering; • Sia Tmax il tempo massimo di elaborazione tra gli element utilizzati nell’intero processo di rende-

ring;

• Sia L la lunghezza media del buffer audio in uscita fornito dal supporto audio; • Sia M il numero medio di instrument utilizzati dall’orchestra;

• Sia N il numero medio di element (outLR/OutLR compreso) utilizzato da ciascuno degli M instru- ment dell’orchestra.

Nel caso sequenziale, per eseguire un singolo ciclo di rendering occorre un tempo medio pari a: T×N×M×L.

Nel caso parallelo, un singolo ciclo di rendering richiede un tempo mediamente pari a: (Tmax×L+T×N)×M.

Per dare una percezione tangibile del miglioramento delle prestazioni, consideriamo per esempio il caso in cui T = 100 µsec (micro-secondi), Tmax = 200 µsec, L = 256, M = 5, N = 20. Con l’attuale

implementazione di pCM, si ottiene un tempo medio totale per ciclo di rendering pari a Ttot = 2,56

sec, mentre nel caso parallelo si ottiene Ttot = 0,26 sec. Abbiamo migliora le prestazione di un ordi-

ne di grandezza.

Ovviamente, queste considerazioni sono valide nel caso ideale in cui ogni modulo sia allocato su di un’unità di elaborazione a parte, e ignorano eventuale overhead introdotto da parte del supporto al

parallelismo adottato. In realtà, nel caso tipico questo non sarà vero. Risultati sperimentali reali sa- ranno valutati nel prossimo capitolo.