AVBインフォメーション　|　ネットワーク・オーディオの優位性　|　AVB / Milan規格
　ネットワーク・オーディオの比較　|　AVBのテクノロジー　|　AVBの優位性

オーディオ・チャンネル数

1 GigE link：500チャンネル以上

 

ストリームの概念

MADIが125MBit/sで伝送されるのに対して、ネットワーク・ソリューションは1 GBit/sを使用してより多くのチャンネル数（500チャンネル以上）を伝送します。さらにMADIは常に全帯域を使用するのに対して、ネットワーク・オーディオ機器は必要なチャンネルだけ使用するため、ごく僅かな帯域のみを使用します。

ここでは「ストリーム」という概念を理解することが重要です。ネットワーク・オーディオのストリームとは、一つのマルチコア・ケーブルと考えて良いでしょう。一つのストリームはチャンネル数が一定で、必要のないチャンネルも含めて全チャンネルが常に伝送されます。例えばMADI信号の場合64チャンネルが1つのストリームです。１つのチャンネルのみ伝送する場合も64チャンネルが伝送され、残りの63チャンネルはオーディオ・データを含みません。

ストリームを使用してオーディオ・チャンネルをグループ化し、論理要素にまとめることにより、ネットワーク上のオーディオ伝送をより効率的かつ容易に監視することができます。

 

レイテンシー（遅延）の定義

• 6msまでのレイテンシー（聴覚認識に影響を与えないと言われる範囲）
• アナログ・コンバーターのレイテンシー（一般的には0.4ms）
• DSPレイテンシー（0.1ms〜数ms）
• リンク・オフセット（MADI＝0.08ms、ネットワーク・オーディオ=1ms）

MADIの送受信に置けるレイテンシーはわずか4サンプルもしくは83usです。レイテンシーは、例えばマイクの前でヘッドフォンで音声を確認しながら歌う場合などに影響します。一般的な見解としては6msまでのレイテンシーは聴覚認識に影響を与えないという研究結果があります。

この6msの中には、例えばスピードの異なるネットワーク内の複数のネットワーク・ストリームや、シグナル・プロセッサー、アナログ・コンバーターなどの信号伝達の全てのファクターが含まれることを意識する必要があります。最近のDAWで高性能なインターフェイスを使用した場合、2ms〜5msのレイテンシーが生じます。

Danteデバイスは一般的に1msのレイテンシー設定を使用し、これは「入力オーディオ・サンプルのタイムスタンプ情報が再生されるまでの時間」を指します。シンプルなA/D入力の様な100MBit/sの送信には受信側で最低1msのレイテンシー設定が必要になります。またマルチキャスト接続の場合、常に1ms以上のレイテンシーが生じます。 AES-67の場合、ネットワーク・ストリームで発生するレイテンシーを「リンク・オフセット」と呼び、これは、設定可能なパケット時間とネットワーク転送時間で構成されています。受信側にも設定され、パケット時間だけの場合はデフォルトで1msになります。全体の遅延はそれにマイクロ秒の1/2程度上乗せします。

AVBの場合には、上記とは違った方法で動作します。

 

AVBネットワークのレイテンシー

• スイッチがgPTP（IEEE 802.1AS）による時間管理された伝送を実行（ナノセカンド精度）
• 時間軸に対するオフセット情報（最大の伝送時間）をソースに追加
• 出力は発音タイミングまでオーディオをバッファー

「プレゼンテーション・タイムによる極めて正確な時間情報」

AVBおよびMILANデバイス（スイッチを含む）は、IEEE802ネットワーク上でgPTP（generalized precision time protocol）と呼ばれるPTP標準のサブセットを使用することで、極めて正確な時間情報を共有します。

これにより送信デバイス（トーカー）は、各オーディオ・サンプルが受信側（リスナー）で再生されるタイミングを指定することができます。送信時に時間オフセットが各サンプルに付与され伝送されることで、受信側は最終的な発音タイミングを把握することができ、受信したタイムスタンプを元に発音を行います。ナノセカンド精度のこのタイムスタンプは、「プレゼンテーション・タイム」と呼ばれます。

受信側は入力された各サンプルのプレゼンテーション・タイムを現在時刻と比較し、プレゼンテーション・タイムが訪れるまでサンプルをバッファーします。

このオフセット（最大伝送時間）は、AVB標準規格で2 ms（クラスAトラフィック）と定められています。これは6台の100 MBit/sスイッチを経由する非常に大規模なネットワークでも十分な長さです。ほとんどのAVB製品は、初期設定でこのオフセット機能が有効に設定されています。ホップ数の少ない、またはリンク・スピードが1 Gbit/sの小規模なネットワークを使用する場合は、オフセットの値を0.3 ms、0.6 ms、1 msなど、より低く調整することが可能です。受信した時点でプレゼンテーション・タイムを過ぎてしまったオーディオ・データは破棄されます（オフセット設定が低すぎた場合など）。 

 

入力遅延

例：Digiface AVB

「最大伝送時間」のオフセットが送信側で付与されることに注目してください。受信側はこのオフセットではなく、現在時刻とプレゼンテーション・タイムのみを認識します。ネットワークが要求通りに機能しているかを確認するため、オフセット時間の計測/表示も可能です。

RME Digiface AVBは入力ストリームに含まれるプレゼンテーション・タイムと現在時刻との差を計算し、結果をナノセカンド単位で表示します。

たとえば現在の時刻が1000、最大伝送時間が500のときに、Digiface AVBがプレゼンテーション・タイムが1500に指定されたストリームを1100の時刻に受信したとしましょう。 入力遅延は次のように計算されます：現在時刻（1100） -（マイナス） プレゼンテーション・タイム（1500）。したがって入力遅延は「-400」となります。つまり送信側から受信側への伝送に100の時間がかかったことになり、Digifaceは再生の時刻を400遅らせます。

MILANおよびAVBでは、最大伝送時間が2 msと規定されています。これは速度100 MBitでホップ数が7の大規模なネットワークを想定した時間です。実際は、デュアル・ギガビット・スイッチAVBネットワークを用いることでレイテンシーはより低くなり、300μsの設定でも問題ありません。 

 

クロックについて

AVB/MILANでは、プレゼンテーション・タイムが付与されたストリームが伝送され、すべてのデバイスがgPTPを使用します。これにより伝送先でのオーディオ再生の精度がDanteやRavennaなどIPベースのネットワークに比べ遙かに優れているのもAVB/MILANの特徴です。ネットワーク内の他のトラフィックとは完全に独立しているため、IPトラフィックとの混在も問題ありません。

AVBストリームは現在時刻だけでなく、もちろんワード・クロックなどのメディア・クロック信号も伝送します。メディア・クロックはMADI同様、受信ストリームから簡単に取り出すことが可能です。AVB/MILANネットワークでは、同じタイム・ドメインの複数のメディア・クロックをネットワーク内で混在させることも可能です。たとえば、わずかな周波数偏差や位相オフセットを持つ複数の96 kHzマスター・クロックを同じスイッチを経由させ、ストリーム用と再生用に個別に使用することもできます。

 

ネットワーク・マネージメント

「Credit Based Shaperによる安定したデータ・フロー」

AVBおよびMILANネットワークの非常に安定したネットワーク・パフォーマンスは、スイッチと密接な関係があります。

AVB標準では、スイッチは「Credit Based Shaper」と呼ばれるアルゴリズムによってフォワード・キューイングが実装されています。これにより、出力ネットワーク・ポートがオーディオ・トラフィックを確実に送出し（正確に125 μs毎にパケットを送信）、優先度の高いオーディオ・トラフィックの隙間に非オーディオ・トラフィックのパケットがスペースが許す限り追加されます。

ネットワークから安定したデータ・フローを得られない他のネットワーク・オーディオでは、VoIPやその他のオーディオ・トラフィックに優先度を付けるDiffServ QoSなどの技術を用いて伝送を行います。AVBと異なり遅延が一定の帯域幅を確保することができず、ITスタイルの設定/管理が必要となります。DiffServが自動設定できず、またスイッチによって実装された汎用的な機能でないことが原因です。

その結果、非AVBオーディオ・ネットワークでは、再生バッファーを受信側で常にモニターする必要があります。ネットワーク・のパフォーマンスが落ちた場合はユーザーがバッファー・サイズを調整しなければなりません（バッファー・サイズが大きくなるとレイテンシーも大きくなります）。それに対しAVBによるネットワークでは、非常に安定したデータ・フローが確保できるため、レイテンシーを送信側で指定することが可能になります。つまり、エンドポイントにおけるバッファー・モニタリングがそれほど重要でなくなります。これはギガビット・スイッチの場合、特に顕著です。一度ストリームが確立されると、ネットワーク上の他のトラフィックによって妨害されることがありません。

 

プラグ・アンド・プレイ

• 物理接続と論理接続が独立
• 検出機構

ポイント・トゥ・ポイントのMADI接続の大きな利点の１つに、検出スピードの速さがあります。MADIの使用経験がある方なら、ケーブルを接続した瞬間に信号が流れるのを体験済みでしょう。ネットワーク・オーディオ製品の場合、こうは行きません。使用される技術や実装によって異なりますが、伝送が中断してから復帰までに最大2分かかる場合もあります。

2台のデバイスを接続する場合、接続自体は簡単です。しかしケーブルを接続しただけではストリームは開始されません。物理接続の上層で、ソフトウェアによる論理接続が必要となります。

 

検出

物理的な接続が行われた後に接続を確立するには、まずデバイスの検出が必要になります。これにより同一ネットワーク内のデバイスがリスト・アップされます。リストはDanteではGUIで実装され、AVBやMILANはGUIなしで実装されます。AES-67やST2110はリスト自体が実装されません。そして検出の次には、ストリームを確立してデバイスを接続するメソッドが必要になります。

 

コントローラー

• Dante コントローラー / Dante
• コントローラー実装 Ember+/AES-70/NMOS / AES-67
• AVDECC コントローラー / AVB

ストリームを作成するにはコントローラーが必要です。

Danteネットワークでは、ソフトウェア・コントローラーをWindowsまたはMac OSにインストールする必要があります。他にはDanteデバイスと独立し、ネットワーク上のバーチャル・マシンで起動するDante Domain Managerを使用する方法もあります。

AES-67の場合は、制御プロトコルに適合したコントローラーを使用する必要があります。本記事執筆時点で汎用コントローラーは存在しないはずですが、複数の制御プロトコルに対応するコントローラーは存在します。

一方AVBでは、AVDECCと呼ばれるオープンな制御プロトコルがIEEE1722.1で策定されているため、各AVBデバイスにDante Controllerと同じ機能が実装されていることになります。つまりユーザーはウェブ・インターフェイスや機器のダイアログでDante Controllerと同様の設定が行えるのです。またHive、Riedel AVBマネージャーやMac OSに統合されたAVDECCコントローラーなど他のAVDECCコントローラーをWindowsまたはMac OSで起動することも可能です。すべてのコントローラーが同じ制御プロトコルを共有するため、まるで複数のDante ContollerがDanteネットワークで同時に起動しているかの様に使用することができます。 

 

チャンネル

ルーティング

• チャンネル・ツー・チャンネル
• チャンネル・ツー・ストリーム、ストリーム・ツー・チャンネル

コントローラーがデバイスを検出すると、使用するネットワーク・オーディオによって異なる2種類の方法で接続が確立されます。基本的にユーザーはオーディオ・チャンネルのみに関心があるため、チャンネルのストリームへの接続は自動で行われます（ユーザーによる設定も可能です）。

MADI入力を搭載するAVBデバイスを使用すれば、SMPTE 2110/AES67やAVBで定義された64チャンネルのシングル・ストリームを伝送することができます。また、たとえば1、2、5、47チャンネルを4チャンネルの連続したチャンネル・ストリームまたはDante信号として伝送することもできます。このとき残りの帯域幅は他の接続用に確保することも可能です。

Danteでこれを行う場合は、ストリーム（フロー）について考える必要はありません（コントローラーがファンアウト状況を検出しストリームをマルチキャストに変更する場合を除く）。接続する2つのデバイスからの4つの独立チャンネルを接続するだけです。AVBデバイスでは、まずはじめに本記事で紹介したようにストリーム・サイズを決定し、必要なチャンネルをストリームへとルーティングします。受信側でも同じ手順を行います。全てのストリームを8チャンネル・ストリームまたは4チャンネル・ストリームにするかは、エンド・ポイントが対応している限り自由に設定できます。 

 

チャンネル管理

• ストリームのグループや各チャンネルに名前を付けられる
• デバイスと入出力を容易に識別可能
• 説明をデバイスに保存可能

グループだけでなく各チャンネルに名前を付けられることは、MADIや他のネットワーク・オーディオ規格に対するアドバンテージです。設定はコントローラーで行え、各デバイスに保存されます。

チャンネル名は各デバイス内のAEM（AVDECC Entity Model）パラメーターとして保存されます。使用するAVDECCコントローラーが対応する場合は、各チャンネルの名称を変更できます。この名称は単なるパラメーターではありません。AVDECCコントローラーは、AVBデバイスの内部構造全体をオブジェクト階層として参照/修正します。

つまりコントローラーとAEMの組み合わせは、リモート・コントロール可能な非常にパワフルなツールとなるのです。