Lezione 14 RTP MIDI e Network Musical Performances

Lezione 14 RTP MIDI e Network Musical Performances Programmazione MIDI (Prof. Luca A. Ludovico)

Network Musical Performance • Obiettivo: permettere a musicisti geograficamente distribuiti di interagire e suonare assieme via rete • Problema: latenze (o ritardi) – – Insite nella produzione fisica del suono (velocità di propagazione nell’aria v = 344 m/s) Introdotte dal sistema informatico, che si sovrappone a quelle di natura precedente • • • Catena di acquisizione Propagazione dei pacchetti in rete Catena di riproduzione Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempi Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempi di latenza di rete • Trasmissione di un pacchetto su rete dedicata – Da Berkeley a Stanford Distanza: 40 miglia Latenza simmetrica: 2. 1 ms Similitudine: musicisti a 0. 72 m di distanza – Da Berkeley a Caltech (California) Distanza: 375 miglia Latenza simmetrica: 14. 2 ms Similitudine: musicisti a 4. 88 m di distanza Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Minimizzare i ritardi • Cuffie e microfono minimizzano la propagazione del suono nell’aria • Schede audio con Direct Memory Access minimizzano i ritardi di buffering interni alla macchina • Non usare compressione minimizza il ritardo algoritmico • Però… Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Minimizzare i ritardi: aspetti fondamentali • Formato dell’informazione inviata – – Compresso o non compresso? Audio o performance? • Caratteristiche fisiche della rete e suo utilizzo – – – Rete dedicata e banda disponibile Distanze Numero di host e congestionamento • Protocollo di trasporto su rete: affidabilità o velocità? Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Livello di trasporto: TCP vs UDP • L'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma • UDP non offre nessuna garanzia dell'arrivo dei datagrammi né sul loro ordine di arrivo (best effort) TCP garantisce la consegna ordinata dei dati, anche se al costo di un maggiore overhead – meccanismi di acknowledgement e di ritrasmissione su timeout • UDP invia solo i datagrammi richiesti dal livello applicativo TCP è un protocollo orientato alla connessione – per stabilire, mantenere e chiudere una connessione è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Acknowledgement e ritrasmissione Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

La sfida di una Network Musical Performance • Contesto: reti su cui non sia praticabile lo streaming audio, a causa della limitazione della banda, del congestionamento e delle garanzie sulla qualità del servizio. • In una rete di questo genere, perdita di pacchetti e ritardi nella consegna sono inevitabili. • Obiettivo: ricreare performance geograficamente distribuite 1. 2. senza introdurre eccessivo ritardo (non tollerabile per un musicista) senza generare artefatti o smarrire eventi di fondamentale importanza nella performance • Soluzione: utilizzare UDP per veicolare informazioni di performance (e non audio) in real time Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

MIDI in tempo reale su rete • Consentire performance live geograficamente distribuite con feedback per gli esecutori • Far comunicare via rete (cablata o wireless) dispositivi per la produzione e la gestione del suono in formato MIDI • Promuovere il MIDI a formato standard per la sonorizzazione su Internet in contesti caratterizzati da poca banda disponibile • Aggiungere una sonorizzazione MIDI ad applicazioni multimediali quali web conference Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Sezione 14. 1 RTP MIDI Programmazione MIDI (Prof. Luca A. Ludovico) 14. RTP MIDI

Request for Comments (RFC) • Una RFC è un documento che riporta informazioni o specifiche riguardanti nuove ricerche, innovazioni e metodologie dell'ambito informatico. • I principali protocolli per Internet sono stati proposti e descritti all’interno di specifiche RFC. • Per diventare standard, devono essere vagliati da IETF (Internet Engineering Task Force, http: //www. ietf. org). • Fonte ufficiale per le RFC sul Web: RFC Editor http: //www. rfc-editor. org/rfc. html Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempi notevoli di RFC • DHCP RFC 2131 • DNS RFC 1034, 1035 "Domain Names" • FTP RFC 959 "File Transfer Protocol" • HTTP RFC 2068 "Hypertext Transfer Protocol 1. 1" • IPv 4 RFC 791 "Internet Protocol" • SMTP RFC 821, 822 "Simple Mail Transfer Protocol" • UDP RFC 768 "User Datagram Protocol" • TCP RFC 793 "Transmission Control Protocol" Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI "Dynamic Host Configuration Protocol"

Il protocollo RTP (Real Time Protocol) • Standard per trasportare stream multimediali su reti IP • Adatto: – – per applicazioni interattive che richiedono bassa latenza per applicazioni di trasporto di contenuto • L’informazione viene suddivisa in pacchetti • Progettato per funzionare sia con UDP (interpretazione prevalente) sia con TCP • E’ estensibile: è sufficiente definire un nuovo formato per il “payload” Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del pacchetto RTP Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Numerazione dei pacchetti e timestamp in RTP • I pacchetti sono numerati con un valore incrementale a 16 bit. Il destinatario può accorgersi dello smarrimento di un pacchetto quando rileva un gap nella sequenza dei numeri d’ordine. • I pacchetti presentano un timestamp a 32 bit che rappresenta il primo istante di codifica del pacchetto. • Il timestamp lavora in riferimento a una frequenza stabilita in fase di setup del protocollo. – – Esempio: fissata f = 44100 Hz, all’istante t = 2 s corrisponde timestamp = 88200 Esempio: fissata f = 1 Hz, all’istante t = 5 s corrisponde timpestamp = 5 Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Altri campi del pacchetto • Altri campi riguardano la specifica RTP – • Ad esempio, il campo V (2 bit) serve a specificare la versione del protocollo in uso. Al momento, la versione più recente è la 2 (codifica 012) Documenti ufficiali: – – RFC 1889 (http: //www. ietf. org/rfc 1889. txt) RFC 3550 (http: //www. ietf. org/rfc 3550. txt) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

RTP MIDI • Proposta di protocollo standard per la trasmissione di messaggi MIDI in pacchetti RTP su reti non affidabili • Problemi dovuti a latenza o smarrimento di pacchetti: introduzione di artefatti – – Transienti (ad esempio, smarrimento di un Note. On) Indefiniti (ad esempio, smarrimento di un Note. Off o di un MIDI Control Change per il controller 7 – Channel Volume) • Obiettivo: minimizzare gli artefatti transienti ed eliminare quelli indefiniti, ma senza trasmissione di pacchetti di acknowledgment dal destinatario al mittente Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del payload RTP MIDI • Il payload è la parte estensibile di un pacchetto RTP. Ciò che caratterizza il protocollo RTP MIDI è il payload. • Il formato del payload mappa uno stream di comandi MIDI su uno stream RTP – – 16 voice channels system commands • In generale, il payload è strutturato nel seguente modo: – – – header MIDI list, ossia coppie (Delta Time, comando), eventualmente con codifica Running status Recovery Journal (opzionale) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del payload RTP MIDI: campo LEN • Il campo LEN ha lunghezza variabile e specifica la lunghezza della MIDI list. La sua lunghezza dipende dal flag B (vedi slide successiva) • Se ha un valore non nullo, questo è il numero di ottetti (ossia di gruppi di 8 bit = 1 byte) che compongono la MIDI list. Può essere nullo, in tal caso la MIDI list è vuota. Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del payload RTP MIDI: flag B • Flag B – – se B = 0, allora LEN ha dimensione 4 bit e la MIDI list è fatta di massimo 15 ottetti Modalità pensata per applicazioni interattive: un comando MIDI per pacchetto minimizza la latenza di codifica se B = 1, allora LEN ha dimensione 12 bit e la MIDI list è fatta di massimo 4095 ottetti Modalità pensata per applicazioni di streaming, con molti comandi MIDI per pacchetto in modo da minimizzare gli overhead dell’header e del journal (vedi più avanti) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del payload RTP MIDI: MIDI list Strutturazione della MIDI list Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Codifica dei tempi delta tra comandi MIDI • Il tempo delta fa riferimento al timestamp base del pacchetto RTP • La codifica dei tempi delta tra comandi in un singolo pacchetto è una versione modificata della specifica SMF, usando da 1 a 4 ottetti per codificare valori su 32 bit. – Un esempio di codifica e decodifica è mostrato alla slide successiva. • Tutti gli istanti iniziali dei comandi nel pacchetto n devono precedere il timestamp del pacchetto n+1. • Codifica comoda per trascrivere da SMF, meno per convertire da temporizzazione implicita (ad es. i messaggi che viaggiano su cavo DIN) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Codifica dei tempi delta tra comandi MIDI Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Formato del payload RTP MIDI: flag Z • Flag Z – – • Se Z = 1, la MIDI list è strutturata come una sequenza di coppie ordinate (Delta Time, Comando) se Z = 0, allora il primo campo Delta Time è assente dalla MIDI list e il primo comando viene eseguito al tempo del timestamp RTP Il caso Z = 0 è tipico quando si codifica un singolo comando MIDI per pacchetto. In tal caso è sufficiente il timestamp. Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Sezione 14. 2 REAL TIME CONTROL PROTOCOL Programmazione MIDI (Prof. Luca A. Ludovico) 14. RTP MIDI

RTCP • RTCP (Real Time Control Protocol): definito dallo standard RTP come protocollo di comunicazione “all’indietro” (da destinatario a mittente) a bassa occupazione di banda – Specifiche su funzionalità e struttura dei pacchetti: RFC 3550 • Agisce congiuntamente a RTP per la consegna e l’impacchettamento di dati multimediali, ma non trasporta informazione multimediale • Funzione primaria: feedback sulla qualità del servizio (Qo. S, quality of service) nella distribuzione, inviando periodicamente informazioni statistiche ai partecipanti della sessione • Osservazione: RTCP è definito da specifiche RTP, non RTP MIDI Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Comunicazione RTP e RTCP • RTP e RTCP sono unidirezionali: – – RTP dal mittente S (source) al destinatario D (destination) RTCP dal destinatario D al mittente S Nel complesso, c’è feedback! Informazione statistica pacchettizzata RTCP S D Informazione multimediale pacchettizzata RTP Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

RTCP e campo EHSNR • I pacchetti di ritorno RTCP comprendono un campo EHSNR • EHSNR (Extended Highest Sequence Number Received) codifica il più alto numero di sequenza che un destinatario D osserva da parte di un mittente S • EHSNR è a 32 bit – – i 16 bit di ordine basso riportano il Sequence Number del pacchetto RTP osservato da D I 16 bit di ordine alto codificano un contatore che tiene conto di quanti cicli ha compiuto il Sequence Number (ossia quante volte è stato azzerato) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Sezione 14. 3 RECOVERY JOURNAL Programmazione MIDI (Prof. Luca A. Ludovico) 14. RTP MIDI

Formato del payload RTP MIDI: flag J • Flag J – • se J = 1, allora il pacchetto si chiude con un Recovery Journal di lunghezza variabile Considerazioni: – – Se J = 0, non è presente il Recovery Journal (vantaggi e svantaggi) Dove inizia il Recovery Journal? Si può inferire dal campo LEN Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Recovery journal • Finalità: minimizzare gli artefatti transienti ed eliminare quelli indefiniti provocati da ritardi nella consegna dei pacchetti o da un loro smarrimento • Si basa sui concetti di checkpoint e di history – Non tiene traccia della storia complessiva della comunicazione tra mittente e destinatario, ma solo a partire da un punto specifico identificato come checkpoint (checkpoint history) • Caratteristiche – – – Non usa ritrasmissione o meccanismi di acknowledgement Non è un log completo dei comandi MIDI: solo alcuni comandi possono generare artefatti (e quindi devono essere protetti); inoltre, alcuni comandi tipicamente generano un gran numero di valori e solo il più recente deve essere mantenuto Il journal viene periodicamente svuotato sulla base del checkpoint. Quando? Quando RTCP invia all’indietro una notifica sulla ricezione di un certo numero di pacchetto Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Come costruire un LOG incrementale S Header D RTP Header Payload MIDI list History Note On 1 Note On 2 Note Off 1 Note On 2 Note On 1 Note Off 2 Note Off 1 Note On 2 Esecuzione della 1 a nota Note On 1 Esecuzione della 2 a nota Pacchetto smarrito (ma D non lo può sapere) Note On 1 Note Off 2 Note Off 1 Note On 2 Note On 1 Entrambe le note ancora in esecuzione Spegnimento di entrambe le note Grazie al confronto dei Recovery journal, un artefatto indefinito (quale lo smarrimento di un Note Off) viene trasformato in artefatto transiente Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Mittente e destinatario RTP • Il mittente S: 1. 2. 3. 4. 5. 6. S Genera l’header RTP del nuovo pacchetto Genera il payload RTP MIDI, ossia l’header e la MIDI list Genera il recovery journal Invia il pacchetto sulla rete Aggiorna la propria copia del recovery journal estendendo la checkpoint history sulla base della MIDI list appena inviata Monitora i pacchetti RTCP per stabilire il checkpoint corrente • Il destinatario D: 1. 2. 3. Esegue con la corretta temporizzazione i comandi MIDI nella MIDI list del pacchetto ricevuto Tiene traccia del numero di sequenza più alto e predice l’arrivo di un pacchetto con numero incrementato di uno Se rileva discontinuità nella sequenza, analizza il Recovery journal del pacchetto più recente ed eventualmente lancia algoritmi di recovery Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI D

Struttura gerarchica del journal Livello più alto della gerarchia Channel journal Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

I capitoli dei Channel journal • Channel journal viene compilato canale per canale • Nell’header c’è un indice dei “capitoli” – – – – P Program Change C Control Change W Pitch Wheel N Note Off, Note On E Note Command Extras T Channel Aftertouch A Poly Aftertouch Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempio: il capitolo W • Il capitolo W protegge il comando Pitch Wheel • Il capitolo, di lunghezza fissa, è costituito da 2 ottetti, in accordo con il formato del comando MIDI (2 data byte) • Questo capitolo appare nel journal se un comando Pitch Wheel fa parte della checkpoint history Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempio: il capitolo P • Il capitolo P protegge il comando Program Change • Il capitolo, di lunghezza fissa, è costituito da 3 ottetti, in parziale accordo con il formato del comando MIDI (selezione del banco e selezione del program) Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Esempio: il capitolo N • Il capitolo N protegge i comandi Note. On (e Note. Off) • Il capitolo ha lunghezza variabile, specificata dal campo LENGTH • Il flag Y specifica se il Note. On è recente o meno, nel secondo caso può essere ignorato Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI

Riferimenti • Sito Web http: //www. cs. berkeley. edu/~lazzaro/rtpmidi/ • Dettagli sullo standard http: //www. rfc-editor. org/rfc 4696. txt http: //www. rfc-editor. org/rfc 6295. txt • Articolo introduttivo http: //www. cs. berkeley. edu/~lazzaro/sa/pubs/pdf/aes 117. pdf • Caso di studio su NMP e RTP MIDI http: //www. cs. berkeley. edu/~lazzaro/sa/pubs/pdf/nossdav 01. pdf Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI