1 / 22

RTP MIDI – parte 2

Lezione 16. RTP MIDI – parte 2. 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.

honorato-berger
Download Presentation

RTP MIDI – parte 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Network Musical Performance (NMP) Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  3. Real Time Protocol (RTP): formato del pacchetto • Specifiche su funzionalità e struttura dei pacchetti: RFC 3550 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  4. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  5. 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" Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  6. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  7. 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)16. RTP MIDI (parte 2)

  8. 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) Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  9. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  10. Comunicazione RTP e RTCP S D Informazione statistica pacchettizzata RTCP Informazione multimediale pacchettizzata RTP • 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! Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  11. 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)16. RTP MIDI (parte 2)

  12. Sezione 16.1 Recovery Journal Programmazione MIDI (Prof. Luca A. Ludovico) 16. RTP MIDI (parte 2)

  13. 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)16. RTP MIDI (parte 2)

  14. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  15. Come costruire un LOG incrementale S D RTP Header Header Payload Payload History History MIDI list MIDI list Note On 1 Note On 1 Esecuzione della 1a nota Note On 2 Note On 1 Note On 2 Note On 1 Esecuzione della 2a nota Note On 1 Note Off 1 Note On 2 Entrambe le note ancora in esecuzione Pacchetto smarrito (ma D non lo può sapere) Note Off 2 Note Off 1 Note On 2 Note On 1 Note Off 2 Note Off 1 Note On 2 Note On 1 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)16. RTP MIDI (parte 2)

  16. Mittente e destinatario RTP S D • Il mittente 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: • 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)16. RTP MIDI (parte 2)

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

  18. 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)16. RTP MIDI (parte 2)

  19. 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)16. RTP MIDI (parte 2)

  20. 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)16. RTP MIDI (parte 2)

  21. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

  22. 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 Programmazione MIDI (Prof. Luca A. Ludovico)16. RTP MIDI (parte 2)

More Related