RFC4696 日本語訳
4696 An Implementation Guide for RTP MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT=83827 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lazzaro
Request for Comments: 4696 J. Wawrzynek
Category: Informational UC Berkeley
November 2006
Lazzaroがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4696年のJ.Wawrzynekカテゴリ: 情報のUCバークレー2006年11月
An Implementation Guide for RTP MIDI
RTPミディのための実現ガイド
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This memo offers non-normative implementation guidance for the Real- time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications.
このメモはレアル時間プロトコル(RTP)MIDI(ミディ)ペイロード形式のために非標準の実施要項を提供します。 メモはネットワーク演奏アプリケーションの文脈におけるアドバイスを提示します。 このアプリケーションでは、異なった物理的な位置に位置する2人のミュージシャンが同じ部屋に位置しているなら相互作用するように実行するネットワークの上に相互作用します。 基礎となって、性能はユニキャストUDPの上のRTP MIDIセッションです。 送受信回復ジャーナル(ペイロード形式のための弾性構造)のためのアルゴリズムは詳細に説明されます。 メモはネットワーク演奏に焦点を合わせますが、提示された実現アドバイスは他のRTP MIDIアプリケーションに関連しています。
Lazzaro & Wawrzynek Informational [Page 1] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[1ページ]のRFC4696
Table of Contents
目次
1. Introduction ....................................................2
2. Starting the Session ............................................3
3. Session Management: Session Housekeeping ........................6
4. Sending Streams: General Considerations .........................7
4.1. Queuing and Coding Incoming MIDI Data .....................11
4.2. Sending Packets with Empty MIDI Lists .....................12
4.3. Congestion Control and Bandwidth Management ...............13
5. Sending Streams: The Recovery Journal ..........................14
5.1. Initializing the RJSS .....................................16
5.2. Traversing the RJSS .......................................19
5.3. Updating the RJSS .........................................19
5.4. Trimming the RJSS .........................................20
5.5. Implementation Notes ......................................21
6. Receiving Streams: General Considerations ......................21
6.1 The NMP Receiver Design ....................................22
6.2 High-Jitter Networks, Local Area Networks ..................24
7. Receiving Streams: The Recovery Journal ........................25
7.1. Chapter W: MIDI Pitch Wheel (0xE) .........................30
7.2. Chapter N: MIDI NoteOn (0x8) and NoteOff (0x9) ............30
7.3. Chapter C: MIDI Control Change (0xB) ......................32
7.4. Chapter P: MIDI Program Change (0xC) ......................34
8. Security Considerations ........................................35
9. IANA Considerations ............................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................36
1. 序論…2 2. セッションを始めます…3 3. セッション管理: セッション家事…6 4. 発信は流れます: 一般問題…7 4.1. 入って来るミディデータを列に並ばせて、コード化します…11 4.2. 空のミディがあるパケットを送るのは記載します…12 4.3. 輻輳制御と帯域幅管理…13 5. 発信は流れます: 回復ジャーナル…14 5.1. RJSSを初期化します…16 5.2. RJSSを横断します…19 5.3. RJSSをアップデートします…19 5.4. RJSSを整えます…20 5.5. 実現注意…21 6. 受信は流れます: 一般問題…21 6.1 NMP受信機デザイン…6.2の高いジターがネットワークでつなぐ22、ローカル・エリア・ネットワーク…24 7. 受信は流れます: 回復ジャーナル…25 7.1. 章W: ミディ大歯車(0xE)…30 7.2. 第N章: ミディNoteOn(0×8)とNoteOff(0×9)…30 7.3. 章C: ミディコントロール変化(0xB)…32 7.4. 章P: ミディプログラム変化(0xC)…34 8. セキュリティ問題…35 9. IANA問題…35 10. 承認…35 11. 参照…35 11.1. 標準の参照…35 11.2. 有益な参照…36
1. Introduction
1. 序論
[RFC4695] normatively defines a Real-time Transport Protocol (RTP, [RFC3550]) payload format for the MIDI (Musical Instrument Digital Interface) command language [MIDI], for use under any applicable RTP profile, such as the Audio/Visual Profile (AVP, [RFC3551]).
[RFC4695]標準はMIDI(ミディ)コマンド言語[MIDI]のためにレアル-時間Transportプロトコル(RTP、[RFC3550])ペイロード書式を定義します、どんな適切なRTPプロフィールの下の使用のために、Audio/視覚のProfile(AVP、[RFC3551])などのように。
However, [RFC4695] does not define algorithms for sending and receiving MIDI streams. Implementors are free to use any sending or receiving algorithm that conforms to the normative text in [RFC4695], [RFC3550], [RFC3551], and [MIDI].
しかしながら、[RFC4695]は送受信MIDIの流れのためのアルゴリズムを定義しません。作成者は自由に[RFC4695]、[RFC3550]、[RFC3551]、および[MIDI]の標準のテキストに従うどんな送付や受信アルゴリズムも使用できます。
In this memo, we offer implementation guidance on sending and receiving MIDI RTP streams. Unlike [RFC4695], this memo is not normative.
このメモでは、私たちは送受信MIDI RTPの流れのときに実施要項を提供します。[RFC4695]と異なって、このメモは規範的ではありません。
Lazzaro & Wawrzynek Informational [Page 2] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[2ページ]のRFC4696
RTP is a mature protocol, and excellent RTP reference materials are available [RTPBOOK]. This memo aims to complement the existing literature by focusing on issues that are specific to the MIDI payload format.
RTPは熟しているプロトコルです、そして、素晴らしいRTP参照の材料は利用可能です[RTPBOOK]。 このメモは、MIDIペイロード形式に特定の問題に焦点を合わせることによって既存文献の補足となることを目指します。
The memo focuses on one application: two-party network musical performance over wide-area networks, following the interoperability guidelines in Appendix C.7.2 of [RFC4695]. Underlying the performances are RTP MIDI sessions over unicast UDP transport. Resiliency is provided by the recovery journal system [RFC4695]. The application also uses the RTP Control Protocol (RTCP, [RFC3550]).
メモは1つのアプリケーションに焦点を合わせます: [RFC4695]のAppendix C.7.2の相互運用性ガイドラインに従って、2パーティーが広域ネットワークの上の演奏をネットワークでつなぎます。 性能の基礎となるのは、ユニキャストUDP輸送の上のRTP MIDIセッションです。 回復ジャーナルシステム[RFC4695]で弾性を提供します。 また、アプリケーションはRTP Controlプロトコル(RTCP、[RFC3550])を使用します。
The application targets a network with a particular set of characteristics: low nominal jitter, low packet loss, and occasional outlier packets that arrive very late. However, in Section 6.2 of this memo, we discuss adapting the application to other network environments.
アプリケーションは特定のセットの特性でネットワークを狙います: 非常に遅く到着する低い名目上のジター、低いパケット損失、および時々のアウトライアーパケット。 しかしながら、このメモのセクション6.2では、私たちは、他のネットワーク環境にアプリケーションを翻案するのを議論します。
As defined in [NMP], a network musical performance occurs when musicians located at different physical locations interact over a network to perform as they would if located in the same room.
[NMP]で定義されるように、異なった物理的な位置に位置するミュージシャンが同じ部屋に位置しているなら相互作用するように実行するネットワークの上に相互作用すると、ネットワーク演奏は起こります。
Sections 2-3 of this memo describe session startup and maintenance. Sections 4-5 cover sending MIDI streams, and Sections 6-7 cover receiving MIDI streams.
このメモのセクション2-3はセッション始動と維持について説明します。 セクション4-5は、MIDIの流れを受けながら、MIDI流れ、およびセクション6-7が覆う発信を覆います。
2. Starting the Session
2. セッションを始めます。
In this section, we describe how the application starts a two-player session. We assume that the two parties have agreed on a session configuration, embodied by a pair of Session Description Protocol (SDP, [RFC4566]) session descriptions.
このセクションで、私たちはアプリケーションがどう2プレーヤーのセッションを始めるかを説明します。 私たちは、2回のパーティーが1組のSession記述プロトコル(SDP、[RFC4566])セッション記述で具体化されたセッション構成に同意したと思います。
One session description (Figure 1) defines how the first party wishes to receive its stream. The other session description (Figure 2) defines how the second party wishes to receive its stream.
1つのセッション記述(図1)が最初のパーティーがどう流れを受けたがっているかを定義します。 もう片方のセッション記述(図2)は2番目のパーティーがどう流れを受けたがっているかを定義します。
The session description in Figure 1 codes that the first party intends to receive a MIDI stream on IP4 number 192.0.2.94 (coded in the c= line) at UDP port 16112 (coded in the m= line). Implicit in the SDP m= line syntax [RFC4566] is that the first party also intends to receive an RTCP stream on 192.0.2.94 at UDP port 16113 (16112 + 1). The receiver expects that the PT field of each RTP header in the received stream will be set to 96 (coded in the m= line).
最初のパーティーがUDPポート16112(m=線では、コード化されます)のIP4No.192.0.2.94(c=線では、コード化される)におけるMIDIの流れを受けるつもりである図1コードにおけるセッション記述。 線SDP m=構文[RFC4566]で暗黙であることは、また、最初のパーティーが192.0におけるRTCPの流れを受けるつもりであるということです。.2 .94 UDPに、16113(16112+1)を移植してください。 受信機は、容認された流れにおけるそれぞれのRTPヘッダーのPT分野が96に設定される(m=線では、コード化される)と予想します。
Likewise, the session description in Figure 2 codes that the second party intends to receive a MIDI stream on IP4 number 192.0.2.105 at UDP port 5004 and intends to receive an RTCP stream on 192.0.2.105 at
同様に、図2におけるセッション記述がパーティーがIP4番号におけるMIDIの流れを受けるつもりである秒にそれをコード化する、192.0、.2、.105、5004をUDPに移植して、192.0におけるRTCPの流れを受けるつもりである、.2、.105
Lazzaro & Wawrzynek Informational [Page 3] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[3ページ]のRFC4696
UDP port 5005 (5004 + 1). The second party expects that the PT RTP header field of received stream will be set to 101.
UDPは5005(5004+1)を移植します。 2番目のパーティーは、容認された流れのPT RTPヘッダーフィールドが101に設定されると予想します。
v=0 o=first 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 c=IN IP4 192.0.2.94 m=audio 16112 RTP/AVP 96 b=AS:20 b=RS:0 b=RR:400 a=rtpmap:96 mpeg4-generic/44100 a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABFGHJKMQTVXYZ; cm_unused=C120-127; ch_never=ADEFMQTVX; tsmode=buffer; linerate=320000; octpos=last; mperiod=44; rtp_ptime=0; rtp_maxptime=0; guardtime=44100; render=synthetic; rinit="audio/asc"; url="http://example.net/sa.asc"; cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
v=0oが0 0c=最初に、IN IP4 2520644554 2838152170の最初の.example.net s=例t=IN IP4と等しい、192.0、.2、.94m、16112=オーディオのRTP/AVP96b=AS: 20b=RS: 0 b=RR: 400 a=rtpmap: 96 mpeg4-ジェネリック/44100a=fmtp: 96streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABFGHJKMQTVXYZ。 _cm未使用の=C120-127。 ch_はADEFMQTVXと決して等しくはありません。 tsmodeはバッファと等しいです。 linerate=320000。 octpos=はもちます。 mperiod=44。 rtp_ptime=0。 rtp_maxptime=0。 guardtime=44100。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 urlは" http://example.net/sa.asc "と等しいです。 Cidは"xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"と等しいです。
(The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it constitutes a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp線を包装してあります; それはSDPの単線を構成します。)
Figure 1. Session description for first participant
図1。 最初の関係者のためのセッション記述
v=0 o=second 2520644554 2838152170 IN IP4 second.example.net s=Example t=0 0 c=IN IP4 192.0.2.105 m=audio 5004 RTP/AVP 101 b=AS:20 b=RS:0 b=RR:400 a=rtpmap:101 mpeg4-generic/44100 a=fmtp:101 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; cm_unused=ABFGHJKMQTVXYZ; cm_unused=C120-127; ch_never=ADEFMQTVX; tsmode=buffer; linerate=320000;octpos=last;mperiod=44; guardtime=44100; rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit="audio/asc"; url="http://example.net/sa.asc"; cid="xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"
2番目の2520644554 2838152170のIN IP4 2番目のv=0o=.example.net s=例tが0 0c=IN IP4と等しい、192.0、.2、.105m、5004=オーディオのRTP/AVP101b=AS: 20b=RS: 0 b=RR: 400 a=rtpmap: 101 mpeg4-ジェネリック/44100a=fmtp: 101streamtype=5。 モードはrtp-ミディと等しいです。 「コンフィグは等しい」、」、。 プロフィール平らなイドの=12。 _cm未使用の=ABFGHJKMQTVXYZ。 _cm未使用の=C120-127。 ch_はADEFMQTVXと決して等しくはありません。 tsmodeはバッファと等しいです。 linerate=320000; octpos=はもちます; mperiod=44 guardtime=44100。 rtp_ptime=0。 rtp_maxptime=0。 =を合成するようにしてください。 rinitは「オーディオ/asc」と等しいです。 urlは" http://example.net/sa.asc "と等しいです。 Cidは"xjflsoeiurvpa09itnvlduihgnvet98pa3w9utnuighbuk"と等しいです。
(The a=fmtp line has been wrapped to fit the page to accommodate
memo formatting restrictions; it constitutes a single line in SDP.)
(メモ形式制限に対応するためにページに合うようにa=fmtp線を包装してあります; それはSDPの単線を構成します。)
Figure 2. Session description for second participant
図2。 2番目の関係者のためのセッション記述
Lazzaro & Wawrzynek Informational [Page 4] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[4ページ]のRFC4696
The session descriptions use the mpeg4-generic media type (coded in the a=rtpmap line) to specify the use of the MPEG 4 Structured Audio renderer [MPEGSA]. The session descriptions also use parameters to customize the stream (Appendix C of [RFC4695]). The parameter values are identical for both parties, yielding identical rendering environments for the two client hosts.
セッション記述は、MPEG4Structured Audioレンダラー[MPEGSA]の使用を指定するのに、mpeg4-ジェネリックメディアタイプ(a=rtpmap線では、コード化される)を使用します。 また、セッション記述は、流れ([RFC4695]の付録C)をカスタマイズするのにパラメタを使用します。 双方にとって、2人のクライアントホストのための同じ表現環境をもたらして、パラメタ値は同じです。
The bandwidth (b=) AS parameter [RFC4566] [RFC3550] indicates that the total RTP session bandwidth is 20 kbs. This value assumes that the two players send 10 kbs streams concurrently. To derive the 10 kbs value, we begin with the analysis of RTP MIDI payload bandwidth in Appendix A.4 of [NMP] and add in RTP and IP4 packet overhead and a small safety factor.
帯域幅(b=)ASパラメタ[RFC4566][RFC3550]は、総RTPセッション帯域幅が20kbsであることを示します。 この値は、2人のプレーヤーが同時に10のkbsの流れを送ると仮定します。 私たちは、10kbs価値を引き出すために、RTP MIDIの分析で[NMP]のAppendix A.4のペイロード帯域幅を始めて、RTP、IP4パケットオーバーヘッド、および小さいセーフティ・ファクターを加えます。
The bandwidth RR parameter [RFC3556] indicates that the shared RTCP session bandwidth for the two parties is 400 bps. We set the bandwidth SR parameter to 0 bps, to signal that sending parties and non-sending parties equally share the 400 bps of RTCP bandwidth. (Note that in this particular example, the guardtime parameter value of 44100 ensures that both parties are sending for the duration of the session.) The 400 bps RTCP bandwidth value supports one RTCP packet per 5 seconds from each party, containing a Sender Report and CNAME information [RFC3550].
帯域幅RRパラメタ[RFC3556]は、2回のパーティーのための共有されたRTCPセッション帯域幅が400ビーピーエスであることを示します。 私たちは、送付パーティーと非発信パーティーが等しくRTCP帯域幅の400ビーピーエスを共有すると合図するために帯域幅SRパラメタを0ビーピーエスに設定します。 (この特定の例では、44100のguardtimeパラメタ価値が、双方がセッションの持続時間のために発信するのを確実にすることに注意してください。) 400ビーピーエスRTCP帯域幅価値は各当事者から5秒あたり1つのRTCPパケットを支持します、Sender ReportとCNAME情報[RFC3550]を含んでいて。
We now show an example of code that implements the actions the parties take during the session. The code is written in C and uses the standard network programming techniques described in [STEVENS]. We show code for the first party (the second party takes a symmetric set of actions).
私たちは、現在、セッションの間、動作を実行するコードではパーティーが取るのを例に示します。 コードは、[スティーブンス]で説明されたテクニックをプログラムしながら、Cに書かれていて、標準のネットワークを使用します。 私たちは最初のパーティーのためにコードを示しています(2番目のパーティーは左右対称の行動を取ります)。
Figure 3 shows how the first party initializes a pair of socket descriptors (rtp_fd and rtcp_fd) to send and receive UDP packets. After the code in Figure 3 runs, the first party may check for new RTP or RTCP packets by calling recv() on rtp_fd or rtcp_fd.
図3は最初のパーティーがUDPパケットを送って、受けるために、どう、1組のソケット記述子(rtp_fdとrtcp_fd)を初期化するかを示しています。 図3のコードが走った後に、rtp_fdやrtcp_の上のrecv()をfdと呼ぶことによって、最初のパーティーは新しいRTPやRTCPパケットがないかどうかチェックするかもしれません。
Applications may use recv() to receive UDP packets on a socket using one of two general methods: "blocking" or "non-blocking".
アプリケーションはソケットの上に2つの一般的な方法の1つを使用することでUDPパケットを受けるのにrecv()を使用するかもしれません: 「ブロッキング」か「非ブロッキング。」
A call to recv() on a blocking UDP socket puts the calling thread to sleep until a new packet arrives.
新しいパケットが到着するまで、ブロッキングUDPソケットの上のrecv()への呼び出しは呼ぶ糸を寝かします。
A call to recv() on a non-blocking socket acts to poll the device: the recv() call returns immediately, with a return value that indicates the polling result. In this case, a positive return value signals the size of a new received packet, and a negative return value (coupled with an errno value of EAGAIN) indicates that no new packet was available.
非ブロッキングソケットの上のrecv()への呼び出しは装置に投票するために行動します: recv()呼び出しはすぐに、世論調査結果を示すリターン値と共に戻ります。 この場合、上向きのリターン値は新しい容認されたパケットのサイズを示します、そして、否定的リターン値(EAGAINのerrno値に結合する)はどんな新しいパケットも利用可能でなかったのを示します。
Lazzaro & Wawrzynek Informational [Page 5] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[5ページ]のRFC4696
The choice of blocking or non-blocking sockets is a critical application choice. Blocking sockets offer the lowest potential latency (as the OS wakes the caller as soon as a packet has arrived). However, audio applications that use blocking sockets must adopt a multi-threaded program architecture, so that audio samples may be generated on a "rendering thread" while the "network thread" sleeps, awaiting the next packet. The architecture must also support a thread communication mechanism, so that the network thread has a mechanism to send MIDI commands the rendering thread.
ブロッキングか非ブロッキングソケットの選択は批判的なアプリケーション選択です。 ブロッキングソケットは最も低い潜在的潜在を提供します(パケットが到着するとすぐに、OSが訪問者を起こすので)。 しかしながら、ブロッキングソケットを使用するオーディオアプリケーションはマルチスレッド化されたプログラム構造を採用しなければなりません、「ネットワーク糸」が眠っている間、オーディオのサンプルが「表現糸」で発生できるように、次のパケットを待って。 また、構造は糸のコミュニケーションメカニズムをサポートしなければなりません、ネットワーク糸には表現糸をMIDIコマンドに送るメカニズムがあるように。
In contrast, audio applications that use non-blocking sockets may be coded using a single thread, that alternates between audio sample generation and network polling. This architecture trades off increased network latency (as a packet may arrive between polls) for a simpler program architecture. For simplicity, our example uses non-blocking sockets and presumes a single run loop. Figure 4 shows how the example configures its sockets to be non-blocking.
対照的に、非ブロッキングソケットを使用するオーディオアプリケーションはシングルスレッドを使用することでコード化されるかもしれなくて、それはオーディオサンプル世代とネットワーク世論調査の間を行き来します。 この構造は、より簡単なプログラム構造のために、増加するネットワーク潜在(パケットが投票の間で到着するかもしれないので)を交換します。 簡単さのために、私たちの例は、非ブロッキングソケットを使用して、ただ一つの走行輪を推定します。 例が、ソケットが非ブロッキングであることをどう構成するかを図4は示しています。
Figure 5 shows how to use recv() to check a non-blocking socket for new packets.
図5は、新しいパケットがないかどうか非ブロッキングソケットをチェックするのにどのようにrecv()を使用するかを示します。
The first party also uses rtp_fd and rtcp_fd to send RTP and RTCP packets to the second party. In Figure 6, we show how to initialize socket structures that address the second party. In Figure 7, we show how to use one of these structures in a sendto() call to send an RTP packet to the second party.
また、最初のパーティーは、2番目のパーティーへのパケットをRTPとRTCPに送るのにrtp_fdとrtcp_fdを使用します。 図6では、私たちは、どのように2番目のパーティーに演説するソケット構造を初期化するかを示します。 図7では、私たちは、2番目のパーティーにRTPパケットを送るというsendto()要求にどのようにこれらの構造の1つを使用するかを示します。
Note that the code shown in Figures 3-7 assumes a clear network path between the participants. The code may not work if firewalls or Network Address Translation (NAT) devices are present in the network path.
図3-7に示されたコードが関係者の間の明確なネットワーク経路を仮定することに注意してください。 ファイアウォールかNetwork Address Translation(NAT)装置がネットワーク経路に存在しているなら、コードは働かないかもしれません。
3. Session Management: Session Housekeeping
3. セッション管理: セッション家事
After the two-party interactive session is set up, the parties begin to send and receive RTP packets. In Sections 4-7, we discuss RTP MIDI sending and receiving algorithms. In this section, we describe session "housekeeping" tasks that the participants also perform.
対話的な2パーティーのセッションがセットアップされた後に、パーティーは、RTPパケットを送って、受け始めます。 セクション4-7では、私たちはRTP MIDI送受信アルゴリズムについて議論します。このセクションで、また関係者が実行するセッション「家事」タスクについて説明します。
One housekeeping task is the maintenance of the 32-bit Synchronization Source (SSRC) value that uniquely identifies each party. Section 8 of [RFC3550] describes SSRC issues in detail, as does Section 2.1 in [RFC4695]. Another housekeeping task is the sending and receiving of RTCP. Section 6 of [RFC3550] describes RTCP in detail.
1つの家事のタスクは唯一各当事者を特定する32ビットのSynchronization Source(SSRC)価値の維持です。 [RFC3550]のセクション8はセクション2.1のように[RFC4695]で詳細にSSRC問題について説明します。 別の家事のタスクはRTCPの送受信です。 [RFC3550]のセクション6は詳細にRTCPについて説明します。
Lazzaro & Wawrzynek Informational [Page 6] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[6ページ]のRFC4696
Another housekeeping task concerns security. As detailed in the Security Considerations section of [RFC4695], per-packet authentication is strongly recommended for use with MIDI streams, because the acceptance of rogue packets may lead to the execution of arbitrary MIDI commands.
別の家事のタスクはセキュリティに関係があります。 [RFC4695]のSecurity Considerations部で詳しく述べられるように、1パケットあたりの認証は使用のためにMIDIの流れによって強く推薦されます、凶暴なパケットの承認が任意のMIDIコマンドの実行につながるかもしれないので。
A final housekeeping task concerns the termination of the session. In our two-party example, the session terminates upon the exit of one of the participants. A clean termination may require active effort by a receiver, as a MIDI stream stopped at an arbitrary point may cause stuck notes and other indefinite artifacts in the MIDI renderer.
最終的な家事のタスクはセッションの終了に関係があります。 私たちの2パーティーの例では、セッションは関係者のひとりの出口で終わります。 清潔な終了は受信機で活発な努力を必要とするかもしれません、任意点で止められたMIDIの流れがMIDIレンダラーで張り付けられた注意と他の無期人工物を引き起こすとき。
The exit of a party may be signalled in several ways. Session management tools may offer a reliable signal for termination (such as the SIP BYE method [RFC3261]). The (unreliable) RTCP BYE packet [RFC3550] may also signal the exit of a party. Receivers may also sense the lack of RTCP activity and timeout a party or may use transport methods to detect an exit.
パーティーの出口はいくつかの方法で合図されるかもしれません。 セッション管理ツールは終了(SIP BYE方法[RFC3261]などの)のために信頼できる信号を提供するかもしれません。 また、(頼り無い)のRTCP BYEパケット[RFC3550]はパーティーの出口に合図するかもしれません。 受信機は、また、RTCP活動とタイムアウトaパーティーの不足を感じるか、または出口を検出する輸送方法を使用するかもしれません。
4. Sending Streams: General Considerations
4. 発信は流れます: 一般問題
In this section, we discuss sender implementation issues.
このセクションで、私たちは送付者導入問題について議論します。
The sender is a real-time data-driven entity. On an ongoing basis, the sender checks to see if the local player has generated new MIDI data. At any time, the sender may transmit a new RTP packet to the remote player for the reasons described below:
送付者はリアルタイムのデータ駆動型実体です。 進行中ベースでは、送付者は、地元のプレーヤーが新しいMIDIデータを発生させたかどうか確認するためにチェックします。 いつでも、送付者は以下で説明された理由で新しいRTPパケットをリモートプレーヤーに伝えるかもしれません:
1. New MIDI data has been generated by the local player, and the
sender decides that it is time to issue a packet coding the data.
1. 新しいMIDIデータは地元のプレーヤーによって発生しました、そして、送付者はもうパケットコード化にデータを発行するべき時間であると決めます。
2. The local player has not generated new MIDI data, but the sender
decides that too much time has elapsed since the last RTP packet
transmission. The sender transmits a packet in order to relay
updated header and recovery journal data.
2. 地元のプレーヤーは新しいMIDIデータを発生させていませんが、送付者は、最後のRTPパケット伝送以来あまりに多くの時間が経過していると決めます。 送付者は、アップデートされたヘッダーと回復ジャーナルデータをリレーするためにパケットを伝えます。
In both cases, the sender generates a packet that consists of an RTP header, a MIDI command section, and a recovery journal. In the first case, the MIDI list of the MIDI command section codes the new MIDI data. In the second case, the MIDI list is empty.
どちらの場合も、送付者はRTPヘッダー、MIDI指揮班、および回復ジャーナルから成るパケットを発生させます。 前者の場合、MIDI指揮班のMIDIリストは新しいMIDIデータをコード化します。 2番目の場合では、MIDIリストはありません。
Lazzaro & Wawrzynek Informational [Page 7] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[7ページ]のRFC4696
#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h>
#<sys/types.h>#インクルード<sys/socket.h>#インクルード<netinet/in.h>を含めてください。
int rtp_fd, rtcp_fd; /* socket descriptors */
struct sockaddr_in addr; /* for bind address */
int rtp_fd、rtcp_fd。 addrの/*ソケット記述子*/struct sockaddr_。 ひもアドレス*/のための/*
/*********************************/
/* create the socket descriptors */
/*********************************/
作成..ソケット..記述子
if ((rtp_fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
ERROR_RETURN("Couldn't create Internet RTP socket");
(rtp_fdはソケット(AF_INET、SOCK_DGRAM、0)<0と等しいです)ERROR_RETURN(「インターネットRTPソケットを作成できなかった」)であるなら。
if ((rtcp_fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
ERROR_RETURN("Couldn't create Internet RTCP socket");
(rtcp_fdはソケット(AF_INET、SOCK_DGRAM、0)<0と等しいです)ERROR_RETURN(「インターネットRTCPソケットを作成できなかった」)であるなら。
/**********************************/
/* bind the RTP socket descriptor */
/**********************************/
縛る..ソケット..記述子
memset(&(addr.sin_zero), 0, 8);
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(16112); /* port 16112, from SDP */
memset((addr.sin_ゼロ)、0、8)。 addr.sin_家族はAF_INETと等しいです。 addr.sin_addr.s_addr=htonl、(INADDR、_少しも)、。 addr.sin_ポートはhtons(16112)と等しいです。 SDP*/からの/*ポート16112
if (bind(rtp_fd, (struct sockaddr *)&addr,
sizeof(struct sockaddr)) < 0)
ERROR_RETURN("Couldn't bind Internet RTP socket");
(ひも(rtp_fdと(struct sockaddr*)とaddr、sizeof(struct sockaddr))の<0)ERROR_RETURN(「インターネットRTPソケットを縛ることができなかった」)であるなら。
/***********************************/
/* bind the RTCP socket descriptor */
/***********************************/
縛る..ソケット..記述子
memset(&(addr.sin_zero), 0, 8);
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(16113); /* port 16113, from SDP */
memset((addr.sin_ゼロ)、0、8)。 addr.sin_家族はAF_INETと等しいです。 addr.sin_addr.s_addr=htonl、(INADDR、_少しも)、。 addr.sin_ポートはhtons(16113)と等しいです。 SDP*/からの/*ポート16113
if (bind(rtcp_fd, (struct sockaddr *)&addr,
sizeof(struct sockaddr)) < 0)
ERROR_RETURN("Couldn't bind Internet RTCP socket");
(ひも(rtcp_fdと(struct sockaddr*)とaddr、sizeof(struct sockaddr))の<0)ERROR_RETURN(「インターネットRTCPソケットを縛ることができなかった」)であるなら。
Figure 3. Setup code for listening for RTP/RTCP packets
図3。 RTP/RTCPパケットの聞こうとするためのセットアップコード
Lazzaro & Wawrzynek Informational [Page 8] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[8ページ]のRFC4696
#include <unistd.h> #include <fcntl.h>
#<unistd.h>#インクルード<fcntl.h>を含めてください。
/***************************/
/* set non-blocking status */
/***************************/
セット..ブロッキング..状態
if (fcntl(rtp_fd, F_SETFL, O_NONBLOCK))
ERROR_RETURN("Couldn't unblock Internet RTP socket");
(fcntl(rtp_fd、F_SETFL、O_NONBLOCK))のERROR_RETURN(「インターネットRTPソケットを「非-妨げ」ることができなかった」)であるなら。
if (fcntl(rtcp_fd, F_SETFL, O_NONBLOCK))
ERROR_RETURN("Couldn't unblock Internet RTCP socket");
(fcntl(rtcp_fd、F_SETFL、O_NONBLOCK))のERROR_RETURN(「インターネットRTCPソケットを「非-妨げ」ることができなかった」)であるなら。
Figure 4. Code to set socket descriptors to be non-blocking
図4。 ソケット記述子に非ブロッキングであるように設定するコード
#include <errno.h> #define UDPMAXSIZE 1472 /* based on Ethernet MTU of 1500 */
#1500*/のイーサネットMTUでUDPMAXSIZE1472/*に基づいた状態で>#が定義する<errno.hを含めてください。
unsigned char packet[UDPMAXSIZE+1]; int len, normal;
無記名の炭のパケット[UDPMAXSIZE+1]。 int len、標準。
while ((len = recv(rtp_fd, packet, UDPMAXSIZE + 1, 0)) > 0)
{
/* process packet[]. If (len == UDPMAXSIZE + 1), recv()
* may be returning a truncated packet -- process with care
*/
}
(len=recv(rtp_fd、パケット、UDPMAXSIZE+1、0)>0)をゆったり過ごしてください。/*はパケット[]を処理します。(len=UDPMAXSIZE+1)であるなら、recv()*は端が欠けているパケットを返しているかもしれません--慎重に*/を処理してください。
/* line below sets "normal" to 1 if the recv() return */
/* status indicates no packets are left to process */
1に「正常な」セットの下の/*線は、recv()リターン*//*状態であるならパケットが全く*/を処理するのが残されないのを示します。
normal = (len < 0) && (errno == EAGAIN);
標準が(len<0)と等しい、(errno=EAGAIN)。
if (!normal)
{
/*
* recv() return status indicates an empty UDP payload
* (len == 0) or an error condition (coded by (len < 0)
* and (errno != EAGAIN)). Examine len and errno, and
* take appropriate recovery action.
*/
}
(標準)です。/**recv()リターン状態は空のUDPペイロード*(len=0)かエラー条件((len<0)*と(errno!=EAGAIN)によってコード化される)を示します。*lenとerrnoを調べてください、そして、適切な回復処置*/を取ってください。
Figure 5. Code to check rtp_fd for new RTP packets
図5。 新しいRTPパケットのために_fdをチェックrtpにコード化してください。
Lazzaro & Wawrzynek Informational [Page 9] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[9ページ]のRFC4696
#include <arpa/inet.h> #include <netinet/in.h>
#<アルパ/inet.h>#インクルード<netinet/in.h>を含めてください。
struct sockaddr_in * rtp_addr; /* RTP destination IP/port */ struct sockaddr_in * rtcp_addr; /* RTCP destination IP/port */
*rtp_addrのstruct sockaddr_。 *rtcp_addrの/*RTP目的地IP/港の*/struct sockaddr_。 /*RTCP目的地IP/港の*/
/* set RTP address, as coded in Figure 2's SDP */
/*は図2のSDP*/でコード化されるようにRTPアドレスを設定しました。
rtp_addr = calloc(1, sizeof(struct sockaddr_in));
rtp_addr->sin_family = AF_INET;
rtp_addr->sin_port = htons(5004);
rtp_addr->sin_addr.s_addr = inet_addr("192.0.2.105");
rtp_addrはcalloc(1、sizeof(中にstruct sockaddr_がある状態で))と等しいです。 rtp_addr->は_家族=AF_INETを犯します。 rtp_addr->は_ポート=htons(5004)を犯します。 rtpの_のaddr>の罪_addr.s_addr=inet_addr、(「192.0 .2 0.105インチ)、」、。
/* set RTCP address, as coded in Figure 2's SDP */
/*は図2のSDP*/でコード化されるようにRTCPアドレスを設定しました。
rtcp_addr = calloc(1, sizeof(struct sockaddr_in));
rtcp_addr->sin_family = AF_INET;
rtcp_addr->sin_port = htons(5005); /* 5004 + 1 */
rtcp_addr->sin_addr.s_addr = rtp_addr->sin_addr.s_addr;
rtcp_addrはcalloc(1、sizeof(中にstruct sockaddr_がある状態で))と等しいです。 rtcp_addr->は_家族=AF_INETを犯します。 rtcp_addr->は_ポート=htons(5005)を犯します。 _/*5004+1_=rtp_addr>のrtcp_addr*/>罪_addr.s addr罪のaddr.s_addr。
Figure 6. Initializing destination addresses for RTP and RTCP
図6。 RTPとRTCPのための初期値設定送付先アドレス
unsigned char packet[UDPMAXSIZE]; /* RTP packet to send */ int size; /* length of RTP packet */
無記名の炭のパケット[UDPMAXSIZE]。 */intサイズを送る/*RTPパケット。 RTPパケット*/の/*長さ
/* first fill packet[] and set size ... then: */
そして/*最初の中詰めパケット[]とセットサイズ…: */
if (sendto(rtp_fd, packet, size, 0, rtp_addr,
sizeof(struct sockaddr)) == -1)
{
/*
* try again later if errno == EAGAIN or EINTR
*
* other errno values --> an operational error
*/
}
(sendto(rtp_fd、パケット、サイズ、0、rtp_addr、sizeof(struct sockaddr))=-1)です。/**は再び他のerrnoが評価するより遅い、しかし、errnoな=EAGAINかEINTR**を試みます--、>、誤操作*/
Figure 7. Using sendto() to send an RTP packet
図7。 RTPパケットを送るのにsendto()を使用します。
Figure 8 shows the 5 steps a sender takes to issue a packet. This algorithm corresponds to the code fragment for sending RTP packets shown in Figure 7 of Section 2. Steps 1, 2, and 3 occur before the sendto() call in the code fragment. Step 4 corresponds to the sendto() call itself. Step 5 may occur once Step 3 completes.
エイト環は、送付者がパケットを発行するために取るのを5ステップに案内します。 このアルゴリズムはセクション2の図7で見せられた送付RTPパケットのためのコード断片に対応しています。 ステップ1、2、および3 コード断片におけるsendto()呼び出しの前に起こってください。 ステップ4はsendto()呼び出し自体に対応しています。 ステップ5は一度起こるかもしれません。Step3は終了します。
Lazzaro & Wawrzynek Informational [Page 10] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[10ページ]のRFC4696
The algorithm for Sending a Packet is as follows:
Sending a Packetのためのアルゴリズムは以下の通りです:
1. Generate the RTP header for the new packet. See Section 2.1 of
[RFC4695] for details.
1. 新しいパケットのためにRTPヘッダーを発生させてください。 詳細に関して[RFC4695]のセクション2.1を見てください。
2. Generate the MIDI command section for the new packet. See Section
3 of [RFC4695] for details.
2. 新しいパケットのためにMIDI指揮班を発生させてください。 詳細に関して[RFC4695]のセクション3を見てください。
3. Generate the recovery journal for the new packet. We discuss this
process in Section 5.2. The generation algorithm examines the
Recovery Journal Sending Structure (RJSS), a stateful coding of a
history of the stream.
3. 新しいパケットのために回復ジャーナルを作ってください。 私たちはセクション5.2のこの過程について議論します。 世代アルゴリズムはRecovery Journal Sending Structure(RJSS)、流れの歴史のstatefulコード化を調べます。
4. Send the new packet to the receiver.
4. 新しいパケットを受信機に送ってください。
5. Update the RJSS to include the data coded in the MIDI command
section of the packet sent in step 4. We discuss the update
procedure in Section 5.3.
5. RJSSをアップデートして、ステップ4で送られたパケットのMIDI指揮班でコード化されたデータを含んでください。 私たちはセクション5.3のアップデート手順について議論します。
Figure 8. A 5 step algorithm for sending a packet
エイト環。 パケットを送るための5ステップアルゴリズム
In the sections that follow, we discuss specific sender implementation issues in detail.
従うセクションで、私たちは詳細に特定の送付者導入問題について議論します。
4.1. Queuing and Coding Incoming MIDI Data
4.1. 入って来るミディデータを列に並ばせて、コード化します。
Simple senders transmit a new packet as soon as the local player generates a complete MIDI command. The system described in [NMP] uses this algorithm. This algorithm minimizes the sender queuing latency, as the sender never delays the transmission of a new MIDI command.
地元のプレーヤーが完全なMIDIコマンドを発生させるとすぐに、純真な送付者は新しいパケットを伝えます。 [NMP]で説明されたシステムはこのアルゴリズムを使用します。 このアルゴリズムは送付者が新しいMIDIコマンドの送信を決して遅らせないので潜在を列に並ばせる送付者を最小にします。
In a relative sense, this algorithm uses bandwidth inefficiently, as it does not amortize the overhead of a packet over several commands. This inefficiency may be acceptable for sparse MIDI streams (see Appendix A.4 of [NMP]). More sophisticated sending algorithms [GRAME] improve efficiency by coding small groups of commands into a single packet, at the expense of increasing the sender queuing latency.
相対的な意味で、このアルゴリズムは効率悪く帯域幅を使用します、いくつかのコマンドの上でパケットのオーバーヘッドを清算しないとき。 まばらなMIDIの流れにおいて、この非能率は許容できるかもしれません([NMP]のAppendix A.4を見てください)。 より高度な送付アルゴリズム[GRAME]は小集団のコマンドを単一のパケットにコード化することによって、能率を増進します、潜在を列に並ばせる送付者を増加させることを犠牲にして。
Senders assign a timestamp value to each command issued by the local player (Appendix C.3 of [RFC4695]). Senders may code the timestamp value of the first MIDI list command in two ways. The most efficient method is to set the RTP timestamp of the packet to the timestamp value of the first command. In this method, the Z bit of the MIDI command section header (Figure 2 of [RFC4695]) is set to 0, and the RTP timestamps increment at a non-uniform rate.
送付者は地元のプレーヤー([RFC4695]の付録C.3)によって発行された各コマンドにタイムスタンプ値を割り当てます。 Sendersは2つの方法で最初のMIDIリストコマンドのタイムスタンプ値をコード化するかもしれません。 最も効率的な方法は最初のコマンドのタイムスタンプ値にパケットに関するRTPタイムスタンプを設定することです。 この方法で、MIDIコマンド節の見出し([RFC4695]の図2)のZビットはタイムスタンプが不均等なレートで増加する0、およびRTPに設定されます。
Lazzaro & Wawrzynek Informational [Page 11] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実現ガイドあたりWawrzynekの情報[11ページ]のRFC4696
However, in some applications, senders may wish to generate a stream whose RTP timestamps increment at a uniform rate. To do so, senders may use the Delta Time MIDI list field to code a timestamp for the first command in the list. In this case, the Z bit of the MIDI command section header is set to 1.
しかしながら、使用目的によっては、送付者はタイムスタンプが定率でRTPを増加する流れを発生させたがっているかもしれません。 そうするなら、送付者は、リストにおける最初のコマンドのためのタイムスタンプをコード化するのにデルタTime MIDIリスト分野を使用するかもしれません。 この場合、MIDIコマンド節の見出しのZビットは1に設定されます。
Senders should strive to maintain a constant relationship between the RTP packet timestamp and the packet sending time: if two packets have RTP timestamps that differ by 1 second, the second packet should be sent 1 second after the first packet. To the receiver, variance in this relationship is indistinguishable from network jitter. Latency issues are discussed in detail in Section 6.
Sendersは、RTPパケットタイムスタンプとパケット送付時間との一定の関係を維持するように努力するべきです: 2つのパケットに1秒異なるRTPタイムスタンプがあるなら、最初のパケットの1秒後に2番目のパケットを送るべきです。 受信機に、この関係における変化はネットワークジターから区別がつきません。 セクション6で詳細に潜在問題について議論します。
Senders may alter the running status coding of the first command in the MIDI list, in order to comply with the coding rules defined in Section 3.2 of [RFC4695]. The P header bit (Figure 2 of [RFC4695]) codes this alteration of the source command stream.
SendersはMIDIリストにおける、最初のコマンドの走行状態コード化を変更するかもしれません、[RFC4695]のセクション3.2で定義されるコード化規則に応じるために。 Pヘッダービット([RFC4695]の図2)はソースコマンドの流れのこの変更をコード化します。
4.2. Sending Packets with Empty MIDI Lists
4.2. 空のミディリストがある送付パケット
During a session, musicians might refrain from generating MIDI data for extended periods of time (seconds or even minutes). If an RTP stream followed the dynamics of a silent MIDI source and stopped sending RTP packets, system behavior might be degraded in the following ways:
During a session, musicians might refrain from generating MIDI data for extended periods of time (seconds or even minutes). If an RTP stream followed the dynamics of a silent MIDI source and stopped sending RTP packets, system behavior might be degraded in the following ways:
o The receiver's model of network performance may fall out of date.
o The receiver's model of network performance may fall out of date.
o Network middleboxes (such as Network Address Translators) may
"time-out" the silent stream and drop the port and IP association
state.
o Network middleboxes (such as Network Address Translators) may "time-out" the silent stream and drop the port and IP association state.
o If the session does not use RTCP, receivers may misinterpret the
silent stream as a dropped network connection.
o If the session does not use RTCP, receivers may misinterpret the silent stream as a dropped network connection.
Senders avoid these problems by sending "keep-alive" RTP packets during periods of network inactivity. Keep-alive packets have empty MIDI lists.
Senders avoid these problems by sending "keep-alive" RTP packets during periods of network inactivity. Keep-alive packets have empty MIDI lists.
Session participants may specify the frequency of keep-alive packets during session configuration with the MIME parameter "guardtime" (Appendix C.4.2 of [RFC4695]). The session descriptions shown in Figures 1-2 use guardtime to specify a keep-alive sending interval of 1 second.
Session participants may specify the frequency of keep-alive packets during session configuration with the MIME parameter "guardtime" (Appendix C.4.2 of [RFC4695]). The session descriptions shown in Figures 1-2 use guardtime to specify a keep-alive sending interval of 1 second.
Senders may also send empty packets to improve the performance of the recovery journal system. As we describe in Section 6, the recovery process begins when a receiver detects a break in the RTP sequence
Senders may also send empty packets to improve the performance of the recovery journal system. As we describe in Section 6, the recovery process begins when a receiver detects a break in the RTP sequence
Lazzaro & Wawrzynek Informational [Page 12] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 12] RFC 4696 An Implementation Guide for RTP MIDI November 2006
number pattern of the stream. The receiver uses the recovery journal of the break packet to guide corrective rendering actions, such as ending stuck notes and updating out-of-date controller values.
number pattern of the stream. The receiver uses the recovery journal of the break packet to guide corrective rendering actions, such as ending stuck notes and updating out-of-date controller values.
Consider the situation where the local player produces a MIDI NoteOff command (which the sender promptly transmits in a packet) but then 5 seconds pass before the player produces another MIDI command (which the sender transmits in a second packet). If the packet coding the NoteOff is lost, the receiver is not aware of the packet loss incident for 5 seconds, and the rendered MIDI performance contains a note that sounds for 5 seconds too long.
Consider the situation where the local player produces a MIDI NoteOff command (which the sender promptly transmits in a packet) but then 5 seconds pass before the player produces another MIDI command (which the sender transmits in a second packet). If the packet coding the NoteOff is lost, the receiver is not aware of the packet loss incident for 5 seconds, and the rendered MIDI performance contains a note that sounds for 5 seconds too long.
To handle this situation, senders may transmit empty packets to "guard" the stream during silent sections. The guard packet algorithm defined in Section 7.3 of [NMP], as applied to the situation described above, sends a guard packet after 100 ms of player inactivity, and sends a second guard packet 100 ms later. Subsequent guard packets are sent with an exponential backoff, with a limiting period of 1 second (set by the "guardtime" parameter in Figures 1-2). The algorithm terminates once MIDI activity resumes, or once RTCP receiver reports indicate that the receiver is up to date.
To handle this situation, senders may transmit empty packets to "guard" the stream during silent sections. The guard packet algorithm defined in Section 7.3 of [NMP], as applied to the situation described above, sends a guard packet after 100 ms of player inactivity, and sends a second guard packet 100 ms later. Subsequent guard packets are sent with an exponential backoff, with a limiting period of 1 second (set by the "guardtime" parameter in Figures 1-2). The algorithm terminates once MIDI activity resumes, or once RTCP receiver reports indicate that the receiver is up to date.
The perceptual quality of guard packet-sending algorithms is a quality of implementation issue for RTP MIDI applications. Sophisticated implementations may tailor the guard packet sending rate to the nature of the MIDI commands recently sent in the stream, to minimize the perceptual impact of moderate packet loss.
The perceptual quality of guard packet-sending algorithms is a quality of implementation issue for RTP MIDI applications. Sophisticated implementations may tailor the guard packet sending rate to the nature of the MIDI commands recently sent in the stream, to minimize the perceptual impact of moderate packet loss.
As an example of this sort of specialization, the guard packet algorithm described in [NMP] protects against the transient artifacts that occur when NoteOn commands are lost. The algorithm sends a guard packet 1 ms after every packet whose MIDI list contains a NoteOn command. The Y bit in Chapter N note logs (Appendix A.6 of [RFC4695]) supports this use of guard packets.
As an example of this sort of specialization, the guard packet algorithm described in [NMP] protects against the transient artifacts that occur when NoteOn commands are lost. The algorithm sends a guard packet 1 ms after every packet whose MIDI list contains a NoteOn command. The Y bit in Chapter N note logs (Appendix A.6 of [RFC4695]) supports this use of guard packets.
Congestion control and bandwidth management are key issues in guard packet algorithms. We discuss these issues in the next section.
Congestion control and bandwidth management are key issues in guard packet algorithms. We discuss these issues in the next section.
4.3. Congestion Control and Bandwidth Management
4.3. Congestion Control and Bandwidth Management
The congestion control section of [RFC4695] discusses the importance of congestion control for RTP MIDI streams and references the normative text in [RFC3550] and [RFC3551] that concerns congestion control. To comply with the requirements described in those normative documents, RTP MIDI senders may use several methods to control the sending rate:
The congestion control section of [RFC4695] discusses the importance of congestion control for RTP MIDI streams and references the normative text in [RFC3550] and [RFC3551] that concerns congestion control. To comply with the requirements described in those normative documents, RTP MIDI senders may use several methods to control the sending rate:
Lazzaro & Wawrzynek Informational [Page 13] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 13] RFC 4696 An Implementation Guide for RTP MIDI November 2006
o As described in Section 4.1, senders may pack several MIDI
commands into a single packet, thereby reducing stream bandwidth
(at the expense of increasing sender queuing latency).
o As described in Section 4.1, senders may pack several MIDI commands into a single packet, thereby reducing stream bandwidth (at the expense of increasing sender queuing latency).
o Guard packet algorithms (Section 4.2) may be designed in a
parametric way, so that the tradeoff between artifact reduction
and stream bandwidth may be tuned dynamically.
o Guard packet algorithms (Section 4.2) may be designed in a parametric way, so that the tradeoff between artifact reduction and stream bandwidth may be tuned dynamically.
o The recovery journal size may be reduced by adapting the
techniques described in Section 5 of this memo. Note that in all
cases, the recovery journal sender must conform to the normative
text in Section 4 of [RFC4695].
o The recovery journal size may be reduced by adapting the techniques described in Section 5 of this memo. Note that in all cases, the recovery journal sender must conform to the normative text in Section 4 of [RFC4695].
o The incoming MIDI stream may be modified to reduce the number of
MIDI commands without significantly altering the performance.
Lossy "MIDI filtering" algorithms are well developed in the MIDI
community and may be directly applied to RTP MIDI rate management.
o The incoming MIDI stream may be modified to reduce the number of MIDI commands without significantly altering the performance. Lossy "MIDI filtering" algorithms are well developed in the MIDI community and may be directly applied to RTP MIDI rate management.
RTP MIDI senders incorporate these rate control methods into feedback systems to implement congestion control and bandwidth management. Sections 10 and 6.4.4 of [RFC3550] and Section 2 in [RFC3551] describe feedback systems for congestion control in RTP, and Section 6 of [RFC4566] describes bandwidth management in media sessions.
RTP MIDI senders incorporate these rate control methods into feedback systems to implement congestion control and bandwidth management. Sections 10 and 6.4.4 of [RFC3550] and Section 2 in [RFC3551] describe feedback systems for congestion control in RTP, and Section 6 of [RFC4566] describes bandwidth management in media sessions.
5. Sending Streams: The Recovery Journal
5. Sending Streams: The Recovery Journal
In this section, we describe how senders implement the recovery journal system. The implementation we describe uses the default "closed-loop" recovery journal semantics (Appendix C.2.2.2 of [RFC4695]).
In this section, we describe how senders implement the recovery journal system. The implementation we describe uses the default "closed-loop" recovery journal semantics (Appendix C.2.2.2 of [RFC4695]).
We begin by describing the Recovery Journal Sending Structure (RJSS). Senders use the RJSS to generate the recovery journal section for RTP MIDI packets.
We begin by describing the Recovery Journal Sending Structure (RJSS). Senders use the RJSS to generate the recovery journal section for RTP MIDI packets.
The RJSS is a hierarchical representation of the checkpoint history of the stream. The checkpoint history holds the MIDI commands that are at risk to packet loss (Appendix A.1 of [RFC4695] precisely defines the checkpoint history). The layout of the RJSS mirrors the hierarchical structure of the recovery journal bitfields.
The RJSS is a hierarchical representation of the checkpoint history of the stream. The checkpoint history holds the MIDI commands that are at risk to packet loss (Appendix A.1 of [RFC4695] precisely defines the checkpoint history). The layout of the RJSS mirrors the hierarchical structure of the recovery journal bitfields.
Figure 9 shows an RJSS implementation for a simple sender. The leaf level of the RJSS hierarchy (the jsend_chapter structures) corresponds to channel chapters (Appendices A.2-9 in [RFC4695]). The second level of the hierarchy (jsend_channel) corresponds to the channel journal header (Figure 9 in [RFC4695]). The top level of the hierarchy (jsend_journal) corresponds to the recovery journal header (Figure 8 in [RFC4695]).
Figure 9 shows an RJSS implementation for a simple sender. The leaf level of the RJSS hierarchy (the jsend_chapter structures) corresponds to channel chapters (Appendices A.2-9 in [RFC4695]). The second level of the hierarchy (jsend_channel) corresponds to the channel journal header (Figure 9 in [RFC4695]). The top level of the hierarchy (jsend_journal) corresponds to the recovery journal header (Figure 8 in [RFC4695]).
Lazzaro & Wawrzynek Informational [Page 14] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 14] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Each RJSS data structure may code several items:
Each RJSS data structure may code several items:
1. The current contents of the recovery journal bitfield associated
with the RJSS structure (jheader[], cheader[], or a chapter
bitfield).
1. The current contents of the recovery journal bitfield associated with the RJSS structure (jheader[], cheader[], or a chapter bitfield).
2. A seqnum variable. Seqnum codes the extended RTP sequence number
of the most recent packet that added information to the RJSS
structure. If the seqnum of a structure is updated, the seqnums
of all structures above it in the recovery journal hierarchy are
also updated. Thus, a packet that caused an update to a specific
jsend_chapter structure would update the seqnum values of this
structure and of the jsend_channel and jsend_journal structures
that contain it.
2. A seqnum variable. Seqnum codes the extended RTP sequence number of the most recent packet that added information to the RJSS structure. If the seqnum of a structure is updated, the seqnums of all structures above it in the recovery journal hierarchy are also updated. Thus, a packet that caused an update to a specific jsend_chapter structure would update the seqnum values of this structure and of the jsend_channel and jsend_journal structures that contain it.
3. Ancillary variables used by the sending algorithm.
3. Ancillary variables used by the sending algorithm.
A seqnum variable for a level is set to zero if the checkpoint history contains no information at the level of the seqnum variable, and no information at any level below the level of the seqnum variable. This coding scheme assumes that the first sequence number of a stream is normalized to 1, and limits the total number of stream packets to 2^32 - 1.
A seqnum variable for a level is set to zero if the checkpoint history contains no information at the level of the seqnum variable, and no information at any level below the level of the seqnum variable. This coding scheme assumes that the first sequence number of a stream is normalized to 1, and limits the total number of stream packets to 2^32 - 1.
The cm_unused and ch_never parameters in Figures 1-2 define the subset of MIDI commands supported by the sender (see Appendix C.2.3 of [RFC4695] for details). The sender transmits most voice commands but does not transmit system commands. The sender assumes that the MIDI source uses note commands in the typical way. Thus, the sender does not use the Chapter E note resiliency tools (Appendix A.7 of [RFC4695]). The sender does not support Control Change commands for controller numbers with All Notes Off (123-127), All Sound Off (120), and Reset All Controllers (121) semantics and does not support enhanced Chapter C encoding (Appendix A.3.3 of [RFC4695]).
The cm_unused and ch_never parameters in Figures 1-2 define the subset of MIDI commands supported by the sender (see Appendix C.2.3 of [RFC4695] for details). The sender transmits most voice commands but does not transmit system commands. The sender assumes that the MIDI source uses note commands in the typical way. Thus, the sender does not use the Chapter E note resiliency tools (Appendix A.7 of [RFC4695]). The sender does not support Control Change commands for controller numbers with All Notes Off (123-127), All Sound Off (120), and Reset All Controllers (121) semantics and does not support enhanced Chapter C encoding (Appendix A.3.3 of [RFC4695]).
We chose this subset of MIDI commands to simplify the example. In particular, the command restrictions ensure that all commands are active, that all note commands are N-active, and that all Control Change commands are C-active (see Appendix A.1 of [RFC4695] for definitions of active, N-active, and C-active).
We chose this subset of MIDI commands to simplify the example. In particular, the command restrictions ensure that all commands are active, that all note commands are N-active, and that all Control Change commands are C-active (see Appendix A.1 of [RFC4695] for definitions of active, N-active, and C-active).
In the sections that follow, we describe the tasks a sender performs to manage the recovery journal system.
In the sections that follow, we describe the tasks a sender performs to manage the recovery journal system.
Lazzaro & Wawrzynek Informational [Page 15] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 15] RFC 4696 An Implementation Guide for RTP MIDI November 2006
5.1. Initializing the RJSS
5.1. Initializing the RJSS
At the start of a stream, the sender initializes the RJSS. All seqnum variables are set to zero, including all elements of note_seqnum[] and control_seqnum[].
At the start of a stream, the sender initializes the RJSS. All seqnum variables are set to zero, including all elements of note_seqnum[] and control_seqnum[].
The sender initializes jheader[] to form a recovery journal header that codes an empty journal. The S bit of the header is set to 1, and the A, Y, R, and TOTCHAN header fields are set to zero. The checkpoint packet sequence number field is set to the sequence number of the upcoming first RTP packet (per Appendix A.1 of [RFC4695]).
The sender initializes jheader[] to form a recovery journal header that codes an empty journal. The S bit of the header is set to 1, and the A, Y, R, and TOTCHAN header fields are set to zero. The checkpoint packet sequence number field is set to the sequence number of the upcoming first RTP packet (per Appendix A.1 of [RFC4695]).
Lazzaro & Wawrzynek Informational [Page 16] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 16] RFC 4696 An Implementation Guide for RTP MIDI November 2006
typedef unsigned char uint8; /* must be 1 octet */
typedef unsigned short uint16; /* must be 2 octet */
typedef unsigned long uint32; /* must be 4 octets */
typedef unsigned char uint8; /* must be 1 octet */ typedef unsigned short uint16; /* must be 2 octet */ typedef unsigned long uint32; /* must be 4 octets */
/**************************************************************/
/* leaf level hierarchy: Chapter W, Appendix A.5 of [RFC4695] */
/**************************************************************/
/**************************************************************/ /* leaf level hierarchy: Chapter W, Appendix A.5 of [RFC4695] */ /**************************************************************/
typedef struct jsend_chapterw { /* Pitch Wheel (0xE) */
uint8 chapterw[2]; /* bitfield Figure A.5.1 [RFC4695] */
uint32 seqnum; /* extended sequence number, or 0 */
} jsend_chapterw;
typedef struct jsend_chapterw { /* Pitch Wheel (0xE) */ uint8 chapterw[2]; /* bitfield Figure A.5.1 [RFC4695] */ uint32 seqnum; /* extended sequence number, or 0 */ } jsend_chapterw;
/**************************************************************/
/* leaf level hierarchy: Chapter N, Appendix A.6 of [RFC4695] */
/**************************************************************/
/**************************************************************/ /* leaf level hierarchy: Chapter N, Appendix A.6 of [RFC4695] */ /**************************************************************/
typedef struct jsend_chaptern { /* Note commands (0x8, 0x9) */
typedef struct jsend_chaptern { /* Note commands (0x8, 0x9) */
/* chapter N maximum size is 274 octets: a 2 octet header, */
/* and a maximum of 128 2-octet logs and 16 OFFBIT octets */
/* chapter N maximum size is 274 octets: a 2 octet header, */ /* and a maximum of 128 2-octet logs and 16 OFFBIT octets */
uint8 chaptern[274]; /* bitfield Figure A.6.1 [RFC4695] */
uint16 size; /* actual size of chaptern[] */
uint32 seqnum; /* extended seq number, or 0 */
uint32 note_seqnum[128]; /* most recent note seqnum, or 0 */
uint32 note_tstamp[128]; /* NoteOn execution timestamp */
uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */
} jsend_chaptern;
uint8 chaptern[274]; /* bitfield Figure A.6.1 [RFC4695] */ uint16 size; /* actual size of chaptern[] */ uint32 seqnum; /* extended seq number, or 0 */ uint32 note_seqnum[128]; /* most recent note seqnum, or 0 */ uint32 note_tstamp[128]; /* NoteOn execution timestamp */ uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */ } jsend_chaptern;
/**************************************************************/
/* leaf level hierarchy: Chapter C, Appendix A.3 of [RFC4695] */
/**************************************************************/
/**************************************************************/ /* leaf level hierarchy: Chapter C, Appendix A.3 of [RFC4695] */ /**************************************************************/
typedef struct jsend_chapterc { /* Control Change (0xB) */
typedef struct jsend_chapterc { /* Control Change (0xB) */
/* chapter C maximum size is 257 octets: a 1 octet header */
/* and a maximum of 128 2-octet logs */
/* chapter C maximum size is 257 octets: a 1 octet header */ /* and a maximum of 128 2-octet logs */
uint8 chapterc[257]; /* bitfield Figure A.3.1 [RFC4695] */
uint16 size; /* actual size of chapterc[] */
uint32 seqnum; /* extended sequence number, or 0 */
uint32 control_seqnum[128]; /* most recent seqnum, or 0 */
uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */
} jsend_chapterc;
uint8 chapterc[257]; /* bitfield Figure A.3.1 [RFC4695] */ uint16 size; /* actual size of chapterc[] */ uint32 seqnum; /* extended sequence number, or 0 */ uint32 control_seqnum[128]; /* most recent seqnum, or 0 */ uint32 bitfield_ptr[128]; /* points to a chapter log, or 0 */ } jsend_chapterc;
Figure 9. Recovery Journal Sending Structure (part 1)
Figure 9. Recovery Journal Sending Structure (part 1)
Lazzaro & Wawrzynek Informational [Page 17] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 17] RFC 4696 An Implementation Guide for RTP MIDI November 2006
/**************************************************************/
/* leaf level hierarchy: Chapter P, Appendix A.2 of [RFC4695] */
/**************************************************************/
/**************************************************************/ /* leaf level hierarchy: Chapter P, Appendix A.2 of [RFC4695] */ /**************************************************************/
typedef struct jsend_chapterp { /* MIDI Program Change (0xC) */
typedef struct jsend_chapterp { /* MIDI Program Change (0xC) */
uint8 chapterp[3]; /* bitfield Figure A.2.1 [RFC4695] */
uint32 seqnum; /* extended sequence number, or 0 */
uint8 chapterp[3]; /* bitfield Figure A.2.1 [RFC4695] */ uint32 seqnum; /* extended sequence number, or 0 */
} jsend_chapterp;
} jsend_chapterp;
/***************************************************/
/* second-level of hierarchy, for channel journals */
/***************************************************/
/***************************************************/ /* second-level of hierarchy, for channel journals */ /***************************************************/
typedef struct jsend_channel {
typedef struct jsend_channel {
uint8 cheader[3]; /* header Figure 9 [RFC4695]) */
uint32 seqnum; /* extended sequence number, or 0 */
uint8 cheader[3]; /* header Figure 9 [RFC4695]) */ uint32 seqnum; /* extended sequence number, or 0 */
jsend_chapterp chapterp; /* chapter P info */
jsend_chapterc chapterc; /* chapter C info */
jsend_chapterw chapterw; /* chapter W info */
jsend_chaptern chaptern; /* chapter N info */
jsend_chapterp chapterp; /* chapter P info */ jsend_chapterc chapterc; /* chapter C info */ jsend_chapterw chapterw; /* chapter W info */ jsend_chaptern chaptern; /* chapter N info */
} jsend_channel;
} jsend_channel;
/*******************************************************/
/* top level of hierarchy, for recovery journal header */
/*******************************************************/
/*******************************************************/ /* top level of hierarchy, for recovery journal header */ /*******************************************************/
typedef struct jsend_journal {
typedef struct jsend_journal {
uint8 jheader[3]; /* header Figure 8, [RFC4695] */
/* Note: Empty journal has a header */
uint8 jheader[3]; /* header Figure 8, [RFC4695] */ /* Note: Empty journal has a header */
uint32 seqnum; /* extended sequence number, or 0 */
/* seqnum = 0 codes empty journal */
uint32 seqnum; /* extended sequence number, or 0 */ /* seqnum = 0 codes empty journal */
jsend_channel channels[16]; /* channel journal state */
/* index is MIDI channel */
jsend_channel channels[16]; /* channel journal state */ /* index is MIDI channel */
} jsend_journal;
} jsend_journal;
Figure 9. Recovery Journal Sending Structure (part 2)
Figure 9. Recovery Journal Sending Structure (part 2)
Lazzaro & Wawrzynek Informational [Page 18] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 18] RFC 4696 An Implementation Guide for RTP MIDI November 2006
In jsend_chaptern, elements of note_tstamp[] are set to zero. In jsend_chaptern and jsend_chapterc, elements of bitfield_ptr[] are set to the null pointer index value (bitfield_ptr[] is an array whose elements point to the first octet of the note or control log associated with the array index).
In jsend_chaptern, elements of note_tstamp[] are set to zero. In jsend_chaptern and jsend_chapterc, elements of bitfield_ptr[] are set to the null pointer index value (bitfield_ptr[] is an array whose elements point to the first octet of the note or control log associated with the array index).
5.2. Traversing the RJSS
5.2. Traversing the RJSS
Whenever an RTP packet is created (Step 3 of the algorithm defined in Figure 8), the sender traverses the RJSS to create the recovery journal for the packet. The traversal begins at the top level of the RJSS. The sender copies jheader[] into the packet and then sets the S bit of jheader[] to 1.
Whenever an RTP packet is created (Step 3 of the algorithm defined in Figure 8), the sender traverses the RJSS to create the recovery journal for the packet. The traversal begins at the top level of the RJSS. The sender copies jheader[] into the packet and then sets the S bit of jheader[] to 1.
The traversal continues depth-first, visiting every jsend_channel whose seqnum variable is non-zero. The sender copies the cheader[] array into the packet and then sets the S bit of cheader[] to 1. After each cheader[] copy, the sender visits each leaf-level chapter, in the order of its appearance in the chapter journal Table of Contents (first P, then C, then W, then N, as shown in Figure 9 of [RFC4695]).
The traversal continues depth-first, visiting every jsend_channel whose seqnum variable is non-zero. The sender copies the cheader[] array into the packet and then sets the S bit of cheader[] to 1. After each cheader[] copy, the sender visits each leaf-level chapter, in the order of its appearance in the chapter journal Table of Contents (first P, then C, then W, then N, as shown in Figure 9 of [RFC4695]).
If a chapter has a non-zero seqnum, the sender copies the chapter bitfield array into the packet and then sets the S bit of the RJSS array to 1. For chaptern[], the B bit is also set to 1. For the variable-length chapters (chaptern[] and chapterc[]), the sender checks the size variable to determine the bitfield length.
If a chapter has a non-zero seqnum, the sender copies the chapter bitfield array into the packet and then sets the S bit of the RJSS array to 1. For chaptern[], the B bit is also set to 1. For the variable-length chapters (chaptern[] and chapterc[]), the sender checks the size variable to determine the bitfield length.
Before copying chaptern[], the sender updates the Y bit of each note log to code the onset of the associated NoteOn command (Figure A.6.3 in [RFC4695]). To determine the Y bit value, the sender checks the note_tstamp[] array for note timing information.
Before copying chaptern[], the sender updates the Y bit of each note log to code the onset of the associated NoteOn command (Figure A.6.3 in [RFC4695]). To determine the Y bit value, the sender checks the note_tstamp[] array for note timing information.
5.3. Updating the RJSS
5.3. Updating the RJSS
After an RTP packet is sent, the sender updates the RJSS to refresh the checkpoint history (Step 5 of the sending algorithm defined in Figure 8). For each command in the MIDI list of the sent packet, the sender performs the update procedure we now describe.
After an RTP packet is sent, the sender updates the RJSS to refresh the checkpoint history (Step 5 of the sending algorithm defined in Figure 8). For each command in the MIDI list of the sent packet, the sender performs the update procedure we now describe.
The update procedure begins at the leaf level. The sender generates a new bitfield array for the chapter associated with the MIDI command using the chapter-specific semantics defined in Appendix A of [RFC4695].
The update procedure begins at the leaf level. The sender generates a new bitfield array for the chapter associated with the MIDI command using the chapter-specific semantics defined in Appendix A of [RFC4695].
For Chapter N and Chapter C, the sender uses the bitfield_ptr[] array to locate and update an existing log for a note or controller. If a log does not exist, the sender adds a log to the end of the
For Chapter N and Chapter C, the sender uses the bitfield_ptr[] array to locate and update an existing log for a note or controller. If a log does not exist, the sender adds a log to the end of the
Lazzaro & Wawrzynek Informational [Page 19] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 19] RFC 4696 An Implementation Guide for RTP MIDI November 2006
chaptern[] or chapterc[] bitfield and changes the bitfield_ptr[] value to point to the log. For Chapter N, the sender also updates note_tstamp[].
chaptern[] or chapterc[] bitfield and changes the bitfield_ptr[] value to point to the log. For Chapter N, the sender also updates note_tstamp[].
The sender also clears the S bit of the chapterp[], chapterw[], or chapterc[] bitfield. For chaptern[], the sender clears the S bit or the B bit of the bitfield, as described in Appendix A.6 of [RFC4695].
The sender also clears the S bit of the chapterp[], chapterw[], or chapterc[] bitfield. For chaptern[], the sender clears the S bit or the B bit of the bitfield, as described in Appendix A.6 of [RFC4695].
Next, the sender refreshes the upper levels of the RJSS hierarchy. At the second level, the sender updates the cheader[] bitfield of the channel associated with the command. The sender sets the S bit of cheader[] to 0. If the new command forced the addition of a new chapter or channel journal, the sender may also update other cheader[] fields. At the top level, the sender updates the top-level jheader[] bitfield in a similar manner.
Next, the sender refreshes the upper levels of the RJSS hierarchy. At the second level, the sender updates the cheader[] bitfield of the channel associated with the command. The sender sets the S bit of cheader[] to 0. If the new command forced the addition of a new chapter or channel journal, the sender may also update other cheader[] fields. At the top level, the sender updates the top-level jheader[] bitfield in a similar manner.
Finally, the sender updates the seqnum variables associated with the changed bitfield arrays. The sender sets the seqnum variables to the extended sequence number of the packet.
Finally, the sender updates the seqnum variables associated with the changed bitfield arrays. The sender sets the seqnum variables to the extended sequence number of the packet.
5.4. Trimming the RJSS
5.4. Trimming the RJSS
At regular intervals, receivers send RTCP receiver reports to the sender (as described in Section 6.4.2 of [RFC3550]). These reports include the extended highest sequence number received (EHSNR) field. This field codes the highest sequence number that the receiver has observed from the sender, extended to disambiguate sequence number rollover.
At regular intervals, receivers send RTCP receiver reports to the sender (as described in Section 6.4.2 of [RFC3550]). These reports include the extended highest sequence number received (EHSNR) field. This field codes the highest sequence number that the receiver has observed from the sender, extended to disambiguate sequence number rollover.
When the sender receives an RTCP receiver report, it runs the RJSS trimming algorithm. The trimming algorithm uses the EHSNR to trim away parts of the RJSS. In this way, the algorithm reduces the size of recovery journals sent in subsequent RTP packets. The algorithm conforms to the closed-loop sending policy defined in Appendix C.2.2.2 of [RFC4695].
When the sender receives an RTCP receiver report, it runs the RJSS trimming algorithm. The trimming algorithm uses the EHSNR to trim away parts of the RJSS. In this way, the algorithm reduces the size of recovery journals sent in subsequent RTP packets. The algorithm conforms to the closed-loop sending policy defined in Appendix C.2.2.2 of [RFC4695].
The trimming algorithm relies on the following observation: if the EHSNR indicates that a packet with sequence number K has been received, MIDI commands sent in packets with sequence numbers J <= K may be removed from the RJSS without violating the closed-loop policy.
The trimming algorithm relies on the following observation: if the EHSNR indicates that a packet with sequence number K has been received, MIDI commands sent in packets with sequence numbers J <= K may be removed from the RJSS without violating the closed-loop policy.
To begin the trimming algorithm, the sender extracts the EHSNR field from the receiver report and adjusts the EHSNR to reflect the sequence number extension prefix of the sender. Then, the sender compares the adjusted EHSNR value with seqnum fields at each level of the RJSS, starting at the top level.
To begin the trimming algorithm, the sender extracts the EHSNR field from the receiver report and adjusts the EHSNR to reflect the sequence number extension prefix of the sender. Then, the sender compares the adjusted EHSNR value with seqnum fields at each level of the RJSS, starting at the top level.
Lazzaro & Wawrzynek Informational [Page 20] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 20] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Levels whose seqnum is less than or equal to the adjusted EHSNR are trimmed, by setting the seqnum to zero. If necessary, the jheader[] and cheader[] arrays above the trimmed level are adjusted to match the new journal layout. The checkpoint packet sequence number field of jheader[] is updated to match the EHSNR.
Levels whose seqnum is less than or equal to the adjusted EHSNR are trimmed, by setting the seqnum to zero. If necessary, the jheader[] and cheader[] arrays above the trimmed level are adjusted to match the new journal layout. The checkpoint packet sequence number field of jheader[] is updated to match the EHSNR.
At the leaf level, the sender trims the size of the variable-length chaptern[] and chapterc[] bitfields. The sender loops through the note_seqnum[] or control_seqnum[] array and removes chaptern[] or chapterc[] logs whose seqnum value is less than or equal to the adjusted EHSNR. The sender sets the associated bitfield_ptr[] to null and updates the LENGTH field of the associated cheader[] bitfield.
At the leaf level, the sender trims the size of the variable-length chaptern[] and chapterc[] bitfields. The sender loops through the note_seqnum[] or control_seqnum[] array and removes chaptern[] or chapterc[] logs whose seqnum value is less than or equal to the adjusted EHSNR. The sender sets the associated bitfield_ptr[] to null and updates the LENGTH field of the associated cheader[] bitfield.
Note that the trimming algorithm does not add information to the checkpoint history. As a consequence, the trimming algorithm does not clear the S bit (and for chaptern[], the B bit) of any recovery journal bitfield. As a second consequence, the trimming algorithm does not set RJSS seqnum variables to the EHSNR value.
Note that the trimming algorithm does not add information to the checkpoint history. As a consequence, the trimming algorithm does not clear the S bit (and for chaptern[], the B bit) of any recovery journal bitfield. As a second consequence, the trimming algorithm does not set RJSS seqnum variables to the EHSNR value.
5.5. Implementation Notes
5.5. Implementation Notes
For pedagogical purposes, the recovery journal sender we describe has been simplified in several ways. In practice, an implementation would use enhanced versions of the traversing, updating, and trimming algorithms presented in Sections 5.2-5.4.
For pedagogical purposes, the recovery journal sender we describe has been simplified in several ways. In practice, an implementation would use enhanced versions of the traversing, updating, and trimming algorithms presented in Sections 5.2-5.4.
6. Receiving Streams: General Considerations
6. Receiving Streams: General Considerations
In this section, we discuss receiver implementation issues.
In this section, we discuss receiver implementation issues.
To begin, we imagine that an ideal network carries the RTP stream. Packets are never lost or reordered, and the end-to-end latency is constant. In addition, we assume that all commands coded in the MIDI list of a packet share the same timestamp (an assumption coded by the "rtp_ptime" and "rtp_maxptime" values in Figures 1-2; see Appendix C.4.1 of [RFC4695] for details).
To begin, we imagine that an ideal network carries the RTP stream. Packets are never lost or reordered, and the end-to-end latency is constant. In addition, we assume that all commands coded in the MIDI list of a packet share the same timestamp (an assumption coded by the "rtp_ptime" and "rtp_maxptime" values in Figures 1-2; see Appendix C.4.1 of [RFC4695] for details).
Under these conditions, a simple algorithm may be used to render a high-quality performance. Upon receipt of an RTP packet, the receiver immediately executes the commands coded in the MIDI command section of the payload. Commands are executed in the order of their appearance in the MIDI list. The command timestamps are ignored.
Under these conditions, a simple algorithm may be used to render a high-quality performance. Upon receipt of an RTP packet, the receiver immediately executes the commands coded in the MIDI command section of the payload. Commands are executed in the order of their appearance in the MIDI list. The command timestamps are ignored.
Lazzaro & Wawrzynek Informational [Page 21] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 21] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Unfortunately, this simple algorithm breaks down once we relax our assumptions about the network and the MIDI list:
Unfortunately, this simple algorithm breaks down once we relax our assumptions about the network and the MIDI list:
1. If we permit lost and reordered packets to occur in the network,
the algorithm may produce unrecoverable rendering artifacts,
violating the mandate defined in Section 4 of [RFC4695].
1. If we permit lost and reordered packets to occur in the network, the algorithm may produce unrecoverable rendering artifacts, violating the mandate defined in Section 4 of [RFC4695].
2. If we permit the network to exhibit variable latency, the
algorithm modulates the network jitter onto the rendered MIDI
command stream.
2. If we permit the network to exhibit variable latency, the algorithm modulates the network jitter onto the rendered MIDI command stream.
3. If we permit a MIDI list to code commands with different
timestamps, the algorithm adds temporal jitter to the rendered
performance, as it ignores MIDI list timestamps.
3. If we permit a MIDI list to code commands with different timestamps, the algorithm adds temporal jitter to the rendered performance, as it ignores MIDI list timestamps.
In this section, we discuss interactive receiver design techniques under these relaxed assumptions. Section 6.1 describes a receiver design for high-performance Wide Area Networks (WANs), and Section 6.2 discusses design issues for other types of networks.
In this section, we discuss interactive receiver design techniques under these relaxed assumptions. Section 6.1 describes a receiver design for high-performance Wide Area Networks (WANs), and Section 6.2 discusses design issues for other types of networks.
6.1. The NMP Receiver Design
6.1. The NMP Receiver Design
The Network Musical Performance (NMP) system [NMP] is an interactive performance application that uses an early version of the RTP MIDI payload format. NMP is designed for use between universities within the State of California, which use the high-performance CalREN2 network.
The Network Musical Performance (NMP) system [NMP] is an interactive performance application that uses an early version of the RTP MIDI payload format. NMP is designed for use between universities within the State of California, which use the high-performance CalREN2 network.
In the NMP system, network artifacts may affect how a musician hears the performances of remote players. However, the network does not affect how a musician hears his own performance.
In the NMP system, network artifacts may affect how a musician hears the performances of remote players. However, the network does not affect how a musician hears his own performance.
Several aspects of CalREN2 network behavior (as measured in 2001 timeframe, as documented in [NMP]) guided the NMP system design:
Several aspects of CalREN2 network behavior (as measured in 2001 timeframe, as documented in [NMP]) guided the NMP system design:
o The median symmetric latency (1/2 the round-trip time) of packets
sent between network sites is comparable to the acoustic latency
between two musicians located in the same room. For example, the
latency between Berkeley and Stanford is 2.1 ms, corresponding to
an acoustic distance of 2.4 feet (0.72 meters). These campuses
are 40 miles (64 km) apart. Preserving the benefits of the
underlying network latency at the application level was a key NMP
design goal.
o The median symmetric latency (1/2 the round-trip time) of packets sent between network sites is comparable to the acoustic latency between two musicians located in the same room. For example, the latency between Berkeley and Stanford is 2.1 ms, corresponding to an acoustic distance of 2.4 feet (0.72 meters). These campuses are 40 miles (64 km) apart. Preserving the benefits of the underlying network latency at the application level was a key NMP design goal.
o For most times of day, the nominal temporal jitter is quite short.
For Berkeley-Stanford, the standard deviation of the round-trip
time was under 200 microseconds.
o For most times of day, the nominal temporal jitter is quite short. For Berkeley-Stanford, the standard deviation of the round-trip time was under 200 microseconds.
Lazzaro & Wawrzynek Informational [Page 22] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 22] RFC 4696 An Implementation Guide for RTP MIDI November 2006
o For most times of day, a few percent (0-4%) of the packets sent
arrive significantly late (> 40 ms), probably due to a queuing
transient somewhere in the network path. More rarely (< 0.1%), a
packet is lost during the transient.
o For most times of day, a few percent (0-4%) of the packets sent arrive significantly late (> 40 ms), probably due to a queuing transient somewhere in the network path. More rarely (< 0.1%), a packet is lost during the transient.
o At predictable times during the day (before lunchtime, at the end
of the workday, etc.), network performance deteriorates (10-20%
late packets) in a manner that makes the network unsuitable for
low-latency interactive use.
o At predictable times during the day (before lunchtime, at the end of the workday, etc.), network performance deteriorates (10-20% late packets) in a manner that makes the network unsuitable for low-latency interactive use.
o CalREN2 has deeply over-provisioned bandwidth, relative to MIDI
bandwidth usage.
o CalREN2 has deeply over-provisioned bandwidth, relative to MIDI bandwidth usage.
The NMP sender freely uses network bandwidth to improve the performance experience. As soon as a musician generates a MIDI command, an RTP packet coding the command is sent to the other players. This sending algorithm reduces latency at the cost of bandwidth. In addition, guard packets (described in Section 4.2) are sent at frequent intervals to minimize the impact of packet loss.
The NMP sender freely uses network bandwidth to improve the performance experience. As soon as a musician generates a MIDI command, an RTP packet coding the command is sent to the other players. This sending algorithm reduces latency at the cost of bandwidth. In addition, guard packets (described in Section 4.2) are sent at frequent intervals to minimize the impact of packet loss.
The NMP receiver maintains a model of the stream and uses this model as the basis of its resiliency system. Upon receipt of a packet, the receiver predicts the RTP sequence number and the RTP timestamp (with error bars) of the packet. Under normal network conditions, about 95% of received packets fit the predictions [NMP]. In this common case, the receiver immediately executes the MIDI command coded in the packet.
The NMP receiver maintains a model of the stream and uses this model as the basis of its resiliency system. Upon receipt of a packet, the receiver predicts the RTP sequence number and the RTP timestamp (with error bars) of the packet. Under normal network conditions, about 95% of received packets fit the predictions [NMP]. In this common case, the receiver immediately executes the MIDI command coded in the packet.
Note that the NMP receiver does not use a playout buffer; the design is optimized for lowest latency at the expense of command jitter. Thus, the NMP receiver design does not completely satisfy the interoperability text in Appendix C.7.2 of [RFC4695], which requires that receivers in network musical performance applications be capable of using a playout buffer.
Note that the NMP receiver does not use a playout buffer; the design is optimized for lowest latency at the expense of command jitter. Thus, the NMP receiver design does not completely satisfy the interoperability text in Appendix C.7.2 of [RFC4695], which requires that receivers in network musical performance applications be capable of using a playout buffer.
Occasionally, an incoming packet fits the sequence number prediction, but falls outside the timestamp prediction error bars (see Appendix B of [NMP] for timestamp model details). In most cases, the receiver still executes the command coded in the packet. However, the receiver discards NoteOn commands with non-zero velocity. By discarding late commands that sound notes, the receiver prevents "straggler notes" from disturbing a performance. By executing all other late commands, the receiver quiets "soft stuck notes" immediately and updates the state of the MIDI system.
Occasionally, an incoming packet fits the sequence number prediction, but falls outside the timestamp prediction error bars (see Appendix B of [NMP] for timestamp model details). In most cases, the receiver still executes the command coded in the packet. However, the receiver discards NoteOn commands with non-zero velocity. By discarding late commands that sound notes, the receiver prevents "straggler notes" from disturbing a performance. By executing all other late commands, the receiver quiets "soft stuck notes" immediately and updates the state of the MIDI system.
More rarely, an incoming packet does not fit the sequence number prediction. The receiver keeps track of the highest sequence number received in the stream and predicts that an incoming packet will have
More rarely, an incoming packet does not fit the sequence number prediction. The receiver keeps track of the highest sequence number received in the stream and predicts that an incoming packet will have
Lazzaro & Wawrzynek Informational [Page 23] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 23] RFC 4696 An Implementation Guide for RTP MIDI November 2006
a sequence number one greater than this value. If the sequence number of an incoming packet is greater than the prediction, a packet loss has occurred. If the sequence number of the received packet is less than the prediction, the packet has been received out of order. All sequence number calculations are modulo 2^16 and use standard methods (described in [RFC3550]) to avoid tracking errors during rollover.
a sequence number one greater than this value. If the sequence number of an incoming packet is greater than the prediction, a packet loss has occurred. If the sequence number of the received packet is less than the prediction, the packet has been received out of order. All sequence number calculations are modulo 2^16 and use standard methods (described in [RFC3550]) to avoid tracking errors during rollover.
If a packet loss has occurred, the receiver examines the journal section of the received packet and uses it to gracefully recover from the loss episode. We describe this recovery procedure in Section 7 of this memo. The recovery process may result in the execution of one or more MIDI commands. After executing the recovery commands, the receiver processes the MIDI command encoded in the packet using the timestamp model test described above.
If a packet loss has occurred, the receiver examines the journal section of the received packet and uses it to gracefully recover from the loss episode. We describe this recovery procedure in Section 7 of this memo. The recovery process may result in the execution of one or more MIDI commands. After executing the recovery commands, the receiver processes the MIDI command encoded in the packet using the timestamp model test described above.
If a packet is received out of order, the receiver ignores the packet. The receiver takes this action because a packet received out of order is always preceded by a packet that signalled a loss event. This loss event triggered the recovery process, which may have executed recovery commands. The MIDI command coded in the out-of- order packet might, if executed, duplicate these recovery commands, and this duplication might endanger the integrity of the stream. Thus, ignoring the out-of-order packet is the safe approach.
If a packet is received out of order, the receiver ignores the packet. The receiver takes this action because a packet received out of order is always preceded by a packet that signalled a loss event. This loss event triggered the recovery process, which may have executed recovery commands. The MIDI command coded in the out-of- order packet might, if executed, duplicate these recovery commands, and this duplication might endanger the integrity of the stream. Thus, ignoring the out-of-order packet is the safe approach.
6.2. High-Jitter Networks, Local Area Networks
6.2. High-Jitter Networks, Local Area Networks
The NMP receiver targets a network with a particular set of characteristics: low nominal jitter, low packet loss, and occasional outlier packets that arrive very late. In this section, we consider how networks with different characteristics impact receiver design.
The NMP receiver targets a network with a particular set of characteristics: low nominal jitter, low packet loss, and occasional outlier packets that arrive very late. In this section, we consider how networks with different characteristics impact receiver design.
Networks with significant nominal jitter cannot use the buffer-free receiver design described in Section 6.1. For example, the NMP system performs poorly for musicians that use dial-up modem connections, because the buffer-free receiver design modulates modem jitter onto the performances. Receivers designed for high-jitter networks should use a substantial playout buffer. References [GRAME] and [CCRMA] describe how to use playout buffers in latency-critical applications.
Networks with significant nominal jitter cannot use the buffer-free receiver design described in Section 6.1. For example, the NMP system performs poorly for musicians that use dial-up modem connections, because the buffer-free receiver design modulates modem jitter onto the performances. Receivers designed for high-jitter networks should use a substantial playout buffer. References [GRAME] and [CCRMA] describe how to use playout buffers in latency-critical applications.
Receivers intended for use on Local Area Networks (LANs) face a different set of issues. A dedicated LAN fabric built with modern hardware is in many ways a predictable environment. The network problems addressed by the NMP receiver design (packet loss and outlier late packets) might only occur under extreme network overload conditions.
Receivers intended for use on Local Area Networks (LANs) face a different set of issues. A dedicated LAN fabric built with modern hardware is in many ways a predictable environment. The network problems addressed by the NMP receiver design (packet loss and outlier late packets) might only occur under extreme network overload conditions.
Lazzaro & Wawrzynek Informational [Page 24] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 24] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Systems designed for this environment may choose to configure streams without the recovery journal system (Appendix C.2.1 of [RFC4695]). Receivers may also wish to forego or simplify the detection of outlier late packets. Receivers should monitor the RTP sequence numbers of incoming packets to detect network unreliability.
Systems designed for this environment may choose to configure streams without the recovery journal system (Appendix C.2.1 of [RFC4695]). Receivers may also wish to forego or simplify the detection of outlier late packets. Receivers should monitor the RTP sequence numbers of incoming packets to detect network unreliability.
However, in some respects, LAN applications may be more demanding than WAN applications. In LAN applications, musicians may be receiving performance feedback from audio that is rendered from the stream. The tolerance a musician has for latency and jitter in this context may be quite low.
However, in some respects, LAN applications may be more demanding than WAN applications. In LAN applications, musicians may be receiving performance feedback from audio that is rendered from the stream. The tolerance a musician has for latency and jitter in this context may be quite low.
To reduce the perceived jitter, receivers may use a small playout buffer (in the range of 100us to 2ms). The buffer adds a small amount of latency to the system, which may be annoying to some players. Receiver designs should include buffer tuning parameters to let musicians adjust the tradeoff between latency and jitter.
To reduce the perceived jitter, receivers may use a small playout buffer (in the range of 100us to 2ms). The buffer adds a small amount of latency to the system, which may be annoying to some players. Receiver designs should include buffer tuning parameters to let musicians adjust the tradeoff between latency and jitter.
7. Receiving Streams: The Recovery Journal
7. Receiving Streams: The Recovery Journal
In this section, we describe the recovery algorithm used by the NMP receiver [NMP]. In most ways, the recovery techniques we describe are generally applicable to interactive receiver design. However, a few aspects of the design are specialized for the NMP system:
In this section, we describe the recovery algorithm used by the NMP receiver [NMP]. In most ways, the recovery techniques we describe are generally applicable to interactive receiver design. However, a few aspects of the design are specialized for the NMP system:
o The recovery algorithm covers a subset of the MIDI command set.
MIDI Systems (0xF), Poly Aftertouch (0xA), and Channel Aftertouch
(0xD) commands are not protected, and Control Change (0xB) command
protection is simplified. Note commands for a particular note
number are assumed to follow the typical NoteOn->NoteOff->NoteOn
->NoteOff pattern. The cm_unused and ch_never parameters in
Figures 1-2 specify this coverage.
o The recovery algorithm covers a subset of the MIDI command set. MIDI Systems (0xF), Poly Aftertouch (0xA), and Channel Aftertouch (0xD) commands are not protected, and Control Change (0xB) command protection is simplified. Note commands for a particular note number are assumed to follow the typical NoteOn->NoteOff->NoteOn ->NoteOff pattern. The cm_unused and ch_never parameters in Figures 1-2 specify this coverage.
o The NMP system does not use a playout buffer. Therefore, the
recovery algorithm does not address interactions with a playout
buffer.
o The NMP system does not use a playout buffer. Therefore, the recovery algorithm does not address interactions with a playout buffer.
At a high level, the receiver algorithm works as follows. Upon detection of a packet loss, the receiver examines the recovery journal of the packet that ends the loss event. If necessary, the receiver executes one or more MIDI commands to recover from the loss.
At a high level, the receiver algorithm works as follows. Upon detection of a packet loss, the receiver examines the recovery journal of the packet that ends the loss event. If necessary, the receiver executes one or more MIDI commands to recover from the loss.
To prepare for recovery, a receiver maintains a data structure, the Recovery Journal Receiver Structure (RJRS). The RJRS codes information about the MIDI commands the receiver executes (both incoming stream commands and self-generated recovery commands). At the start of the stream, the RJRS is initialized to code that no commands have been executed. Immediately after executing a MIDI
To prepare for recovery, a receiver maintains a data structure, the Recovery Journal Receiver Structure (RJRS). The RJRS codes information about the MIDI commands the receiver executes (both incoming stream commands and self-generated recovery commands). At the start of the stream, the RJRS is initialized to code that no commands have been executed. Immediately after executing a MIDI
Lazzaro & Wawrzynek Informational [Page 25] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 25] RFC 4696 An Implementation Guide for RTP MIDI November 2006
command, the receiver updates the RJRS with information about the command.
command, the receiver updates the RJRS with information about the command.
We now describe the recovery algorithm in detail. We begin with two definitions that classify loss events. These definitions assume that the packet that ends the loss event has RTP sequence number I.
We now describe the recovery algorithm in detail. We begin with two definitions that classify loss events. These definitions assume that the packet that ends the loss event has RTP sequence number I.
o Single-packet loss. A single-packet loss occurs if the last
packet received before the loss event (excluding out-of-order
packets) has the sequence number I-2 (modulo 2^16).
o Single-packet loss. A single-packet loss occurs if the last packet received before the loss event (excluding out-of-order packets) has the sequence number I-2 (modulo 2^16).
o Multi-packet loss. A multi-packet loss occurs if the last packet
received before the loss event (excluding out-of-order packets)
has a sequence number less than I-2 (modulo 2^16).
o Multi-packet loss. A multi-packet loss occurs if the last packet received before the loss event (excluding out-of-order packets) has a sequence number less than I-2 (modulo 2^16).
Upon detection of a packet loss, the recovery algorithm examines the recovery journal header (Figure 8 of [RFC4695]) to check for special cases:
Upon detection of a packet loss, the recovery algorithm examines the recovery journal header (Figure 8 of [RFC4695]) to check for special cases:
o If the header field A is 0, the recovery journal has no channel
journals, so no action is taken.
o If the header field A is 0, the recovery journal has no channel journals, so no action is taken.
o If a single-packet loss has occurred, and if the header S bit is
1, the lost packet has a MIDI command section with an empty MIDI
list. No action is taken.
o If a single-packet loss has occurred, and if the header S bit is 1, the lost packet has a MIDI command section with an empty MIDI list. No action is taken.
If these checks fail, the algorithm parses the recovery journal body. For each channel journal (Figure 9 in [RFC4695]) in the recovery journal, the receiver compares the data in each chapter journal (Appendix A of [RFC4695]) to the RJRS data for the chapter. If the data are inconsistent, the algorithm infers that MIDI commands related to the chapter journal have been lost. The recovery algorithm executes MIDI commands to repair this loss and updates the RJRS to reflect the repair.
If these checks fail, the algorithm parses the recovery journal body. For each channel journal (Figure 9 in [RFC4695]) in the recovery journal, the receiver compares the data in each chapter journal (Appendix A of [RFC4695]) to the RJRS data for the chapter. If the data are inconsistent, the algorithm infers that MIDI commands related to the chapter journal have been lost. The recovery algorithm executes MIDI commands to repair this loss and updates the RJRS to reflect the repair.
For single-packet losses, the receiver skips channel and chapter journals whose S bits are set to 1. For multi-packet losses, the receiver parses each channel and chapter journal and checks for inconsistency.
For single-packet losses, the receiver skips channel and chapter journals whose S bits are set to 1. For multi-packet losses, the receiver parses each channel and chapter journal and checks for inconsistency.
In the sections that follow, we describe the recovery steps that are specific to each chapter journal. We cover 4 chapter journal types: P (Program Change, 0xC), C (Control Change, 0xB), W (Pitch Wheel, 0xE), and N (Note, 0x8 and 0x9). Chapters are parsed in the order of their appearance in the channel journal (P, then W, then N, then C).
In the sections that follow, we describe the recovery steps that are specific to each chapter journal. We cover 4 chapter journal types: P (Program Change, 0xC), C (Control Change, 0xB), W (Pitch Wheel, 0xE), and N (Note, 0x8 and 0x9). Chapters are parsed in the order of their appearance in the channel journal (P, then W, then N, then C).
Lazzaro & Wawrzynek Informational [Page 26] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 26] RFC 4696 An Implementation Guide for RTP MIDI November 2006
The sections below reference the C implementation of the RJRS shown in Figure 10. This structure is hierarchical, reflecting the recovery journal architecture. At the leaf level, specialized data structures (jrec_chapterw, jrec_chaptern, jrec_chapterc, and jrec_chapterp) code state variables for a single chapter journal type. A mid-level structure (jrec_channel) represents a single MIDI channel, and a top-level structure (jrec_stream) represents the entire MIDI stream.
The sections below reference the C implementation of the RJRS shown in Figure 10. This structure is hierarchical, reflecting the recovery journal architecture. At the leaf level, specialized data structures (jrec_chapterw, jrec_chaptern, jrec_chapterc, and jrec_chapterp) code state variables for a single chapter journal type. A mid-level structure (jrec_channel) represents a single MIDI channel, and a top-level structure (jrec_stream) represents the entire MIDI stream.
Lazzaro & Wawrzynek Informational [Page 27] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 27] RFC 4696 An Implementation Guide for RTP MIDI November 2006
typedef unsigned char uint8; /* must be 1 octet */
typedef unsigned short uint16; /* must be 2 octets */
typedef unsigned long uint32; /* must be 4 octets */
typedef unsigned char uint8; /* must be 1 octet */ typedef unsigned short uint16; /* must be 2 octets */ typedef unsigned long uint32; /* must be 4 octets */
/*****************************************************************/
/* leaf level of hierarchy: Chapter W, Appendix A.5 of [RFC4695] */
/*****************************************************************/
/*****************************************************************/ /* leaf level of hierarchy: Chapter W, Appendix A.5 of [RFC4695] */ /*****************************************************************/
typedef struct jrec_chapterw { /* MIDI Pitch Wheel (0xE) */
typedef struct jrec_chapterw { /* MIDI Pitch Wheel (0xE) */
uint16 val; /* most recent 14-bit wheel value */
uint16 val; /* most recent 14-bit wheel value */
} jrec_chapterw;
} jrec_chapterw;
/*****************************************************************/
/* leaf level of hierarchy: Chapter N, Appendix A.6 of [RFC4695] */
/*****************************************************************/
/*****************************************************************/ /* leaf level of hierarchy: Chapter N, Appendix A.6 of [RFC4695] */ /*****************************************************************/
typedef struct jrec_chaptern { /* Note commands (0x8, 0x9) */
typedef struct jrec_chaptern { /* Note commands (0x8, 0x9) */
/* arrays of length 128 --> one for each MIDI Note number */
/* arrays of length 128 --> one for each MIDI Note number */
uint32 time[128]; /* exec time of most recent NoteOn */
uint32 extseq[128]; /* extended seqnum for that NoteOn */
uint8 vel[128]; /* NoteOn velocity (0 for NoteOff) */
uint32 time[128]; /* exec time of most recent NoteOn */ uint32 extseq[128]; /* extended seqnum for that NoteOn */ uint8 vel[128]; /* NoteOn velocity (0 for NoteOff) */
} jrec_chaptern;
} jrec_chaptern;
/*****************************************************************/
/* leaf level of hierarchy: Chapter C, Appendix A.3 of [RFC4695] */
/*****************************************************************/
/*****************************************************************/ /* leaf level of hierarchy: Chapter C, Appendix A.3 of [RFC4695] */ /*****************************************************************/
typedef struct jrec_chapterc { /* Control Change (0xB) */
typedef struct jrec_chapterc { /* Control Change (0xB) */
/* array of length 128 --> one for each controller number */
/* array of length 128 --> one for each controller number */
uint8 value[128]; /* Chapter C value tool state */
uint8 count[128]; /* Chapter C count tool state */
uint8 toggle[128]; /* Chapter C toggle tool state */
uint8 value[128]; /* Chapter C value tool state */ uint8 count[128]; /* Chapter C count tool state */ uint8 toggle[128]; /* Chapter C toggle tool state */
} jrec_chapterc;
} jrec_chapterc;
Figure 10. Recovery Journal Receiving Structure (part 1)
Figure 10. Recovery Journal Receiving Structure (part 1)
Lazzaro & Wawrzynek Informational [Page 28] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 28] RFC 4696 An Implementation Guide for RTP MIDI November 2006
/*****************************************************************/
/* leaf level of hierarchy: Chapter P, Appendix A.2 of [RFC4695] */
/*****************************************************************/
/*****************************************************************/ /* leaf level of hierarchy: Chapter P, Appendix A.2 of [RFC4695] */ /*****************************************************************/
typedef struct jrec_chapterp { /* MIDI Program Change (0xC) */
typedef struct jrec_chapterp { /* MIDI Program Change (0xC) */
uint8 prognum; /* most recent 7-bit program value */
uint8 prognum_qual; /* 1 once first 0xC command arrives */
uint8 prognum; /* most recent 7-bit program value */ uint8 prognum_qual; /* 1 once first 0xC command arrives */
uint8 bank_msb; /* most recent Bank Select MSB value */
uint8 bank_msb_qual; /* 1 once first 0xBn 0x00 arrives */
uint8 bank_msb; /* most recent Bank Select MSB value */ uint8 bank_msb_qual; /* 1 once first 0xBn 0x00 arrives */
uint8 bank_lsb; /* most recent Bank Select LSB value */
uint8 bank_lsb_qual; /* 1 once first 0xBn 0x20 arrives */
uint8 bank_lsb; /* most recent Bank Select LSB value */ uint8 bank_lsb_qual; /* 1 once first 0xBn 0x20 arrives */
} jrec_chapterp;
} jrec_chapterp;
/***************************************************/
/* second-level of hierarchy, for MIDI channels */
/***************************************************/
/***************************************************/ /* second-level of hierarchy, for MIDI channels */ /***************************************************/
typedef struct jrec_channel {
typedef struct jrec_channel {
jrec_chapterp chapterp; /* Program Change (0xC) info */
jrec_chapterc chapterc; /* Control Change (0xB) info */
jrec_chapterw chapterw; /* Pitch Wheel (0xE) info */
jrec_chaptern chaptern; /* Note (0x8, 0x9) info */
jrec_chapterp chapterp; /* Program Change (0xC) info */ jrec_chapterc chapterc; /* Control Change (0xB) info */ jrec_chapterw chapterw; /* Pitch Wheel (0xE) info */ jrec_chaptern chaptern; /* Note (0x8, 0x9) info */
} jrec_channel;
} jrec_channel;
/***********************************************/
/* top level of hierarchy, for the MIDI stream */
/***********************************************/
/***********************************************/ /* top level of hierarchy, for the MIDI stream */ /***********************************************/
typedef struct jrec_stream {
typedef struct jrec_stream {
jrec_channel channels[16]; /* index is MIDI channel */
jrec_channel channels[16]; /* index is MIDI channel */
} jrec_stream;
} jrec_stream;
Figure 10. Recovery Journal Receiving Structure (part 2)
Figure 10. Recovery Journal Receiving Structure (part 2)
Lazzaro & Wawrzynek Informational [Page 29] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 29] RFC 4696 An Implementation Guide for RTP MIDI November 2006
7.1. Chapter W: MIDI Pitch Wheel (0xE)
7.1. Chapter W: MIDI Pitch Wheel (0xE)
Chapter W of the recovery journal protects against the loss of MIDI Pitch Wheel (0xE) commands. A common use of the Pitch Wheel command is to transmit the current position of a rotary "pitch wheel" controller placed on the side of MIDI piano controllers. Players use the pitch wheel to dynamically alter the pitch of all depressed keys.
Chapter W of the recovery journal protects against the loss of MIDI Pitch Wheel (0xE) commands. A common use of the Pitch Wheel command is to transmit the current position of a rotary "pitch wheel" controller placed on the side of MIDI piano controllers. Players use the pitch wheel to dynamically alter the pitch of all depressed keys.
The NMP receiver maintains the jrec_chapterw structure (Figure 10) for each voice channel in jrec_stream to code pitch wheel state information. In jrec_chapterw, val holds the 14-bit data value of the most recent Pitch Wheel command that has arrived on a channel. At the start of the stream, val is initialized to the default pitch wheel value (0x2000).
The NMP receiver maintains the jrec_chapterw structure (Figure 10) for each voice channel in jrec_stream to code pitch wheel state information. In jrec_chapterw, val holds the 14-bit data value of the most recent Pitch Wheel command that has arrived on a channel. At the start of the stream, val is initialized to the default pitch wheel value (0x2000).
At the end of a loss event, a receiver may find a Chapter W (Appendix A.5 in [RFC4695]) bitfield in a channel journal. This chapter codes the 14-bit data value of the most recent MIDI Pitch Wheel command in the checkpoint history. If the Chapter W and jrec_chapterw pitch wheel values do not match, one or more commands have been lost.
At the end of a loss event, a receiver may find a Chapter W (Appendix A.5 in [RFC4695]) bitfield in a channel journal. This chapter codes the 14-bit data value of the most recent MIDI Pitch Wheel command in the checkpoint history. If the Chapter W and jrec_chapterw pitch wheel values do not match, one or more commands have been lost.
To recover from this loss, the NMP receiver immediately executes a MIDI Pitch Wheel command on the channel, using the data value coded in the recovery journal. The receiver then updates the jrec_chapterw variables to reflect the executed command.
To recover from this loss, the NMP receiver immediately executes a MIDI Pitch Wheel command on the channel, using the data value coded in the recovery journal. The receiver then updates the jrec_chapterw variables to reflect the executed command.
7.2. Chapter N: MIDI NoteOn (0x8) and NoteOff (0x9)
7.2. Chapter N: MIDI NoteOn (0x8) and NoteOff (0x9)
Chapter N of the recovery journal protects against the loss of MIDI NoteOn (0x9) and NoteOff (0x8) commands. If a NoteOn command is lost, a note is skipped. If a NoteOff command is lost, a note may sound indefinitely. Recall that NoteOn commands with a velocity value of 0 have the semantics of NoteOff commands.
Chapter N of the recovery journal protects against the loss of MIDI NoteOn (0x9) and NoteOff (0x8) commands. If a NoteOn command is lost, a note is skipped. If a NoteOff command is lost, a note may sound indefinitely. Recall that NoteOn commands with a velocity value of 0 have the semantics of NoteOff commands.
The recovery algorithms in this section only work for MIDI sources that produce NoteOn->NoteOff->NoteOn->NoteOff patterns for a note number. Piano keyboard and drum pad controllers produce these patterns. MIDI sources that use NoteOn->NoteOn->NoteOff->NoteOff patterns for legato repeated notes, such as guitar and wind controllers, require more sophisticated recovery strategies. Chapter E (not used in this example) supports recovery algorithms for atypical note command patterns (see Appendix A.7 of [RFC4695] for details).
The recovery algorithms in this section only work for MIDI sources that produce NoteOn->NoteOff->NoteOn->NoteOff patterns for a note number. Piano keyboard and drum pad controllers produce these patterns. MIDI sources that use NoteOn->NoteOn->NoteOff->NoteOff patterns for legato repeated notes, such as guitar and wind controllers, require more sophisticated recovery strategies. Chapter E (not used in this example) supports recovery algorithms for atypical note command patterns (see Appendix A.7 of [RFC4695] for details).
The NMP receiver maintains a jrec_chaptern structure (Figure 10) for each voice channel in jrec_stream to code note-related state information. State is kept for each of the 128 note numbers on a
The NMP receiver maintains a jrec_chaptern structure (Figure 10) for each voice channel in jrec_stream to code note-related state information. State is kept for each of the 128 note numbers on a
Lazzaro & Wawrzynek Informational [Page 30] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 30] RFC 4696 An Implementation Guide for RTP MIDI November 2006
channel, using three arrays of length 128 (vel[], seq[], and time[]). The arrays are initialized to zero at the start of a stream.
channel, using three arrays of length 128 (vel[], seq[], and time[]). The arrays are initialized to zero at the start of a stream.
The vel[n] array element holds information about the most recent note command for note number n. If this command is a NoteOn command, vel[n] holds the velocity data for the command. If this command is a NoteOff command, vel[n] is set to 0.
The vel[n] array element holds information about the most recent note command for note number n. If this command is a NoteOn command, vel[n] holds the velocity data for the command. If this command is a NoteOff command, vel[n] is set to 0.
The time[n] and extseq[n] array elements code information about the most recently executed NoteOn command. The time[n] element holds the execution time of the command, referenced to the local timebase of the receiver. The extseq[n] element holds the RTP extended sequence number of the packet associated with the command. For incoming stream commands, extseq[n] codes the packet of the associated MIDI list. For commands executed to perform loss recovery, extseq[n] codes the packet of the associated recovery journal.
The time[n] and extseq[n] array elements code information about the most recently executed NoteOn command. The time[n] element holds the execution time of the command, referenced to the local timebase of the receiver. The extseq[n] element holds the RTP extended sequence number of the packet associated with the command. For incoming stream commands, extseq[n] codes the packet of the associated MIDI list. For commands executed to perform loss recovery, extseq[n] codes the packet of the associated recovery journal.
The Chapter N recovery journal bitfield (Figure A.6.1 in [RFC4695]) consists of two data structures: a bit array coding recently sent NoteOff commands that are vulnerable to packet loss, and a note log list coding recently sent NoteOn commands that are vulnerable to packet loss.
The Chapter N recovery journal bitfield (Figure A.6.1 in [RFC4695]) consists of two data structures: a bit array coding recently sent NoteOff commands that are vulnerable to packet loss, and a note log list coding recently sent NoteOn commands that are vulnerable to packet loss.
At the end of a loss event, Chapter N recovery processing begins with the NoteOff bit array. For each set bit in the array, the receiver checks the corresponding vel[n] element in jrec_chaptern. If vel[n] is non-zero, a NoteOff command or a NoteOff->NoteOn->NoteOff command sequence has been lost. To recover from this loss, the receiver immediately executes a NoteOff command for the note number on the channel and sets vel[n] to 0.
At the end of a loss event, Chapter N recovery processing begins with the NoteOff bit array. For each set bit in the array, the receiver checks the corresponding vel[n] element in jrec_chaptern. If vel[n] is non-zero, a NoteOff command or a NoteOff->NoteOn->NoteOff command sequence has been lost. To recover from this loss, the receiver immediately executes a NoteOff command for the note number on the channel and sets vel[n] to 0.
The receiver then parses the note log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk note log, the receiver checks the corresponding vel[n] element.
The receiver then parses the note log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk note log, the receiver checks the corresponding vel[n] element.
If vel[n] is zero, a NoteOn command or a NoteOn->NoteOff->NoteOn command sequence has been lost. The receiver may execute the most recent lost NoteOn (to play the note) or may take no action (to skip the note), based on criteria we describe at the end of this section. Whether the note is played or skipped, the receiver updates the vel[n], time[n], and extseq[n] elements as if the NoteOn executed.
If vel[n] is zero, a NoteOn command or a NoteOn->NoteOff->NoteOn command sequence has been lost. The receiver may execute the most recent lost NoteOn (to play the note) or may take no action (to skip the note), based on criteria we describe at the end of this section. Whether the note is played or skipped, the receiver updates the vel[n], time[n], and extseq[n] elements as if the NoteOn executed.
If vel[n] is non-zero, the receiver performs several checks to test if a NoteOff->NoteOn sequence has been lost.
If vel[n] is non-zero, the receiver performs several checks to test if a NoteOff->NoteOn sequence has been lost.
o If vel[n] does not match the note log velocity, the note log must
code a different NoteOn command, and thus a NoteOff->NoteOn
sequence has been lost.
o If vel[n] does not match the note log velocity, the note log must code a different NoteOn command, and thus a NoteOff->NoteOn sequence has been lost.
Lazzaro & Wawrzynek Informational [Page 31] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 31] RFC 4696 An Implementation Guide for RTP MIDI November 2006
o If extseq[n] is less than the (extended) checkpoint packet
sequence numbed coded in the recovery journal header (Figure 8 of
[RFC4695]), the vel[n] NoteOn command is not in the checkpoint
history, and thus a NoteOff->NoteOn sequence has been lost.
o If extseq[n] is less than the (extended) checkpoint packet sequence numbed coded in the recovery journal header (Figure 8 of [RFC4695]), the vel[n] NoteOn command is not in the checkpoint history, and thus a NoteOff->NoteOn sequence has been lost.
o If the Y bit is set to 1, the NoteOn is musically "simultaneous"
with the RTP timestamp of the packet. If time[n] codes a time
value that is clearly not recent, a NoteOff->NoteOn sequence has
been lost.
o If the Y bit is set to 1, the NoteOn is musically "simultaneous" with the RTP timestamp of the packet. If time[n] codes a time value that is clearly not recent, a NoteOff->NoteOn sequence has been lost.
If these tests indicate a lost NoteOff->NoteOn sequence, the receiver immediately executes a NoteOff command. The receiver decides if the most graceful action is to play or to skip the lost NoteOn, using the criteria we describe at the end of this section. Whether or not the receiver issues a NoteOn command, the vel[n], time[n], and extseq[n] arrays are updated as if it did.
If these tests indicate a lost NoteOff->NoteOn sequence, the receiver immediately executes a NoteOff command. The receiver decides if the most graceful action is to play or to skip the lost NoteOn, using the criteria we describe at the end of this section. Whether or not the receiver issues a NoteOn command, the vel[n], time[n], and extseq[n] arrays are updated as if it did.
Note that the tests above do not catch all lost NoteOff->NoteOn commands. If a fast NoteOn->NoteOff->NoteOn sequence occurs on a note number with identical velocity values for both NoteOn commands, a lost NoteOff->NoteOn does not result in the recovery algorithm generating a NoteOff command. Instead, the first NoteOn continues to sound, to be terminated by the future NoteOff command. In practice, this (rare) outcome is not musically objectionable.
Note that the tests above do not catch all lost NoteOff->NoteOn commands. If a fast NoteOn->NoteOff->NoteOn sequence occurs on a note number with identical velocity values for both NoteOn commands, a lost NoteOff->NoteOn does not result in the recovery algorithm generating a NoteOff command. Instead, the first NoteOn continues to sound, to be terminated by the future NoteOff command. In practice, this (rare) outcome is not musically objectionable.
The number of tests in this resiliency algorithm may seem excessive. However, in some common cases, a subset of the tests is not useful. For example, MIDI streams that assigns the same velocity value to all note events are often produced by inexpensive keyboards. The vel[n] tests are not useful for these streams.
The number of tests in this resiliency algorithm may seem excessive. However, in some common cases, a subset of the tests is not useful. For example, MIDI streams that assigns the same velocity value to all note events are often produced by inexpensive keyboards. The vel[n] tests are not useful for these streams.
Finally, we discuss how the receiver decides whether to play or to skip a lost NoteOn command. The note log Y bit is set if the NoteOn is "simultaneous" with the RTP timestamp of the packet holding the note log. If Y is 0, the receiver does not execute a NoteOn command. If Y is 1, and if the packet has not arrived late, the receiver immediately executes a NoteOn command for the note number, using the velocity coded in the note log.
Finally, we discuss how the receiver decides whether to play or to skip a lost NoteOn command. The note log Y bit is set if the NoteOn is "simultaneous" with the RTP timestamp of the packet holding the note log. If Y is 0, the receiver does not execute a NoteOn command. If Y is 1, and if the packet has not arrived late, the receiver immediately executes a NoteOn command for the note number, using the velocity coded in the note log.
7.3. Chapter C: MIDI Control Change (0xB)
7.3. Chapter C: MIDI Control Change (0xB)
Chapter C (Appendix A.3 in [RFC4695]) protects against the loss of MIDI Control Change commands. A Control Change command alters the 7-bit value of one of the 128 MIDI controllers.
Chapter C (Appendix A.3 in [RFC4695]) protects against the loss of MIDI Control Change commands. A Control Change command alters the 7-bit value of one of the 128 MIDI controllers.
Chapter C offers three tools for protecting a Control Change command: the value tool (for graded controllers such as sliders), the toggle tool (for on/off switches), and the count tool (for momentary-contact
Chapter C offers three tools for protecting a Control Change command: the value tool (for graded controllers such as sliders), the toggle tool (for on/off switches), and the count tool (for momentary-contact
Lazzaro & Wawrzynek Informational [Page 32] RFC 4696 An Implementation Guide for RTP MIDI November 2006
Lazzaro & Wawrzynek Informational [Page 32] RFC 4696 An Implementation Guide for RTP MIDI November 2006
switches). Senders choose a tool to encode recovery information for a controller and encode the tool type along with the data in the journal (Figures A.3.2 and A.3.3 in [RFC4695]).
switches). Senders choose a tool to encode recovery information for a controller and encode the tool type along with the data in the journal (Figures A.3.2 and A.3.3 in [RFC4695]).
A few uses of Control Change commands are not solely protected by Chapter C. The protection of controllers 0 and 32 (Bank Select MSB and Bank Select LSB) is shared between Chapter C and Chapter P (Section 7.4).
A few uses of Control Change commands are not solely protected by Chapter C. The protection of controllers 0 and 32 (Bank Select MSB and Bank Select LSB) is shared between Chapter C and Chapter P (Section 7.4).
Chapter M (Appendix A.4 of [RFC4695]) also protects the Control Change command. However, the NMP system does not use this chapter, because MPEG 4 Structured Audio [MPEGSA] does not use the controllers protected by this chapter.
Chapter M (Appendix A.4 of [RFC4695]) also protects the Control Change command. However, the NMP system does not use this chapter, because MPEG 4 Structured Audio [MPEGSA] does not use the controllers protected by this chapter.
The Chapter C bitfield consists of a list of controller logs. Each log codes the controller number, the tool type, and the state value for the tool.
The Chapter C bitfield consists of a list of controller logs. Each log codes the controller number, the tool type, and the state value for the tool.
The NMP receiver maintains the jrec_chapterc structure (Figure 10) for each voice channel in jrec_stream to code Control Change state information. The value[] array holds the most recent data values for each controller number. At the start of the stream, value[] is initialized to the default controller data values specified in [MPEGSA].
The NMP receiver maintains the jrec_chapterc structure (Figure 10) for each voice channel in jrec_stream to code Control Change state information. The value[] array holds the most recent data values for each controller number. At the start of the stream, value[] is initialized to the default controller data values specified in [MPEGSA].
The count[] and toggle[] arrays hold the count tool and toggle tool state values. At the start of a stream, these arrays are initialized to zero. Whenever a Control Command executes, the receiver updates the count[] and toggle[] state values, using the algorithms defined in Appendix A.3 of [RFC4695].
The count[] and toggle[] arrays hold the count tool and toggle tool state values. At the start of a stream, these arrays are initialized to zero. Whenever a Control Command executes, the receiver updates the count[] and toggle[] state values, using the algorithms defined in Appendix A.3 of [RFC4695].
At the end of a loss event, the receiver parses the Chapter C controller log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk controller number n, the receiver determines the tool type in use (value, toggle, or count) and compares the data in the log to the associated jrec_chapterc array element (value[n], toggle[n], or count[n]). If the data do not match, one or more Control Change commands have been lost.
At the end of a loss event, the receiver parses the Chapter C controller log list, using the S bit to skip over "safe" logs in the single-packet loss case. For each at-risk controller number n, the receiver determines the tool type in use (value, toggle, or count) and compares the data in the log to the associated jrec_chapterc array element (value[n], toggle[n], or count[n]). If the data do not match, one or more Control Change commands have been lost.
The method the receiver uses to recover from this loss depends on the tool type and the controller number. For graded controllers protected by the value tool, the receiver executes a Control Change command using the new data value.
受信機がこの損失から回復するのに使用するメソッドはツールタイプとコントローラ番号に頼っています。 値のツールによって保護された等級付けされたコントローラに関しては、受信機は、新しいデータ値を使用することでControl Changeコマンドを実行します。
For the toggle and count tools, the recovery action is more complex. For example, the Damper Pedal (Sustain) controller (number 64) is typically used as a sustain pedal for piano-like sounds and is typically coded using the toggle tool. If Damper Pedal (Sustain)
トグルとカウントツールにおいて、回復動きは、より複雑です。 例えば、Damper Pedal(支える)コントローラ(No.64)は、aがピアノのような音のためにペダルを支えるとき通常使用されて、トグルツールを使用することで通常コード化されます。 より湿るなら、ペダルを踏んでください。(支えます)
Lazzaro & Wawrzynek Informational [Page 33] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実装ガイドあたりWawrzynekの情報[33ページ]のRFC4696
Control Change commands are lost, the receiver takes different actions depending on the starting and ending state of the lost sequence, to ensure that "ringing" piano notes are "damped" to silence.
規制Change命令が無くなる、受信機は黙らせる「鳴る」ピアノ注意が「じめじめとすること」を保証するために無くなっている系列の始めの、そして、終わりの事情に依存する異なった行動を取ります。
After recovering from the loss, the receiver updates the value[], toggle[], and count[] arrays to reflect the Chapter C data and the executed commands.
損失から回復した後に、受信機は、章のCデータと実行されたコマンドを反映するために値[]、トグル[]、およびカウント[]配列をアップデートします。
7.4. Chapter P: MIDI Program Change (0xC)
7.4. 章P: ミディプログラム変化(0xC)
Chapter P of the recovery journal protects against the loss of MIDI Program Change (0xC) commands.
回復ジャーナルの章PはMIDI Program Change(0xC)コマンドの損失から守ります。
The 7-bit data value of the Program Change command selects one of 128 possible timbres for the channel. To increase the number of possible timbres, Control Change (0xB) commands may be issued prior to the Program Change command to select a "program bank". The Bank Select MSB (number 0) and Bank Select LSB (number 32) controllers specify the 14-bit bank number that subsequent Program Change commands reference.
Program Changeコマンドの7ビットのデータ値はチャンネルのために128回の可能な音色の1つを選択します。 可能な音色の数を増強するために、「プログラム銀行」を選択するProgram Changeコマンドの前にControl Change(0xB)コマンドを発行するかもしれません。 Bank Select MSB(No.0)とBank Select LSB(No.32)コントローラはその後のProgram Changeコマンドが参照をつける14ビットの銀行番号を指定します。
The NMP receiver maintains the jrec_chapterp structure (Figure 10) for each voice channel in jrec_stream to code Program Change state information.
jrec_ストリームにおけるそれぞれの音声チャンネルがProgram Change州の情報をコード化するように、NMP受信機はjrec_chapterp構造(図10)を維持します。
The prognum variable of jrec_chapterp holds the data value for the most recent Program Change command that has arrived on the stream. The bank_msb and bank_lsb variables of jrec_chapterp code the Bank Select MSB and Bank Select LSB controller data values that were in effect when that Program Change command arrived. The prognum_qual, bank_msb_qual, and bank_lsb_qual variables are initialized to 0 and are set to 1 to qualify the associated data values.
jrec_chapterpのprognum変数はストリームで到着した最新のProgram Changeコマンドのためのデータ値を保持します。 jrec_chapterpの銀行_msbと銀行_lsb変数は事実上そのProgram Changeコマンドが到着した時であるBank Select MSBとBank Select LSBコントローラデータ値をコード化します。 prognum_qual、銀行_msb_qual、および銀行_lsb_qual変数は、0に初期化されて、関連データ値に資格を与えるように1に用意ができています。
Chapter P fields code the data value for the most recent Program Change command, and the MSB and LSB bank values in effect for that command.
章P 事実上、分野はそのコマンドのために最新のProgram Changeコマンドのためのデータ値、MSB、およびLSB銀行値をコード化します。
At the end of a loss event, the receiver checks Chapter P to see if the recovery journal fields match the data stored in jrec_chapterp. If these checks fail, one or more Program Change commands have been lost.
損失イベントの終わりでは、受信機は、回復ジャーナル分野がjrec_chapterpに保存されたデータに合っているかどうか確認するために章Pをチェックします。 これらのチェックが失敗するなら、1つ以上のProgram Changeコマンドが失われました。
To recover from this loss, the receiver takes the following steps. If the B bit in Chapter P is set (Figure A.2.1 in [RFC4695]), Control Change bank commands have preceded the Program Change command. The receiver compares the bank data coded by Chapter P with the current bank data for the channel (coded in jrec_channelc).
この損失から回復するために、受信機は以下の方法を採ります。 章PのBビットが設定されるなら([RFC4695]の図A.2.1)、Control Change銀行コマンドはProgram Changeコマンドに先行しました。 受信機はチャンネル(jrec_channelcでは、コード化される)のために現在の銀行データで章Pコード化された銀行データを比較します。
Lazzaro & Wawrzynek Informational [Page 34] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実装ガイドあたりWawrzynekの情報[34ページ]のRFC4696
If the bank data do not agree, the receiver issues Control Change commands to align the stream with Chapter P. The receiver then updates jrec_channelp and jrec_channelc variables to reflect the executed command(s). Finally, the receiver issues a Program Change command that reflects the data in Chapter P and updates the prognum and qual_prognum fields in jrec_channelp.
銀行データが同意しないなら、受信機は章P.にストリームを一直線にするコマンドをControl Changeに発行します。次に、受信機は、実行されたコマンドを反映するためにjrec_channelpとjrec_channelc変数をアップデートします。 最終的に、受信機はjrec_channelpのprognumとqual_prognum分野を章Pとアップデートにデータを反映するProgram Changeコマンドに発行します。
Note that this method relies on Chapter P recovery to precede Chapter C recovery during channel journal processing. This ordering ensures that lost Bank Select Control Change commands that occur after a lost Program Change command in a stream are handled correctly.
このメソッドがチャンネルジャーナル処理の間、章C 回復に先行するために章P 回復を当てにすることに注意してください。 この注文は、ストリームにおける無くなっているProgram Changeコマンドの後に起こる無くなっているBank Select Control Changeコマンドが正しく扱われるのを確実にします。
8. Security Considerations
8. セキュリティ問題
Security considerations for the RTP MIDI payload format are discussed in the Security Considerations section of [RFC4695].
[RFC4695]のSecurity Considerations部でRTP MIDIペイロード形式のためのセキュリティ問題について議論します。
9. IANA Considerations
9. IANA問題
IANA considerations for the RTP MIDI payload format are discussed in the IANA Considerations section of [RFC4695].
[RFC4695]のIANA Considerations部でRTP MIDIペイロード形式のためのIANA問題について議論します。
10. Acknowledgements
10. 承認
This memo was written in conjunction with [RFC4695], and the Acknowledgements section of [RFC4695] also applies to this memo.
このメモはまた[RFC4695]のセクションがこのメモに当てはまる[RFC4695]、およびAcknowledgementsに関連して書かれました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for
MIDI", RFC 4695, November 2006.
[RFC4695] LazzaroとJ.とJ.Wawrzynek、「ミディのためのRTP有効搭載量形式」、RFC4695、2006年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0
Detailed Specification", 1996.
[ミディ]ミディメーカー協会。 「完全なミディ1.0仕様詳細」、1996。
Lazzaro & Wawrzynek Informational [Page 35] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実装ガイドあたりWawrzynekの情報[35ページ]のRFC4696
[MPEGSA] International Standards Organization. "ISO/IEC 14496
MPEG-4", Part 3 (Audio), Subpart 5 (Structured Audio),
2001.
[MPEGSA]世界規格組織。 「ISO/IECの14496MPEG-4インチ、パート3(オーディオ)、下位区分5(オーディオを構造化します)、2001。」
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
3556, July 2003.
[RFC3556] Casner、S.、「RTP制御プロトコル(RTCP)帯域幅へのセッション記述プロトコル(SDP)帯域幅修飾語」、RFC3556、2003年7月。
11.2. Informative References
11.2. 有益な参照
[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network Musical
Performance", 11th International Workshop on Network and
Operating Systems Support for Digital Audio and Video
(NOSSDAV 2001) June 25-26, 2001, Port Jefferson, New York.
[NMP] Lazzaro、J.、およびJ.Wawrzynek。 「ネットワーク演奏のためのケース」、ネットワークに関する第11国際ワークショップ、およびオペレーティングシステムはデジタル・オーディオとビデオ(NOSSDAV2001)のために2001年6月25日〜26日、ポート・ジェファーソン、ニューヨークをサポートします。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical
Events Streaming over Internet", Proceedings of the
International Conference on WEB Delivering of Music 2001,
pages 147-154.
[GRAME] Fober、D.、Orlarey、Y.、およびS.レッツ。 「インターネットの上の本当のTime Musical Events Streaming」、Music2001、147-154ページのWEB Deliveringの上の国際コンファレンスのProceedings。
[CCRMA] Chafe C., Wilson S., Leistikow R., Chisholm D., and G.
Scavone. "A simplified approach to high quality music and
sound over IP", COST-G6 Conference on Digital Audio Effects
(DAFx-00), Verona, Italy, December 2000.
[CCRMA]はC.、ウィルソンS.、ライスティコーR.、チスホルムD.、およびG.Scavoneを擦りむきます。 「高品質の音楽と音へのIPの上の簡単なアプローチ」、デジタル・オーディオEffects(DAFx-00)、ベロナ(イタリア)(2000年12月)のCOST-G6コンファレンス。
[RTPBOOK] Perkins, C. "RTP: Audio and Video for the Internet",
Addison-Wesley, ISBN 0-672-32249-8, 2003.
[RTPBOOK]パーキンス、C.、「RTP:」 「インターネットへのオーディオとビデオ」、アディソン-ウエスリー、ISBN0-672-32249-8、2003
[STEVENS] Stevens, R. W, Fenner, B., and A. Rudoff. "Unix Network
Programming: The Sockets Networking API", Addison-Wesley,
2003.
[スティーブンス]スティーブンス、R.W、フェナー、B.、およびA.Rudoff。 「以下をプログラムするunixネットワーク」 「APIをネットワークでつなぐソケット」、アディソン-ウエスリー、2003。
Lazzaro & Wawrzynek Informational [Page 36] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実装ガイドあたりWawrzynekの情報[36ページ]のRFC4696
Authors' Addresses
作者のアドレス
John Lazzaro (corresponding author) UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
ジョンLazzaro(対応する作者)UCバークレーCS事業部315Soda Hallバークレーカリフォルニア94720-1776
EMail: lazzaro@cs.berkeley.edu
メール: lazzaro@cs.berkeley.edu
John Wawrzynek UC Berkeley CS Division 631 Soda Hall Berkeley CA 94720-1776
ジョンWawrzynek UCバークレーのCs区画631ソーダホールバークレーカリフォルニア94720-1776
EMail: johnw@cs.berkeley.edu
メール: johnw@cs.berkeley.edu
Lazzaro & Wawrzynek Informational [Page 37] RFC 4696 An Implementation Guide for RTP MIDI November 2006
RTPミディ2006年11月のためのLazzaroと実装ガイドあたりWawrzynekの情報[37ページ]のRFC4696
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lazzaro & Wawrzynek Informational [Page 38]
Lazzaro&Wawrzynek情報です。[38ページ]
一覧
スポンサーリンク
