RTP MIDI – parte 2 Lezione 16 Programmazione MIDI (Prof. Luca A. Ludovico)

RTP MIDI – parte 2

Lezione 16

Programmazione MIDI (Prof. Luca A. Ludovico)

Network Musical Performance (NMP)

Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

Real Time Protocol (RTP): formato del pacchetto


• Specifiche su funzionalità e struttura dei pacchetti: RFC 3550

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 Editorhttp://www.rfc-editor.org/rfc.html


Esempi notevoli di RFC

• DHCP RFC 2131 "Dynamic Host Configuration Protocol"

• DNS RFC 1034,1035 "Domain Names"

• FTP RFC 959 "File Transfer Protocol"

• HTTP RFC 2068 "Hypertext Transfer Protocol 1.1"

• IPv4 RFC 791 "Internet Protocol"

• SMTP RFC 821,822 "Simple Mail Transfer Protocol"

• UDP RFC 768 "User Datagram Protocol"

• TCP RFC 793 "Transmission Control Protocol"


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

• Specifiche su funzionalità e struttura dei pacchetti: RFC 6295


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: MIDI list


Strutturazione della MIDI list (di lunghezza variabile a seconda del valore del flag B e quindi del campo LEN nell’header)

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 (QoS, quality of service) nella distribuzione inviando periodicamente informazioni statistiche ai partecipanti della sessione

• Osservazione: RTCP è definito da specifiche RTP, non RTP MIDI


• 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!

Comunicazione RTP e RTCP


Informazione multimediale pacchettizzata RTP

Informazione statistica pacchettizzata RTCP

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)


RECOVERY JOURNALSezione 16.1

Programmazione MIDI (Prof. Luca A. Ludovico) 16. RTP MIDI (parte 2)

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

Recovery journal


• Finalità: minimizzare gli artefatti transienti ed eliminare quelli indefiniti provocati da ritardi nella consegna dei pacchetti o da una loro perdita

• 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 acknowledgment– 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

Come costruire un LOG incrementale


RTP

Note On 1

Header Payload

MIDI list

History

Note On 1

Note On 2

Note On 1

Note Off 1

Note On 2

Note On 1

Note Off 2

Note On 2

Note Off 1

Note On 1

Header Payload

MIDI list

History

Note On 1

Note On 2

Pacchetto smarrito (ma D non lo può sapere)

Esecuzione della 1a nota

Esecuzione della 2a nota

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

Note On 1

Note Off 2

Note On 2

Note Off 1

Mittente e destinatario RTP


• Il mittente S:1. Genera l’header RTP del nuovo pacchetto2. Genera il payload RTP MIDI, ossia l’header e la MIDI list3. Genera il recovery journal4. Invia il pacchetto sulla rete 5. Aggiorna la propria copia del recovery journal estendendo la checkpoint

history sulla base della MIDI list appena inviata6. Monitora i pacchetti RTCP per stabilire il checkpoint corrente

• Il destinatario D:1. Esegue con la corretta temporizzazione i comandi MIDI nella MIDI list del

pacchetto ricevuto2. Tiene traccia del numero di sequenza più alto e predice l’arrivo di un

pacchetto con numero incrementato di uno3. Se rileva discontinuità nella sequenza, analizza il Recovery journal del

pacchetto più recente ed eventualmente lancia algoritmi di recovery

Livello più alto della gerarchia

Channel journal

Struttura gerarchica del journal


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

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

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)

Esempio: il capitolo N


• Il capitolo N protegge i comandi NoteOn (e NoteOff)

• Il capitolo ha lunghezza variabile, specificata dal campo LENGTH

• Il flag Y specifica se il NoteOn è recente o meno, nel secondo caso può essere ignorato

Riferimenti

• Sito Web http://www.cs.berkeley.edu/~lazzaro/rtpmidi/

• Dettagli sullo standardhttp://www.rfc-editor.org/rfc/rfc4696.txthttp://www.rfc-editor.org/rfc/rfc6295.txt

• Articolo introduttivohttp://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/aes117.pdf

• Caso di studio su NMP e RTP MIDIhttp://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf


RTP MIDI – parte 2 Lezione 16 Programmazione MIDI (Prof. Luca A. Ludovico)

Documents

Transcript of RTP MIDI – parte 2 Lezione 16 Programmazione MIDI (Prof. Luca A. Ludovico)