RTP -MIDI - RTP-MIDI

RTP-MIDI
Mezinárodní standard IETF RFC 4696
Vyvinuto UC Berkeley
webová stránka https://www.midi.org/midi-articles/rtp-midi-or-midi-over-networks

RTP-MIDI (také známý jako AppleMIDI) je protokol pro přenos zpráv MIDI v paketech RTP ( Real-time Protocol ) přes sítě Ethernet a WiFi. Je zcela otevřený a bezplatný (není nutná licence) a je kompatibilní s aplikačními poli LAN i WAN. Ve srovnání s MIDI 1.0 obsahuje RTP-MIDI nové funkce, jako je správa relací, synchronizace zařízení a detekce ztracených paketů, s automatickou regenerací ztracených dat. RTP-MIDI je kompatibilní s aplikacemi v reálném čase a podporuje synchronizaci přesných vzorků pro každou zprávu MIDI.

Historie RTP-MIDI

V roce 2004 John Lazzaro a John Wawrzynek z UC Berkeley předstoupili před AES s názvem „An RTP payload for MIDI“. V roce 2006 byl dokument předložen IETF a obdržel číslo RFC 4695. Souběžně s tím Lazzaro a Wawrzynek vydali další dokument, který obsahuje podrobnosti o praktické implementaci protokolu RTP-MIDI, zejména mechanismu žurnálování.

RFC 4695 byl zastaralý RFC 6295 v roce 2011. Protokol se mezi dvěma verzemi dokumentů RFC nezměnil, poslední obsahuje opravu chyb nalezených v RFC 4695)

MMA ( MIDI Manufacturers Association ) vytvořila na svých webových stránkách stránku s cílem poskytnout základní informace týkající se protokolu RTP-MIDI.

AppleMIDI

Společnost Apple Computer představila RTP-MIDI jako součást svého operačního systému, Mac OS X v10.4 , v roce 2005. Ovladač RTP-MIDI je dostupný pomocí ikony Network v nástroji MIDI/Audio Configuration. Implementace Apple striktně dodržuje RFC 4695 pro RTP užitečné zatížení a žurnálovací systém, ale používá vyhrazený protokol pro správu relací; nedodržují návrh správy relací RFC 4695. Tento protokol je ve Wireshark zobrazen jako „AppleMIDI“ a později byl dokumentován společností Apple .

Apple také vytvořil vyhrazenou třídu v jejich implementaci mDNS / Bonjour . Zařízení, která vyhovují této třídě, se automaticky zobrazí na konfiguračním panelu RTP-MIDI společnosti Apple jako adresář Účastníci, čímž je systém Apple MIDI plně „ Plug & Play “. V tomto adresáři je však možné ručně zadat IP adresy a porty pro připojení k zařízením, která Bonjour nepodporují.

Apple také představil podporu RTP-MIDI v iOS4, ale taková zařízení nemohou být iniciátory relací.

Ovladač RTP-MIDI od společnosti Apple vytváří virtuální MIDI porty s názvem „Sessions“, které jsou k dispozici jako MIDI porty v jakémkoli softwaru, jako jsou sekvencery nebo softwarové nástroje, pomocí CoreMIDI, kde se zobrazují jako dvojice portů MIDI IN / MIDI OUT jako jakýkoli jiný port MIDI 1.0 nebo USB MIDI port.

Implementace

Vestavěná zařízení

V roce 2006 představila nizozemská společnost Kiss-Box první integrovanou implementaci RTP-MIDI v různých produktech, jako jsou rozhraní MIDI nebo LTC . Tato zařízení vyhovují implementaci AppleMIDI pomocí stejného protokolu pro správu relací, aby byly kompatibilní s ostatními zařízeními a operačním systémem používajícím tento protokol.

Společnost původně vyvinula proprietární ovladač pro Windows XP , ale byl omezen na komunikaci s jejich zařízeními; pomocí tohoto ovladače nebylo možné propojit PC s počítačem Mac. Podpora tohoto ovladače byla v roce 2012 zrušena ve prospěch standardního přístupu, když byl k dispozici ovladač rtpMIDI pro Windows.

Společnost Kiss-Box v roce 2012 oznámila vydání nové generace procesorových desek s názvem „V3“, které podporují funkce iniciátoru relací. Tyto modely jsou schopny navázat relace s jinými zařízeními RTP-MIDI, aniž by jako řídicí bod vyžadovaly počítač.

Během NAMM 2013 představila kanadská společnost iConnectivity nové rozhraní s názvem iConnectivityMIDI4+, které podporuje RTP-MIDI a umožňuje přímé přemostění mezi USB a RTP-MIDI zařízeními. Od té doby navázali na několik dalších rozhraní podporujících RTP-MIDI, včetně mio4 a mio10 a PlayAUDIO 12.

Okna

Tobias Erichsen v roce 2010 vydal implementaci ovladače RTP-MIDI od společnosti Windows. Tento ovladač funguje pod verzemi XP , Vista , Windows 7 , Windows 8 a Windows 10 , 32 a 64 bitů. Ovladač používá konfigurační panel velmi podobný tomu na Apple, a je plně kompatibilní s implementací Apple. Poté jej lze použít k připojení počítače se systémem Windows k počítači Macintosh, ale také k vestavěným systémům. Stejně jako u ovladače Apple, ovladač Windows vytváří virtuální MIDI porty, které jsou viditelné z jakékoli MIDI aplikace běžící na PC. Přístup se provádí přes vrstvu mmsystem, jako všechny ostatní MIDI porty.

Linux

Podpora RTP-MIDI pro Linux byla znovu aktivována v únoru 2013 po období nečinnosti. Dostupnost ovladačů byla oznámena na některých fórech na základě původní práce Nicolase Falqueta a Dominique Fobera. K dispozici je také specifická implementace pro počítač Raspberry PI, nazývaná raveloxmidi. Plná implementace RTP-MIDI (včetně žurnálovacího systému) je k dispozici v distribuci Ubuntu v softwarovém balíčku Scenic.

iOS

Apple přidal plnou podporu CoreMIDI do svých iOS zařízení v roce 2010, což umožňuje vývoj MIDI aplikací pro iPhone, iPad a iPod. MIDI se poté stalo dostupným z dokovacího portu ve formě USB řadiče, umožňujícího připojení USB MIDI zařízení pomocí „Apple Camera Kit“. Byl také k dispozici ve formě posluchače relace RTP-MIDI přes WiFi.

Zařízení iOS nepodporují funkce zahájení relace, což vyžaduje použití externího iniciátoru relací v síti k otevření relace RTP-MIDI s iPadem. Tento iniciátor relace může být počítač Mac nebo počítač se systémem Windows s aktivovaným ovladačem RTP-MIDI nebo integrované zařízení RTP-MIDI. Relace RTP-MIDI se u všech aplikací CoreMIDI v systému iOS zobrazuje pod názvem „Network MIDI“ a pro přidání podpory RTP-MIDI do aplikace pro iOS není vyžadován žádný konkrétní vývoj. MIDI port je virtualizován pomocí CoreMIDI, takže programátor stačí otevřít připojení MIDI, bez ohledu na to, zda je port připojen k USB nebo RTP-MIDI.

Objevily se určité stížnosti na používání MIDI přes USB se zařízeními iOS, protože iPad/iPhone musí zajišťovat napájení externího zařízení. Některé USB MIDI adaptéry odebírají pro iPad příliš mnoho proudu, což omezuje proud a blokuje spuštění zařízení, které se pak aplikaci nezdá jako dostupné. Tomuto problému se lze vyhnout použitím RTP-MIDI.

Javascript

Od června 2013 je jako open-source projekt k dispozici Javascriptová implementace RTP-MIDI, vytvořená J.Dachterou. Zdrojový kód je založen na protokolu Apple pro správu relací a může fungovat jako iniciátor relace a posluchač relací.

Jáva

Jsou možné implementace RTP-MIDI napříč platformami Java, zejména knihovna 'nmj'.

WinRT

Projekt WinRTP-MIDI je open-source implementace zásobníku protokolů RTP-MIDI pod Windows RT. Kód byl původně navržen tak, aby byl přenosný mezi různými verzemi systému Windows, ale poslední verze byla optimalizována pro WinRT, aby se zjednodušil návrh aplikací pro Windows Store.

Arduino

RTP-MIDI byl pro platformu Arduino k dispozici v listopadu 2013 pod názvem „knihovna AppleMIDI“. Softwarový modul může běžet buď na modulech Arduino s integrovaným ethernetovým adaptérem, jako je Intel Galileo, nebo může běžet na „ethernetovém štítu“.

KissBox produkuje RTP-MIDI OEM modul, desku externího komunikačního procesoru, která se připojuje přes sběrnici SPI .

MIDIbox

V prosinci 2013 začali dva členové skupiny MIDIbox DIY pracovat na počáteční verzi MIOS (operační systém MIDIbox) včetně podpory RTP-MIDI prostřednictvím rychlého propojení SPI. Aby se integrace zjednodušila, bylo rozhodnuto použít desku externího síťového procesoru, která bude zpracovávat celý zásobník protokolů. První beta verze byla vydána druhý týden v lednu 2014. První oficiální software byl vydán během prvního týdne v březnu 2014.

Protokol použitý na propojení SPI mezi procesorem MIOS a síťovým procesorem je založen na stejném formátu jako USB a používá 32bitová slova obsahující úplnou zprávu MIDI a byl navržen jako otevřený standard pro komunikaci mezi moduly síťového procesoru a MIDI aplikační desky.

Axoloti

Axoloti je hardwarový syntetizátor s otevřeným zdrojovým kódem založený na procesoru STM32F427 ARM. Tento syntezátor je plně programovatelný pomocí konceptu virtuální opravy, podobně jako Max/MSP, a obsahuje plnou podporu MIDI. Bylo vyvinuto rozšíření node.js, které umožňuje připojení Axoloti RTP-MIDI k jakémukoli zařízení RTP-MIDI. Hardware Axoloti může být také vybaven externím koprocesorem RTP-MIDI, připojeným přes sběrnici SPI dostupnou na rozšiřujícím portu jádra Axoloti. Přístup je stejný jako ten, který je popsán pro Arduino a MIDIbox.

Cross-platformová knihovna MIDIKit

MIDIKit je open-source, multiplatformní knihovna, která poskytuje jednotné MIDI API pro různá MIDI API dostupná na trhu (Core MIDI, Windows MME, Linux ALSA atd.). MIDIKit podporuje protokol RTP-MIDI, včetně žurnálovacího systému. RTP-MIDI porty jsou v MIDIKit vnímány jako doplňkové porty (nespoléhají na ovladač rtpMIDI), přidané do nativních systémových MIDI portů

Použití bez řidiče

Protože RTP-MIDI je založeno na UDP/IP, může jakákoli aplikace implementovat protokol přímo, aniž by potřebovala jakýkoli ovladač. Ovladače jsou potřeba pouze tehdy, když uživatelé chtějí, aby se síťové porty MIDI zobrazovaly jako standardní port MIDI. Podle této metodiky byly například vyvinuty některé objekty Max/MSP a doplňky VST.

RTP-MIDI přes AVB

AVB je soubor technických norem, které definují specifikace pro streamovací služby s extrémně nízkou latencí přes ethernetové sítě. Sítě AVB jsou schopny poskytovat latence až po jeden zvukový vzorek v celé síti.
RTP-MIDI je nativně kompatibilní se sítěmi AVB, jako každý jiný protokol IP, protože přepínače AVB (také známé jako „přepínače IEEE802.1“) automaticky spravují prioritu mezi audio/video toky v reálném čase a provozem IP. Protokol RTP-MIDI může také využívat možnosti AVB v reálném čase, pokud zařízení implementuje užitečné zatížení RTCP popsané v dokumentu IEEE-1733. RTP-MIDI aplikace pak mohou korelovat "prezentační" časové razítko, poskytnuté IEEE-802.1 Master Clock, s RTP časovým razítkem, zajišťujícím vzorově přesné časové rozložení MIDI událostí.

Protokol

RFC 4695/RFC 6295 rozdělil implementaci RTP-MIDI na různé části. Jediným povinným, který definuje soulad se specifikací RTP-MIDI, je formát užitečného zatížení. Část žurnálování je volitelná, ale pakety RTP-MIDI musí indikovat, že mají prázdný deník, takže žurnál je v paketu RTP-MIDI vždy přítomen, i když je prázdný. Část pro zahájení/správu relace je čistě informativní. Nebyl použit společností Apple, která vytvořila vlastní protokol pro správu relací.

Formát záhlaví

Formát hlavičky RTP-MIDI
Sekce Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
RTP 0 PROTI P X CC M Typ užitečného zatížení (PT) Pořadové číslo
32 Časové razítko
64 Identifikátor zdroje synchronizace (SSRC)
96 Přispívající identifikátory zdroje (CSRC) (volitelně)
MIDI příkazy B J. Z P LEN… Seznam zpráv MIDI…
Deník (volitelně v závislosti na příznaku J) S Y A H TOTCHAN Checkpoint Packet Seqnum Systémový deník (volitelně)…
Kanálské deníky…

Zasedání

RTP-MIDI relace mají na starosti vytváření virtuální cesty mezi dvěma zařízeními RTP-MIDI a z aplikačního hlediska vypadají jako pár MIDI IN / MIDI OUT. RFC 6295 navrhuje používat SIP (Session Initiation Protocol) a SDP (Session Description Protocol), ale Apple se rozhodl vytvořit vlastní protokol pro správu relací. Protokol Apple propojuje relace se jmény používanými na Bonjour a také nabízí službu synchronizace hodin.

Popisuje, jak se relace RTP-MIDI automaticky slučují a duplikují toky MIDI mezi řadiči sdílejícími stejnou relaci.

Daná relace je vždy vytvořena mezi dvěma a pouze dvěma účastníky, přičemž každá relace slouží k detekci potenciální ztráty zpráv mezi těmito dvěma účastníky. Daný řadič relací však může otevřít více relací souběžně, což umožňuje funkce, jako je rozdělení, sloučení nebo distribuovaný patchbay. Na zde uvedeném diagramu má zařízení 1 otevřeny dvě relace současně, jednu se zařízením 2 a druhou se zařízením 3, ale dvě relace v zařízení 1 se konečnému uživateli jeví jako stejné virtuální MIDI rozhraní.

Relace vs. koncové body

Častou chybou je nesoulad mezi koncovými body RTP-MIDI a relacemi RTP-MIDI, protože oba představují dvojici portů MIDI IN / MIDI OUT.

Koncový bod se používá k výměně dat MIDI mezi prvkem (softwarovým a/nebo hardwarovým), který má na starosti dekódování přenosového protokolu RTP-MIDI, a prvkem pomocí zpráv MIDI. Jinými slovy, na úrovni koncových bodů jsou viditelná pouze data MIDI. U zařízení s konektory MIDI 1.0 DIN existuje jeden koncový bod na dvojici konektorů, například: 2 koncové body pro KissBox MIDI2TR, 4 koncové body pro iConnectivityMIDI4+atd. Zařízení využívající jiné komunikační linky jako SPI nebo USB nabízejí více koncových bodů, například zařízení pomocí 32bitového kódování USB MIDI třídy může reprezentovat až 16 koncových bodů pomocí pole Identifikátor kabelu. Při použití protokolu relace AppleMIDI je koncový bod na straně RTP-MIDI reprezentován spárovaným portem UDP.

Relace definuje spojení mezi dvěma koncovými body. MIDI IN jednoho koncového bodu je připojen k MIDI OUT vzdáleného koncového bodu a naopak. Jeden koncový bod může přijímat více relací v závislosti na konfiguraci softwaru. Každá relace pro daný koncový bod se zobrazí jako jedna pro obsluhu vzdálené relace. Obsluha vzdálené relace neví, zda je koncový bod, ke kterému je připojen, používán jinými relacemi současně. Pokud je pro daný koncový bod aktivní více relací, sloučí se různé MIDI streamy dosahující koncového bodu před odesláním dat MIDI do aplikace. V opačném směru jsou MIDI data vytvářená aplikací odesílána všem obslužným programům relací připojeným ke koncovému bodu.

Účastníci relace AppleMIDI

Implementace AppleMIDI definuje dva druhy řadičů relací: iniciátory relací a posluchače relací. Iniciátoři relací mají na starosti pozvání posluchačů relací a zodpovídají za synchronizační sekvenci hodin. Iniciátory relace mohou být obecně posluchači relací, ale některá zařízení, například zařízení iOS, mohou být pouze posluchači relací.

MIDI slučování

Na rozdíl od zařízení MIDI 1.0, která vyžadují „slučování MIDI“, mohou zařízení RTP-MIDI sloučit různé toky MIDI, aniž by potřebovaly jakýkoli konkrétní komponent. Jak je vidět na diagramu, když je řadič relace připojen ke dvěma nebo více vzdáleným relacím, automaticky sloučí MIDI streamy přicházející ze vzdálených zařízení, aniž by vyžadovaly jakoukoli konkrétní konfiguraci.

MIDI rozdělení („MIDI THRU“)

Zařízení RTP-MIDI jsou schopna duplikovat toky MIDI z jedné relace na libovolný počet vzdálených relací, aniž by vyžadovaly jakékoli podpůrné zařízení „MIDI THRU“. Když je relace RTP-MIDI připojena ke dvěma nebo více vzdáleným relacím, všechny vzdálené relace obdrží kopii dat MIDI odeslaných ze zdroje.

Distribuovaný koncept patchbay

Relace RTP-MIDI jsou také schopny poskytnout funkci „patchbay“, která vyžadovala samostatné hardwarové zařízení s připojením MIDI 1.0. MIDI 1.0 patchbay je hardwarové zařízení, které umožňuje dynamické propojení mezi sadou MIDI vstupů a sadou MIDI výstupů, většinou ve formě matice. Koncept „dynamického“ připojení je vytvořen na rozdíl od klasického použití linek MIDI 1.0, kde byly kabely propojeny „staticky“ mezi dvěma zařízeními. Místo vytváření datové cesty mezi zařízeními ve formě kabelu se patchbay stává ústředním bodem, kde jsou připojena všechna zařízení MIDI. Software v MIDI patchbay je nakonfigurován tak, aby definoval, který MIDI vstup jde do kterého MIDI výstupu, a uživatel může tuto konfiguraci kdykoli změnit, aniž by musel odpojovat MIDI kabely DIN.

Hardwarové moduly „patchbay“ již s RTP-MIDI nejsou potřeba, díky konceptu relace. Relace jsou podle definice virtuální cesty vytvořené v síti mezi dvěma porty MIDI. K provádění funkcí patchbay není potřeba žádný konkrétní software, protože proces konfigurace přesně definuje cíle pro každý MIDI stream produkovaný daným MIDI zařízením. Potom je možné tyto virtuální cesty kdykoli změnit pouhou změnou cílových IP adres používaných každým iniciátorem relace. Takto vytvořená konfigurace „patche“ může být uložena v energeticky nezávislé paměti, aby se oprava mohla automaticky reformovat, když je nastavení napájeno, ale lze je také změnit přímo, jako pomocí softwarového nástroje RTP-MIDI Manager nebo pomocí Ovládací panely ovladačů RTP-MIDI na úrovni RAM.

Pojem „distribuovaný patchbay“ pochází ze skutečnosti, že různá zařízení RTP-MIDI lze distribuovat geograficky po celém nastavení MIDI, zatímco patchbay MIDI 1.0 přinutil fyzicky umístit různá zařízení MIDI přímo kolem samotného zařízení patchbay.

Relační protokol Apple

Dokument RFC6295 navrhuje používat protokoly SDP (Session Description Protocol) a SIP (Session Initiation Protocol) k vytváření a správě relací mezi partnerem RTP-MIDI. Tyto dva protokoly jsou však poměrně náročné na implementaci, zejména na malých systémech, zejména proto, že neomezují žádné parametry vyjmenované v deskriptoru relace, jako je vzorkovací frekvence, která zase definuje všechna pole související s časovacími daty v hlavičkách RTP i v RTP -MIDI užitečné zatížení. Dokument RFC6295 navíc navrhuje pouze použití těchto protokolů, což umožňuje použití jakéhokoli jiného protokolu, což vede k potenciální nekompatibilitě mezi dodavateli.

Apple se rozhodl vytvořit vlastní protokol, který ukládá všechny parametry související se synchronizací, jako je vzorkovací frekvence. Tento protokol relace se v softwaru Wireshark nazývá „AppleMIDI“. Správa relací pomocí protokolu AppleMIDI vyžaduje dva UDP porty, první se nazývá „Control Port“, druhý se nazývá „Data Port“. Při použití v rámci implementace s více vlákny vyžaduje pouze datový port vlákno „v reálném čase“, druhý port lze ovládat běžným vláknem s prioritou. Tyto dva porty musí být umístěny na dvou po sobě jdoucích místech (n / n+1); prvním může být kterýkoli z 65536 možných portů.

Počet relací, které lze současně otevřít na sadě portů UDP s protokolem AppleMIDI, není nijak omezen. Je možné buď vytvořit jednu skupinu portů na správce relací, nebo použít pouze jednu skupinu pro více relací, což omezuje paměťovou stopu v systému. V tomto posledním případě zásobník IP poskytuje prostředky k identifikaci partnerů podle jejich IP adres a čísel portů. Tato funkce se nazývá „opětovné použití soketu“ a je k dispozici ve většině moderních implementací IP.

Všechny zprávy protokolu AppleMIDI používají společnou strukturu 4 slov o 32 bitech, přičemž záhlaví obsahuje dva bajty s hodnotou 255, za nímž následují dva bajty popisující význam zprávy:

Popis Definice záhlaví Wireshark Hodnota pole (hex) Hodnota pole (znaky)
Pozvání APPLEMIDI_COMMAND_INVITATION 0x494e IN
Pozvánka přijata APPLEMIDI_COMMAND_INVITATION_ACCEPTED 0x4f4b OK
Pozvánka odmítnuta APPLEMIDI_COMMAND_INVITATION_REJECTED 0x4e4f NO
Závěrečné zasedání APPLEMIDI_COMMAND_ENDSESSION 0x4259 BY
Synchronizace hodin APPLEMIDI_COMMAND_SYNCHRONIZATION 0x434b CK
Journalling synchronizace APPLEMIDI_COMMAND_RECEIVER_FEEDBACK 0x5253 RS
Bitrate APPLEMIDI_COMMAND_BITRATE_RECEIVE_LIMIT 0x524c RL

Tyto zprávy řídí stavový stroj související s každou relací. Tento stavový stroj například zakazuje jakoukoli výměnu dat MIDI, dokud relace nedosáhne stavu „otevřeno“.

Pozvánka

Otevření relace začíná sekvencí pozvánek. První partner relace („Iniciátor relace“) odešle zprávu IN na řídicí port druhého partnera. Odpovídají odesláním zprávy OK, pokud souhlasí s otevřením relace, nebo zprávou NE, pokud pozvání nepřijmou. Pokud je na řídicím portu přijato pozvání, opakuje se stejná sekvence na datovém portu. Jakmile byly na obou portech přijaty pozvánky, stavový stroj přejde do fáze synchronizace.

Synchronizační sekvence

Synchronizační sekvence umožňuje oběma účastníkům relace sdílet informace týkající se jejich místních hodin. Tato fáze umožňuje kompenzovat latenci vyvolanou sítí a také podporovat „budoucí časové razítko“ (viz část „Latence“ níže).

Iniciátor relace odešle vzdálenému partnerovi první zprávu (pojmenovanou CK0) s udáním místního času v 64 bitech (Všimněte si, že to není absolutní čas, ale čas související s místní referencí, obvykle udávaný v mikrosekundách od spuštění jádro operačního systému). Tento čas je vyjádřen na základě vzorkovacích hodin 10 kHz (100 mikrosekund na přírůstek). Vzdálený partner musí na tuto zprávu odpovědět zprávou CK1 obsahující vlastní místní čas v 64 bitech. Oba partneři pak znají rozdíl mezi svými příslušnými hodinami a mohou určit posun, který se má použít pro pole Časové razítko a Deltatime v protokolu RTP-MIDI.

Iniciátor relace dokončí tuto sekvenci odesláním poslední zprávy s názvem CK2, obsahující místní čas, kdy přijal zprávu CK1. Tato technika umožňuje vypočítat průměrnou latenci sítě a také kompenzovat potenciální zpoždění způsobené pomalým spouštěcím vláknem, ke kterému může dojít u operačních systémů, které nejsou v reálném čase, jako jsou Linux, Windows nebo OS X.

Společnost Apple doporučuje tuto sekvenci několikrát opakovat hned po otevření relace, aby byla zajištěna lepší přesnost synchronizace v případě, že došlo k náhodnému zpoždění jednoho z nich kvůli dočasnému přetížení sítě nebo špičce latence při aktivaci vlákna.

Tato sekvence se musí cyklicky opakovat, obvykle 2 až 6krát za minutu, a vždy iniciátor relace, aby byla zachována přesnost dlouhodobé synchronizace kompenzací posunu místních hodin a také aby byla detekována ztráta komunikačního partnera. Partner, který neodpovídá na více zpráv CK0, bude mít za to, že vzdálený partner je odpojen. Ve většině případů iniciátoři relací přepnou svůj stavový stroj do stavu „Pozvánka“, aby automaticky obnovili komunikaci, jakmile se vzdálený partner znovu připojí k síti. Některé implementace, zejména na osobních počítačích, také zobrazují výstražnou zprávu a nabízejí uživateli možnost volby mezi novým pokusem o připojení nebo ukončením relace.

Aktualizace deníku

Mechanismus žurnálování umožňuje detekovat ztrátu MIDI zpráv a umožňuje přijímači generovat chybějící data bez nutnosti opakovaného přenosu. Deník uchovává v paměti „MIDI obrázky“ pro různé partnery relace v různých okamžicích. Je však zbytečné uchovávat v paměti žurnálovací data odpovídající událostem přijatým správně partnerem relace. Každý partner poté cyklicky posílá druhému partnerovi zprávu RS, která označuje poslední správně přijaté pořadové číslo, jinými slovy bez mezery mezi dvěma pořadovými čísly. Odesílatel pak může v případě potřeby uvolnit paměť obsahující stará žurnálovací data.

Odpojení partnera relace

Partner relace může kdykoli požádat o ukončení relace, čímž relaci na oplátku ukončí. To se provádí pomocí zprávy BY. Když partner relace obdrží tuto zprávu, okamžitě zavře relaci se vzdáleným partnerem, který zprávu odeslal, a uvolní všechny prostředky přidělené této relaci. Je třeba poznamenat, že tuto zprávu může odeslat iniciátor relace nebo posluchač relace („pozvaný“ partner).

Latence

Nejčastější obavy týkající se RTP-MIDI se týkají problémů s latencí, což je obecný problém u digitálních zvukových pracovních stanic, hlavně proto, že používá zásobník IP. Lze však snadno ukázat, že správně naprogramovaná aplikace nebo ovladač RTP-MIDI nevykazuje větší latenci než jiné komunikační metody.

Navíc RTP-MIDI, jak je popsáno v RFC 6295, obsahuje mechanismus kompenzace latence. Podobný mechanismus se nachází ve většině pluginů, které mohou informovat hostitele o latenci, kterou přidávají do cesty zpracování. Hostitel pak může předem zaslat vzorky do pluginu, takže vzorky jsou připraveny a odesílány synchronně s jinými audio streamy. Kompenzační mechanismus popsaný v RF6295 používá systém relativních časových razítek, založený na MIDI deltatime, jak je popsáno v. Každá událost MIDI přenášená v datové části RTP má počáteční hodnotu deltatime související s počátkem času aktuálního užitečného zatížení, definovaného polem Timestamp v RTP záhlaví.

Každá událost MIDI v datové části RTP-MIDI pak může být striktně synchronizována s globálními hodinami. Přesnost synchronizace přímo závisí na zdroji hodin definovaném při otevírání relace RTP-MIDI. RFC 6295 uvádí několik příkladů založených na vzorkovacích hodinách zvuku, aby bylo možné získat přesné časové razítko událostí MIDI. Implementace RTP-MIDI od společnosti Apple, stejně jako u všech ostatních souvisejících implementací, jako je ovladač rtpMIDI pro systémy Windows nebo vestavěné systémy KissBox, používá namísto vzorkovací frekvence zvuku pevnou taktovací frekvenci 10 kHz. Časová přesnost všech MIDI událostí je pak pro tyto implementace 100 mikrosekund.

Hodiny odesílatele a příjemce jsou synchronizovány při zahájení relace a jsou synchronizovány po celou dobu relace pravidelnými synchronizačními cykly, řízenými iniciátory relace. Tento mechanismus má schopnost kompenzovat jakoukoli latenci, od několika stovek mikrosekund, jak je vidět na aplikacích LAN, až po sekundy. Může například kompenzovat latenci zavedenou internetem, což umožňuje provádění hudebních skladeb v reálném čase.

Tento mechanismus je však určen hlavně pro předem zaznamenané MIDI streamy, jako je ten, který pochází ze stopy sekvenceru. Pokud se RTP-MIDI používá pro aplikace v reálném čase (např. Ovládání zařízení z klávesnice kompatibilní s RTP-MIDI), je deltatime většinou nastaveno na konkrétní hodnotu 0, což znamená, že související MIDI událost bude interpretována, jakmile je obdržel). S takovým případem použití nelze použít dříve popsaný mechanismus kompenzace latence.

Latence, kterou lze získat, pak přímo souvisí s různými síťovými komponentami zapojenými do komunikační cesty mezi zařízeními RTP-MIDI:

  • Doba zpracování MIDI aplikace
  • Doba zpracování zásobníku IP komunikace
  • Čas přeposílání paketů síťových přepínačů/směrovačů

Doba zpracování aplikace

Doba zpracování aplikace je obecně přísně kontrolována, protože úkoly MIDI jsou nejčastěji úkoly v reálném čase. Latence ve většině případů pochází přímo z latence vláken, kterou lze získat v daném operačním systému, obvykle 1–2 ms maximálně v systémech Windows a Mac OS. Systémy s jádrem v reálném čase mohou dosáhnout mnohem lepších výsledků, až 100 mikrosekund. Tento čas lze považovat za konstantní bez ohledu na komunikační kanál (MIDI 1.0, USB, RTP-MIDI atd. ...), protože vlákna zpracování fungují na jiné úrovni než vlákna/úkoly související s komunikací.

Doba zpracování IP zásobníku

Doba zpracování IP zásobníku je nejdůležitější, protože komunikační proces je pod kontrolou operačního systému. To platí pro jakýkoli komunikační protokol, ať už související s IP nebo ne, protože většina operačních systémů, včetně Windows, Mac OS nebo Linux, neumožňuje přímý přístup k ethernetovému adaptéru. Zejména je běžnou chybou spojování „surových soketů“ s „přímým přístupem k síti“; zásuvky jsou vstupním bodem pro odesílání a přijímání dat přes síť ve většině operačních systémů. „Surový soket“ je soket, který umožňuje aplikaci odeslat libovolný paket pomocí libovolného protokolu. Aplikace je pak zodpovědná za sestavení telegramu podle daných pravidel protokolu, zatímco „přímý přístup“ by vyžadoval přístup na úrovni systému, který je omezen na jádro operačního systému. Paket odeslaný pomocí nezpracovaného soketu pak může operační systém odložit, pokud síťový adaptér aktuálně používá jiná aplikace. IP paket lze tedy odeslat do sítě před paketem souvisejícím s nezpracovanou zásuvkou. Technicky vzato, přístup k dané síťové kartě je řízen „semafory“.

IP stacky musí korelovat ethernetové adresy (MAC adresy) a IP adresy pomocí specifického protokolu s názvem ARP. Když chce aplikace RTP-MIDI odeslat paket na vzdálené zařízení, musí jej nejprve vyhledat v síti, protože ethernet nerozumí konceptům souvisejícím s IP, aby vytvořil přenosovou cestu mezi směrovači/přepínači. To se provádí automaticky pomocí zásobníku IP odesláním nejprve požadavku ARP (Address Recognition Protocol). Když cílové zařízení rozpozná vlastní IP adresu v paketu ARP, odešle zpět odpověď ARP se svou adresou MAC. IP stack pak může odeslat RTP-MIDI paket. Další pakety RTP-MIDI již sekvenci ARP nepotřebují, pokud se spojení na několik minut neaktivní, čímž se vymaže položka ARP ve směrovací tabulce odesílatele.

Tato sekvence ARP může trvat několik sekund, což může zase přinést znatelnou latenci, alespoň pro první RTP-MIDI paket. Implementace společnosti Apple však tento problém vyřešila elegantním způsobem pomocí protokolu pro řízení relací. Protokol relace používá stejné porty jako samotný protokol RTP-MIDI. Sekvence ARP pak probíhá během sekvence zahájení relace. Když aplikace RTP-MIDI chce odeslat první RTP-MIDI paket, směrovací tabulky počítače jsou již inicializovány se správnými cílovými adresami MAC, čímž se zabrání jakékoli latenci prvního paketu.

Kromě sekvence ARP samotný zásobník IP vyžaduje pro přípravu záhlaví paketů výpočty, jako je například záhlaví IP, záhlaví UDP a záhlaví RTP. U moderních procesorů je tato příprava extrémně rychlá a zabere jen pár mikrosekund, což je ve srovnání se samotnou latencí aplikace zanedbatelné. Jak již bylo popsáno dříve, RTP-MIDI paket může být po přípravě zpožděn, pouze když se pokusí dosáhnout síťového adaptéru, pokud adaptér již vysílá další paket, ať už je soket IP nebo „raw“. Latence zavedená na této úrovni je však obecně extrémně nízká, protože vlákna ovladačů zodpovědná za síťové adaptéry mají velmi vysokou prioritu. Většina síťových adaptérů má navíc vyrovnávací paměti FIFO na hardwarové úrovni, takže pakety mohou být uloženy pro okamžitý přenos v samotném síťovém adaptéru, aniž by bylo nutné nejprve spustit vlákno ovladače. Metoda, která pomůže udržet latenci související s „konkurencí v přístupu k adaptéru“ na co nejnižší úrovni, je vyhradit síťový adaptér pouze pro komunikaci MIDI a použít jiný síťový adaptér pro jiná použití v síti, jako je sdílení souborů nebo procházení internetu.

Doba směrování síťových komponent

Různé komponenty používané k přenosu ethernetových paketů mezi počítači, bez ohledu na používané protokoly, také zavádějí latenci. Všechny moderní síťové přepínače používají technologii „Store and Forward“, ve které jsou pakety uloženy v přepínači před odesláním na další přepínač. Spínací časy jsou však nejčastěji zanedbatelné. Například 64bajtový paket v síti 100 Mbit/s trvá přeposlání každého síťového přepínače přibližně 5,1 mikrosekundy. Složitá síť s 10 přepínači na dané cestě zavádí latenci 51 mikrosekund.

Latence je však přímo úměrná samotnému zatížení sítě, protože přepínače budou zpožďovat paket, dokud nebude přenesen předchozí. Výpočet/měření skutečné latence zavedené síťovými komponentami může být obtížný úkol a bude zahrnovat reprezentativní případy použití, například měření latence mezi dvěma síťovými zařízeními připojenými ke stejnému síťovému přepínači vždy poskytne vynikající výsledky. Jak bylo řečeno v předchozí části, jedním z řešení, jak omezit latenci zavedenou síťovými komponentami, je použití samostatných sítí. To je však pro síťové součásti mnohem méně důležité než pro síťové adaptéry v počítačích.

Očekávaná latence pro aplikace v reálném čase

Jak je vidět, přesná latence získaná pro spojení RTP-MIDI závisí na mnoha parametrech, většina z nich souvisí s operačními systémy samotnými. Měření provedená různými aktéry RTP-MIDI udávají dobu latence od několika stovek mikrosekund u vestavěných systémů využívajících operační systémy v reálném čase, až 3 milisekundy u počítačů s obecnými operačními systémy.

Vylepšení latence (latence sub milisekund)

AES začala pracovní skupina s názvem SC-02-12H v roce 2010 s cílem prokázat schopnost používat RTP užitečné zatížení v IP sítích pro velmi nízké latence aplikací. Návrh návrhu, který skupina vydala v květnu 2013, ukazuje, že je možné dosáhnout streamování RTP pro živé aplikace s hodnotou latence až 125 mikrosekund.

Konfigurace

Dalším nejběžnějším problémem spojeným s RTP-MIDI je proces konfigurace, protože fyzické připojení zařízení k síti nestačí k zajištění komunikace s jiným zařízením. Protože RTP-MIDI je založeno na zásobníku protokolů IP, musí být nakonfigurovány různé vrstvy zahrnuté v komunikačním procesu, například adresa IP a porty UDP. Za účelem zjednodušení této konfigurace byla navržena různá řešení, z nichž nejběžnější je sada technologií „ Zero Configuration “, známá také jako Zeroconf.

RFC 3927 popisuje běžnou metodu automatického přiřazování IP adres, kterou používá většina produktů kompatibilních s RTP-MIDI. Po připojení k síti IP si takové zařízení může přiřadit IP adresu s automatickým řešením konfliktu IP adres. Pokud zařízení splňuje doporučení pro přiřazení portů podle specifikace RTP, stane se z hlediska sítě „Plug & Play“. Potom je možné zcela vytvořit síť RTP-MIDI, aniž byste museli definovat libovolnou adresu IP nebo čísla portů UDP. Je však třeba poznamenat, že tyto metody jsou obecně vyhrazeny pro malá nastavení. U velkých instalací se obecně vyhýbá úplné automatizaci konfigurace sítě, protože lokalizace vadných zařízení může být složitá, protože nebude existovat žádný přímý vztah mezi IP adresou, kterou vybral systém Zeroconf, a fyzickým umístěním zařízení. Minimální konfigurací by pak bylo přiřadit zařízení název před připojením k síti, což v takovém případě ruší koncept „skutečného Plug & Play“.

Je třeba poznamenat, že koncept „nulové konfigurace“ je omezen na vrstvy síťové komunikace. Je technicky nemožné provést úplnou instalaci jakéhokoli síťového zařízení (souvisejícího s MIDI nebo ne) pouhou abstrakcí adresovací vrstvy. Praktickým případem použití, který ilustruje toto omezení, je zvukový generátor RTP-MIDI, který musí být řízen z hlavní MIDI klávesnice připojené k rozhraní RTP-MIDI. I když zvukový generátor a MIDI rozhraní integrují služby „nulové konfigurace“, nemohou samy vědět, že potřebují společně vytvořit relaci, protože konfigurační služby IP působí na různých úrovních. Jakýkoli síťový MIDI systém, bez ohledu na protokol používaný k výměně MIDI dat (na základě IP nebo ne), pak vyžaduje povinné použití konfiguračního nástroje k definování výměn, které musí probíhat mezi zařízeními poté, co byly připojeny k síti . Tento konfigurační nástroj může být externí nástroj pro správu spuštěný na počítači nebo může být vložen do aplikačního softwaru zařízení ve formě konfigurační nabídky, pokud zařízení integruje rozhraní člověk-stroj.

Kompatibilita s MIDI 2.0

Sdružení výrobců MIDI v lednu 2019 oznámilo, že do finální fáze prototypování vstupuje zásadní evoluce protokolu MIDI s názvem MIDI 2.0 .

MIDI 2.0 do značné míry spoléhá na rozšíření MIDI-CI, používané pro vyjednávání protokolů (identifikace zařízení MIDI 1.0 a MIDI 2.0 umožňující přepnutí protokolu). RTP-MIDI plně podporuje protokol MIDI-CI, protože používá MIDI 1.0 System Exclusive i na zařízeních MIDI 2.0.

Vývoj MTP protokolu RTP-MIDI, který zahrnuje MIDI 2.0, byl předložen MMA a je v současné době projednáván v pracovní skupině MIDI 2.0. Vylepšený protokol podporuje paralelně datový formát MIDI 1.0 i MIDI 2.0 (MIDI 2.0 používá 32bitové pakety, zatímco MIDI 1.0 používá 8bitové pakety)

Společnosti/Projekty využívající RTP-MIDI

  • Počítač Apple (ovladač RTP-MIDI integrovaný v systému Mac OS X a iOS pro celou řadu produktů)-RTP-MIDI přes ethernet a WiFi
  • Yamaha (syntetizátory motivu, adaptér UD-WL01)-RTP-MIDI přes ethernet a WiFi
  • Behringer (X-Touch Control Surface)
  • KissBox (rozhraní RTP-MIDI s MIDI 1.0, LTC, I/O a ArtNet, VST pluginy pro dálkové ovládání hardwarového syntetizátoru)
  • Tobias Erichsen Consulting (bezplatný ovladač RTP-MIDI pro Windows / Utilities)
  • GRAME (ovladač Linuxu)
  • HRS (MIDI distribuce časového kódu v ethernetovém / synchronizačním softwaru)
  • iConnectivity (audio a MIDI rozhraní s podporou USB a RTP-MIDI)
  • Sloučení technologií (Horus, Hapi, Pyramix, Ovation) - RTP -MIDI pro ovládání LTC/MTC, MIDI DIN a MicPre
  • Zivix PUC (bezdrátové rozhraní RTP-MIDI pro zařízení iOS)
  • Knihovna Arduino-AppleMIDI
  • MIDIbox
  • Cinara (MIDI rozhraní s podporou USB a RTP-MIDI)
  • McLaren Labs rtpmidi pro Linux
  • BEB (DSP moduly pro modulární syntezátory založené na páteři RTP-MIDI)
  • Axoloti (hardwarový open-source syntezátor s připojením RTP-MIDI)

Reference