オーディオ通信システムの方法において、1つ以上の有線オーディオデバイス用の有線ネットワーク上および1つ以上のスレーブ無線オーディオデバイス用の無線ネットワーク上で、マスターデバイスから複数のオーディオデバイスを制御するステップと、前記有線オーディオデバイスの各々から、マスターデバイスからのポーリングメッセージに対する応答を受信するステップと、マスターデバイスからのポーリングメッセージを待たずに、有線マスターが無線オーディオデバイスにハード配線されていると有線マスターに実質的に思い込ませるために、スレーブ無線オーディオデバイスから受信される全てのメッセージおよびポーリング情報によって適切な時間内に応答することによって、ローカル有線マスターとして動作するスレーブ無線オーディオデバイスのうちの1つからスレーブ無線オーディオデバイスの状態を示す総ポーリング情報をマスターデバイスにおいて受信するステップとを有していて、前記ローカル有線マスターは、ポーリング応答を生成する全スレーブ無線オーディオデバイスを発見し、ローカル有線マスターによって予め決定されかつ確認されているように、予め設定されていた時間、マスターデバイスによる差し迫った周期的なポーリングと同時に起こる前記ポーリング応答の全てをバッファリングし、マスターデバイスによる全スレーブ無線オーディオデバイスに対するポーリング要求の発行の直後にマスターデバイスに到達するように、バッファリングされたポーリング応答を解放し、前記ローカル有線マスターは、ポーリングの明示的なステップを実行し、全ポーリング応答情報を組み立てて、組み立てられたポーリング応答情報をマスターデバイスに送信することを特徴とする方法。総ポーリング情報を供給するマスターとして動作するスレーブ無線オーディオデバイスのうちの1つは、所定のサイクルで無線オーディオデバイスをローカルにポーリングすることを特徴とする請求項1に記載の方法。少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを送信するステップを有していて、前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの4つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの4つの最下位ビットは、ポーリングされているオーディオデバイスを識別することを特徴とする請求項1に記載の方法。少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを受信するステップを有していて、前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの4つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの4つの最下位ビットは、ポーリングされているオーディオデバイスを識別することを特徴とする請求項1に記載の方法。少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを組み立てるステップを有していて、前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの4つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの4つの最下位ビットは、ポーリングされているオーディオデバイスを識別することを特徴とする請求項1に記載の方法。前記メッセージを送信するステップを更に有していることを特徴とする請求項5に記載の方法。少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのためのプロトコルを記憶する一時的ではないコンピュータ読み出し可能な媒体を含むオーディオ通信ネットワークのための方法において、前記プロトコルは、ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージ形式を含み、メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの4つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの4つの最下位ビットは、ポーリングされているオーディオデバイスを識別することを特徴とする方法。一般に、一態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むマルチゾーンオーディオ通信ネットワークの方法を特徴とする。この方法は、コマンドを含むメッセージをデバイス上のリモートコントロールまたはコントロールボタンからマスターデバイスで受信することおよびコマンドを1つまたは複数のスレーブデバイスに送信することを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージは、送信されスレーブデバイスを制御するために使用される前にマスターデバイスで処理される。コマンドは、マスターデバイスを通じて、マスターデバイスで処理されることなく1つまたは複数のスレーブデバイスに渡される。リモートコントロールは、マスターデバイスとスレーブデバイスの両方を制御する。コマンドは、マスターデバイスとスレーブデバイスとの間の第1の通信チャネル上で送信される。オーディオストリームは、第1の通信チャネル上でコマンドと多重化される。オーディオストリームは、マスターデバイスとスレーブデバイスとの間の第2の通信チャネル上で送信される。第1の通信チャネルは、無線チャネルを含む。スレーブは、リモートコントロールを介して複数のゾーンに動的に構成される。スレーブデバイスは、さらに、ローカルの音源に接続され、スレーブデバイスは再生のためローカルの音源とオーディオストリームとから選択する。一般に、他の態様では、本発明は、マスターデバイス、および1つまたは複数のスレーブデバイスを備えるマルチゾーンオーディオネットワーク制御システムを特徴とし、マスターデバイスは、コマンドを含むメッセージをデバイス上のリモートコントロールまたはコントロールボタンから受信し、そのコマンドをスレーブデバイスに送信する回路を備える。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、複数の優先度をメッセージに割り当て、マスターデバイスからスレーブデバイスに最高優先度の保留メッセージを送信することを含む、通信プロトコルを使用してマスターデバイスから1つまたは複数のスレーブデバイスを制御することを含む。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、複数の優先度をメッセージに割り当て、マスターデバイスからのポーリングメッセージに対する応答としてスレーブデバイスからマスターデバイスに最高優先度の保留メッセージを送信することを含む、通信プロトコルを使用してマスターデバイスから1つまたは複数のスレーブデバイスを制御することを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。最高優先度の保留メッセージは、スレーブデバイスを制御するための情報を含む。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、マスターデバイスから複数のオーディオデバイスを制御し、第1のサイクルでオフ状態にあるオーディオデバイスの第1の集合および第2のサイクルでオン状態にあるオーディオデバイスの第2の集合をポーリングすることを含み、第2のサイクルは第1のサイクルよりも短い。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。オーディオデバイスの第2の集合のすべてのメンバがポーリングされ、その後、オーディオデバイスの第1の集合の単一メンバがポーリングされ、というように、このステップは、循環ラウンドロビン方式で繰り返される。一般に、他の態様では、本発明は、オーディオデバイスがオン状態にある場合にオーディオデバイスに関連付けられているゾーンに基づいて音源から再生するためにマスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。一般に、他の態様では、本発明は、オーディオデバイスがローカル状態にある場合にマスターデバイスで処理せずにマスターデバイスを通じてオーディオデバイスに対しすべてのコマンドを渡すことを含むマスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。一般に、他の態様では、本発明は、オーディオデバイスが非応答状態にある場合にオーディオデバイスのリモートコントロールからキー押下を監視することを含む、マスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。一般に、他の態様では、本発明は、オーディオ通信システムのメッセージ同期処理のための方法を特徴とし、この方法は、複数のメッセージを送信することを含む、マスターデバイスから複数のオーディオデバイスを制御することを含み、それぞれのメッセージは、連続バーストとして送信され、第1のメッセージの終わりから第2のメッセージの始まりまでの間の所定の最短時間遅延が保持される。一般に、他の態様では、本発明は、オーディオ通信システムのための方法を特徴とし、この方法は、1つまたは複数の有線オーディオデバイス用の有線ネットワーク上で、および1つまたは複数の無線デバイス用の無線ネットワーク上でマスターデバイスから複数のオーディオデバイスを制御することを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。有線オーディオデバイスのそれぞれからポーリングメッセージに対する応答が受信され、無線デバイスのうちの1つから無線デバイスの状態を示す総ポーリング情報が受信される。総ポーリング情報を供給する無線デバイスのうちの1つは、所定のサイクルにより無線デバイスをローカルでポーリングする。総ポーリング情報は、所定の時間間隔で無線デバイスのうちの1つにより送信される。一般に、他の態様では、本発明は、オーディオ通信システムのための方法を特徴とし、この方法は、ネットワーク上で複数のオーディオストリームを送信すること、および複数のオーディオストリームのうちのそれぞれ1つを再生するためネットワーク上の1つまたは複数のオーディオデバイスを制御することを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。オーディオデバイスのうちの1つは、ネットワーク上のマスターデバイスからのメッセージに基づいて複数のオーディオストリームのうちの第2のストリームを再生することに切り替わるように制御される。メッセージは、オーディオストリームを指定する情報を含む。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、ネットワーク接続されている音源およびオーディオデバイスに接続されているローカル音源を含む、音源からオーディオデバイスにオーディオストリームを送信し、オーディオデバイス上の音源に関する情報を表示することを含む。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを送信することを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージの引数フィールドは、メッセージがポーリングメッセージである場合にはバイトを含まず、アドレスフィールドの最上位ビットは、再生するオーディオデバイスのオーディオゾーンを識別し、アドレスフィールドの最下位ビットは、ポーリングされているオーディオデバイスを識別する。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを受信することを含む。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを組み立てることを含む。実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージが送信される。一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワーク用のオーディオ通信プロトコルを特徴とし、このプロトコルは、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージ形式を含む。いくつかの実装では、メッセージの引数フィールドは、メッセージがポーリングメッセージである場合にはバイトを含まず、アドレスフィールドの最上位ビットは、再生するオーディオデバイスのオーディオゾーンを識別し、アドレスフィールドの最下位ビットは、ポーリングされているオーディオデバイスを識別する。本発明の利点としてとりわけ、以下のうちの1つまたは複数がある。オーディオネットワーク制御システムは、交換可能なスレーブデバイスで動作することができる。このため、マスターデバイスとスレーブデバイスとを混ぜてマッチングさせることにより、複数の統一小売価格を組み立てられる。スレーブデバイスは、共通通信プロトコルを使用することができる。マスターデバイスは、スレーブデバイスの特徴またはユーザインターフェイスの仕様を知る必要がない。共通通信プロトコルを使用することに加えて、スレーブデバイスには、共通の一連の動作がありえる。例えば、すべてのスレーブデバイスは、同じようにミュート、ミュート解除、音量調整コマンドに応答することができる。それとは別に、いくつかのスレーブデバイスは、共通通信プロトコルのいくつかの共通の態様を共有できるが、他の態様では異なる場合がある。さらに、オーディオネットワーク制御システムを使用することで、ユーザは、複数の部屋にわたって、また複数のリモコンを使用しても、継ぎ目のない運用を行える。システムは、リモートルームでも、メインルームとほぼ同じように動作することができる。スレーブデバイスは、マスターデバイスのリモコンでも、ネイティブリモコンとほぼ同じように機能することができる。この継ぎ目のない動作を実現するために、マスターデバイスは、リモートコントロールから受信したコマンドまたは赤外線リモコンを適切なスレーブデバイスにディスパッチすることができる。新しい機能を持つ将来のスレーブデバイスとの相互運用性を確実なものとするため、マスターデバイスは、不明なコマンドをスレーブデバイスへ通り抜けさせることができる。マスターデバイスは、そのコマンドがどのようなものであるかを知る必要はない。この点で、マスターデバイスは、ルータとして機能し、コマンドの発信元と送信先を判別する。場合によっては、コマンドはマスターデバイスのコマンドプロセッサに送られる。他の場合には、コマンドは、スレーブデバイスに直接経路指定される。この決定は、スレーブデバイスの状態および受信したコマンドに基づく。このようにして、新しいタイプのスレーブデバイスに拡張可能なシステムを作成することが可能である。いくつかのスレーブデバイスは、それ自体、システムとすることもでき、他の接続されたデバイスに対する制御統合を含むことができる。そのような制御自動化は、通常、スレーブデバイスのネイティブリモートコントロールを通じてアクセスされる。その制御自動化は、上記の経路指定メカニズムを介してサポートすることができるマスターデバイスのリモートコントロールからアクセス可能である。スレーブデバイス側で制御統合に対応するために、マスターデバイスによる追加処理は必要ない。通信プロトコルは、スレーブスピーカ上のローカルボタンでマスターコンソールを制御できるようにする優先順位付けされたメッセージを含む。スレーブデバイスは、ステータスなどあらゆる種類のメッセージをコンソールに送り返すことができるが、最高優先度のメッセージは、例えばスレーブスピーカ上のローカルボタンが押されたときの制御コマンドである。制御コマンドは、マスターコンソールを制御するために使用される。本発明の他の特徴および利点は、以下の詳細な説明および請求項から明白になるであろう。1.概要図1Aは、部屋が複数ある環境におけるオーディオデバイスのネットワークを含むオーディオネットワーク制御システム100を示している。システム100は、第1の部屋120にマスターデバイス110およびスレーブデバイス112Aを、第2の部屋122にスレーブデバイス112Bおよび112C、および第3の部屋124にスレーブデバイス112D~112Fを備える。マスターデバイス110は、例えば、コンピュータの通信機能を利用するスタンドアロンのコントロールコンソールまたは制御プログラムを備える。スレーブデバイス112A~112Dは、スピーカ、オーディオ再生およびまたは記録機能を備える電子デバイス、またはオーディオストリームに関する情報を収集し、およびまたは表示するデバイスを含む、さまざまなデバイスのどれかを備えることができる。スレーブデバイスは、図1Bに概略が示されているように、マスターデバイスインターフェイスおよびスレーブデバイスインターフェイスを含む通信プロトコル140により通信チャネルを介してマスターデバイス110と通信する。ユーザは、マスターまたはスレーブデバイス上のローカルコントロールボタンを介して、または1つまたは複数のリモートコントロール、例えば、マスターデバイス用のリモートコントロール130またはスレーブデバイス用のリモートコントロール132を使用することにより、直接デバイスのどれかを制御することができる。IRリモートコントロールは、対応するデバイスに配置されているコントロールに類似するコントロールを備えることができる。IRリモートコントロールからのコマンドは、IRリモートコントロールと同じ部屋に置かれているデバイスに伝播することができる。IRリモートコントロールからのコマンドにより、ローカルデバイスは、受信コマンドに対する応答として何らかの方法で状態を変更することができる。いくつかの実際の例では、1つのリモートコントロール、例えばマスターリモートコントロール130は、マスターデバイス110およびスレーブデバイス112A~112Dの両方を制御することができる。例えば、RFリモートコントロールは、マスターデバイス、1つまたは複数のスレーブデバイス、またはマスターおよびスレーブの両方のデバイスのいずれかを制御することができる。いくつかの実装では、RFリモートコントロールは、スレーブデバイスを直接制御しない。その代わりに、RFリモートコントロールから発行されたコマンドは、まず最初に、マスターデバイスに送信され、その後、マスターがコマンドに基づいて動作するか、またはスレーブデバイスに渡して動作させることができる。スレーブデバイスが直接制御されるか、または単一のRFリモートコントロールを通じて制御できるという事実を調整するために、ポーリングを使用して、スレーブデバイスに関するステータス情報を収集する。スレーブデバイスまたはIRリモートコントロール上のコントロールを使用して、スレーブデバイスの状態を変更する場合、ポーリングプロセスでは、変更された状態に関する情報を取得し、それをマスターデバイスに供給し、マスターデバイスがスレーブの状態を認識するようにする。物理的インターフェイスを通じて、またはIRリモートコントロールを介してデバイスに直接発行されるコマンドは、RFリモートコントロールを介して発行されるコマンドと異なる形で処理することができる。マスターデバイスと同じ部屋にあるIRリモートコントロールは、マスターデバイスを通じてコマンドを発行することができ、したがって、マスターと異なる部屋に配置されているRFリモートコントロールと同じ動作をすることができる。リモートコントロールは、双方向リモートコントロールを含むことができる。例えば、コマンドはリモートコントロールからマスターデバイスに発行され、データはマスターデバイスからリモートコントロールに送り返され、ユーザに表示される。送り返されるデータは、ネットワークに接続されたさまざまなデバイスの状態のステータスとすることができるか、またはユーザに対して演じられるデジタル作品を含むハードドライブ上に格納されているデータなど、マスターデバイスのさまざまな機能に関連付けられているデータとすることができる。いくつかの実際の例では、スレーブデバイス112A~112Dは、さらに、互いに通信する。いくつかの実際の例では、オーディオネットワーク制御システム100は、複数のマスターデバイスを備える。オーディオネットワーク制御システム100は、複数のゾーンに分けることができる。それぞれのデバイスは、アドレスにより識別され、それぞれの部屋は、部屋コードにより識別され、それぞれのゾーンは、ゾーンコードにより識別される。例えば、Zone1は、第1および第2の部屋内にデバイスを備え、Zone2は、第3の部屋内にデバイスを備えることができる。通常動作では、マスターデバイスは、接続されているすべてのスレーブデバイスを連続してポーリングし、それらがネットワーク上にあり、オンになっているかを判別する。例えば、実際の一例では、スレーブデバイスに対しては、On、Off、Local、またはNotRespondingの4つの状態がありえる。ほかに、スレーブデバイスに対する状態が4つよりも少ない実例も、多い実例もありえる。マスターデバイスのコマンド処理は、次のようにしてスレーブデバイスの状態に応じて進行する。すべての状態において、マスターデバイス110は、以下で詳述するように、音量およびミュートコマンドをマスターリモート130から通信プロトコル140に従って一致する部屋コードを持つスレーブデバイスに経路指定する。ポーリングした結果、スレーブデバイスがオンになっていることをマスターデバイスが検出すると、マスターデバイス110は、適切なゾーンをアクティブ化し、最後に選択された音源の再生を開始する。ゾーンがすでに再生している場合、スレーブデバイスはそのゾーンに対する現在の音源を結合する。与えられたゾーンに接続されているすべてのスレーブデバイスがオフまたはローカルのいずれかであるとマスターデバイス110が判別した場合、これは、そのゾーンの電源を切る。スレーブデバイスがオン状態の場合、マスターデバイスに知られている制御コマンドは、マスターデバイス固有の方法により処理される。マスターデバイス110によって認識できない新しい特徴を備えるスレーブデバイスなどの不明なコマンドが適切なスレーブデバイスに渡される。これにより、マスターデバイス110は、追加された新しいコマンドを含むことができるスレーブデバイスの新しいクラスに拡張することができる。スレーブデバイスがLocal状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。トランスポートコマンドは、マスターデバイス110によりローカルで処理されない。このため、すべてのマスターデバイス110内部トランスポートとともにリモートデバイスのローカルトランスポートでも完全にコンテキスト依存のトランスポートコマンドが使用可能である。スレーブデバイスがOff状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。これにより、ローカル音源選択コマンドまたはOnOffコマンドを送信することによりスレーブデバイスの電源を入れることができる。OnOffコマンドの場合、スレーブデバイスは前に選択された音源で電源オンになる。音源がマスターデバイス110であった場合、状態はOnに設定され、これは、次のポーリングサイクルで捕捉される。この方式は、それぞれのスレーブデバイスが各自の動作を管理するという点で非常に拡張性が高く、マスターデバイス110は、それぞれのスレーブデバイスに関して最小限度のことのみを知っているだけでよい。スレーブデバイスがNotResponding状態にある場合、トランスポートコマンドを含むすべてのコマンドは、上述のOff状態の場合と同様に、マスターデバイス110を通じて適切なスレーブデバイスに渡される。しかし、マスターデバイス110は、リモートからオンオフおよび音源選択キー押下を追跡することによりそれらのスレーブデバイスに対するオンオフ状態変数を管理する。このため、マスターデバイス110はゾーンをいつ適切にシャットダウンするかを知ることになる。スレーブデバイスの電源がオンになり、ネットワーク上での応答を開始した場合、その応答に含まれるオンオフ状態情報は高い優先度を与えられ、その部屋に対するマスターデバイス110オンオフ状態変数を更新するために使用される。2.通信プロトコル通信プロトコル140により、マスターデバイスは、それぞれ一意的なアドレスを持つ所定の数のネットワーク接続スレーブデバイスをサポートすることができる。これらのアドレスは、例えば、RoomA、RoomB、RoomCなどで、最大RoomOである。16番目のアドレスは、ブロードキャストメッセージ用に予約されている。これら15個のスレーブデバイスは、リモートコントロールコマンドに対する応答として、与えられた任意の時点に、Zone1、Zone2、または追加ゾーンオーディオストリームのどれかを再生することができる。したがって、通信プロトコル140に対して、部屋コードだけで、特定のスレーブデバイスを識別することができ、スレーブデバイスに送信されるゾーン情報は、単に、再生されることが意図されているオーディオストリームをスレーブデバイスに知らせるだけである。通信プロトコル140は、プラグプレイ機能を持つ。ネットワークまたは他のスレーブデバイスの電源を切らずに、またマスターデバイス110の電源を切らずに、新しいスレーブデバイスをいつでもネットワークに追加することができる。1つのスレーブデバイスアドレスを共有アドレスとして使用し、マスターデバイス110上のZone2可変オーディオ出力に割り当てることができる。このアドレスに設定されたRFリモートコントロールからのVolumeUpDownコマンドが、スレーブデバイスのメッセージを起動し、このZone2可変オーディオ出力に給電する内部音量調節チップを制御する。3.マスターデバイス回路3.1概要スタンドアロンコンソール200マスターデバイスの実際の一例が図2に示されている。コンソール200のハードウェアインターフェイスは、制御データバス202、およびオーディオインターフェイス204、および10VのTurnOn信号206を含む。制御データバス202は、コンソール200からネットワーク接続スレーブデバイス208に接続されることを意図されている2線式双方向半二重インターフェイスである。すべてのデータおよび制御メッセージは、このバス200経由で送信される。メッセージ送受信は、192kbpsに固定されており、以下に定義されたパケット化およびタイミング規則に従う。最大150フィートのネットワーク長をサポートすることができ、ケーブル配線は、ディジーチェーンまたはスター型構成に従う。電気的には、ネットワーク接続スレーブデバイスは並列に配線される。Data信号は、1kΩのプルアップ抵抗を通してコンソール側の5Vに入り、メッセージが送信されていない場合には5Vでアイドル状態となる。ネットワーク接続スレーブデバイスは、オプションにより、ローカルの5V音源への1MΩのプルアップ抵抗を含み、これにより、コンソールから切断されたときにData信号を知られている状態へバイアスすることができる。いくつかの実際の例では、信号伝達は、Data信号をローカルのGNDに引き込むオープンコレクタトランジスタを通じて実現される。3.2送信機の詳細本例では、それぞれのスレーブデバイスはバス202とインターフェイスし、5Vを許容でき、また最悪時のプルアップ抵抗で完全プルダウンすることができるオープンコレクタトランジスタを通して信号を送る。バス202は家庭内に張り巡らされ、また過去の著しい電気的雑音源となりうるため、フィルタ保護コンポーネントも用意すべきである。バス送信機の出力セクション例が図3に示されている。他の送信機トポロジも可能である。送信機の電気的パラメータは以下のとおりである。スピーカケーブルの長さが120フィートだと、ネットワークに約01μFの余分な容量を負荷としてかけることになる。したがって、図4に示されている波形は、最悪の場合の数のスピーカによりロードされた最大長のネットワークの上へのスレーブデバイスにより駆動されるスタートビットに対する最悪の場合の駆動波形を表す。バス容量によるビットの拡張に注意されたい。ビット立ち下がり時間は、立ち上がり時間よりも約10倍高速であろう。この実施例に対するパラメータを以下に示す。3.3受信機の詳細バス受信機は、ネットワーク上で立ち下がり遷移を検出し、それらをマイクロプロセッサに中継する。受信機回路は、スレーブデバイスに対しては立ち下がり受信しきい値を約26Vに設定し、コンソール200に対しては3Vに設定する。この実施例では、ヒステリシスは与えられない。したがって、いくつかの多重遷移が、ノイジービットのエッジで発生しうる。スレーブデバイスでは、その受信アルゴリズムがそれらの遷移を許容できない場合、ヒステリシスを加えるであろう。例えば、標準的なUARTデバイスおよびビットセルの中心付近でビットをサンプリングするその他の方式では、多重遷移を許容する。ネットワークのHIGHLOW時間を測定するためにエッジトリガ割り込みを使用してデータを復号化する受信方式では、リアーミングの前に割り込みサービスルーチンに十分な遅延が存在していない限り、ヒステリシスを必要とする可能性がある。理想的には、使用する回路に関係なく、ソフトウェアで擬似ヒステリシスを実施するデバウンス方式を実施すべきである。バス受信機は、さらに、ネットワーク過渡電流に耐えなければならない。したがって、受信機回路は、図3に示されているように、送信機出力段の保護ノードからタップオフされる。このトポロジでは、ネットワークスレーブデバイスにより送信されるすべてのデータは、それ自体の受信機内にフィードバックされる。ソフトウェアは、これに耐えられるよう十分に堅牢でなければならない。5Vおよび33Vバス受信機回路例は、それぞれ、図5Aおよび5Bに示されている。送信機の電気的パラメータは以下のとおりである。3.410VTurnOn線コンソール200は、10VTurnOn信号206を供給する。この信号は、与えられたZone上でアクティブなスレーブデバイスがない場合にLOWレベルであり、あればHIGHレベルである。最大駆動能力は、88Vで約75mAである。したがって、スレーブデバイスがこの線を他の目的に使用する場合、スレーブデバイス1つ当たり引き込む電流が5mAを超えないよう注意しなければならない。このような電流引き込みは、さらに、コンソールのワット損を減らすために、単に一時的なものでなければならない。3.5オーディオインターフェイスの詳細スレーブデバイスインターフェイスは、オーディオインターフェイス204とともに、本明細書で説明されている制御データバス202を含む。ネットワーク接続スレーブデバイスに対するオーディオ信号出力の一種に固定出力がある。音量調節は、スレーブデバイス内で実施される。このため、スレーブデバイスで信号対雑音比が最大になる。可変出力も備えられ、例えば、従来のスレーブデバイスをサポートする。1つまたは複数の信号出力は、アナログ出力、デジタル出力、またはアナログ出力とデジタル出力の組み合わせとすることができる。オーディオ信号の分配は、通信プロトコル140に従ってマスターデバイス110と通信する機能を持つスマートスピーカを含むスマートスピーカシステムである、スレーブデバイスのネットワークに関して以下で説明される。メインルームスマートスピーカシステムでは、コンソール200は、以下で詳しく説明するように、Zone1SpeakerOutputminiDIN、ピン1および2上でSPDIFベースの差動デジタルオーディオストリームを供給する。このオーディオストリームは、スピーカによる負荷がかかったときに、3Vpp出力レベルに対し構成されており、トランスで絶縁され、平衡している。放射を低減するためグラウンドへの390pFのフィルタキャパシタが追加される。コンソール200は、さまざまなデータ転送速度で、例えば、48kFPSから最大192kFPSまでの速さでオーディオストリームを生成することができる。コンソール200は、さまざまな圧縮形式のうちのどれか、例えば、PCM、AC3、DTS、MPEG2、またはAACでデジタルオーディオを生成することができる。圧縮形式は、スピーカにより識別され復号化される。家中の非メインルームスマートスピーカシステムでは、アナログ出力ステレオのペアは、以下で詳述するように、Zone2SpeakerOutputminiDINコネクタ上に備えられる。これらの左右ペアは両方とも固定出力である。フルスケールの出力信号は約2Vrmsで、標準的な再生レベルは約300~400Vrmsとなる。コンソールの内部および外部音源に対する再生レベルは、コンソール内でゲインスケーリングされており、等しい振幅で再生される。これらの出力は、約50Ωの直列抵抗がそれぞれの出力に追加された、OPアンプにより本質的に駆動される、標準のシングルエンドアナログ出力である。47μFのDC阻止キャパシタが、コンソール内のそれぞれの出力信号に追加され、その後に100K抵抗器がつながりコンソールのアナロググラウンドをそれぞれ基準とする。この出力インピーダンスは、最大15個までのスピーカを駆動することができ、しかも、低周波応答の不要な減衰または損失が発生しないことが予想される。以下では、適切なゾーンゾーン絶縁および雑音遮蔽を保証するためのケーブル配線ガイドラインを示す。Zone2SpeakerOutputコネクタピン1および2は、さらに、可変入力スピーカ用の左右可変アナログ信号ペアも備える。これらの信号は、ピン3および4のZone2固定出力と同一であるが、コンソール200の内側のZone2音量調節チップにより減衰することができる。家中に長いオーディオケーブルを引き回すと、耳に聞こえるほどの雑音を拾いやすいことが判明している。したがって、制御データバス202にインターフェイスするスピーカでは、オーディオ入力段に差動アンプを構成すべきである。これらの差動アンプ入力の基準として、専用AudioReferenceがコンソール200から送られ、他のネットワーク導線とともに含まれる。ケーブル配線の詳細を以下で説明する。いくつかの実際の例では、ネットワーク接続スピーカのオーディオインターフェイスの特徴として、以下のものがある。Zone1およびZone2入力diffアンプ回路は、同じでなければならない。Diffアンプは、すべての脚が等しく平衡している状態で使用すべきである。ネットワークからそれぞれの脚を見たときの抵抗は、20KΩ以上でなければならない。これにより、例えば、Diffアンプは10KΩの抵抗器をそれぞれの脚に付けて構成されるようにできる。それぞれの脚はネットワークにキャパシタを介して接続されるべきであり、キャパシタはすべて等しい値を持つ。それぞれのネットワーク接続スレーブデバイスは、所望の周波数応答に基づいてそれ固有のキャパシタ値を持つことができる。専用AudioReference信号を、Diffアンプ、Zone1LeftRightとともにZone2LeftRightに対し使用しなければならない。オーディオ電流がこの信号に還流し、Zone1Zone2絶縁を破壊するのを避けるために、AudioReferenceをDiffアンプのみのNONINVERTING脚に対し使用しなければならない。1マイクロアンペアrms以下のオーディオ電流が、AudioReference信号上に誘起されなければならない。これは92dBの絶縁を維持する。コンソール200とインターフェイスするように開発されたスマートスピーカは、2つの可能なオーディオストリーム、Zone1ストリームまたはZone2ストリームのうちの1つを選択することができる。選択は、スマートスピーカコマンドを介して制御される。したがって、スマートスピーカは、スマートスピーカメッセージを管理するマイクロプロセッサの制御の下で、そのネットワークオーディオ入力に2入力、ステレオオーディオマルチプレクサを備えるべきである。このMUXをDiffアンプの前に構成する作業は、コスト低減につながるが、パフォーマンスの低下または上記特徴のうちのいくつかを除去することのないように慎重に行わなければならない。3.6コンソールスピーカ出力のMiniDINコネクタコンソール200は、2つの9ピンSpeakerOutputminiDINコネクタを、Zone1に1つ、Zone2に1つ、備える。図6は、9ピンminiDINコネクタを見た場合のピン配置例を示している。コネクタは、導電性シェル600を備える。これらのコネクタに対するピン配置を以下に示す。ZONE1ピン1メインスピーカ用のSPDIF0デジタルオーディオ信号。ピン2メインスピーカ用のSPDIF1デジタルオーディオ信号。ピン3Zone1固定左アナログオーディオ信号。可変でない。ピン4Zone1固定右アナログオーディオ信号。可変でない。ピン5GND。ピン6Zone1の10VTurnOn信号。ピン7Zone1のSmartSpeakerData。ピン8GND。ピン9接続なし。シェルGND。ZONE2ピン1Zone2可変左アナログオーディオ信号。ピン2Zone2可変右アナログオーディオ信号。ピン3Zone2固定左アナログオーディオ信号。ピン4Zone2固定右アナログオーディオ信号。ピン5BufferedZone1固定右アナログオーディオ信号。ピン6Zone2の10VTurnOn信号。ピン7Zone2のSmartSpeakerData。ピン8GND。ピン9BufferedZone1固定左アナログオーディオ信号。シェルGND。3.7ネットワーク接続スピーカの入力miniDINコネクタネットワーク接続スマートスピーカも、同様に、バス202に接続するための9ピンminiDINコネクタを備える。この一方のコネクタは、Zone1およびZone2のLeftRightオーディオとともに、Data線、デジタルグラウンド、およびオーディオDiffアンプの基準電圧として使用する別のグラウンドを取り込む。オプションにより、10VTurnOn信号も取り込める。全部で8本の導線にしかならないが、スピーカは、ケーブルを反転可能にできるように、コンソールのと同じ9ピンminiDINを使用するように定義される。スピーカのminiDINは、以下のピン配置となっている。ピン1未接続。ピン2未接続。ピン3Zone2固定左アナログオーディオ信号。ピン4Zone2固定右アナログオーディオ信号。ピン5Zone1固定右アナログオーディオ信号。ピン6Zone2の10VTurnOn信号。ピン7Zone2のSmartSpeakerData。ピン8AudioReference。スピーカの製品グラウンドに結線されない。ピン9Zone1固定左アナログオーディオ信号。シェルGND、スピーカのデジタルグラウンドとして使用される。スピーカ内のピン8GNDに短絡しない。3.8ケーブル配線の詳細いくつかの実際の例では、スマートスピーカをコンソール200のZone2SpeakerOutputに接続するためのケーブルは、図7に示されているような独立のシールドを使用する、ピン3から9までの11パススルーを持つ。ピン1および2は、接続されておらず、ケーブルは反転可能である。8線ケーブルを4つのシールド付きツイストペアケーブルとともに使用してスピーカをコンソール200に接続する場合、図7に示されているように接続することができる。いくつかの従来のスピーカでは、直接、Zone2Speakerコネクタにプラグを差し込み、正常に動作させることができ、新しいスピーカと共存できる。これらは、ピン12上でZone2VariableLeftRight信号を使用するとともに、ピン6上で10VTurnOn線を使用する。ピン8は、TurnOn線を遮蔽し、スピーカをグラウンドに接続するために使用される。シェル600のグラウンドは、このスピーカ内のAudioReferenceに使用される。これらのケーブルは、内部で、ピン5をシェルグラウンドに短絡し、Zone1FixedRight出力を新しいスピーカから使用できなくするこれらのスピーカが新しいスピーカとZone2を共有する必要がある場合に特殊なスプリッタを使用してこれを防止する。従来のスピーカケーブルがコンソール200のZone2SpeakerOutputに差し込まれた場合、ピン5上のZone1FixedRightオーディオ出力信号はグラウンドに短絡される。FixedRightオーディオ出力はバッファリングされるため、新しいスタイルのスピーカをサポートする必要がなければ、この信号をグラウンドに短絡するのが安全である。しかし、新しいスピーカを従来スピーカと併用する場合、特別なスプリッタを使用する必要がある。このスプリッタ内の接続は図8に示されているとおりである。スプリッタの従来出力は以下の特徴を持つ。1ピン5をシェルに短絡する、出力に差し込まれるケーブルは、Z1FixedRightをGNDに短絡しない。2そのピン8グラウンドは、デジタルGNDに使用できる。3そのシェルグラウンドは、ピン5に短絡され、LeftRightオーディオ遮蔽に使用することができる。スプリッタのNewSpeaker出力は、コンソールminiDINからのピン3から9のフルパススルーである。新しいスピーカは、決して、ピン1~2のVariableオーディオ信号を使用せず、実際には、ピン1~2をアクセサリ用のオーディオ出力として使用することができ、したがって、これらはスプリッタ内に含まれない。4.通信プロトコルの詳細通信プロトコル140は、コンソール200と1組のネットワーク接続スピーカとの間で1線、双方向、半二重、信号伝達方式を使用する。すべての通信は、コンソール20の背後にあるSpeakerOutputminiDINコネクタから引き回されるケーブル上のSpeakerData線を介してネットワーク接続スピーカに送られる。この信号のアイドル状態は、コンソール内の1KΩ抵抗器を介してプルアップされた、論理HIGHレベルである。送信は、コンソール200およびスピーカ内の直接キーイングオープンコレクタトランジスタ段により行われる。プロトコル140では、192Kbpsビットレート、1スタートビット、1ストップビット、およびパリティビットなしの設定を使用する。メッセージバイトを以下で定義する。以下の例では、すべてのメッセージバイトは、LSBを先に送信する。4.1許容可能な論理レベル信号伝達の論理レベルは以下のとおりである。4.2ビット幅すべてのネットワーク接続デバイスで使用する192kbpsのデータ転送速度は公称転送速度の05内となるように保証される。これにより、必ず、各バイトのストップビットまでのエッジ精度は±5となる。したがって、ビット幅は以下のように定義される。これらの許容範囲は、バス送信機により生成されるとおりビット幅に適用される。実際の受信ビット幅は、最悪の場合のネットワーク上では歪むことがある。4.3メッセージタイミングスピーカの同期をとるために、メッセージがパケット化され、メッセージ間タイミングは以下のように制御される。ネットワークから見た場合の共通4バイトコマンドおよび応答のメッセージ例が図9に示されている。4.4メッセージ同期上の表に示されているように、コンソール200では、ネットワークが、新しい伝送を開始するまでに少なくとも1066m秒の間アイドル状態になっていることを確実にする。この遅延は、意図的に、コンソールメッセージとスピーカ応答との間の許容可能な遅延よりも長くとってあり、ネットワーク上のデバイスは単純なタイムアウトを使用して、必要な場合にコンソールとの再同期をとることができる。スピーカがコンソールとの再同期に使用する推奨タイムアウトは、916μ秒2である。スピーカ側で、ネットワークが916μ秒の間アイドル状態にあったと識別した場合、そのスピーカは、受信ルーチンをリアーミングすることができ、次のコンソールメッセージをその先頭から適切に捕捉する。スピーカでは、安全に469μ秒を超える最初のネットワークアイドル時間の間待つことにより受信コンソールメッセージの終わりを識別することができる。推奨タイムアウトは、約521μ秒である。これにより、スピーカ側には246μ秒の猶予が与えられ、受信メッセージを調べ、767μ秒よりも前にそのACK応答を開始する。これらのメッセージタイミングを守った場合、同期喪失は発生しないであろう。しかしながら、メッセージアドレスおよびベリファイヤバイトを調べて、受信したすべてのメッセージが有効であることを確認すべきである。さらに、メッセージの終わりを識別するのに十分に長いネットワークアイドル時間が検出された場合、4バイト長よりも短い部分受信メッセージを削除し、再同期をとらなければならない。4.5ソフトウェアドライバ4.5.1低レベル受信機標準ハードウェアUART受信機は、雑音およびジッタスルー歪みの防止機能を備える。ハードウェアUARTが利用できない場合にソフトウェアでこの機能を近似するために、ビットバングド受信ルーチンが以下のように機能する。1同期が確認され、受信メッセージが予期できるようになった後、データ入力をエッジトリガ割り込みでアーミングされなければならない。2メッセージ第1のエッジが検出されると、即座にさらに1~2回リサンプリングを行って雑音を除去することによりデバウンスしなければならない。有効であると分かった場合、自動リロードされる52083μ秒タイムアウトにより駆動される状態マシンを実行し、できる限りビットセルの中心近くで次の10ビットをサンプリングしなければならない。3この状態マシンの第1の8段で、メッセージビットを収集する。8つのメッセージビットのそれぞれを、ビットセルの中心で1~3回素早くサンプリングし、適切な値を格納しておく必要がある。49番目のビットに対するタイマー割り込みルーチンで、バスがアイドル状態にあることを確認し、次のバイトのスタートビットに対しエッジトリガ割り込みをリアーミングしなければならない。5新しいバイトのスタートビットエッジが10番目の52083μ秒の割り込みの前に検出された場合、10番目のタイマー割り込みをキャンセルして、前のように新しい着信バイトを組み立てる。しかし、10番目の52083μ秒の割り込みが最初にタイムアウトになると、メッセージは終了する。それに応じて処理を進める。スレーブは、即座に、その応答の生成を開始することができる。4.5.2マスターデバイスの送信受信タイミングいくつかの実際の例では、コンソール200は、ハードウェアUARTをスマートスピーカインターフェイスに割り当てている。以下の方式では、このUARTを管理することに関連する割り込みが最小限で済む。1完了時にシステムに割り込みがかかるようにUARTを設定し、送信メッセージを一度に丸ごと送信する。CS98200内の16バイトの最大UARTバッファよりも長いメッセージについては、割り込みを使用して、可能な限り最大のブロック単位でメッセージをバラバラにして送信する。これは、バイト間に目立った遅延が入り込まないようにして実行すべきである。2送信メッセージが終了したら、UART受信機を有効にし、1受信バイトの後に割り込みがかかるように設定する。さらに、約134m秒以内にタイムアウトになるようにタイマー割り込みをアーミングする。3最初の完全なバイトがスレーブから受信される前に134m秒のタイマー割り込みがタイムアウトした場合、スレーブはアクティブでないと想定して、次のスレーブのポーリングに進む。4そうでない場合、引き続き、受信バイト毎に割り込みをかける。その後のバイトは、52083m秒毎に受信されなければならない。しかし、1066m秒のSynchronizationDelayがコンソールメッセージの前に使用されるため、1066m秒タイムアウトを使用して、スレーブメッセージの終わりを検出しなければならない。図10は、スピーカからの応答がある場合と、スピーカからの応答がない場合のメッセージシーケンスを示している。5.0メッセージパケットの概要メッセージパケットは、バスマスターまたはスレーブにより送信されたバイトの集合として定義される。メッセージパケットのすべてのビットは、バイトとバイトの間に割り込みまたは遅延を発生することなく、1つの連続バーストとして設定される。さまざまな長さのメッセージがサポートされている。いくつかの実装では、後述のHeaderAddressArgumentVerifier形式を使用する。5.1Headerバイトバス202上のメッセージは、コンソールマスターからであろうとスピーカスレーブからであろうと、1バイトのHeaderから始まる。このHeaderのビット7は、予約されており、メッセージがコンソール200により送信されるのか、またはスピーカにより送信されるのかを示す。ビット7は、コンソールメッセージについては0に設定され、スピーカメッセージについては1に設定される。スタートビットとストップビットを含む完全なHeaderバイトの図が、図11に示されている。H7H08ビットのHeader識別子。したがって、256個の別々のコマンドが可能である。DIR1ビットのMessageDirectionIndicator。5.2ConsoleMessageAddressByteスマートスピーカメッセージについては、第2バイトはメッセージのアドレス指定を含む。Addressバイトの図が図12に示されている。R3R0RoomNumber。15個の一意的部屋が使用可能である。0000bRoomA。0001~1110bRoomB~RoomO。1111bALLROOMS、これはブロードキャストに使用される。Z3Z0ZoneNumber。15個の一意的なゾーンが使用可能である。それぞれのゾーンは、所望のオーディオストリームを識別するために使用できる。0000bZone1。0001~1110bZone2~Zone15。1111bALLZONES、これは、コンソールメッセージによりスピーカがその入力ストリームゾーン選択を変更すべきでない場合に使用される。アドレスバイトの例は、Zone1、RoomA00000000b。Zone2、RoomI00011001b。Addressバイトに含まれるゾーン情報は、例えば、RFリモートコントロールから、コンソール200に通され、スピーカによって選択されたオーディオストリームを識別する。有効なオプションの例は、Zone1、Zone2、およびALLZonesである。他のオプションも可能である。例えば、いくつかのオプションでは、それ独自のオーディオストリームが用意されるそれぞれの部屋をサポートする。5.3SpeakerMessageAddressバイトスピーカAddressバイトを使用することで、スピーカ応答で、スピーカがOFFであるか、またはLocal音源の受信を待っているか、またはコンソール200から送信されたストリームのうちの1つの受信を待っているかを示すことができる。このバイトの形式は、図13に示されている。R3R0コンソール200について定義されているのと同じ15個の使用可能な部屋のうちの1つを示すが、1111bはスピーカについては未定義である。Z3Z00000~1101b14個の可能なZonesのうちの1つを再生する。1110bローカル音源を再生する。1111bOFF。現在、ローカルまたはネットワーク接続音源を再生していない。5.4ArgumentバイトAddressバイトの後、メッセージを終了するVerifierバイトの前のところに、メッセージArgumentバイトが含まれる。ポーリングには、引数バイトが含まれない。いくつかのスマートスピーカメッセージは、Argumentバイトを1つしか含まないが、スピーカメッセージは、Argumentバイトをいくつでも含むことができる。さまざまなコマンドの中で使用されるArgumentバイトのメッセージ定義および詳細について以下で説明する。それぞれのArgumentバイトは、図14に示されている形式で送信される。A7A08ビットメッセージ引数。5.5Verifierバイトスマートスピーカメッセージの最終バイトは、Verifierバイトである。このバイトは、基本メッセージ情報が破損していないことを確認するために使用される。以下のメッセージ定義に示されているように、このバイトは、一般に、先行するすべてのメッセージバイトのソフトウェア排他ORであるが、長いメッセージ形式では、これを使用して、HeaderAddressのみを検証し、ローカルチェックサムなどをArgumentフィールド内に含めて、その大量のデータペイロードをより厳格に検証したい場合もある。このVerifierバイトの形式は、図15に示されている。V7V0一般に、先行するすべてのメッセージバイトのXOR。6.0交換のルール交換は、コンソール200から特定のスピーカへのメッセージとその返信としてそのスピーカから送信される後続の応答の2つのバスメッセージの集まりとして定義される。このような交換を左右するルール群を以下に示す。6.1マスターのみが自発的メッセージを生成するコンソール200は、スマートスピーカバス202上のすべての通信のマスターである。例えば、コンソール200のみが、バス202上の自発的伝送を発生する。6.2マスターは、進行中の交換に割り込みをかけないコンソールマスターによるメッセージ保留の重要度に関係なく、外へ向かう伝送は、新しい伝送を開始する前にすでに開始している交換サイクルが完了するまで待つ。コンソール200またはスピーカからの進行中のメッセージは割り込みされない。6.3スレーブはそれにアドレス指定されたメッセージの直後にしか送信しないスレーブスピーカは、それに対し特にアドレス指定されたコンソールメッセージの直後にしか送信できない。このルールは、スピーカメッセージの保留がどれだけ重要であろうと、適用される。スピーカが上流で通信を送り返せるタイミングのよい機会を十分保証できるように頻繁に、メッセージをそれぞれのスピーカに送信するのはコンソールの役目である。6.4スレーブはそれにアドレス指定されたメッセージに応答するスピーカがOFFでない限り、スレーブスピーカは、何らかの形の返信メッセージでそれにアドレス指定されたコンソールメッセージに応答する。応答は、許容可能な遅延期間以内に生成される。スピーカは、以下のメッセージタイプのうちのどれか1つでコンソールメッセージに応答することができる。PollReplyメッセージ。これは、既定のスピーカ応答であり、さらに高い優先度の応答が送信できるのではない限りすべてのポーリング、コマンド、およびクエリの後に使用される。PASSKEYCODEメッセージ。DOWNLOADINFORMATIONメッセージ。6.5スレーブは現在保留中の最高優先度の情報で応答するスピーカスレーブでは、コンソール200に送り返す機会が到来したときに複数のメッセージが保留になっている可能性がある。このような状況では、最高優先度のメッセージが送信されなければならない。可能なメッセージタイプの一般的ガイドラインは以下のとおりである。6.5.1最高優先度非ポーリングクエリ応答コンソール200が特定のクエリメッセージをスピーカに送信した場合、スピーカはできる限り速やかに適切な応答を送信する。クエリ応答が組み立てられるまで低優先度の応答を送信できるが、いったん組み立てられると、送信キュー内で最高優先度を割り当てられる。6.5.2中優先度PassKeyCodeメッセージスピーカスレーブ製品上でいくつかのボタンが押されると、コンソール音源などに対する緊急の変更が必要になることがある。PassKeyCodeメッセージは、該当する押下をコンソール200に伝達するために以下で定義される。これらのメッセージは、スレーブの送信キュー内で中優先度を与えられなければならない。6.5.3中優先度DownloadInformationメッセージDownloadInformationメッセージは、スピーカスレーブがデータのブロックをコンソール200に伝達できるように以下で定義される。このデータは、通常、スレーブ上で再生されるローカル音源に関係する情報を表すことが期待される。このようなメッセージは、中優先度を与えられ、これはPassKeyCodeメッセージと同じである。これらは、したがって、PassKeyCodeメッセージとともにFIFO内にバッファリングされなければならず、ポーリング応答に優先するが、他のすべての特定のクエリ応答がキュー内にある場合には保留になる。6.5.4最低優先度ポーリング応答他のスピーカメッセージが送信SmartSpeakerキュー内にない場合に、PollReplyと呼ばれる既定の応答が送信されなければならない。この応答は、応答の他のクラスよりも重要度が低いとみなされる、スピーカのオンオフ状態およびその音量レベルに関する基本情報のみを含む。6.6マスターはすべてのスピーカを連続的にポーリングするが、低優先度としてであるスピーカが上流方向に情報をコンソール200へタイミングよく送信できるようにするため、ポーリングメッセージが送信され、これは、スピーカステータスの変更に気づく機会として利用される。コンソールメッセージの場合と同様、スピーカは、オプションにより、上述のメッセージタイプのどれかでのポーリングに応答することができる。コンソールのポーリングサイクルのタイミングに関する詳細を以下で説明する。一般的には、これらのポーリングは連続的に送信されるが、コンソールの送信キュー内に利用可能な高い優先度のメッセージが入っていない場合のみである。6.7マスターは現在保留中の最高優先度メッセージを送信するスレーブの場合と同様に、コンソールマスター送信メッセージは優先度を割り当てられる。優先度の高いメッセージは、以下のように低い優先度のメッセージよりも優先される。6.7.1最高優先度非ポーリングクエリおよび制御メッセージクエリまたは制御メッセージが特定のスピーカに送信される必要がある場合、最高優先度を与えられる。メッセージ定義を参照。6.7.2中優先度PassKeyCodeメッセージコンソール200は、コンソールによって使用されていないRFコマンドをスピーカに直接通すことができる。以下で定義される、PassKeyCodeはこのために使用される。このようなメッセージは、クエリよりも低い優先度を持つが、ポーリングには優先度が高い。PassKeyCodeメッセージが保留になっている場合、ポーリングサイクルは割り込みがかかり、、PassKeyCodeメッセージが送信され、その後ポーリングは再開できる。6.7.3中優先度DownloadInformationメッセージコンソール200はDownloadInformationメッセージを使用して、データの大きなブロックをスピーカにダウンロードすることができる。これは、スピーカアプリケーションコードなどを更新する場合に使用することができる。これらのメッセージに対する優先度は、クエリよりも低いが、ポーリングよりも高い。PassKeyCodeメッセージの場合と同様、ポーリングサイクルは一時的に割り込みがかけられ、保留中のDownloadInformationメッセージを送信する。6.7.4最低優先度ポーリングスピーカポーリングは、最低優先度を割り当てられ、コンソール200が送信すべき重要性の高い情報がない間に送信されるメッセージの連続サイクルを表すべきである。これらのポーリングを送信することにより、それぞれのスピーカは、上流に向かってメッセージをコンソール200に送信する定期的機会がそれぞれのスピーカに対し保証される。6.8クエリ交換時に1つのスピーカのみがポーリングされるコンソール200とスピーカとの間の完全なクエリ交換は以下のようにして実行される。1クエリを送信する必要がある場合、コンソール200は、通常のポーリングサイクルに割り込みをかけ、所望のクエリを適切なスピーカに即座に送信する。2スピーカは、可能ならば、767μ秒以内にその応答を送信する。可能でなければ、767μ秒以内にPOLLRESPONSEメッセージで応答する。3コンソール200は、他のすべてのスピーカをポーリングすることを差し控え、その代わりに、このスピーカのみを6m秒おきにポーリングする。スピーカは、クエリ応答の用意が整うまでPOLLRESPONSEメッセージで応答する。用意ができたら、所望のクエリ応答で応答する。4所望のクエリ応答を受信した後、コンソール200は、すべてのスピーカに対する通常のポーリングサイクルを再開する。代替えとして、スピーカが全く応答できない場合、またはOFFとして応答する場合、通常ポーリングは、高水準のソフトウェアの裁量により再開することもできる。6.8メインルームの外で使用されるコマンドの全リストメインルーム内のスピーカは、後述のメッセージ定義を使用する。メインルームの外のスピーカは、例えば、音量大小、ミュートミュート解除、およびオンオフといった限られた制御メッセージのみを使用できる。他のすべての特定のコントロールは、リモートコントロールコマンドを透過的にコンソールからスピーカに受け渡すことにより処理することができるが、ただし、それらが正常に解釈される場合に限る。以下に、非メインルームスピーカにより受信できるコマンドのリストを示す。メッセージの構成の詳細については、以下のメッセージ定義を参照されたい。6.8.1POLLおよびPOLLREPLYメッセージポーリングは、最低優先度メッセージであり、ポーリングサイクルによる決定に従いコンソール200によりすべてのスピーカに連続的に送信される。すべてのスピーカのONOFF、LocalNetwork、および音量ミュートステータスを監視するほかに、スピーカからコンソール200にメッセージを頻繁に送信する機会を与えるため、コンソール200により使用される。高い優先度のメッセージを送信する必要がある場合に割り込みが発生する。スピーカは、通常、PollReplyで応答するが、保留中のものがあればより高い優先度の応答を置き換える。6.8.2ONOFFメッセージこのメッセージは、スピーカをONまたはOFFにするためにコンソール200により使用することができる。スピーカは、さらに、いくつもの異なるパススルーされたRFリモートボタンを受け取った後、またはローカルのIRリモートからコマンドを受け取った後にオンになりうる。これらの場合、ポーリングは、電源オンを検出するために使用される。6.8.3PASSKEYCODEメッセージこのメッセージは、スピーカ特有のRFリモートコントロールコマンドを通すためにコンソール200により使用されることができる。コンソール200は、これらのコマンドを全く解釈しえない。ヘッダ0x8Dを使用することで、スピーカは、ボタン押下を上流に向かってコンソール200に送り返すことができる。6.8.4SETMAINATTENUATIONメッセージコンソール200は、MuteAllイベントに対する応答として、MuteおよびReturntoLastVolume引数をブロードキャストとして使用できる。6.8.5QUERYSPEAKERINFOメッセージこのメッセージは、取り付けられているさまざまなスピーカを判別するためにコンソール200により使用される。コンソール200は、さらに、QueryMainAttenuationおよびQueryDownloadInfoStatus引数を使用することもできる。6.8.6DOWNLOADINFORMATIONメッセージこのメッセージは、コンソール200ステータス情報をスピーカにプッシュする場合に使用するか、または他のデータブロックをスピーカに送信する場合に使用することができる。ヘッダ0x8Aを使用することにより、スピーカはこのメッセージタイプを利用して、データのブロックをコンソールにアップロードすることができる。7.0ポーリングサイクル7.1概要ポーリングに対する標準的な応答では、そのオンオフ状態、ローカルネットワーク聴取モード、ミュート状態、および音量レベルに関する基本的なスピーカステータス情報を供給することができる。スピーカは、標準ポーリング応答に対する高い優先度のメッセージを置き換える機能を持ち、これにより、重要なボタン押下およびデータのブロックを上流に向かってコンソール200に転送する機会を与える。ネットワークに接続されているスピーカは、長時間にわたってオフになっている場合がある。オフの場合、スピーカは、キーストロークでオンになった場合を検出するために時折ポーリングするだけでよい。しかし、接続され、かつオンにされているスピーカは、上流に向かってコンソール200に送信されるメッセージの適切な応答時間を保証するために高速なポーリングが実行されなければならない。そこで、これらの必要条件を満たし、ONのスピーカの個数が増えたときに予測可能な形で、ただし急激にでなくデグレードするようにパフォーマンスが制御されるポーリングサイクルについて説明する。72ポーリングサイクルのタイミングの詳細ポーリングプロセスでは、15個の可能なスピーカのすべてを2つのリスト、つまり、現在ONのスピーカと、NOTONスピーカに編成する。コンソールは、まず、現在ONのスピーカリストのすべてのメンバをポーリングし、その後、NOTONリストの単一メンバをポーリングする。これは、ポーリングサイクルの1サブサイクルを表す。その後、サブサイクルは繰り返すが、その際に、NOTONリストの次のメンバを除くONスピーカの同じリストを使用する。例えば、スピーカAのみがONの場合、全ポーリングサイクルは以下のようになる。AB、AC、AD、AE、AF、AG、AH、AI、AJ、AK、AL、AM、AN、AO、その後、これは、割り込みなしで繰り返す。全部で14のサブクラス。1サブサイクル~11ミリ秒。全サイクル~153ミリ秒。スピーカCおよびGのみがONであるとわかっている場合、ポーリングサイクルは以下のようになる。CGA、CGB、CGD、CGE、CGF、CGH、CGI、CGJ、CGK、CGL、CGM、CGN、CGO、その後、これは繰り返す。13サブサイクル。1サブサイクル~16ミリ秒。全サイクル~214ミリ秒。すべてのスピーカがONであった場合、ポーリングサイクルは以下のようになる。ABCDEFGHIJKLMNO、その後、これは繰り返す。15サブサイクル。1サブサイクル全サイクル~82ミリ秒。この結果、スピーカからコンソールまでのメッセージの待ち時間は最長となる。すべてのスピーカがNOTONであった場合、ポーリングサイクルはすべてONの場合と同じになる。15サブサイクル。最長の全サイクルは、7個のスピーカONで、残りNOTONである。1サブサイクル~44ミリ秒。全サイクル~351ミリ秒。これは、スピーカがONになるのを識別する最長の待ち時間を持つ。ポーリングサイクルのそれぞれのサブサイクルが完了すると、ONスピーカおよびNOTONスピーカのリストは、ポーリング応答に基づいて更新されなければならない。最後のサブサイクルでONとして応答した、すでにNOTONであるスピーカは、即座に、ONリストに移行しなければならない。OFFとして応答した、または5サブサイクルの間に一斉に応答できなかった、すべてのすでにONであるスピーカは、NOTONリストに移動されなければならない。コンソールのリセット後、ポーリングが最初に開始したときに、NOTONリスト内のすべてのスピーカが開始する。7.3標準的なポーリングおよび応答メッセージバイトコンソールまたはスピーカに、送信する高い優先度のメッセージがない限り、システムは、既定で、以下のような形式のメッセージを使用してポーリングサイクルに入る。ConsolePoll第1のバイト0x00。第2のバイト現在の通常プロトコルによる。第3のバイト現在の通常プロトコルによる。SpeakerPollReply第1のバイト0x80。第2のバイトオンオフローカルネットワークステータスを含む、スピーカのアドレスバイト。第3のバイト以下のように音量ミュートステータスになる引数詳細ビット60現在の通常プロトコルによる、スピーカのMainAttenuationレベル。ビット7ミュート状態1ミュート。0ミュートしていない。第4のバイト現在の通常プロトコルによる。7.4PASSKEYCODEメッセージを応答として使用するコンソールメッセージの後では真であるが、このメッセージは、送信できる場合に、コンソールPOLLメッセージの後に、SPEAKERINFO応答の代わりに返される。Argumentバイトは、コンソールを制御することを意図されている256個の可能なボタンのうちの1つに関連付けられたキーコードを含む。注意IRRFリモートに対する既存のキーコードは、可能ならば使用されなければならない。75DOWNLOADINFORMATIONメッセージを応答として使用するこのの応答は、送信できる場合には、ポーリングを含む、コンソールメッセージの後に、SPEAKERINFO応答の代わりに返される。ArgumentDataバイトは、コンソール向けの何らかの種類のデータ、高水準のコマンド、またはクエリを含むことも可能である。これは、リモートコントロールに表示するためローカル音源関連のデータをコンソールに送信する場合に使用できる。さらに、これにより、スピーカは音源変更などを直接指令したり、またはローカルディスプレイに対するゾーン音源特有のステータス情報を要求することも、概念的には可能である。8.0高レベルのスピーカ制御問題8.1マスタースレーブ構成与えられたバス上にマスターが1つだけある。バスMasterは、バスがIdle状態である限り、また後述のメッセージタイミング詳細に留意する限り、いつでも送信を開始できる。スピーカは、コンソールによって送信されたメッセージの後でないと送信しない。しかし、後述のように、コンソールメッセージは、スピーカが送信を開始するためのちょうどよい機会として使用することができる。8.2部屋のアドレス指定は一意であるネットワークに追加される新しいスピーカは、ネットワークに接続する前に、一意的な4ビットRoomAddressを適切に設定しておく。8.3Zone1およびZone2に対する別々の物理的バスの管理コンソール200は、2つの別々の物理的スマートスピーカバスを備える。Zone1およびZone2オーディオストリームは、Zone2SpeakerData信号のように、Zone2SpeakerOutputコネクタ上で使用可能である。RoomBからRoomOスピーカは、そのプラグをZone2SpeakerOutputコネクタに差し込み、Zone2SpeakerData信号を使用して制御することができる。8.4スピーカ制御モードMasterModeおよびPassThroughModeという、スピーカを制御する2つの異なるモードを使用できる、SmartSpeakerメッセージが定義される。MasterModeコマンドを使用すると、制御ユニットはすべてのクリティカルなスピーカパラメータを追跡し、適宜、それらのパラメータを絶対値としてスピーカに送信することができる。PassThroughModeでは、インテリジェント機能の低い制御ユニットでも、リモートコントロールメッセージを効果的にスピーカに直接受け渡すことができる。このモードでは、スピーカは、クリティカルなパラメータを追跡する。MasterModeを介してネットワーク接続スピーカを制御することを望んでいるコンソールでは、制御すべきスピーカのそれぞれのタイプの利用可能な特徴を記述したテーブルを保持する。8.5新しいスピーカの検出電源投入後、ネットワーク接続スピーカは、OFFSTATEに入り、ハードウェアを最低電流状態にする必要がある。この状態では、ネットワークとインターフェイスする役割を持つハードウェアのみが動作している。スピーカは、PollMessages、QuerySpeakerInfoMessages、さらにONOFFMessagesを受信し、それに応答できる。コンソールは、可能なすべてのスピーカRoomAddressesを連続的にポーリングするので、SmartSpeakerバスに新規追加されたスピーカは、ポーリングに応答し始めるとすぐに検出されることができる。新しいスピーカが検出されたら、コンソールは、QuerySpeakerInfoメッセージを送信して、そのタイプを識別しなければならない。8.6ネットワーク接続スピーカの電源オンネットワーク接続スピーカにPollまたはQuerySpeakerInfoメッセージ以外のコマンド送信する前に、まず、ONOFFMessageを使用してオンにしなければならない。これにより、スピーカのハードウェアは完全に動作するようになる。コンソール200は、この電源オンプロセスが完了できるように適宜遅延すべきである。それぞれのネットワーク接続スピーカに対する電源オン遅延を記述するテーブルが用意されていない場合、コンソール200では、既定の遅延時間として1秒を使用しなければならない。8.7ボーリングによるスピーカステータスの変化の検出このポーリング過程で、スピーカの応答のAddressByteのビット74は、オンオフステータスに関する情報だけでなく、以下のように、再生している音源に関する情報も含む。Z3Z000001101b14個の可能なZonesのうちの1つを再生する。1110bローカル音源を再生する。1111bOFF。現在、ローカルまたはネットワーク接続音源を再生していない。これらのビットを監視することにより、以下の重要なステータス変化が生じた場合を検出することができる。8.7.1スピーカのオンオフスピーカは、ユニット自体のボタンを使って、またはそのIRリモートコントロールを介して、またはその重要性を理解することなくコンソールに単純にパススルーするリモートコントロールコマンドを介して、オン、オフすることも可能である。AddressZ3Z0ビットを使用することにより、コンソール200はそれぞれのスピーカのオンオフ状態を監視することができる。これにより、コンソール200は、例えば、すべてのスピーカがオフの場合に電源オフにすることができる。8.7.2スピーカの音源変更同様に、スピーカは、コンソール200がそれと予期することなく、Zone1とZone2を切り替えることができる。同じAddressビットを監視することにより、コンソール200は、そのような変更を検出し、適切な処置を講じることができる。88スピーカストリームの切り替えの管理スピーカは、コンソールからZone1またはZone2ネットワーク接続アナログ出力のいずれかを選択する機能を持つことができる。スピーカは、すべてのコンソールPassKeyCodeメッセージおよびOnOffメッセージのAddressバイトのZoneビットに反応することにより自動的にこの選択を行う。これらのメッセージは、RFリモートコントロール上のボタン押下の直接的結果としてスピーカに送信され、したがって、Zoneビットはリモートからメッセージを受け取ったとおり正確にセットされる。OnOffメッセージは、ここでは、コンソールがすべてのリモートコントロールの音源ボタン押下に対する応答としてそのメッセージを送信し、その場合OnOffメッセージにより、音源が選択されたときにネットワーク接続スピーカはONおよびミュート解除の両方の状態になる。PassKeyCodeメッセージがローカル音源を再生するスピーカに送信されても、Localモードからスピーカが切り替わることはない。PassKeyCodeメッセージがOnOFFボタン引数とともにスピーカに渡されると、最後に再生された音源でスピーカは電源オンになる。この場合にスピーカ側でネットワーク接続ストリームゾーンを再生することを選択した場合、メッセージAddressで示されるストリームを選択する。9.0メッセージ定義9.1早見表9.2コンソールにより送信されるメッセージ以下のメッセージは、コンソール200により送信することができるメッセージ定義集の例である。9.2.1POLLメッセージ送信側コンソール総バイト数3キュー優先度低PollMessageは、現在定義されている唯一の3バイトメッセージである。そのAddressバイトの4個の最上位ビットで、スピーカで再生する適切なオーディオZoneを識別する。4個の最下位ビットで、ポーリングされるスピーカを識別する。Argumentは必要ないので、使われず、ネットワーク帯域幅が節約される。Pollメッセージは、PollResponse情報を取得し、スピーカに他の重要なメッセージを渡す通常の機会を与えるために、実際には、単純なクエリ形式で送信される。9.2.2ONOFFメッセージ送信側コンソール総バイト数4キュー優先度高ONOFFMessageは、オーディオ再生の準備のため完全電源オンにするか、またはセッションの後電源をオフにするようアドレス指定されたSmartSpeakerに通知する。注意このコマンドは、リモート上の音源ボタンが押されたときにコンソールにより使用され、これにより、スピーカの完全電源オン、ミュート解除、所望のネットワーク入力ストリームの選択を行うようにできる。スピーカの電源レールなどがミュート解除できるようになる前に整定するのにある程度の時間を要することが予想される。オンになった後、システムは、この問題に対し以下の3つの方法で対処することができる。1コンソールからスピーカに対し準備完了しているか問い合わせしてから、スピーカモード、減衰レベルなどを構成するよう指令することができる。2スピーカは、ミュート解除の準備が整うまでSETSPEAKERMODEなどの後続のコマンドに応答しないことを単に選択することができる。3コンソールは、OnOffメッセージの送信から後続のメッセージの送信までの間に遅延を設定することができる。9.2.3SETMAINATTENUATIONメッセージ送信側コンソール総バイト数4キュー優先度高SetMainAttenuationメッセージで、アドレス指定されたSmartSpeakerにそのマスター音量設定を示されているレベルに変更するよう指令する。注意引数は、減衰のdBで表された新しいレベルを含み、0dBはスピーカの最大音量を表す。スピーカの利用可能なダイナミックレンジは、QuerySpeakerInfo応答を通じて渡される。9.2.4SETSECONDARYLEVELSメッセージ送信側コンソール総バイト数4キュー優先度高9.2.5SETEQTYPETONELEVELSメッセージ送信側コンソール総バイト数4キュー優先度高9.2.6SETSPEAKERMODEメッセージ送信側コンソール総バイト数4キュー優先度高9.2.7CONTROLEFFECTSメッセージ送信側コンソール総バイト数4キュー優先度高9.2.8SELECTAUDIOINPUTメッセージ送信側コンソール総バイト数4キュー優先度高9.2.9SELECTDECOMPRESSORメッセージ送信側コンソール総バイト数4キュー優先度高9.2.10SELECTPOSTPROCESSINGメッセージ送信側コンソール総バイト数4キュー優先度高9.2.11DOWNLOADINFORMATIONメッセージ送信側コンソール総バイト数5255キュー優先度中DOWNLOADINFORMATIONメッセージは、SmartSpeakerパケット自体を介して最大250バイトまでのデータをスピーカに送信できる形式を持ち、ペイロードは好きなように定義することができる。スピーカVFDに直接書き込む、またはコンソールステータスの変更をアナウンスする、このメッセージタイプの変種を定義することも可能である。9.2.12QUERYSPEAKERINFOメッセージ送信側コンソール総バイト数4キュー優先度高9.2.13PASSKEYCODEメッセージ送信側コンソール総バイト数4キュー優先度中PassKeyCodeメッセージは、この場合、RFリモートコントロールボタンの押下をスピーカにパススルーするためにコンソールにより使用される。Argumentバイトは、RFリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。9.3スピーカによって送信されるメッセージ以下は、スピーカにより送信されることが許されているメッセージの例である。9.3.1POLLREPLYメッセージ送信側スピーカ総バイト数4キュー優先度低9.3.2DOWNLOADINFORMATIONメッセージ送信側スピーカ総バイト数5255キュー優先度中9.3.3QUERYSPEAKERINFOREPLYメッセージ送信側スピーカ総バイト数4キュー優先度高9.3.4PASSKEYCODEメッセージ送信側スピーカ総バイト数4キュー優先度中PassKeyCodeメッセージは、この場合、ローカルスピーカボタン押下を上流のコンソールに送信するためにスピーカにより使用される。Argumentバイトは、スピーカのローカルIRリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。10.0無線デバイス無線デバイスを含むオーディオネットワーク制御システムの実施例では、無線デバイスは、無線チャネルを通じて送信されるメッセージの完全性に関する責任を負う。これは、コンソールから下流に向かってスピーカに送信されるメッセージとともに、それに対する応答として送り返されるメッセージに適用される。合意されているレベルのロバスト性を保証するために、トランシーバにより付加的な誤り防止訂正機能が追加される。コンソールからのポーリングは、無線リンクを介しては送信されない。その代わりに、無線スレーブが、それに接続されているスピーカをローカルでポーリングし、20ミリ秒毎に1回無線マスターに応答を送信する。無線マスターは、それらの応答をバッファリングし、ローカルで、適切なポーリングに対する応答としてそれらをコンソールに受け渡す。以下で詳細を述べる。既定の応答も、場合によってはクエリ応答がバックリンクを介して返されるまで、コンソールからスピーカへの他のすべてのメッセージに対する応答として無線マスターにより生成される。スレーブデバイスでは、スピーカにはコンソールに接続されているのと十分同じであるように見えるSmartSpeakerインターフェイスを実装している。これは、コンソールと同様の方法でスピーカをポーリングすること、このポーリングに割り込みをかけて下流メッセージを即座にスピーカに渡すこと、およびすべてのポーリング応答情報を組み立てて、バックリンクを介してコンソールに送信することを含む。Slaveのポーリングは、1つのWirelessSlaveがすべてのネットワーク接続スピーカ専用に割り当てられるというトポロジ的な利点があれば、いくぶん簡素化される。10.1スレーブのローカルポーリングサイクルコンソールにより生成されるポーリングはSlavesに送信されないため、それぞれのSlaveは、その関連するスピーカを自律的に識別し、ローカルポーリングサイクルを管理する。WirelessSlavesは、接続されている単一スピーカをポーリングするだけでよい他のスピーカに対してローカルポーリングは不要である。接続されているスピーカのRoomCodeを判別するために、WirelessSlaveは、次のようにして、コンソール内に実装されるポーリングサイクルのより単純なバージョンを設定する。1WirelessSlaveは、応答のあるスピーカが見つかるまで可能なすべてのスピーカを連続的にポーリングする。2その後、WirelessSlaveは、20ミリ秒の速さでそのスピーカのみをポーリングする。3スピーカが応答を停止した場合、無線マスターは、応答スピーカが見つかるまで可能なすべてのスピーカのポーリングを再び開始する。20ミリ秒のバックリンク期間毎にそれに間に合うように1回のボーリング応答を確実に組み立てるために、SlaveによりWirelessSlaveのローカルポーリング期間を同期させ、ポーリング交換がそれぞれのバックリンクメッセージの送信直前に実行されるようにする。したがって、スピーカ高優先度メッセージは、Slaveから無線マスターへの送信の機会が得られるまでに最大約20ミリ秒の待ち時間を被る。10.2ローカルポーリングに対するコンソールメッセージの優先度すでに概要を述べたように、コンソールメッセージの送出は、スピーカからポーリング情報を取り出すことよりも優先度が高い。したがって、Slaveが接続されているスピーカ向けのメッセージをコンソールから受信すると、メッセージは、ローカルポーリングサイクルのタイミングに関係なく、スピーカに即座にパススルーされなければならない。10.3スレーブのローカル再試行ルールそれぞれのSlaveは、再試行が使用されなければならない2つの状況を管理する必要がある。Slaveのローカルスピーカにパススルーされたメッセージに対しスピーカによる応答が行えない場合。バックリンクを介してSlaveによりコンソールに送信されたメッセージが無線マスターにより正常に受信されない場合。第1の場合、Slaveは、スピーカへのコンソールのメッセージの即時再試行をローカルで管理する。1回の再試行のみが必須として定義される。ここでもまた、これは、この再試行がスピーカのスケジュールされたローカルポーリングに干渉する場合に受け入れ可能である。第2の場合は、バックリンクを介して試行されたメッセージ転送の直後のWirelessマスターからSlaveへのある種の形態のフィードバックを想定する。このようなフィードバックは、次のWireless20ミリ秒ポーリングサイクルのときに含めるように定義されなければならない。実際に、これは、Wirelessマスターからそれぞれの影響を受けるSlaveへのRequestforRetryの形をとらなければならない。SlaveがこのRequestforRetryを確認した場合、バックリンクを介して情報送信する次の機会に、もう一度、最後のスピーカメッセージの再送に有利になるようにWirelessマスターにポーリング情報を送信することを差し控えなければならない。この再試行メカニズムは、Wirelessマスターにメッセージを届けるために必要なだけ続けることが可能であり、Wirelessマスターの支配下になければならない。ここでは、100ミリ秒がリミットとして適切である。スピーカポーリングは、再試行状況を通じて続行することができ、これにより、スピーカポーリング情報を更新し、メッセージをキューにバッファリングして、バックリンクを介して送信する次の機会を待つことができる。10.6Wirelessマスターの一般的な役目WirelessMasterは、説明されているように、スピーカSlavesから受信されたすべてのメッセージおよびポーリング情報による適切な時間内での応答により、実際には、そのスピーカ群にハード配線されているとコンソールに思いこませることにより、コンソールポーリングプロトコルの条件を満たす。後述のようにいくつかの特定の役目にはこれが欠けている。10.6.1ローカルで使用するようにスピーカのポーリング応答をバッファリングするWirelessMasterは、スピーカからの高い優先度のメッセージが保留になっていない場合に、すべての接続スピーカについて、すべてのコンソールメッセージに対する応答としてPollReplyメッセージを送信する。これらのPollRepliesを生成するために、Slavesのローカルポーリングサイクルから得られるバックリンクメッセージをバッファリングし、この情報を使用して、タイミングの制約条件の範囲内で適切な応答をフォーマットする。ポーリング情報は同じ状態変数の進行中の更新を表すので、それぞれのスピーカに対するポーリングステータスバッファは、メッセージ1つ分の深さしかなく、さらに新しいデータがスピーカから取り出される毎に絶えず更新される。Wirelessマスターは、与えられたスピーカから無効なポーリング応答データを受信した場合、Wirelessマスターはバッファ内に格納されているデータを使用して、コンソールに応答することになる。Wirelessマスターが5秒以内に与えられたスピーカから有効なポーリング応答情報を受信できない場合、Wirelessマスターはそのスピーカに関連付けられているポーリングステータスバッファを空にし、コンソールによりポーリングされたときに差し控えていた応答を開始する。ONスピーカなどのリストからそのスピーカを削除することはコンソール側の役目である。10.6.2ポーリング応答の代わりに高優先度スピーカメッセージを使用する前のセクションで説明したように、スピーカは、コンソールメッセージに対し、保留になっている最高優先度戻りメッセージで応答する。したがって、これをシミュレートするために、WirelessMasterは、PollReplyよりも優先度の高いメッセージが与えられたスピーカからいつ保留になったのかを識別し、そのスピーカに対する次のコンソールメッセージの後に、このメッセージを既定値のPollReplyの代わりに使用する。中優先度と高優先度のメッセージが保留になっている場合、高優先度メッセージが最初に送信されなければならない。これらの高優先度メッセージをコンソールに渡しても、それぞれのスピーカに対するポーリングステータスバッファを破損しない。高優先度メッセージがコンソールに渡された後、WirelessマスターはPollReplyメッセージでの応答に戻らなければならない。10.6.3高優先度コンソールメッセージの役目すでに述べたように、WirelessMasterは、すべてのコンソールメッセージに応答する。これは、コンソールメッセージの優先度に関係なく成立する。応答は、すでに説明されている767μ秒のウィンドウの範囲内で開始する。コンソールにいったん応答すると、Wirelessサブシステムでは、高い信頼性の下で中または高優先度コンソールメッセージをスピーカに送出する役割を持つが、なぜかというと、コンソール側では、これ以降、それらのメッセージはスピーカによって受信されたとみなし、より高いレベルで再試行を管理できなくなる場合があるからである。10.6.4クエリ交換時の役目前のセクションで説明したように、コンソールは、特定のスピーカにクエリを送信すると、応答が返されるまで他のスピーカのポーリングを停止する。その代わりに、応答が保留中であるスピーカを連続してポーリングする。このような状況では、WirelessMasterは、以下のいずれかが生じるまでコンソールのポーリングに対する応答を単に続けるだけである。1コンソール側で、他のスピーカのポーリングをあきらめて、また再開するか、または2クエリ応答が所望のスピーカから抜けてくる。Wirelessマスターは、これに、ポーリング応答よりも高い優先度を与え、したがって、それを次の有効なポーリングに対する応答としてコンソールに転送すべきである。10.6.5スレーブへの再試行の要求Wirelessバックリンクはダウンリンクよりも信頼性が劣る場合があるため、Slaveからの高優先度メッセージはWirelessマスターに破損した状態で到着する可能性がある。このような状況では、Wirelessマスターは、メッセージが無傷で転送されるまでSlaveに再試行を継続的に要求することができる。他の実施形態は、請求項の範囲内に収まる。