RTP-MIDI

Apple Computerは、2005年にオペレーティングシステムMac OS X v10.4の一部としてRTP-MIDIを導入しました。RTP -MIDIドライバは、MIDI/オーディオ構成ツールのネットワークアイコンからアクセスできます。Appleの実装は、RTPペイロードとジャーナリングシステムに関するRFC 4695に厳密に準拠していますが、セッション管理には専用のプロトコルを使用しており、RFC 4695のセッション管理提案には準拠していません。このプロトコルはWiresharkで「AppleMIDI」と表示され、後にAppleによって文書化されました。

Appleは、 mDNS / Bonjourの実装において専用のクラスを作成しました。このクラスに準拠するデバイスは、AppleのRTP-MIDI設定パネルの「参加者」ディレクトリに自動的に表示され、Apple MIDIシステムを完全に「プラグアンドプレイ」で利用できるようになります。ただし、Bonjourをサポートしていないデバイスに接続するには、このディレクトリにIPアドレスとポートを手動で入力することも可能です。

AppleはiOS4でRTP-MIDIのサポートも導入したが、そのようなデバイスはセッション開始者にはなれない。

AppleのRTP-MIDIドライバは、「セッション」という名前の仮想MIDIポートを作成します。これらのセッションは、CoreMIDIを使用するシーケンサーやソフトウェア音源などのソフトウェアでMIDIポートとして利用でき、他のMIDI 1.0ポートやUSB MIDIポートと同様に、MIDI IN / MIDI OUTポートのペアとして表示されます。

2006年、オランダのKiss-Box社は、MIDIやLTCインターフェースなどのさまざまな製品にRTP-MIDIを初めて組み込んだ実装を発表しました。^{[ 6 ]}これらのデバイスは、AppleMIDIの実装に準拠し、同じセッション管理プロトコルを使用することで、このプロトコルを使用する他のデバイスやオペレーティングシステムとの互換性を確保しています。

当初、同社はWindows XP向けに独自のドライバを開発しましたが、これは自社製デバイスとの通信に限定されており、このドライバを使用してPCとMacコンピュータを接続することはできませんでした。Windows用のrtpMIDIドライバが利用可能になった2012年、このドライバのサポートは終了し、標準的な方法に切り替えられました。

Kiss-Boxは2012年に、セッション開始機能をサポートする新世代CPUボード「V3」を発表しました。これらのモデルは、制御点としてコンピュータを必要とせずに、他のRTP-MIDIデバイスとのセッションを確立することができます。

2013年のNAMMショーで、カナダのiConnectivity社は、RTP-MIDIをサポートし、USBデバイスとRTP-MIDIデバイス間の直接ブリッジ接続を可能にする新しいインターフェース「iConnectivityMIDI4+」を発表しました。その後、同社はmio4、mio10、PlayAUDIO 12など、RTP-MIDIに対応した他のインターフェースもいくつか発表しています。

Tobias Erichsen は 2010 年に Apple の RTP-MIDI ドライバの Windows 実装をリリースしました。^{[ 7 ]}このドライバは、 XP、Vista、Windows 7、Windows 8、Windows 10 の32 ビット版と 64 ビット版で動作します。^{[ 8 ]}このドライバは Apple のものと非常によく似た構成パネルを使用し、Apple の実装に完全に準拠しています。そのため、Windows マシンを Macintosh コンピュータだけでなく組み込みシステムにも接続するために使用できます。Apple のドライバと同様に、Windows ドライバは仮想 MIDI ポートを作成し、PC 上で実行されている任意の MIDI アプリケーションから見えるようになります。アクセスは、他のすべての MIDI ポートと同様に mmsystem レイヤーを介して行われます。

Linuxの RTP-MIDI サポートは、休止期間を経て 2013 年 2 月に再開されました。Nicolas Falquet と Dominique Fober のオリジナル作品に基づいて、いくつかのフォーラムでドライバが利用可能になったことが発表されています。^{[ 9 ] [ 10 ]}

Raspberry PIコンピュータ向けの特定の (ただし不完全な) 実装も利用可能で、raveloxmidi と呼ばれています。^{[ 11 ]}完全な実装については、後述の rtpmidid を参照してください。

RTP-MIDIの完全な実装（ジャーナリングシステムを含む）は、Ubuntuディストリビューション内のScenicソフトウェアパッケージで利用可能です。^{[ 12 ]}

ALSAシーケンサーとシームレスに統合された新しい実装rtpmidid ^{[ 13 ]}があり、 QjackCtlなどのツールを使用して接続を制御できます。この実装はARM64でも利用可能で、Raspberry Piコンピュータでも動作します。

Appleは2010年にiOSデバイスにCoreMIDIのフルサポートを追加し、iPhone、iPad、iPod向けのMIDIアプリケーション開発を可能にした。その後、USBコントローラとしてドッキングポートからMIDIが利用可能になり、「Apple Camera Kit」を使用してUSB MIDIデバイスを接続できるようになった。また、Wi-Fi経由でRTP-MIDIセッションリスナーとしても利用可能になった。

iOS デバイスはセッション開始機能をサポートしていないため、iPad との RTP-MIDI セッションを開くには、ネットワーク上の外部セッション開始装置を使用する必要があります。このセッション開始装置は、RTP-MIDI ドライバが有効になっている Mac コンピュータまたは Windows コンピュータ、あるいは組み込みの RTP-MIDI デバイスです。RTP-MIDI セッションは、iOS 上のすべての CoreMIDI アプリケーションで「ネットワーク MIDI」という名前で表示されるため、iOS アプリケーションに RTP-MIDI サポートを追加するための特別な開発は必要ありません。MIDI ポートは CoreMIDI によって仮想化されるため、プログラマはポートが USB に接続されているか RTP-MIDI に接続されているかに関わらず、MIDI 接続を開くだけで済みます。

iOS デバイスで USB 経由の MIDI を使用する際に、iPad/iPhone が外部デバイスに電源を供給する必要があるため、いくつかの苦情が発生しました。 ^{[ 14 ]}一部の USB MIDI アダプタは iPad に対して消費電流が大きすぎるため、電流が制限され、デバイスの起動がブロックされ、アプリケーションからデバイスが利用できない状態になります。この問題は RTP-MIDI を使用することで回避できます。

2013年6月以降、 J.Dachteraによって作成されたRTP-MIDIのJavaScript実装がオープンソースプロジェクトとして利用可能になっている。^{[ 15 ]}ソースコードはAppleのセッション管理プロトコルに基づいており、セッション開始者およびセッションリスナーとして機能できる。

特に「nmj」ライブラリを使えば、クロスプラットフォームのJavaによるRTP-MIDIの実装が可能である。 ^{[ 16 ]}

WinRTP-MIDIプロジェクト^{[ 17 ]}は、 Windows RT上で動作するRTP-MIDIプロトコルスタックのオープンソース実装です。このコードは当初、Windowsのさまざまなバージョン間で移植できるように設計されていましたが、最新バージョンはWindowsストア向けアプリケーションの設計を簡素化するためにWinRT向けに最適化されています。

RTP-MIDIは、2013年11月に「AppleMIDIライブラリ」という名前でArduinoプラットフォーム向けに提供開始されました。 ^{[ 18 ]}このソフトウェアモジュールは、Intel Galileoなどのイーサネットアダプタを内蔵したArduinoモジュール、または「イーサネットシールド」上で動作させることができます。

KissBox社は、 SPIバスリンクを介して接続する外部通信プロセッサボードであるRTP-MIDI OEMモジュールを製造しています。

2013年12月、MIDIbox DIYグループの2人のメンバーが、高速SPIリンクを介したRTP-MIDIサポートを含むMIOS（MIDIboxオペレーティングシステム）の初期バージョンの開発に着手しました。統合を簡素化するために、プロトコルスタック全体を処理する外部ネットワークプロセッサボードを使用することが決定されました。最初のベータ版は2014年1月の第2週にリリースされました。^{[ 19 ]}最初の公式ソフトウェアは2014年3月の第1週にリリースされました。

MIOSプロセッサとネットワークプロセッサ間のSPIリンクで使用されるプロトコルは、USBと同じフォーマットに基づいており、完全なMIDIメッセージを含む32ビットワードを使用し、ネットワークプロセッサモジュールとMIDIアプリケーションボード間の通信のためのオープンスタンダードとして提案されている。

Axoloti は、STM32F427 ARM プロセッサをベースにしたオープンソースのハードウェアシンセサイザーです。このシンセサイザーは、 Max/MSPと同様の仮想パッチの概念を使用して完全にプログラム可能で、完全な MIDI サポートが含まれています。Axolotiを任意の RTP-MIDI デバイスと RTP-MIDI 接続できるように、node.js拡張機能が開発されています。 ^{[ 20 ]} Axoloti ハードウェアには、Axoloti コアの拡張ポートで使用可能な SPI バスを介して接続される RTP-MIDI 外部コプロセッサを搭載することもできます。このアプローチは、Arduino および MIDIbox で説明したものと同じです。

MIDIKit は、市場で入手可能なさまざまな MIDI API (Core MIDI、Windows MME、Linux ALSA など) に対して統一された MIDI API を提供するオープンソースのクロスプラットフォームライブラリです。MIDIKit は、ジャーナリング システムを含む RTP-MIDI プロトコルをサポートしています。RTP-MIDI ポートは、MIDIKit 内で補完的なポート (rtpMIDI ドライバに依存しない) として認識され、ネイティブ システム MIDI ポートに追加されます^{[ 21 ]}

RTP-MIDIはUDP/IPをベースとしているため、ドライバを必要とせずに、あらゆるアプリケーションがプロトコルを直接実装できます。ドライバが必要となるのは、ネットワーク接続されたMIDIポートを標準MIDIポートとして認識させたい場合のみです。例えば、Max/MSPオブジェクトやVSTプラグインの中には、この手法に基づいて開発されたものがあります。

AVB は、イーサネット ネットワーク上で極めて低遅延のストリーミング サービスの仕様を定義する一連の技術標準です。AVB ネットワークは、ネットワーク全体で 1 オーディオ サンプルまでの遅延を提供できます。RTP -MIDI は、他の IP プロトコルと同様に、AVB ネットワークとネイティブに互換性があります。これは、AVB スイッチ (「IEEE802.1 スイッチ」とも呼ばれる) が、リアルタイムのオーディオ/ビデオ ストリームと IP トラフィックの優先順位を自動的に管理するためです。デバイスがIEEE-1733 文書に記載されているRTCPペイロードを実装している場合、RTP-MIDI プロトコルは AVB のリアルタイム機能を使用することもできます。 ^{[ 22 ]} RTP-MIDI アプリケーションは、IEEE-802.1 マスター クロックによって提供される「プレゼンテーション」タイムスタンプを RTP タイムスタンプと関連付け、MIDI イベントのサンプル精度のタイム ディストリビューションを保証します。

RTP-MIDIセッションは、2つのRTP-MIDIデバイス間に仮想パスを作成する役割を担い、アプリケーション側からはMIDI IN / MIDI OUTペアとして認識されます。RFC 6295ではSIP（Session Initiation Protocol）とSDP（Session Description Protocol）の使用が提案されていますが、Appleは独自のセッション管理プロトコルを開発しました。Appleのプロトコルは、Bonjourで使用される名前でセッションをリンクし、クロック同期サービスも提供します。

セッションは常に2人（2人のみ）の間で作成され、各セッションは2人の参加者間のメッセージ損失の可能性を検出するために使用されます。ただし、1つのセッションコントローラは複数のセッションを並行して開くことができ、これにより分割、マージ、分散パッチベイなどの機能が実現します。ここに示した図では、デバイス1はデバイス2とのセッションとデバイス3とのセッションの2つを同時に開いていますが、デバイス1の2つのセッションは最終ユーザーには同じ仮想MIDIインターフェースとして表示されます。

よくある間違いとして、RTP-MIDIエンドポイントとRTP-MIDIセッションの不一致が挙げられます。どちらもMIDI IN/MIDI OUTポートのペアを表しているためです。

エンドポイントは、RTP-MIDIトランスポートプロトコルのデコードを担当する要素（ソフトウェアおよび/またはハードウェア）とMIDIメッセージを使用する要素との間でMIDIデータを交換するために使用されます。言い換えれば、エンドポイントレベルではMIDIデータのみが表示されます。MIDI 1.0 DINコネクタを備えたデバイスの場合、コネクタペアごとに1つのエンドポイントがあります。たとえば、KissBox MIDI2TRでは2つのエンドポイント、iConnectivityMIDI4+では4つのエンドポイントなどです。SPIやUSBなどの他の通信リンクを使用するデバイスは、より多くのエンドポイントを提供します。たとえば、USB MIDIクラスの32ビットエンコーディングを使用するデバイスは、ケーブル識別子フィールドを使用して最大16個のエンドポイントを表すことができます。エンドポイントは、AppleMIDIセッションプロトコルを使用する場合、RTP-MIDI側ではペアになったUDPポートによって表されます。

セッションは、2つのエンドポイント間の接続を定義します。一方のエンドポイントのMIDI INはリモートエンドポイントのMIDI OUTに接続され、その逆も同様です。ソフトウェア構成によっては、1つのエンドポイントが複数のセッションを受け入れることができます。特定のエンドポイントの各セッションは、リモートセッションハンドラからは単一のセッションとして認識されます。リモートセッションハンドラは、接続されているエンドポイントが同時に他のセッションで使用されているかどうかを知ることはできません。特定のエンドポイントに対して複数のセッションがアクティブになっている場合、エンドポイントに到達する異なるMIDIストリームは、MIDIデータがアプリケーションに送信される前にマージされます。逆方向では、アプリケーションによって生成されたMIDIデータは、エンドポイントに接続されているすべてのセッションハンドラに送信されます。

RTP-MIDIデバイスは、特別なコンポーネントを必要とせずに異なるMIDIストリームをマージできます。これは、「MIDIマージ装置」を必要とするMIDI 1.0デバイスとは対照的です。図に示すように、セッションコントローラが2つ以上のリモートセッションに接続されると、特別な設定を必要とせずに、リモートデバイスから送られてくるMIDIストリームが自動的にマージされます。

RTP-MIDIデバイスは、「MIDI THRU」サポートデバイスを必要とせずに、1つのセッションから任意の数のリモートセッションにMIDIストリームを複製できます。RTP-MIDIセッションが2つ以上のリモートセッションに接続されている場合、すべてのリモートセッションは、送信元から送信されたMIDIデータのコピーを受信します。

RTP-MIDIセッションでは、「パッチベイ」機能も利用できます。これはMIDI 1.0では専用のハードウェアデバイスを使用した場合にのみ可能でした。MIDI 1.0パッチベイは、一連のMIDI入力と一連のMIDI出力を動的に接続できるハードウェアデバイスで、多くの場合マトリックス形式で接続されます。「動的」接続という概念は、2つのデバイス間をケーブルで「静的」に接続する従来のMIDI 1.0ラインの使用方法とは対照的です。ケーブルの形でデバイス間のデータパスを確立するのではなく、パッチベイはすべてのMIDIデバイスが接続される中心的なポイントとなります。MIDIパッチベイのソフトウェアは、どのMIDI入力がどのMIDI出力に接続されるかを定義するように構成されており、ユーザーはMIDI DINケーブルを外すことなく、いつでもこの構成を変更できます。

RTP-MIDIでは、セッションの概念のおかげで、「パッチベイ」ハードウェアモジュールは不要になりました。セッションとは、定義上、2つのMIDIポート間でネットワーク上に確立される仮想パスです。設定プロセスによって、特定のMIDIデバイスによって生成される各MIDIストリームの宛先が正確に定義されるため、パッチベイ機能を実行するための特別なソフトウェアは必要ありません。各セッションの開始者が使用する宛先IPアドレスを変更するだけで、これらの仮想パスをいつでも変更できます。このようにして形成された「パッチ」構成は不揮発性メモリに保存して、セットアップの電源投入時にパッチを自動的に再構築できますが、RTP-MIDI ManagerソフトウェアツールやRTP-MIDIドライバのコントロールパネルなどを使用して、RAMレベルで直接変更することもできます。

セッションの開始は、招待シーケンスから始まります。最初のセッションパートナー（「セッション開始者」）は、2番目のパートナーの制御ポートにINメッセージを送信します。2番目のパートナーは、セッションの開始に同意する場合はOKメッセージを、招待を受け入れない場合はNOメッセージを送信して応答します。制御ポートで招待が受け入れられた場合、同じシーケンスがデータポートでも繰り返されます。両方のポートで招待が受け入れられると、ステートマシンは同期フェーズに入ります。

同期シーケンスにより、セッション参加者はそれぞれのローカルクロックに関する情報を共有できます。このフェーズでは、ネットワークによって発生する遅延を補償し、「将来のタイムスタンプ」をサポートすることが可能です（下記の「遅延」の項を参照）。

セッション開始側は、リモート パートナーに最初のメッセージ (CK0 と命名) を送信し、64 ビットでローカル タイムを示します (これは絶対時刻ではなく、ローカル リファレンスに関連付けられた時刻であり、通常はオペレーティングシステム カーネルの起動からのマイクロ秒単位で表されます)。この時刻は、10  kHz サンプリング クロック (100 マイクロ秒ごとに増分) を基準として表現されます。リモート パートナーは、このメッセージに 64 ビットでローカル タイムを含む CK1 メッセージで応答する必要があります。これにより、両方のパートナーはそれぞれのクロックの差を知ることができ、RTP-MIDI プロトコルのタイムスタンプ フィールドとデルタタイム フィールドに適用するオフセットを決定できます。

セッション開始者は、CK1メッセージを受信した際のローカル時刻を含むCK2という最後のメッセージを送信することで、この一連の処理を完了します。この手法により、ネットワークの平均遅延を計算できるだけでなく、Linux、Windows、OS Xなどの非リアルタイムオペレーティングシステムで発生する可能性のある、スレッドの起動の遅さによって生じる遅延を補償することも可能です。

Appleは、セッションを開いた直後にこの一連の処理を数回繰り返すことを推奨しています。これは、一時的なネットワークの過負荷やスレッドの起動時のレイテンシのピークによって、いずれかの処理が意図せず遅延した場合に、同期の精度を向上させるためです。

このシーケンスは、通常1分間に2～6回、セッション開始者によって周期的に繰り返される必要があります。これは、ローカルクロックのずれを補正して長期的な同期精度を維持するため、また通信相手の切断を検出するためです。複数のCK0メッセージに応答しない相手は、遠隔の相手が切断されたとみなします。ほとんどの場合、セッション開始者はステートマシンを「招待」状態に切り替え、遠隔の相手がネットワークに再接続するとすぐに自動的に通信を再確立します。一部の実装、特にパーソナルコンピュータでは、警告メッセージを表示し、新しい接続試行またはセッションの終了のいずれかをユーザーに選択させる場合もあります。

ジャーナリング機構により、MIDIメッセージの損失を検出でき、受信側は再送信することなく欠落したデータを生成できます。ジャーナルは、異なるセッションパートナーごとに異なる時点での「MIDIイメージ」をメモリに保持します。ただし、セッションパートナーが正しく受信したイベントに対応するジャーナリングデータをメモリに保持しておくことは無意味です。各パートナーは、正しく受信した最後のシーケンス番号を示すRSメッセージを、つまり2つのシーケンス番号の間にギャップがない状態で、他のパートナーに周期的に送信します。送信側は、必要に応じて古いジャーナリングデータを含むメモリを解放できます。

セッションパートナーはいつでもセッションからの退出を要求でき、相手側はそれに応じてセッションを閉じます。これはBYメッセージを使用して行われます。セッションパートナーがこのメッセージを受信すると、メッセージを送信したリモートパートナーとのセッションを直ちに閉じ、このセッションに割り当てられていたすべてのリソースを解放します。このメッセージは、セッション開始者またはセッションリスナー（「招待された」パートナー）によって送信できます。^{[ 23 ]}

MIDIタスクはほとんどの場合リアルタイムタスクであるため、アプリケーション処理時間は一般的に厳密に制御されます。多くの場合、レイテンシはスレッドレイテンシに直接起因し、これは特定のオペレーティングシステムで実現可能であり、WindowsおよびMac OSシステムでは通常最大1～2ミリ秒です。リアルタイムカーネルを備えたシステムでは、100マイクロ秒まで大幅に改善できます。処理スレッドは通信関連のスレッド/タスクとは異なるレベルで動作するため、この時間は通信チャネル（MIDI 1.0、USB、RTP-MIDIなど）に関係なく一定とみなすことができます。

IPスタックの処理時間は、通信プロセスがオペレーティングシステムの制御下にあるため、最も重要な要素です。これは、IP関連かどうかにかかわらず、あらゆる通信プロトコルに当てはまります。Windows、Mac OS、Linuxなどのほとんどのオペレーティングシステムでは、イーサネットアダプタへの直接アクセスが許可されていないためです。特によくある間違いは、「rawソケット」と「ネットワークへの直接アクセス」を混同することです。ソケットは、ほとんどのオペレーティングシステムでネットワーク経由でデータを送受信するためのエントリポイントです。「rawソケット」とは、アプリケーションが任意のプロトコルを使用して任意のパケットを送信できるソケットです。アプリケーションは、指定されたプロトコル規則に従ってテレグラムを構築する責任がありますが、「直接アクセス」では、オペレーティングシステムカーネルに制限されたシステムレベルのアクセスが必要になります。rawソケットを使用して送信されたパケットは、ネットワークアダプタが現在別のアプリケーションによって使用されている場合、オペレーティングシステムによって遅延される可能性があります。したがって、IPパケットは、rawソケットに関連するパケットよりも先にネットワークに送信される可能性があります。技術的には、特定のネットワークカードへのアクセスは「セマフォ」によって制御されます。^{[ 26 ]}

IPスタックは、ARPと呼ばれる特定のプロトコルを使用して、イーサネットアドレス（MACアドレス）とIPアドレスを関連付ける必要があります。RTP-MIDIアプリケーションがリモートデバイスにパケットを送信する場合、イーサネットはIP関連の概念を理解しないため、ルーター/スイッチ間の伝送パスを確立するために、まずネットワーク上でそのデバイスを特定する必要があります。これは、IPスタックが最初にARP（アドレス認識プロトコル）要求を送信することで自動的に行われます。宛先デバイスがARPパケット内の自身のIPアドレスを認識すると、MACアドレスを含むARP応答を返信します。その後、IPスタックはRTP-MIDIパケットを送信できます。リンクが数分間非アクティブになり、送信側のルーティングテーブルのARPエントリがクリアされない限り、次のRTP-MIDIパケットではARPシーケンスは不要になります。

このARPシーケンスには数秒かかる場合があり、その結果、少なくとも最初のRTP-MIDIパケットでは顕著な遅延が発生する可能性があります。しかし、Appleの実装では、セッション制御プロトコルを使用することでこの問題を巧みに解決しています。セッションプロトコルは、RTP-MIDIプロトコル自体と同じポートを使用します。ARPシーケンスは、セッション開始シーケンス中に実行されます。RTP-MIDIアプリケーションが最初のRTP-MIDIパケットを送信しようとすると、コンピュータのルーティングテーブルは既に正しい宛先MACアドレスで初期化されているため、最初のパケットの遅延は発生しません。

ARPシーケンスに加えて、IPスタック自体も、IPヘッダー、UDPヘッダー、RTPヘッダーなどのパケットヘッダーを準備するための計算を必要とします。最新のプロセッサでは、この準備は非常に高速で、わずか数マイクロ秒しかかかりません。これは、アプリケーションのレイテンシ自体と比較すると無視できるほど小さい時間です。前述のように、RTP-MIDIパケットは、準備が完了すると、ネットワークアダプタが既に別のパケットを送信している場合にのみ、ネットワークアダプタに到達しようとしたときに遅延する可能性があります。これは、ソケットがIPソケットか「raw」ソケットかに関わらず発生します。ただし、ネットワークアダプタを担当するドライバスレッドの優先度が非常に高いため、このレベルで発生するレイテンシは一般的に非常に低くなっています。さらに、ほとんどのネットワークアダプタはハードウェアレベルでFIFOバッファを備えているため、ドライバスレッドを最初に実行する必要なく、パケットをネットワークアダプタ自体に格納してすぐに送信できます。「アダプタアクセス競合」に関連するレイテンシをできるだけ低く抑える方法の1つは、ネットワークアダプタをMIDI通信専用に予約し、ファイル共有やインターネットブラウジングなどの他のネットワーク用途には別のネットワークアダプタを使用することです。

コンピュータ間でイーサネットパケットを伝送するために使用されるさまざまなコンポーネントは、使用されるプロトコルに関係なく、遅延を引き起こします。最新のネットワークスイッチはすべて「ストアアンドフォワード」技術を使用しており、パケットは次のスイッチに送信される前にスイッチに保存されます。ただし、スイッチング時間はほとんどの場合無視できるほど小さいです。たとえば、100  Mbit/s ネットワーク上の 64 バイトのパケットは、各ネットワークスイッチによって転送されるのに約 5.1 マイクロ秒かかります。特定のパス上に 10 台のスイッチがある複雑なネットワークでは、遅延は 51 マイクロ秒になります。

しかし、遅延はネットワーク負荷そのものに直接関係しています。スイッチは前のパケットが送信されるまで次のパケットを遅延させるためです。ネットワークコンポーネントによって生じる実際の遅延を計算/測定することは困難な作業となる場合があり、代表的なユースケースが必要になります。例えば、同じネットワークスイッチに接続された2つのネットワークデバイス間の遅延を測定すれば、常に優れた結果が得られます。前のセクションで述べたように、ネットワークコンポーネントによって生じる遅延を制限する1つの解決策は、別々のネットワークを使用することです。ただし、これはコンピュータのネットワークアダプタの場合よりも、ネットワークコンポーネントの場合の方がはるかに重要ではありません。

ご覧のとおり、RTP-MIDIリンクで得られる正確なレイテンシは多くのパラメータに依存し、そのほとんどはオペレーティングシステム自体に関連しています。さまざまなRTP-MIDIアクターによる測定では、リアルタイムオペレーティングシステムを使用する組み込みシステムでは数百マイクロ秒から、汎用オペレーティングシステムを実行するコンピュータでは最大3ミリ秒までのレイテンシ時間が得られています。

AESは、超低遅延アプリケーション向けにIPネットワークでRTPペイロードを使用する能力を実証するために、2010年にSC-02-12H ^{[ 27 ]}というワーキンググループを立ち上げました。2013年5月に同グループが発表したドラフト提案では、125マイクロ秒という低遅延値でライブアプリケーション向けのRTPストリーミングを実現できることが実証されています。