network musical performance: rtp midi lezione 15 programmazione midi (prof. luca a. ludovico)

Network Musical Performance: RTP MIDI

Lezione 15

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 (parte 1)

Esempi


Esempi di latenza di rete

• Trasmissione di un pacchetto su rete dedicata

– Da Berkeley a StanfordDistanza: 40 migliaLatenza simmetrica: 2.1 msSimilitudine: musicisti a 0.72 m di distanza

– Da Berkeley a Caltech (California)Distanza: 375 migliaLatenza simmetrica: 14.2 msSimilitudine: musicisti a 4.88 m di distanza


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ò…


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à?


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 applicativoTCP è un protocollo orientato alla connessione

– per stabilire, mantenere e chiudere una connessione è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione.


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, smarrimento di pacchetti e ritardi nella consegna sono inevitabili.

• Obiettivo: ricreare performance geograficamente distribuite 1. senza introdurre eccessivo ritardo (non tollerabile per un musicista)2. 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


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


RTP MIDISezione 15.1

Programmazione MIDI (Prof. Luca A. Ludovico) 15. RTP MIDI (parte 1)

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”


Formato del pacchetto RTP


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

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/rfc1889.txt)– RFC 3550 (http://www.ietf.org/rfc/rfc3550.txt)

http://www.ietf.org/rfc/rfc1889.txt




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 NoteOn)– Indefiniti (ad esempio, smarrimento di un NoteOff 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


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)

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.

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

ottettiModalità 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)

Formato del payload RTP MIDI: MIDI list


Strutturazione della MIDI list

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 comandi che passano su cavo DIN)

Codifica dei tempi delta tra comandi 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.

network musical performance: rtp midi lezione 15 programmazione midi (prof. luca a. ludovico)

Documents