JP2012050136A - オーディオネットワークの管理 - Google Patents
オーディオネットワークの管理 Download PDFInfo
- Publication number
- JP2012050136A JP2012050136A JP2011243520A JP2011243520A JP2012050136A JP 2012050136 A JP2012050136 A JP 2012050136A JP 2011243520 A JP2011243520 A JP 2011243520A JP 2011243520 A JP2011243520 A JP 2011243520A JP 2012050136 A JP2012050136 A JP 2012050136A
- Authority
- JP
- Japan
- Prior art keywords
- message
- audio
- speaker
- console
- polling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
- H04R2227/00—Details of public address [PA] systems covered by H04R27/00 but not provided for in any of its subgroups
- H04R2227/005—Audio distribution systems for home, i.e. multi-room use
Abstract
【課題】オーディオデバイスに対するコマンドを含むメッセージを受信し、そのコマンドをオーディオデバイスに送信する方法を提供すること。
【解決手段】メッセージは、送信されスレーブデバイスを制御するために使用される前にマスターデバイスで処理される。コマンドは、マスターデバイスを通じて、マスターデバイスで処理されることなくスレーブデバイスに渡される。リモートコントロールは、マスターデバイスとスレーブデバイスを制御する。コマンドは、マスターデバイスとスレーブデバイスとの間の第１の通信チャネル上で送信される。オーディオストリームは、該通信チャネル上でコマンドと多重化される。オーディオストリームは、マスターデバイスとスレーブデバイスとの間の第２の通信チャネル上で送信される。第１の通信チャネルは、無線チャネルを含む。スレーブデバイスは再生のためローカルの音源とオーディオストリームとから選択する。
【選択図】図２
【解決手段】メッセージは、送信されスレーブデバイスを制御するために使用される前にマスターデバイスで処理される。コマンドは、マスターデバイスを通じて、マスターデバイスで処理されることなくスレーブデバイスに渡される。リモートコントロールは、マスターデバイスとスレーブデバイスを制御する。コマンドは、マスターデバイスとスレーブデバイスとの間の第１の通信チャネル上で送信される。オーディオストリームは、該通信チャネル上でコマンドと多重化される。オーディオストリームは、マスターデバイスとスレーブデバイスとの間の第２の通信チャネル上で送信される。第１の通信チャネルは、無線チャネルを含む。スレーブデバイスは再生のためローカルの音源とオーディオストリームとから選択する。
【選択図】図２
Description
本発明の説明は、オーディオネットワークを管理することに関係する。
家族の何人かが、さまざまな部屋で異なるオーディオを選択して聴くことができ、しかもそれぞれの部屋に追加音源を用意する必要はない。中心となる部屋に置かれているマスターデバイスに接続されているCDチェンジャまたはデジタル音楽プレーヤーなどの中央集中音源は、マスターデバイスと通信する他の部屋にあるスレーブデバイスからアクセスされ、制御されることができる。
一般に、一態様では、本発明は、少なくとも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つまたは複数がある。オーディオネットワーク制御システムは、交換可能なスレーブデバイス(例えば、オーディオ再生またはオーディオ情報表示デバイス)で動作することができる。このため、マスターデバイスとスレーブデバイスとを混ぜてマッチングさせることにより、複数の統一小売価格を組み立てられる。スレーブデバイスは、共通通信プロトコルを使用することができる。マスターデバイスは、スレーブデバイスの特徴またはユーザインターフェイスの仕様を知る必要がない。共通通信プロトコルを使用することに加えて、スレーブデバイスには、共通の一連の動作がありえる。例えば、すべてのスレーブデバイスは、同じようにミュート、ミュート解除、音量調整コマンドに応答することができる。それとは別に、いくつかのスレーブデバイス(例えば、無線デバイス)は、共通通信プロトコル(例えば、メッセージ形式)のいくつかの共通の態様を共有できるが、他の態様(ポーリング手順)では異なる場合がある。
さらに、オーディオネットワーク制御システムを使用することで、ユーザは、複数の部屋にわたって、また複数のリモコンを使用しても、継ぎ目のない運用を行える。システムは、リモートルームでも、メインルームとほぼ同じように動作することができる。スレーブデバイスは、マスターデバイスのリモコンでも、ネイティブリモコンとほぼ同じように機能することができる。この継ぎ目のない動作を実現するために、マスターデバイスは、リモートコントロールから受信したコマンド(例えば、無線周周波数(RF)または赤外線(IR)リモコン)を適切なスレーブデバイスにディスパッチすることができる。新しい機能を持つ将来のスレーブデバイスとの相互運用性を確実なものとするため、マスターデバイスは、不明なコマンドをスレーブデバイスへ通り抜けさせることができる。マスターデバイスは、そのコマンドがどのようなものであるかを知る必要はない。この点で、マスターデバイスは、ルータとして機能し、コマンドの発信元と送信先を判別する。場合によっては(例えば、音源変更コマンド)、コマンドはマスターデバイスのコマンドプロセッサに送られる。他の場合には(例えば、不明なコマンド)、コマンドは、スレーブデバイスに直接経路指定される。この決定は、スレーブデバイスの状態および受信したコマンドに基づく。このようにして、新しいタイプのスレーブデバイスに拡張可能なシステムを作成することが可能である。
いくつかのスレーブデバイスは、それ自体、システムとすることもでき、他の接続されたデバイスに対する制御統合を含むことができる。そのような制御自動化は、通常、スレーブデバイスのネイティブリモートコントロールを通じてアクセスされる。その制御自動化は、上記の経路指定メカニズムを介してサポートすることができるマスターデバイスのリモートコントロールからアクセス可能である。スレーブデバイス側で制御統合に対応するために、マスターデバイスによる追加処理は必要ない。
通信プロトコルは、スレーブスピーカ上のローカルボタンでマスターコンソールを制御できるようにする優先順位付けされたメッセージを含む。スレーブデバイスは、ステータスなどあらゆる種類のメッセージをコンソールに送り返すことができるが、最高優先度のメッセージは、例えばスレーブスピーカ上のローカルボタンが押されたときの「制御」コマンドである。制御コマンドは、マスターコンソールを制御するために使用される。
本発明の他の特徴および利点は、以下の詳細な説明および請求項から明白になるであろう。
本発明の他の特徴および利点は、以下の詳細な説明および請求項から明白になるであろう。
１．概要
図1Aは、部屋が複数ある環境におけるオーディオデバイスのネットワークを含むオーディオネットワーク制御システム100を示している。システム100は、第1の部屋120にマスターデバイス110およびスレーブデバイス112Aを、第2の部屋122にスレーブデバイス112Bおよび112C、および第3の部屋124にスレーブデバイス112D〜112Fを備える。マスターデバイス110は、例えば、コンピュータの通信機能(例として、デスクトップ、ラップトップ、またはハンドヘルドコンピュータ)を利用するスタンドアロンのコントロールコンソールまたは制御プログラムを備える。スレーブデバイス112A〜112Dは、スピーカ、オーディオ再生および/または記録機能を備える電子デバイス、またはオーディオストリームに関する情報を収集し、および/または表示するデバイスを含む、さまざまなデバイスのどれかを備えることができる。スレーブデバイスは、図1Bに概略が示されているように、マスターデバイスインターフェイスおよびスレーブデバイスインターフェイスを含む通信プロトコル140により通信チャネル(例えば、有線バスまたは無線チャネル)を介してマスターデバイス110と通信する。
図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の部屋(RoomAおよびRoomB)内にデバイスを備え、Zone2は、第3の部屋(RoomC)内にデバイスを備えることができる。
通常動作では、マスターデバイスは、接続されているすべてのスレーブデバイスを連続してポーリングし、それらがネットワーク上にあり、オンになっているかを判別する。例えば、実際の一例では、スレーブデバイスに対しては、「On」、「Off」、「Local」、または「Not Responding」の4つの状態がありえる。ほかに、スレーブデバイスに対する状態が4つよりも少ない実例も、多い実例もありえる。マスターデバイスのコマンド処理は、次のようにしてスレーブデバイスの状態に応じて進行する。
すべての状態において、マスターデバイス110は、以下で詳述するように、音量およびミュートコマンドをマスターリモート130から通信プロトコル140に従って一致する部屋コードを持つスレーブデバイスに経路指定する。ポーリングした結果、スレーブデバイスが「オン」になっていることをマスターデバイスが検出すると、マスターデバイス110は、適切なゾーンをアクティブ化し、最後に選択された音源の再生を開始する。ゾーンがすでに再生している場合、スレーブデバイスはそのゾーンに対する現在の音源を結合する。与えられたゾーンに接続されているすべてのスレーブデバイスが「オフ」または「ローカル」のいずれかであるとマスターデバイス110が判別した場合、これは、そのゾーンの電源を切る。
スレーブデバイスが「オン」状態の場合、マスターデバイスに知られている制御コマンドは、マスターデバイス固有の方法により処理される。マスターデバイス110によって認識できない新しい特徴を備えるスレーブデバイスなどの不明なコマンドが適切なスレーブデバイスに渡される。これにより、マスターデバイス110は、追加された新しいコマンドを含むことができるスレーブデバイスの新しいクラスに拡張することができる。
スレーブデバイスが「Local」状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。トランスポートコマンドは、マスターデバイス110によりローカルで処理されない。このため、すべてのマスターデバイス110内部トランスポートとともにリモートデバイスのローカルトランスポートでも完全にコンテキスト依存のトランスポートコマンドが使用可能である。
スレーブデバイスが「Off」状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。これにより、ローカル音源選択コマンドまたはOn/Offコマンドを送信することによりスレーブデバイスの電源を入れることができる。「On/Off」コマンドの場合、スレーブデバイスは前に選択された音源で電源オンになる。音源がマスターデバイス110であった場合、状態は「On」に設定され、これは、次のポーリングサイクルで捕捉される。この方式は、それぞれのスレーブデバイスが各自の動作を管理するという点で非常に拡張性が高く、マスターデバイス110は、それぞれのスレーブデバイスに関して最小限度のことのみを知っているだけでよい。
スレーブデバイスが「Not Responding」状態にある場合(例えば、サードパーティ製のアンプの場合のように)、トランスポートコマンドを含むすべてのコマンドは、上述の「Off」状態の場合と同様に、マスターデバイス110を通じて適切なスレーブデバイスに渡される。しかし、マスターデバイス110は、リモートからオン/オフおよび音源選択キー押下を追跡することによりそれらのスレーブデバイスに対するオン/オフ状態変数を管理する。このため、マスターデバイス110はゾーンをいつ適切にシャットダウンするか(例えば、それを使用している部屋がいつオフになるか)を知ることになる。スレーブデバイスの電源がオンになり、ネットワーク上での応答を開始した場合、その応答に含まれるオン/オフ状態情報は高い優先度を与えられ、その部屋に対するマスターデバイス110オン/オフ状態変数を更新するために使用される。
２．通信プロトコル
通信プロトコル140により、マスターデバイスは、それぞれ一意的なアドレス(高々1つのスレーブデバイスが与えられたアドレスを使用することができる)を持つ所定の数(例えば、一実施例では15)のネットワーク接続スレーブデバイスをサポートすることができる。これらのアドレスは、例えば、RoomA、RoomB、RoomCなどで、最大RoomO(15個のスレーブデバイスの場合)である。16番目のアドレス(実際には、RoomP)は、ブロードキャストメッセージ用に予約されている(すべてのスレーブデバイス向けである)。これら15個のスレーブデバイスは、リモートコントロールコマンドに対する応答として、与えられた任意の時点に、Zone1、Zone2、または追加ゾーンオーディオストリームのどれかを再生することができる(またはどれも再生しない)。したがって、通信プロトコル140に対して、部屋コードだけで、特定のスレーブデバイスを識別することができ、スレーブデバイスに送信されるゾーン情報は、単に、再生されることが意図されているオーディオストリームをスレーブデバイスに知らせるだけである。
通信プロトコル140により、マスターデバイスは、それぞれ一意的なアドレス(高々1つのスレーブデバイスが与えられたアドレスを使用することができる)を持つ所定の数(例えば、一実施例では15)のネットワーク接続スレーブデバイスをサポートすることができる。これらのアドレスは、例えば、RoomA、RoomB、RoomCなどで、最大RoomO(15個のスレーブデバイスの場合)である。16番目のアドレス(実際には、RoomP)は、ブロードキャストメッセージ用に予約されている(すべてのスレーブデバイス向けである)。これら15個のスレーブデバイスは、リモートコントロールコマンドに対する応答として、与えられた任意の時点に、Zone1、Zone2、または追加ゾーンオーディオストリームのどれかを再生することができる(またはどれも再生しない)。したがって、通信プロトコル140に対して、部屋コードだけで、特定のスレーブデバイスを識別することができ、スレーブデバイスに送信されるゾーン情報は、単に、再生されることが意図されているオーディオストリームをスレーブデバイスに知らせるだけである。
通信プロトコル140は、「プラグ&プレイ」機能を持つ。ネットワークまたは他のスレーブデバイスの電源を切らずに、またマスターデバイス110の電源を切らずに、新しいスレーブデバイスをいつでもネットワークに追加することができる。
1つのスレーブデバイスアドレス(例えば、RoomO)を共有アドレスとして使用し、マスターデバイス110上のZone2可変オーディオ出力に割り当てることができる。このアドレスに設定されたRFリモートコントロールからのVolume Up/Downコマンドが、スレーブデバイスのメッセージを起動し、このZone2可変オーディオ出力に給電する内部音量調節チップを制御する。
３．マスターデバイス回路
３．１ 概要
スタンドアロンコンソール200マスターデバイスの実際の一例が図2に示されている。コンソール200のハードウェアインターフェイスは、制御データバス202、およびオーディオインターフェイス204、および+10VのTurn On信号206を含む。制御データバス202は、コンソール200からネットワーク接続スレーブデバイス208に接続されることを意図されている2線式(DataおよびGND)双方向半二重インターフェイスである。すべてのデータおよび制御メッセージは、このバス200経由で送信される。メッセージ送受信は、19.2kbpsに固定されており、以下に定義されたパケット化およびタイミング規則に従う。
３．１ 概要
スタンドアロンコンソール200マスターデバイスの実際の一例が図2に示されている。コンソール200のハードウェアインターフェイスは、制御データバス202、およびオーディオインターフェイス204、および+10VのTurn On信号206を含む。制御データバス202は、コンソール200からネットワーク接続スレーブデバイス208に接続されることを意図されている2線式(DataおよびGND)双方向半二重インターフェイスである。すべてのデータおよび制御メッセージは、このバス200経由で送信される。メッセージ送受信は、19.2kbpsに固定されており、以下に定義されたパケット化およびタイミング規則に従う。
最大150フィートのネットワーク長(コンソール200からスタブ上の最も遠いスレーブデバイスまで)をサポートすることができ、ケーブル配線は、ディジーチェーンまたはスター型構成(またはそれらの組み合わせ)に従う。電気的には、ネットワーク接続スレーブデバイスは並列に配線される。
Data信号は、1kΩのプルアップ抵抗を通してコンソール側の+5Vに入り、メッセージが送信されていない場合には+5V(通常はHIGHレベル)でアイドル状態となる。ネットワーク接続スレーブデバイスは、オプションにより、ローカルの+5V音源への1MΩのプルアップ抵抗を含み、これにより、コンソールから切断されたときにData信号を知られている状態へバイアスすることができる。いくつかの実際の例では、信号伝達(コンソール200とともにネットワーク接続スレーブデバイスからの)は、Data信号をローカルのGNDに引き込むオープンコレクタトランジスタを通じて実現される。
３．２ 送信機の詳細
本例では、それぞれのスレーブデバイスはバス202とインターフェイスし、+5Vを許容でき、また最悪時のプルアップ抵抗(約650Ω、15個のスレーブデバイスの効果を考慮して)で完全プルダウン(飽和を保証)することができるオープンコレクタトランジスタを通して信号を送る。バス202は家庭内に張り巡らされ、また過去の著しい電気的雑音源となりうるため、フィルタ/保護コンポーネントも用意すべきである(バス上で最大100pF)。バス送信機の出力セクション例が図3に示されている。他の送信機トポロジも可能である。送信機の電気的パラメータは以下のとおりである。
本例では、それぞれのスレーブデバイスはバス202とインターフェイスし、+5Vを許容でき、また最悪時のプルアップ抵抗(約650Ω、15個のスレーブデバイスの効果を考慮して)で完全プルダウン(飽和を保証)することができるオープンコレクタトランジスタを通して信号を送る。バス202は家庭内に張り巡らされ、また過去の著しい電気的雑音源となりうるため、フィルタ/保護コンポーネントも用意すべきである(バス上で最大100pF)。バス送信機の出力セクション例が図3に示されている。他の送信機トポロジも可能である。送信機の電気的パラメータは以下のとおりである。
スピーカケーブルの長さが120フィートだと、ネットワークに約.01μFの余分な容量を負荷としてかけることになる。したがって、図4に示されている波形は、最悪の場合の数のスピーカによりロードされた最大長のネットワークの上へのスレーブデバイスにより駆動されるスタートビットに対する最悪の場合の駆動波形を表す。バス容量によるビットの拡張に注意されたい。ビット立ち下がり時間は、立ち上がり時間よりも約10倍高速であろう。この実施例に対するパラメータを以下に示す。
３．３ 受信機の詳細
バス受信機は、ネットワーク上で立ち下がり遷移を検出し、それらをマイクロプロセッサに中継する。受信機回路は、スレーブデバイスに対しては立ち下がり受信しきい値を約2.6Vに設定し、コンソール200に対しては3Vに設定する。この実施例では、ヒステリシスは与えられない。したがって、いくつかの多重遷移が、ノイジービットのエッジで発生しうる。スレーブデバイスでは、その受信アルゴリズムがそれらの遷移を許容できない場合、ヒステリシスを加えるであろう。例えば、標準的なUART(Universal Asynchronous Receiver/Transmitter)デバイスおよびビットセルの中心付近でビットをサンプリングするその他の方式では、多重遷移を許容する。ネットワークのHIGH/LOW時間を測定するためにエッジトリガ割り込みを使用してデータを復号化する受信方式では、リアーミングの前に割り込みサービスルーチンに十分な遅延が存在していない限り、ヒステリシスを必要とする可能性がある。理想的には、使用する回路に関係なく、ソフトウェアで擬似ヒステリシスを実施するデバウンス方式を実施すべきである。
バス受信機は、ネットワーク上で立ち下がり遷移を検出し、それらをマイクロプロセッサに中継する。受信機回路は、スレーブデバイスに対しては立ち下がり受信しきい値を約2.6Vに設定し、コンソール200に対しては3Vに設定する。この実施例では、ヒステリシスは与えられない。したがって、いくつかの多重遷移が、ノイジービットのエッジで発生しうる。スレーブデバイスでは、その受信アルゴリズムがそれらの遷移を許容できない場合、ヒステリシスを加えるであろう。例えば、標準的なUART(Universal Asynchronous Receiver/Transmitter)デバイスおよびビットセルの中心付近でビットをサンプリングするその他の方式では、多重遷移を許容する。ネットワークのHIGH/LOW時間を測定するためにエッジトリガ割り込みを使用してデータを復号化する受信方式では、リアーミングの前に割り込みサービスルーチンに十分な遅延が存在していない限り、ヒステリシスを必要とする可能性がある。理想的には、使用する回路に関係なく、ソフトウェアで擬似ヒステリシスを実施するデバウンス方式を実施すべきである。
バス受信機は、さらに、ネットワーク過渡電流に耐えなければならない。したがって、受信機回路は、図3に示されているように、送信機出力段の保護ノードからタップオフされる。このトポロジでは、ネットワークスレーブデバイスにより送信されるすべてのデータは、それ自体の受信機内にフィードバックされる。ソフトウェアは、これに耐えられるよう十分に堅牢でなければならない。+5Vおよび+3.3Vバス受信機回路例は、それぞれ、図5Aおよび5Bに示されている。送信機の電気的パラメータは以下のとおりである。
３．４ +10V Turn-On線
コンソール200は、+10V Turn-On信号206を供給する。この信号は、与えられたZone上でアクティブなスレーブデバイスがない場合にLOWレベル(GNDに2.2Kプルダウン)であり、あればHIGHレベル(限流HIGH側PNPスイッチ、負荷に応じて+8.8Vから+10Vを供給)である。最大駆動能力は、+8.8Vで約75mAである。したがって、スレーブデバイスがこの線を他の目的(Energy Starなど)に使用する場合、スレーブデバイス1つ当たり引き込む電流が5mAを超えないよう注意しなければならない(5mA=75mA/スレーブデバイス15個)。このような電流引き込みは、さらに、コンソールのワット損を減らすために、単に一時的なものでなければならない。
コンソール200は、+10V Turn-On信号206を供給する。この信号は、与えられたZone上でアクティブなスレーブデバイスがない場合にLOWレベル(GNDに2.2Kプルダウン)であり、あればHIGHレベル(限流HIGH側PNPスイッチ、負荷に応じて+8.8Vから+10Vを供給)である。最大駆動能力は、+8.8Vで約75mAである。したがって、スレーブデバイスがこの線を他の目的(Energy Starなど)に使用する場合、スレーブデバイス1つ当たり引き込む電流が5mAを超えないよう注意しなければならない(5mA=75mA/スレーブデバイス15個)。このような電流引き込みは、さらに、コンソールのワット損を減らすために、単に一時的なものでなければならない。
３．５ オーディオインターフェイスの詳細
スレーブデバイスインターフェイスは、オーディオインターフェイス204とともに、本明細書で説明されている制御データバス202を含む。ネットワーク接続スレーブデバイスに対するオーディオ信号出力の一種に固定出力がある(例えば、常に、全量が送信される)。音量調節は、スレーブデバイス内で実施される。このため、スレーブデバイスで信号対雑音比が最大になる。可変出力も備えられ、例えば、従来のスレーブデバイスをサポートする。1つまたは複数の信号出力は、アナログ出力、デジタル出力、またはアナログ出力とデジタル出力の組み合わせとすることができる。オーディオ信号の分配は、通信プロトコル140に従ってマスターデバイス110と通信する機能を持つ「スマート」スピーカを含む「スマートスピーカシステム」である、スレーブデバイスのネットワークに関して以下で説明される。
スレーブデバイスインターフェイスは、オーディオインターフェイス204とともに、本明細書で説明されている制御データバス202を含む。ネットワーク接続スレーブデバイスに対するオーディオ信号出力の一種に固定出力がある(例えば、常に、全量が送信される)。音量調節は、スレーブデバイス内で実施される。このため、スレーブデバイスで信号対雑音比が最大になる。可変出力も備えられ、例えば、従来のスレーブデバイスをサポートする。1つまたは複数の信号出力は、アナログ出力、デジタル出力、またはアナログ出力とデジタル出力の組み合わせとすることができる。オーディオ信号の分配は、通信プロトコル140に従ってマスターデバイス110と通信する機能を持つ「スマート」スピーカを含む「スマートスピーカシステム」である、スレーブデバイスのネットワークに関して以下で説明される。
「メインルーム」スマートスピーカシステムでは、コンソール200は、以下で詳しく説明するように、Zone1 Speaker Output mini-DIN、ピン1および2上でS/PDIFベースの差動デジタルオーディオストリームを供給する。このオーディオストリームは、スピーカによる負荷がかかったときに、(非標準)3Vpp出力レベルに対し構成されており、トランスで絶縁され、平衡している。放射を低減するためグラウンドへの390pFのフィルタキャパシタが追加される。
コンソール200は、さまざまなデータ転送速度(フレーム/秒(FPS))で、例えば、48kFPSから最大192kFPSまでの速さでオーディオストリームを生成することができる。コンソール200は、さまざまな圧縮形式のうちのどれか、例えば、PCM、AC-3、DTS、MPEG2、またはAACでデジタルオーディオを生成することができる。圧縮形式は、スピーカにより識別され復号化される。
家中の「非メインルーム」スマートスピーカシステムでは、アナログ出力ステレオのペア(Zone1に対する左/右およびZone2に対する左/右)は、以下で詳述するように、Zone2 Speaker Output mini-DINコネクタ上に備えられる。これらの左/右ペアは両方とも固定出力である。フルスケール(最大)の出力信号は約2Vrmsで、標準的な再生レベルは約300〜400Vrmsとなる。コンソールの内部および外部音源に対する再生レベルは、コンソール内でゲインスケーリングされており、等しい振幅で再生される。
これらの出力は、約50Ωの直列抵抗がそれぞれの出力に追加された、OPアンプにより本質的に駆動される、標準のシングルエンドアナログ出力である。47μFのDC阻止キャパシタが、コンソール内のそれぞれの出力信号に追加され、その後に100K抵抗器がつながりコンソールのアナロググラウンドをそれぞれ基準とする。この出力インピーダンスは、最大15個までのスピーカ(入力段は以下で定義される)を駆動することができ、しかも、低周波応答の不要な減衰または損失が発生しないことが予想される。以下では、適切なゾーン/ゾーン絶縁および雑音遮蔽を保証するためのケーブル配線ガイドラインを示す。
Zone2 Speaker Outputコネクタピン1および2は、さらに、可変入力スピーカ用の左/右可変アナログ信号ペアも備える。これらの信号は、ピン3および4のZone2固定出力と同一であるが、コンソール200の内側のZone2音量調節チップにより減衰することができる。
家中に長いオーディオケーブルを引き回すと、耳に聞こえるほどの雑音を拾いやすいことが判明している。したがって、制御データバス202にインターフェイスするスピーカでは、オーディオ入力段に差動アンプ(「diffアンプ」)を構成すべきである。これらの差動アンプ入力の基準として、専用Audio Referenceがコンソール200から送られ、他のネットワーク導線とともに含まれる。ケーブル配線の詳細を以下で説明する。いくつかの実際の例では、ネットワーク接続スピーカのオーディオインターフェイスの特徴として、以下のものがある。
・ Zone1およびZone2入力diffアンプ回路は、同じでなければならない(同じゲイン、雑音レベル、および帯域幅、スピーカの音質目標に合致している)。
・ Diffアンプは、すべての脚が等しく平衡している状態で使用すべきである。
・ ネットワークからそれぞれの脚を見たときの抵抗は、20KΩ以上でなければならない。これにより、例えば、Diffアンプは10KΩの抵抗器をそれぞれの脚に付けて構成されるようにできる。
・ それぞれの脚はネットワークにキャパシタを介して接続されるべきであり、キャパシタはすべて等しい値を持つ。それぞれのネットワーク接続スレーブデバイスは、所望の周波数応答に基づいてそれ固有のキャパシタ値を持つことができる。
・ 専用Audio Reference信号を、Diffアンプ、Zone1 Left/RightとともにZone2 Left/Rightに対し使用しなければならない。オーディオ電流がこの信号に還流し、Zone1/Zone2絶縁を破壊するのを避けるために、Audio ReferenceをDiffアンプのみのNON-INVERTING脚に対し使用しなければならない。1マイクロアンペアrms以下のオーディオ電流が、Audio Reference信号上に誘起されなければならない。これは92dBの絶縁(許容可能な最低値とみなされる)を維持する。
コンソール200とインターフェイスするように開発されたスマートスピーカは、2つの可能なオーディオストリーム、Zone1ストリームまたはZone2ストリームのうちの1つを選択することができる。選択は、スマートスピーカコマンドを介して制御される。したがって、スマートスピーカは、スマートスピーカメッセージを管理するマイクロプロセッサの制御の下で、そのネットワークオーディオ入力に2入力、ステレオオーディオマルチプレクサ(MUX)を備えるべきである。このMUXをDiffアンプの前に構成する作業は、コスト低減につながるが、パフォーマンスの低下または上記特徴のうちのいくつかを除去することのないように慎重に行わなければならない。
３．６ コンソールスピーカ出力のMini-DINコネクタ
コンソール200は、2つの9ピンSpeaker Output mini-DINコネクタを、Zone1に1つ、Zone2に1つ、備える。図6は、9ピンmini-DINコネクタを見た場合のピン配置例を示している(差し込んだ場合のように)。コネクタは、導電性シェル600を備える。これらのコネクタに対するピン配置を以下に示す。
コンソール200は、2つの9ピンSpeaker Output mini-DINコネクタを、Zone1に1つ、Zone2に1つ、備える。図6は、9ピンmini-DINコネクタを見た場合のピン配置例を示している(差し込んだ場合のように)。コネクタは、導電性シェル600を備える。これらのコネクタに対するピン配置を以下に示す。
ZONE1:
ピン1:メインスピーカ用のS/PDIF0デジタルオーディオ信号(Z1_NET0)。
ピン2:メインスピーカ用のS/PDIF1デジタルオーディオ信号(Z1_NET1)。
ピン3:Zone1固定左アナログオーディオ信号(Z1_LEFT)。可変でない。
ピン4:Zone1固定右アナログオーディオ信号(Z1_RIGHT)。可変でない。
ピン5:GND。
ピン6:Zone1の+10V Turn On信号(Z1_TURNON)。
ピン7:Zone1のSmart Speaker Data(Z1SPKR_DATA)。
ピン8:GND。
ピン9:接続なし。
シェル:GND。
ピン1:メインスピーカ用のS/PDIF0デジタルオーディオ信号(Z1_NET0)。
ピン2:メインスピーカ用のS/PDIF1デジタルオーディオ信号(Z1_NET1)。
ピン3:Zone1固定左アナログオーディオ信号(Z1_LEFT)。可変でない。
ピン4:Zone1固定右アナログオーディオ信号(Z1_RIGHT)。可変でない。
ピン5:GND。
ピン6:Zone1の+10V Turn On信号(Z1_TURNON)。
ピン7:Zone1のSmart Speaker Data(Z1SPKR_DATA)。
ピン8:GND。
ピン9:接続なし。
シェル:GND。
ZONE2:
ピン1:Zone2可変左アナログオーディオ信号(OUTLVAR)。
ピン2:Zone2可変右アナログオーディオ信号(OUTRVAR)。
ピン3:Zone2固定左アナログオーディオ信号(Z2_LEFT)。
ピン4:Zone2固定右アナログオーディオ信号(Z2_RIGHT)。
ピン5:Buffered Zone1固定右アナログオーディオ信号(BZ1_R)。
ピン6:Zone2の+10V Turn On信号(Z2_TURNON)。
ピン7:Zone2のSmart Speaker Data(Z2SPKR_DATA)。
ピン8:GND。
ピン9:Buffered Zone1固定左アナログオーディオ信号(BZ1_L)。
シェル:GND。
ピン1:Zone2可変左アナログオーディオ信号(OUTLVAR)。
ピン2:Zone2可変右アナログオーディオ信号(OUTRVAR)。
ピン3:Zone2固定左アナログオーディオ信号(Z2_LEFT)。
ピン4:Zone2固定右アナログオーディオ信号(Z2_RIGHT)。
ピン5:Buffered Zone1固定右アナログオーディオ信号(BZ1_R)。
ピン6:Zone2の+10V Turn On信号(Z2_TURNON)。
ピン7:Zone2のSmart Speaker Data(Z2SPKR_DATA)。
ピン8:GND。
ピン9:Buffered Zone1固定左アナログオーディオ信号(BZ1_L)。
シェル:GND。
３．７ ネットワーク接続スピーカの入力mini-DINコネクタ
ネットワーク接続スマートスピーカも、同様に、バス202に接続するための9ピンmini-DINコネクタを備える。この一方のコネクタは、Zone1およびZone2のLeft/Rightオーディオとともに、Data線、デジタルグラウンド、およびオーディオDiffアンプの基準電圧として使用する別のグラウンドを取り込む。オプションにより、+10V Turn On信号も取り込める。全部で8本の導線にしかならないが、スピーカは、ケーブルを反転可能にできるように、コンソールのと同じ(ただし、デュアルではなくシングルのみ)9ピンmini-DINを使用するように定義される。
ネットワーク接続スマートスピーカも、同様に、バス202に接続するための9ピンmini-DINコネクタを備える。この一方のコネクタは、Zone1およびZone2のLeft/Rightオーディオとともに、Data線、デジタルグラウンド、およびオーディオDiffアンプの基準電圧として使用する別のグラウンドを取り込む。オプションにより、+10V Turn On信号も取り込める。全部で8本の導線にしかならないが、スピーカは、ケーブルを反転可能にできるように、コンソールのと同じ(ただし、デュアルではなくシングルのみ)9ピンmini-DINを使用するように定義される。
スピーカのmini-DINは、以下のピン配置となっている。
ピン1:未接続(コンソールのZone2可変左アナログオーディオ)。
ピン2:未接続(コンソールのZone2可変右アナログオーディオ)。
ピン3:Zone2固定左アナログオーディオ信号。
ピン4:Zone2固定右アナログオーディオ信号。
ピン5:Zone1固定右アナログオーディオ信号。
ピン6:Zone2の+10V Turn On信号。
ピン7:Zone2のSmart Speaker Data。
ピン8:Audio Reference(diffアンプの専用グラウンド)。スピーカの製品グラウンドに結線されない。
ピン9:Zone1固定左アナログオーディオ信号。
シェル:GND、スピーカのデジタル(製品)グラウンドとして使用される。スピーカ内のピン8 GNDに短絡しない。
ピン1:未接続(コンソールのZone2可変左アナログオーディオ)。
ピン2:未接続(コンソールのZone2可変右アナログオーディオ)。
ピン3:Zone2固定左アナログオーディオ信号。
ピン4:Zone2固定右アナログオーディオ信号。
ピン5:Zone1固定右アナログオーディオ信号。
ピン6:Zone2の+10V Turn On信号。
ピン7:Zone2のSmart Speaker Data。
ピン8:Audio Reference(diffアンプの専用グラウンド)。スピーカの製品グラウンドに結線されない。
ピン9:Zone1固定左アナログオーディオ信号。
シェル:GND、スピーカのデジタル(製品)グラウンドとして使用される。スピーカ内のピン8 GNDに短絡しない。
３．８ ケーブル配線の詳細
いくつかの実際の例では、スマートスピーカをコンソール200のZone2 Speaker Outputに接続するためのケーブルは、図7に示されているような独立のシールドを使用する、ピン3から9までの1:1パススルーを持つ。ピン1および2は、接続されておらず、ケーブルは反転可能である。8線ケーブルを4つのシールド付きツイストペアケーブル(Bose Corporation社の部品番号257187)とともに使用してスピーカをコンソール200に接続する場合、図7に示されているように接続することができる。
いくつかの実際の例では、スマートスピーカをコンソール200のZone2 Speaker Outputに接続するためのケーブルは、図7に示されているような独立のシールドを使用する、ピン3から9までの1:1パススルーを持つ。ピン1および2は、接続されておらず、ケーブルは反転可能である。8線ケーブルを4つのシールド付きツイストペアケーブル(Bose Corporation社の部品番号257187)とともに使用してスピーカをコンソール200に接続する場合、図7に示されているように接続することができる。
いくつかの従来のスピーカ(AM5P/AM2OP、Bose Corporation)では、直接、Zone2 Speakerコネクタにプラグを差し込み、正常に動作させることができ、新しいスピーカ(LSA2、A2、およびBallpark、Bose Corporation)と共存できる。これらは、ピン1&2上でZone2 Variable Left/Right信号を使用するとともに、ピン6上で+10V Turn-On線を使用する。ピン8は、Turn-On線を遮蔽し、スピーカをグラウンドに接続するために使用される。シェル600のグラウンドは、このスピーカ内のAudio Referenceに使用される。これらのケーブルは、内部で、ピン5をシェルグラウンドに短絡し、Zone1 Fixed Right出力を新しいスピーカから使用できなくする-これらのスピーカが新しいスピーカとZone2を共有する必要がある場合に特殊なスプリッタを使用してこれを防止する(コンソールシェルをスプリッタOutputのピン5に接続するが、この出力のシェルは浮動状態にしておく)。
従来のスピーカケーブルがコンソール200のZone2 Speaker Outputに差し込まれた場合、ピン5上のZone1 Fixed Rightオーディオ出力信号はグラウンドに短絡される。Fixed Rightオーディオ出力はバッファリングされるため、新しいスタイルのスピーカをサポートする必要がなければ、この信号をグラウンドに短絡するのが安全である。しかし、新しいスピーカを従来スピーカと併用する場合、特別なスプリッタを使用する必要がある。このスプリッタ内の接続は図8に示されているとおりである(コンソール側がオスであり、Speaker Output側がメスである)。
スプリッタの従来出力は以下の特徴を持つ。
1.ピン5をシェルに短絡する、出力に差し込まれるケーブルは、Z1 Fixed RightをGNDに短絡しない。
2.そのピン8グラウンドは、デジタルGNDに使用できる(Data信号、さらには+10V Turn-Onの場合)。
3.そのシェルグラウンドは、ピン5に短絡され、Left/Rightオーディオ遮蔽に使用することができる。
1.ピン5をシェルに短絡する、出力に差し込まれるケーブルは、Z1 Fixed RightをGNDに短絡しない。
2.そのピン8グラウンドは、デジタルGNDに使用できる(Data信号、さらには+10V Turn-Onの場合)。
3.そのシェルグラウンドは、ピン5に短絡され、Left/Rightオーディオ遮蔽に使用することができる。
スプリッタのNew Speaker出力は、コンソールmini-DINからのピン3から9(およびシェル)のフルパススルーである。新しいスピーカは、決して、ピン1〜2のVariableオーディオ信号を使用せず、実際には、ピン1〜2をアクセサリ(例えば、ボールパークペデスタル)用のオーディオ出力として使用することができ、したがって、これらはスプリッタ内に含まれない。
４．通信プロトコルの詳細
通信プロトコル140は、コンソール200と1組のネットワーク接続スピーカとの間で1線(グラウンドを含めて2線)、双方向、半二重、信号伝達方式を使用する。
通信プロトコル140は、コンソール200と1組のネットワーク接続スピーカとの間で1線(グラウンドを含めて2線)、双方向、半二重、信号伝達方式を使用する。
すべての通信は、コンソール20の背後にあるSpeaker Output mini-DINコネクタから引き回されるケーブル上のSpeaker Data線を介してネットワーク接続スピーカに送られる。この信号のアイドル状態は、コンソール内の1KΩ抵抗器を介してプルアップされた、論理HIGHレベル(+5V)である。送信は、コンソール200およびスピーカ内の直接キーイングオープンコレクタトランジスタ段により行われる。
プロトコル140では、19.2Kbpsビットレート、1スタートビット、1ストップビット、およびパリティビットなしの設定を使用する。メッセージバイトを以下で定義する。以下の例では、すべてのメッセージバイトは、LSB(最下位ビット)を先に送信する。
４．１ 許容可能な論理レベル
信号伝達の論理レベルは以下のとおりである(バス202のSpeaker Data線に示されているとおり)。
信号伝達の論理レベルは以下のとおりである(バス202のSpeaker Data線に示されているとおり)。
４．２ ビット幅
すべてのネットワーク接続デバイスで使用する19.2kbpsのデータ転送速度は公称転送速度の0.5%内となるように保証される。これにより、必ず、各バイトのストップビットまでのエッジ精度は±5%となる(送信機と受信機の両方について最悪の場合のタイミング誤差を想定すると、±10%)。したがって、ビット幅は以下のように定義される。
すべてのネットワーク接続デバイスで使用する19.2kbpsのデータ転送速度は公称転送速度の0.5%内となるように保証される。これにより、必ず、各バイトのストップビットまでのエッジ精度は±5%となる(送信機と受信機の両方について最悪の場合のタイミング誤差を想定すると、±10%)。したがって、ビット幅は以下のように定義される。
これらの許容範囲は、バス送信機により生成されるとおりビット幅に適用される。実際の受信ビット幅は、最悪の場合のネットワーク上では歪むことがある。
４．３ メッセージタイミング
スピーカの同期をとるために、メッセージがパケット化され(バイト間の遅延なしで、1つの連続バーストとして送信される)、メッセージ間タイミングは以下のように制御される。
スピーカの同期をとるために、メッセージがパケット化され(バイト間の遅延なしで、1つの連続バーストとして送信される)、メッセージ間タイミングは以下のように制御される。
ネットワークから見た場合の共通4バイトコマンドおよび応答のメッセージ例が図9に示されている(バス202はHIGHレベルでアイドル状態)。
４．４ メッセージ同期
上の表に示されているように、コンソール200では、ネットワークが、新しい伝送を開始するまでに少なくとも1.066m秒の間アイドル状態になっていることを確実にする。この遅延は、意図的に、コンソールメッセージとスピーカ応答との間の許容可能な遅延よりも長くとってあり、ネットワーク上のデバイスは単純なタイムアウトを使用して、必要な場合に(理想的には、進行中に)コンソールとの再同期をとることができる。スピーカがコンソールとの再同期に使用する推奨タイムアウトは、916μ秒(916μ秒=767μ秒+(1.066m秒-767μ秒)/2.)である。スピーカ側で、ネットワークが916μ秒の間アイドル状態にあったと識別した場合、そのスピーカは、受信ルーチンをリアーミングすることができ、次のコンソールメッセージをその先頭から適切に捕捉する。
上の表に示されているように、コンソール200では、ネットワークが、新しい伝送を開始するまでに少なくとも1.066m秒の間アイドル状態になっていることを確実にする。この遅延は、意図的に、コンソールメッセージとスピーカ応答との間の許容可能な遅延よりも長くとってあり、ネットワーク上のデバイスは単純なタイムアウトを使用して、必要な場合に(理想的には、進行中に)コンソールとの再同期をとることができる。スピーカがコンソールとの再同期に使用する推奨タイムアウトは、916μ秒(916μ秒=767μ秒+(1.066m秒-767μ秒)/2.)である。スピーカ側で、ネットワークが916μ秒の間アイドル状態にあったと識別した場合、そのスピーカは、受信ルーチンをリアーミングすることができ、次のコンソールメッセージをその先頭から適切に捕捉する。
スピーカでは、安全に469μ秒を超える最初のネットワークアイドル時間の間待つことにより受信コンソールメッセージの終わりを識別することができる(メッセージ本文内の1の可能な最長な列)。推奨タイムアウトは、約521μ秒である。これにより、スピーカ側には246μ秒の猶予が与えられ、受信メッセージを調べ、767μ秒よりも前にそのACK/応答を開始する。
これらのメッセージタイミングを守った場合、同期喪失は発生しないであろう(ネットワークデバイスは、メッセージの開始と終わりがどこにあるかの追跡を不適切な形で失うことは決してない)。しかしながら、メッセージアドレスおよびベリファイヤバイトを調べて、受信したすべてのメッセージが有効であることを確認すべきである。さらに、メッセージの終わりを識別するのに十分に長いネットワークアイドル時間が検出された場合、4バイト長よりも短い部分受信メッセージを削除し、再同期をとらなければならない。
４．５ ソフトウェアドライバ
４．５．１ 低レベル受信機
標準ハードウェアUART受信機は、雑音およびジッタ/スルー歪みの防止機能を備える。ハードウェアUARTが利用できない場合にソフトウェアでこの機能を近似するために、ビットバングド受信ルーチンが以下のように機能する。
４．５．１ 低レベル受信機
標準ハードウェアUART受信機は、雑音およびジッタ/スルー歪みの防止機能を備える。ハードウェアUARTが利用できない場合にソフトウェアでこの機能を近似するために、ビットバングド受信ルーチンが以下のように機能する。
1.同期が確認され、受信メッセージが予期できるようになった後、データ入力をエッジトリガ割り込みでアーミングされなければならない。
2.メッセージ第1のエッジが検出されると(第1のバイトの第1のスタートビット)、即座にさらに1〜2回リサンプリングを行って雑音を除去することによりデバウンスしなければならない(雑音は、通常のネットワークではきわめてまれなことであろうが)。有効であると分かった場合、自動リロードされる52.083μ秒タイムアウトにより駆動される状態マシンを実行し、できる限りビットセルの中心近くで次の10ビットをサンプリングしなければならない。
3.この状態マシンの第1の8段で、メッセージビットを収集する。8つのメッセージビットのそれぞれを、ビットセルの中心で1〜3回素早くサンプリングし、適切な値を格納しておく必要がある。
4.9番目のビット(ストップビット)に対するタイマー割り込みルーチンで、バスがアイドル(HIGHレベル)状態にあることを確認し、次のバイトのスタートビットに対しエッジトリガ割り込みをリアーミングしなければならない。
5.新しいバイトのスタートビットエッジが10番目の52.083μ秒の割り込みの前に検出された場合、10番目のタイマー割り込みをキャンセルして、前のように新しい着信バイトを組み立てる(このエッジを使用して、10ビットサンプリングエンジンのタイミングの再同期をとる)。しかし、10番目の52.083μ秒の割り込みが最初にタイムアウトになると、メッセージは終了する。それに応じて処理を進める。スレーブは、即座に、その応答の生成を開始することができる。
４．５．２ マスターデバイスの送信/受信タイミング
いくつかの実際の例では、コンソール200は、ハードウェアUARTをスマートスピーカインターフェイスに割り当てている。以下の方式では、このUARTを管理することに関連する割り込みが最小限で済む。
いくつかの実際の例では、コンソール200は、ハードウェアUARTをスマートスピーカインターフェイスに割り当てている。以下の方式では、このUARTを管理することに関連する割り込みが最小限で済む。
1.完了時にシステムに割り込みがかかるようにUARTを設定し、送信メッセージを一度に丸ごと(Nバイト)送信する。CS98200内の16バイトの最大UARTバッファよりも長いメッセージについては(まれ)、割り込みを使用して、可能な限り最大のブロック単位(最大16バイトまで)でメッセージをバラバラにして送信する。これは、バイト間に目立った遅延が入り込まないようにして実行すべきである。
2.送信メッセージが終了したら、UART受信機を有効にし、1受信バイトの後に割り込みがかかるように設定する(最初の割り込みは、1.288m秒以内に発生すべきであるが、ただし、1.288m秒=767μ秒のReply Delay+520.83μ秒の第1のバイト長)。さらに、約1.34m秒以内にタイムアウトになるようにタイマー割り込みをアーミングする。
3.最初の完全なバイトがスレーブから受信される前に1.34m秒のタイマー割り込みがタイムアウトした場合、スレーブはアクティブでないと想定して、次のスレーブのポーリングに進む。
4.そうでない場合(スレーブが応答中の場合)、引き続き、受信バイト毎に割り込みをかける。その後のバイトは、520.83m秒毎に受信されなければならない。しかし、1.066m秒のSynchronization Delayがコンソールメッセージの前に使用されるため、1.066m秒タイムアウト(受信バイト毎にリセットされる)を使用して、スレーブメッセージの終わりを検出しなければならない。
図10は、スピーカからの応答がある場合と、スピーカからの応答がない場合のメッセージシーケンスを示している。
５．０ メッセージパケットの概要
メッセージパケットは、バスマスター(例えば、コンソール)またはスレーブ(例えば、スピーカ)により送信されたバイトの集合として定義される。メッセージパケットのすべてのビットは、バイトとバイトの間に割り込みまたは遅延を発生することなく、1つの連続バーストとして設定される。さまざまな長さのメッセージがサポートされている。いくつかの実装では、後述のHeader/Address/Argument/Verifier形式を使用する。
メッセージパケットは、バスマスター(例えば、コンソール)またはスレーブ(例えば、スピーカ)により送信されたバイトの集合として定義される。メッセージパケットのすべてのビットは、バイトとバイトの間に割り込みまたは遅延を発生することなく、1つの連続バーストとして設定される。さまざまな長さのメッセージがサポートされている。いくつかの実装では、後述のHeader/Address/Argument/Verifier形式を使用する。
５．１ Headerバイト(第1メッセージバイト)
バス202上のメッセージは、コンソール/マスターからであろうとスピーカ/スレーブからであろうと、1バイトのHeaderから始まる(これは、送信される第1のバイトである)。このHeaderのビット7は、予約されており、メッセージがコンソール200により送信されるのか、またはスピーカにより送信されるのかを示す。ビット7は、コンソールメッセージについては0に設定され、スピーカメッセージについては1に設定される。
バス202上のメッセージは、コンソール/マスターからであろうとスピーカ/スレーブからであろうと、1バイトのHeaderから始まる(これは、送信される第1のバイトである)。このHeaderのビット7は、予約されており、メッセージがコンソール200により送信されるのか、またはスピーカにより送信されるのかを示す。ビット7は、コンソールメッセージについては0に設定され、スピーカメッセージについては1に設定される。
スタートビットとストップビットを含む完全なHeaderバイトの図が、図11に示されている。
H7..H0(ビット7..0):8ビットのHeader識別子(後述のヘッダ定義を参照)。したがって、256個の別々のコマンドが可能である(コンソールからスピーカまで128、スピーカから戻ってコンソールまで128であるが、それはビット7で送信者を識別するからである)。
DIR(ビット7):1ビットのMessage Direction Indicator(0=コンソール/マスターから送信、1=スピーカ/スレーブから送信)。
５．２ Console Message Address Byte(第2メッセージバイト)
スマートスピーカメッセージについては、第2バイトはメッセージのアドレス指定を含む。Addressバイトの図が図12に示されている。
スマートスピーカメッセージについては、第2バイトはメッセージのアドレス指定を含む。Addressバイトの図が図12に示されている。
R3..R0(ビット3..0):Room Number(0000〜1111b)。15個の一意的部屋が使用可能である(A〜Oで参照される)。0000b=RoomA。0001〜1110b=RoomB〜RoomO。1111b=ALL ROOMS、これはブロードキャストに使用される。
Z3..Z0(ビット7..4):Zone Number(0000〜1111b)。15個の一意的なゾーンが使用可能である。それぞれのゾーンは、所望のオーディオストリームを識別するために使用できる。
0000b=Zone1。0001〜1110b=Zone2〜Zone15。1111b=ALL ZONES、これは、コンソールメッセージによりスピーカがその入力ストリーム/ゾーン選択を変更すべきでない場合に使用される。
アドレスバイトの例(スタート/ストップビットを無視する)は、Zone1、RoomA:00000000b。Zone2、RoomI:00011001b。
Addressバイトに含まれるゾーン情報は、例えば、RFリモートコントロールから、コンソール200に通され、スピーカによって選択されたオーディオストリームを識別する。有効なオプションの例は、Zone1(0000b)、Zone2(0001b)、およびALL Zones(1111b)である。他のオプションも可能である。例えば、いくつかのオプションでは、それ独自の(独立の)オーディオストリームが用意されるそれぞれの部屋をサポートする。
５．３ Speaker Message Addressバイト(第2メッセージバイト)
スピーカAddressバイトを使用することで、スピーカ応答で、スピーカがOFFであるか、またはLocal音源(その可能なもののうちの1つ)の受信を待っているか、またはコンソール200から送信されたストリームのうちの1つ(Zone1またはZone2)の受信を待っているかを示すことができる。このバイトの形式は、図13に示されている。
スピーカAddressバイトを使用することで、スピーカ応答で、スピーカがOFFであるか、またはLocal音源(その可能なもののうちの1つ)の受信を待っているか、またはコンソール200から送信されたストリームのうちの1つ(Zone1またはZone2)の受信を待っているかを示すことができる。このバイトの形式は、図13に示されている。
R3..R0(ビット3..0):コンソール200について定義されているのと同じ:15個の使用可能な部屋のうちの1つを示すが、1111bはスピーカについては未定義である(スピーカはブロードキャストに応答しないからである)。
Z3..Z0(ビット7..4):0000〜1101b:14個の可能なZonesのうちの1つを再生する(0010b=Zone1、0011b=Zone2など)。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
５．４ Argumentバイト
Addressバイトの後、メッセージを終了するVerifierバイトの前のところに、メッセージArgumentバイトが含まれる。ポーリングには、引数バイトが含まれない。いくつかのスマートスピーカメッセージは、Argumentバイトを1つしか含まないが、スピーカメッセージは、Argumentバイトをいくつでも含むことができる。さまざまなコマンドの中で使用されるArgumentバイトのメッセージ定義および詳細について以下で説明する。それぞれのArgumentバイトは、図14に示されている形式で送信される。
Addressバイトの後、メッセージを終了するVerifierバイトの前のところに、メッセージArgumentバイトが含まれる。ポーリングには、引数バイトが含まれない。いくつかのスマートスピーカメッセージは、Argumentバイトを1つしか含まないが、スピーカメッセージは、Argumentバイトをいくつでも含むことができる。さまざまなコマンドの中で使用されるArgumentバイトのメッセージ定義および詳細について以下で説明する。それぞれのArgumentバイトは、図14に示されている形式で送信される。
A7..A0(ビット7..0):8ビットメッセージ引数。
５．５ Verifierバイト(最後のメッセージバイト)
スマートスピーカメッセージの最終バイトは、Verifierバイトである。このバイトは、基本メッセージ情報が破損していないことを確認するために使用される。以下のメッセージ定義に示されているように、このバイトは、一般に、先行するすべてのメッセージバイトのソフトウェア排他OR(XOR)であるが、長いメッセージ形式では、これを使用して、Header/Addressのみを検証し、ローカルチェックサムなどをArgumentフィールド内に含めて、その大量のデータペイロードをより厳格に検証したい場合もある。このVerifierバイトの形式は、図15に示されている。
スマートスピーカメッセージの最終バイトは、Verifierバイトである。このバイトは、基本メッセージ情報が破損していないことを確認するために使用される。以下のメッセージ定義に示されているように、このバイトは、一般に、先行するすべてのメッセージバイトのソフトウェア排他OR(XOR)であるが、長いメッセージ形式では、これを使用して、Header/Addressのみを検証し、ローカルチェックサムなどをArgumentフィールド内に含めて、その大量のデータペイロードをより厳格に検証したい場合もある。このVerifierバイトの形式は、図15に示されている。
V7..V0(ビット7..0):一般に、先行するすべてのメッセージバイトのXOR。
６．０ 交換のルール
「交換」は、コンソール200から特定のスピーカへのメッセージとその返信としてそのスピーカから送信される後続の応答の2つのバスメッセージの集まりとして定義される。このような交換を左右するルール群を以下に示す。
「交換」は、コンソール200から特定のスピーカへのメッセージとその返信としてそのスピーカから送信される後続の応答の2つのバスメッセージの集まりとして定義される。このような交換を左右するルール群を以下に示す。
６．１ マスターのみが自発的メッセージを生成する
コンソール200は、スマートスピーカバス202上のすべての通信のマスターである。例えば、コンソール200のみが、バス202上の自発的伝送を発生する。
コンソール200は、スマートスピーカバス202上のすべての通信のマスターである。例えば、コンソール200のみが、バス202上の自発的伝送を発生する。
６．２ マスターは、進行中の交換に割り込みをかけない
コンソール/マスターによるメッセージ保留の重要度に関係なく、外へ向かう伝送は、新しい伝送を開始する前にすでに開始している交換サイクルが完了するまで待つ。コンソール200またはスピーカからの進行中のメッセージは割り込みされない。
コンソール/マスターによるメッセージ保留の重要度に関係なく、外へ向かう伝送は、新しい伝送を開始する前にすでに開始している交換サイクルが完了するまで待つ。コンソール200またはスピーカからの進行中のメッセージは割り込みされない。
６．３ スレーブはそれにアドレス指定されたメッセージの直後にしか送信しない
スレーブ/スピーカは、それに対し特にアドレス指定されたコンソールメッセージの直後にしか送信できない(例えば、コンソールブロードキャストの後に送信するスレーブはない)。このルールは、スピーカメッセージの保留がどれだけ重要であろうと、適用される。スピーカが上流で通信を送り返せるタイミングのよい機会を十分保証できるように頻繁に、メッセージ(例えば、ポーリング)をそれぞれのスピーカに送信するのはコンソールの役目である。
スレーブ/スピーカは、それに対し特にアドレス指定されたコンソールメッセージの直後にしか送信できない(例えば、コンソールブロードキャストの後に送信するスレーブはない)。このルールは、スピーカメッセージの保留がどれだけ重要であろうと、適用される。スピーカが上流で通信を送り返せるタイミングのよい機会を十分保証できるように頻繁に、メッセージ(例えば、ポーリング)をそれぞれのスピーカに送信するのはコンソールの役目である。
６．４ スレーブはそれにアドレス指定されたメッセージに応答する
スピーカがOFFでない限り(応答がオプションの場合)、スレーブ/スピーカは、何らかの形の返信メッセージでそれにアドレス指定されたコンソールメッセージに応答する(既定の応答は、目下のところスレーブに通信すべき重要なものが何もない状況ではPoll_Replyである)。応答は、許容可能な遅延期間(例えば、767μ秒)以内に生成される。
スピーカがOFFでない限り(応答がオプションの場合)、スレーブ/スピーカは、何らかの形の返信メッセージでそれにアドレス指定されたコンソールメッセージに応答する(既定の応答は、目下のところスレーブに通信すべき重要なものが何もない状況ではPoll_Replyである)。応答は、許容可能な遅延期間(例えば、767μ秒)以内に生成される。
スピーカは、以下のメッセージタイプのうちのどれか1つでコンソールメッセージに応答することができる。
・ Poll_Replyメッセージ(4バイト)。これは、既定のスピーカ応答であり、さらに高い優先度の応答が送信できる(クエリ応答を含めて)のではない限りすべてのポーリング、コマンド、およびクエリの後に使用される。
・ PASS_KEY_CODEメッセージ(メッセージ定義を参照)。
・ DOWNLOAD_INFORMATIONメッセージ(メッセージ定義を参照)。
６．５ スレーブは現在保留中の最高優先度の情報で応答する
スピーカ/スレーブでは、コンソール200に送り返す機会が到来したときに複数のメッセージが保留になっている可能性がある。このような状況では、最高優先度のメッセージが送信されなければならない。可能なメッセージタイプの一般的ガイドラインは以下のとおりである。
スピーカ/スレーブでは、コンソール200に送り返す機会が到来したときに複数のメッセージが保留になっている可能性がある。このような状況では、最高優先度のメッセージが送信されなければならない。可能なメッセージタイプの一般的ガイドラインは以下のとおりである。
６．５．１ 最高優先度:非ポーリングクエリ応答
コンソール200が特定のクエリメッセージ(「poll」以外-メッセージ定義を参照)をスピーカに送信した場合、スピーカはできる限り速やかに適切な応答を送信する。クエリ応答が組み立てられるまで低優先度の応答を送信できるが、いったん組み立てられると、送信キュー内で最高優先度を割り当てられる。
コンソール200が特定のクエリメッセージ(「poll」以外-メッセージ定義を参照)をスピーカに送信した場合、スピーカはできる限り速やかに適切な応答を送信する。クエリ応答が組み立てられるまで低優先度の応答を送信できるが、いったん組み立てられると、送信キュー内で最高優先度を割り当てられる。
６．５．２ 中優先度:Pass_Key_Codeメッセージ
スピーカ/スレーブ製品(またはそのローカルリモートコントロール)上でいくつかのボタンが押されると、コンソール音源などに対する緊急の変更が必要になることがある。Pass_Key_Codeメッセージは、該当する押下をコンソール200に伝達するために以下で定義される。これらのメッセージは、スレーブの送信キュー内で中優先度を与えられなければならない(クエリ応答がキュー内で使用できる場合には保留にしなければならないが、ポーリング応答に優先する)。
スピーカ/スレーブ製品(またはそのローカルリモートコントロール)上でいくつかのボタンが押されると、コンソール音源などに対する緊急の変更が必要になることがある。Pass_Key_Codeメッセージは、該当する押下をコンソール200に伝達するために以下で定義される。これらのメッセージは、スレーブの送信キュー内で中優先度を与えられなければならない(クエリ応答がキュー内で使用できる場合には保留にしなければならないが、ポーリング応答に優先する)。
６．５．３ 中優先度:Download_Informationメッセージ
Download_Informationメッセージは、スピーカ/スレーブがデータのブロックをコンソール200に伝達できるように以下で定義される。このデータは、通常、スレーブ(例えば、現在のAM/FM局)上で再生されるローカル音源に関係する情報を表すことが期待される。このようなメッセージは、中優先度を与えられ、これはPass_Key_Codeメッセージと同じである。これらは、したがって、Pass_Key_CodeメッセージとともにFIFO内にバッファリングされなければならず、ポーリング応答に優先するが、他のすべての特定のクエリ応答がキュー内にある場合には保留になる。
Download_Informationメッセージは、スピーカ/スレーブがデータのブロックをコンソール200に伝達できるように以下で定義される。このデータは、通常、スレーブ(例えば、現在のAM/FM局)上で再生されるローカル音源に関係する情報を表すことが期待される。このようなメッセージは、中優先度を与えられ、これはPass_Key_Codeメッセージと同じである。これらは、したがって、Pass_Key_CodeメッセージとともにFIFO内にバッファリングされなければならず、ポーリング応答に優先するが、他のすべての特定のクエリ応答がキュー内にある場合には保留になる。
６．５．４ 最低優先度:ポーリング応答
他のスピーカメッセージが送信Smart Speakerキュー内にない場合に、Poll_Reply(メッセージ定義を参照)と呼ばれる既定の応答が送信されなければならない。この応答は、応答の他のクラスよりも重要度が低いとみなされる、スピーカのオン/オフ状態およびその音量レベルに関する基本情報のみを含む。
他のスピーカメッセージが送信Smart Speakerキュー内にない場合に、Poll_Reply(メッセージ定義を参照)と呼ばれる既定の応答が送信されなければならない。この応答は、応答の他のクラスよりも重要度が低いとみなされる、スピーカのオン/オフ状態およびその音量レベルに関する基本情報のみを含む。
６．６ マスターはすべてのスピーカを連続的にポーリングするが、低優先度としてである
スピーカが上流方向に情報をコンソール200へタイミングよく送信できるようにするため、ポーリングメッセージが送信され、これは、スピーカステータスの変更に気づく機会として利用される。コンソールメッセージの場合と同様、スピーカは、オプションにより、上述のメッセージタイプのどれかでのポーリングに応答することができる。コンソールのポーリングサイクルのタイミングに関する詳細を以下で説明する。一般的には、これらのポーリングは連続的に送信されるが、コンソールの送信キュー内に利用可能な高い優先度のメッセージが入っていない場合のみである。
スピーカが上流方向に情報をコンソール200へタイミングよく送信できるようにするため、ポーリングメッセージが送信され、これは、スピーカステータスの変更に気づく機会として利用される。コンソールメッセージの場合と同様、スピーカは、オプションにより、上述のメッセージタイプのどれかでのポーリングに応答することができる。コンソールのポーリングサイクルのタイミングに関する詳細を以下で説明する。一般的には、これらのポーリングは連続的に送信されるが、コンソールの送信キュー内に利用可能な高い優先度のメッセージが入っていない場合のみである。
６．７ マスターは現在保留中の最高優先度メッセージを送信する
スレーブの場合と同様に、コンソール/マスター送信メッセージは優先度を割り当てられる。優先度の高いメッセージは、以下のように低い優先度のメッセージよりも優先される。
スレーブの場合と同様に、コンソール/マスター送信メッセージは優先度を割り当てられる。優先度の高いメッセージは、以下のように低い優先度のメッセージよりも優先される。
６．７．１ 最高優先度:非ポーリングクエリおよび制御メッセージ
クエリまたは制御メッセージが特定のスピーカに送信される必要がある場合、最高優先度を与えられる。メッセージ定義を参照。
クエリまたは制御メッセージが特定のスピーカに送信される必要がある場合、最高優先度を与えられる。メッセージ定義を参照。
６．７．２ 中優先度:Pass_Key_Codeメッセージ
コンソール200は、コンソールによって使用されていないRFコマンドをスピーカに直接通すことができる。以下で定義される、Pass_Key_Codeはこのために使用される。このようなメッセージは、クエリよりも低い優先度を持つが、ポーリングには優先度が高い。Pass_Key_Codeメッセージが保留になっている場合、ポーリングサイクルは割り込みがかかり、(進行中の交換が完了した後)、Pass_Key_Codeメッセージが送信され、その後ポーリングは再開できる。
コンソール200は、コンソールによって使用されていないRFコマンドをスピーカに直接通すことができる。以下で定義される、Pass_Key_Codeはこのために使用される。このようなメッセージは、クエリよりも低い優先度を持つが、ポーリングには優先度が高い。Pass_Key_Codeメッセージが保留になっている場合、ポーリングサイクルは割り込みがかかり、(進行中の交換が完了した後)、Pass_Key_Codeメッセージが送信され、その後ポーリングは再開できる。
６．７．３ 中優先度:Download_Informationメッセージ
コンソール200はDownload_Informationメッセージ(メッセージ定義を参照)を使用して、データの大きなブロックをスピーカにダウンロードすることができる。これは、スピーカアプリケーションコードなどを更新する場合に使用することができる。これらのメッセージに対する優先度は、クエリよりも低いが、ポーリングよりも高い。Pass_Key_Codeメッセージの場合と同様、ポーリングサイクルは一時的に割り込みがかけられ、保留中のDownload_Informationメッセージを送信する。
コンソール200はDownload_Informationメッセージ(メッセージ定義を参照)を使用して、データの大きなブロックをスピーカにダウンロードすることができる。これは、スピーカアプリケーションコードなどを更新する場合に使用することができる。これらのメッセージに対する優先度は、クエリよりも低いが、ポーリングよりも高い。Pass_Key_Codeメッセージの場合と同様、ポーリングサイクルは一時的に割り込みがかけられ、保留中のDownload_Informationメッセージを送信する。
６．７．４ 最低優先度:ポーリング
スピーカポーリングは、最低優先度を割り当てられ、コンソール200が送信すべき重要性の高い情報がない間に送信されるメッセージの連続サイクルを表すべきである。これらのポーリングを送信することにより、それぞれのスピーカは、上流に向かってメッセージをコンソール200に送信する定期的機会がそれぞれのスピーカに対し保証される。
スピーカポーリングは、最低優先度を割り当てられ、コンソール200が送信すべき重要性の高い情報がない間に送信されるメッセージの連続サイクルを表すべきである。これらのポーリングを送信することにより、それぞれのスピーカは、上流に向かってメッセージをコンソール200に送信する定期的機会がそれぞれのスピーカに対し保証される。
６．８ クエリ交換時に1つのスピーカのみがポーリングされる
コンソール200とスピーカとの間の完全なクエリ交換は以下のようにして実行される。
コンソール200とスピーカとの間の完全なクエリ交換は以下のようにして実行される。
1.クエリを送信する必要がある場合、コンソール200は、通常のポーリングサイクルに割り込みをかけ(進行中の交換が完了した後)、所望のクエリを適切なスピーカに即座に送信する。
2.スピーカは、可能ならば、767μ秒以内にその応答を送信する。可能でなければ、767μ秒以内にPOLL_RESPONSEメッセージで応答する。
3.コンソール200は、他のすべてのスピーカをポーリングすることを差し控え、その代わりに、このスピーカのみを6m秒おきにポーリングする。スピーカは、クエリ応答の用意が整うまでPOLL_RESPONSEメッセージで応答する。用意ができたら、所望のクエリ応答で応答する。
4.所望のクエリ応答を受信した後、コンソール200は、すべてのスピーカに対する通常のポーリングサイクルを再開する。代替えとして、スピーカが全く応答できない場合、またはOFFとして応答する場合、通常ポーリングは、高水準のソフトウェアの裁量により再開することもできる。
６．８ メインルームの外で使用されるコマンドの全リスト
「メインルーム」内のスピーカは、後述のメッセージ定義を使用する。メインルームの外のスピーカは、例えば、音量大/小、ミュート/ミュート解除、およびオン/オフといった限られた制御メッセージのみを使用できる。他のすべての特定のコントロールは、リモートコントロールコマンドを透過的にコンソールからスピーカに(Pass_Key_Codeコマンドを使用して)受け渡すことにより処理することができるが、ただし、それらが正常に解釈される場合に限る。
「メインルーム」内のスピーカは、後述のメッセージ定義を使用する。メインルームの外のスピーカは、例えば、音量大/小、ミュート/ミュート解除、およびオン/オフといった限られた制御メッセージのみを使用できる。他のすべての特定のコントロールは、リモートコントロールコマンドを透過的にコンソールからスピーカに(Pass_Key_Codeコマンドを使用して)受け渡すことにより処理することができるが、ただし、それらが正常に解釈される場合に限る。
以下に、非メインルームスピーカにより受信できるコマンドのリストを示す。メッセージの構成の詳細については、以下のメッセージ定義を参照されたい。
６．８．１ POLLおよびPOLL REPLYメッセージ(ヘッダ0x00/0x80)
ポーリングは、最低優先度メッセージであり、ポーリングサイクルによる決定に従いコンソール200によりすべてのスピーカに連続的に送信される。すべてのスピーカのON/OFF、Local/Network、および音量/ミュートステータスを監視するほかに、スピーカからコンソール200にメッセージを頻繁に送信する機会を与えるため、コンソール200により使用される。高い優先度のメッセージを送信する必要がある場合に割り込みが発生する。スピーカは、通常、Poll Replyで応答するが、保留中のものがあればより高い優先度の応答を置き換える。
ポーリングは、最低優先度メッセージであり、ポーリングサイクルによる決定に従いコンソール200によりすべてのスピーカに連続的に送信される。すべてのスピーカのON/OFF、Local/Network、および音量/ミュートステータスを監視するほかに、スピーカからコンソール200にメッセージを頻繁に送信する機会を与えるため、コンソール200により使用される。高い優先度のメッセージを送信する必要がある場合に割り込みが発生する。スピーカは、通常、Poll Replyで応答するが、保留中のものがあればより高い優先度の応答を置き換える。
６．８．２ ON/OFFメッセージ(ヘッダ0x01)
このメッセージは、スピーカをONまたはOFFにするためにコンソール200により使用することができる。スピーカは、さらに、いくつもの異なるパススルーされたRFリモートボタンを受け取った後、またはローカルのIRリモートからコマンドを受け取った後にオンになりうる。これらの場合、ポーリングは、電源オンを検出するために使用される。
このメッセージは、スピーカをONまたはOFFにするためにコンソール200により使用することができる。スピーカは、さらに、いくつもの異なるパススルーされたRFリモートボタンを受け取った後、またはローカルのIRリモートからコマンドを受け取った後にオンになりうる。これらの場合、ポーリングは、電源オンを検出するために使用される。
６．８．３ PASS_KEY_CODEメッセージ(ヘッダ0x0D/0x8D)
このメッセージは、スピーカ特有のRFリモートコントロールコマンドを通すためにコンソール200により(ヘッダ0x0Dを使用して)使用されることができる。コンソール200は、これらのコマンドを全く解釈しえない。ヘッダ0x8Dを使用することで、スピーカは、ボタン押下を上流に向かってコンソール200に送り返すことができる。
このメッセージは、スピーカ特有のRFリモートコントロールコマンドを通すためにコンソール200により(ヘッダ0x0Dを使用して)使用されることができる。コンソール200は、これらのコマンドを全く解釈しえない。ヘッダ0x8Dを使用することで、スピーカは、ボタン押下を上流に向かってコンソール200に送り返すことができる。
６．８．４ SET_MAIN_ATTENUATIONメッセージ(ヘッダ0x02)
コンソール200は、Mute Allイベントに対する応答として、MuteおよびReturn_to_Last_Volume引数をブロードキャストとして使用できる。
コンソール200は、Mute Allイベントに対する応答として、MuteおよびReturn_to_Last_Volume引数をブロードキャストとして使用できる。
６．８．５ QUERY_SPEAKER_INFOメッセージ(ヘッダ0x0B)
このメッセージは、取り付けられているさまざまなスピーカを判別するためにコンソール200により使用される。コンソール200は、さらに、Query_Main_AttenuationおよびQuery_Download_Info_Status引数を使用することもできる。
このメッセージは、取り付けられているさまざまなスピーカを判別するためにコンソール200により使用される。コンソール200は、さらに、Query_Main_AttenuationおよびQuery_Download_Info_Status引数を使用することもできる。
６．８．６ DOWNLOAD_INFORMATIONメッセージ(ヘッダ0x0A/0x8A)
このメッセージ(ヘッダ0x0A)は、コンソール200ステータス情報をスピーカにプッシュする場合に使用するか、または他のデータブロックをスピーカに送信する場合に使用することができる(場合によっては、アプリケーションコードの更新など)。ヘッダ0x8Aを使用することにより、スピーカはこのメッセージタイプを利用して、データのブロックをコンソールにアップロードすることができる(例えば、表示する音源関連データ)。
このメッセージ(ヘッダ0x0A)は、コンソール200ステータス情報をスピーカにプッシュする場合に使用するか、または他のデータブロックをスピーカに送信する場合に使用することができる(場合によっては、アプリケーションコードの更新など)。ヘッダ0x8Aを使用することにより、スピーカはこのメッセージタイプを利用して、データのブロックをコンソールにアップロードすることができる(例えば、表示する音源関連データ)。
７．０ ポーリングサイクル
７．１ 概要
ポーリングに対する標準的な応答では、そのオン/オフ状態、ローカル/ネットワーク聴取モード、ミュート状態、および音量レベルに関する基本的なスピーカステータス情報を供給することができる。スピーカは、標準ポーリング応答に対する高い優先度のメッセージ(保留の場合)を置き換える機能を持ち、これにより、重要なボタン押下およびデータのブロックを上流に向かってコンソール200に転送する機会を与える。
７．１ 概要
ポーリングに対する標準的な応答では、そのオン/オフ状態、ローカル/ネットワーク聴取モード、ミュート状態、および音量レベルに関する基本的なスピーカステータス情報を供給することができる。スピーカは、標準ポーリング応答に対する高い優先度のメッセージ(保留の場合)を置き換える機能を持ち、これにより、重要なボタン押下およびデータのブロックを上流に向かってコンソール200に転送する機会を与える。
ネットワークに接続されているスピーカは、長時間にわたってオフになっている場合がある。オフの場合、スピーカは、キーストロークでオンになった場合を検出するために時折ポーリングするだけでよい。しかし、接続され、かつオンにされているスピーカは、上流に向かってコンソール200に送信されるメッセージの適切な応答時間を保証するために高速なポーリングが実行されなければならない。そこで、これらの必要条件を満たし、ONのスピーカの個数が増えたときに予測可能な形で、ただし急激にでなくデグレードするようにパフォーマンスが制御されるポーリングサイクルについて説明する。
7.2 ポーリングサイクルのタイミングの詳細
ポーリングプロセスでは、15個の可能なスピーカのすべてを2つのリスト、つまり、現在ONのスピーカと、NOT ONスピーカ(オフまたは切断されている)に編成する。コンソールは、まず、現在ONのスピーカリストのすべてのメンバ(最大15まで、順番に)をポーリングし、その後、NOT ONリスト(もしあれば)の単一メンバをポーリングする。これは、ポーリングサイクルの1サブサイクルを表す。その後、サブサイクルは(割り込みなしで)繰り返すが、その際に、NOT ONリストの次のメンバを除くONスピーカの同じリストを(循環ラウンドロビン方式で)使用する。
ポーリングプロセスでは、15個の可能なスピーカのすべてを2つのリスト、つまり、現在ONのスピーカと、NOT ONスピーカ(オフまたは切断されている)に編成する。コンソールは、まず、現在ONのスピーカリストのすべてのメンバ(最大15まで、順番に)をポーリングし、その後、NOT ONリスト(もしあれば)の単一メンバをポーリングする。これは、ポーリングサイクルの1サブサイクルを表す。その後、サブサイクルは(割り込みなしで)繰り返すが、その際に、NOT ONリストの次のメンバを除く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ミリ秒。この結果、スピーカからコンソールまでのメッセージの待ち時間は最長となる。
すべてのスピーカがNOT ONであった場合、ポーリングサイクルはすべてONの場合と同じになる。15サブサイクル。
最長の全サイクルは、7個のスピーカONで、残りNOT ONである。
1サブサイクル〜44ミリ秒。全サイクル〜351ミリ秒。これは、スピーカがONになるのを識別する最長の待ち時間を持つ。
ポーリングサイクルのそれぞれのサブサイクルが完了すると、ONスピーカおよびNOT ONスピーカのリストは、ポーリング応答に基づいて更新されなければならない。最後のサブサイクルでONとして応答した、すでにNOT ONであるスピーカは、即座に、ONリストに移行しなければならない。OFFとして応答した、または5サブサイクルの間に一斉に応答できなかった、すべてのすでにONであるスピーカは、NOT ONリストに移動されなければならない。コンソールのリセット後、ポーリングが最初に開始したときに、NOT ONリスト内のすべてのスピーカが開始する。
７．３ 標準的なポーリングおよび応答メッセージバイト
コンソールまたはスピーカに、送信する高い優先度のメッセージがない限り、システムは、既定で、以下のような形式のメッセージを使用してポーリングサイクルに入る。
コンソールまたはスピーカに、送信する高い優先度のメッセージがない限り、システムは、既定で、以下のような形式のメッセージを使用してポーリングサイクルに入る。
Console Poll (3バイト):
第1の(Header)バイト:0x00 (POLLメッセージ)。
第2の(Address)バイト:現在の通常プロトコルによる。
第3の(Verifier)バイト:現在の通常プロトコルによる。
第1の(Header)バイト:0x00 (POLLメッセージ)。
第2の(Address)バイト:現在の通常プロトコルによる。
第3の(Verifier)バイト:現在の通常プロトコルによる。
Speaker Poll Reply (4バイト):
第1の(Header)バイト:0x80 (POLL REPLY)。
第2の(Address)バイト:オン/オフ/ローカル/ネットワークステータスを含む、スピーカのアドレスバイト。
第3の(Argument)バイト:以下のように音量/ミュートステータスになる:
引数詳細:
ビット6..0:現在の通常プロトコルによる、スピーカのMain Attenuationレベル。
ビット7:ミュート状態:1=ミュート。0=ミュートしていない。
第4の(Verifier)バイト:現在の通常プロトコルによる。
第1の(Header)バイト:0x80 (POLL REPLY)。
第2の(Address)バイト:オン/オフ/ローカル/ネットワークステータスを含む、スピーカのアドレスバイト。
第3の(Argument)バイト:以下のように音量/ミュートステータスになる:
引数詳細:
ビット6..0:現在の通常プロトコルによる、スピーカのMain Attenuationレベル。
ビット7:ミュート状態:1=ミュート。0=ミュートしていない。
第4の(Verifier)バイト:現在の通常プロトコルによる。
７．４ PASS_KEY_CODEメッセージを応答として使用する(Header 0x8D)
コンソールメッセージの後では真であるが、この(4バイト)メッセージは、送信できる場合に、コンソールPOLLメッセージの後に、SPEAKER_INFO応答(0x8C)の代わりに返される。Argumentバイトは、コンソールを制御することを意図されている256個の可能なボタンのうちの1つに関連付けられたキーコードを含む。注意:IR/RFリモートに対する既存のキーコードは、可能ならば使用されなければならない。
コンソールメッセージの後では真であるが、この(4バイト)メッセージは、送信できる場合に、コンソールPOLLメッセージの後に、SPEAKER_INFO応答(0x8C)の代わりに返される。Argumentバイトは、コンソールを制御することを意図されている256個の可能なボタンのうちの1つに関連付けられたキーコードを含む。注意:IR/RFリモートに対する既存のキーコードは、可能ならば使用されなければならない。
7.5 DOWNLOAD_INFORMATIONメッセージ(0x8A)を応答として使用する
この(Nバイト)の応答は、送信できる場合には、ポーリングを含む、コンソールメッセージの後に、SPEAKER_INFO応答(Ox8C)の代わりに返される。Argument/Dataバイトは、コンソール向けの何らかの種類のデータ、高水準のコマンド、またはクエリ(すべて現在未定義)を含むことも可能である。これは、リモートコントロールに表示するためローカル音源関連のデータをコンソールに送信する場合に使用できる。さらに、これにより、スピーカは音源変更などを直接指令したり、またはローカルディスプレイ(再生中のチューナステーションなど)に対するゾーン/音源特有のステータス情報を要求することも、概念的には可能である。
この(Nバイト)の応答は、送信できる場合には、ポーリングを含む、コンソールメッセージの後に、SPEAKER_INFO応答(Ox8C)の代わりに返される。Argument/Dataバイトは、コンソール向けの何らかの種類のデータ、高水準のコマンド、またはクエリ(すべて現在未定義)を含むことも可能である。これは、リモートコントロールに表示するためローカル音源関連のデータをコンソールに送信する場合に使用できる。さらに、これにより、スピーカは音源変更などを直接指令したり、またはローカルディスプレイ(再生中のチューナステーションなど)に対するゾーン/音源特有のステータス情報を要求することも、概念的には可能である。
８．０ 高レベルのスピーカ制御問題
８．１ マスター/スレーブ構成
与えられたバス上にマスターが1つだけある。バスMasterは、バスがIdle状態である限り(現在進行中のすべてのメッセージおよび応答が送信を開始する前に完了できる)、また後述のメッセージタイミング詳細に留意する限り、いつでも送信を開始できる。
８．１ マスター/スレーブ構成
与えられたバス上にマスターが1つだけある。バスMasterは、バスがIdle状態である限り(現在進行中のすべてのメッセージおよび応答が送信を開始する前に完了できる)、また後述のメッセージタイミング詳細に留意する限り、いつでも送信を開始できる。
スピーカは、コンソールによって送信されたメッセージの後でないと送信しない。しかし、後述のように、コンソールメッセージは、スピーカが送信を開始するためのちょうどよい機会として使用することができる。
８．２ 部屋のアドレス指定は一意である
ネットワークに追加される新しいスピーカは、ネットワークに接続する前に、一意的な4ビットRoom Address(RoomAからRoomOまで、スピーカを動作させることが意図されているリモートコントロールと一致する)を適切に設定しておく。
ネットワークに追加される新しいスピーカは、ネットワークに接続する前に、一意的な4ビットRoom Address(RoomAからRoomOまで、スピーカを動作させることが意図されているリモートコントロールと一致する)を適切に設定しておく。
８．３ Zone1およびZone2に対する別々の物理的バスの管理
コンソール200は、2つの別々の物理的スマートスピーカバス(Speaker Outputコネクタ毎に1つ)を備える。Zone1およびZone2オーディオストリームは、Zone2 Speaker Data信号のように、Zone2 Speaker Outputコネクタ上で使用可能である。RoomBからRoomOスピーカは、そのプラグをZone2 Speaker Outputコネクタに差し込み、Zone2 Speaker Data信号を使用して制御することができる。
コンソール200は、2つの別々の物理的スマートスピーカバス(Speaker Outputコネクタ毎に1つ)を備える。Zone1およびZone2オーディオストリームは、Zone2 Speaker Data信号のように、Zone2 Speaker Outputコネクタ上で使用可能である。RoomBからRoomOスピーカは、そのプラグをZone2 Speaker Outputコネクタに差し込み、Zone2 Speaker Data信号を使用して制御することができる。
８．４ スピーカ制御モード
Master ModeおよびPass-Through Modeという、スピーカを制御する2つの異なるモードを使用できる、Smart Speakerメッセージが定義される。Master Modeコマンドを使用すると、制御ユニット(例えば、コンソール)はすべてのクリティカルなスピーカパラメータを追跡し、適宜、それらのパラメータを絶対値(引数)としてスピーカに送信することができる。Pass-Through Modeでは、インテリジェント機能の低い制御ユニット(IR/Smart Speakerプロトコルブリッジ程度の単純さ)でも、リモートコントロールメッセージを効果的にスピーカに直接受け渡すことができる。このモードでは、スピーカは、クリティカルなパラメータ(ミュート前の最後の音量レベルなど)を追跡する。
Master ModeおよびPass-Through Modeという、スピーカを制御する2つの異なるモードを使用できる、Smart Speakerメッセージが定義される。Master Modeコマンドを使用すると、制御ユニット(例えば、コンソール)はすべてのクリティカルなスピーカパラメータを追跡し、適宜、それらのパラメータを絶対値(引数)としてスピーカに送信することができる。Pass-Through Modeでは、インテリジェント機能の低い制御ユニット(IR/Smart Speakerプロトコルブリッジ程度の単純さ)でも、リモートコントロールメッセージを効果的にスピーカに直接受け渡すことができる。このモードでは、スピーカは、クリティカルなパラメータ(ミュート前の最後の音量レベルなど)を追跡する。
Master Modeを介してネットワーク接続スピーカを制御することを望んでいるコンソールでは、制御すべきスピーカのそれぞれのタイプの利用可能な特徴(コントロールのタイプおよび範囲など)を記述したテーブルを保持する。
８．５ 新しいスピーカの検出
電源投入(ハードウェアリセット)後、ネットワーク接続スピーカは、OFF STATE(ミュート状態)に入り、ハードウェアを最低電流状態にする必要がある。この状態では、ネットワークとインターフェイスする役割を持つハードウェアのみが動作している。スピーカは、(最低でも) Poll Messages、Query_Speaker_Info Messages、さらにON/OFF Messagesを受信し、それに応答できる。
電源投入(ハードウェアリセット)後、ネットワーク接続スピーカは、OFF STATE(ミュート状態)に入り、ハードウェアを最低電流状態にする必要がある。この状態では、ネットワークとインターフェイスする役割を持つハードウェアのみが動作している。スピーカは、(最低でも) Poll Messages、Query_Speaker_Info Messages、さらにON/OFF Messagesを受信し、それに応答できる。
コンソールは、可能なすべてのスピーカRoom Addressesを連続的にポーリングするので、Smart Speakerバスに新規追加されたスピーカは、ポーリングに応答し始めるとすぐに検出されることができる。新しいスピーカが検出されたら、コンソールは、Query_Speaker_Infoメッセージを送信して、そのタイプを識別しなければならない。
８．６ ネットワーク接続スピーカの電源オン
ネットワーク接続スピーカにPollまたはQuery_Speaker_Infoメッセージ以外のコマンド送信する前に、まず、ON/OFF Messageを使用してオンにしなければならない。これにより、スピーカのハードウェアは完全に動作するようになる。コンソール200は、この電源オンプロセスが完了できるように適宜遅延すべきである。それぞれのネットワーク接続スピーカに対する電源オン遅延を記述するテーブルが用意されていない場合、コンソール200では、既定の遅延時間として1秒を使用しなければならない。
ネットワーク接続スピーカにPollまたはQuery_Speaker_Infoメッセージ以外のコマンド送信する前に、まず、ON/OFF Messageを使用してオンにしなければならない。これにより、スピーカのハードウェアは完全に動作するようになる。コンソール200は、この電源オンプロセスが完了できるように適宜遅延すべきである。それぞれのネットワーク接続スピーカに対する電源オン遅延を記述するテーブルが用意されていない場合、コンソール200では、既定の遅延時間として1秒を使用しなければならない。
８．７ ボーリングによるスピーカステータスの変化の検出
このポーリング過程で、スピーカの応答のAddress Byteのビット7..4は、オン/オフステータスに関する情報だけでなく、以下のように、再生している音源(Zone1、Zone2、またはそれ自体のローカル音源)に関する情報も含む。
このポーリング過程で、スピーカの応答のAddress Byteのビット7..4は、オン/オフステータスに関する情報だけでなく、以下のように、再生している音源(Zone1、Zone2、またはそれ自体のローカル音源)に関する情報も含む。
Z3..Z0(ビット7..4):0000-1101b:14個の可能なZonesのうちの1つを再生する(0010b=Zone1、0011b=Zone2など)。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
これらのビットを監視することにより、以下の重要なステータス変化が生じた場合を検出することができる。
８．７．１ スピーカのオン/オフ
スピーカは、ユニット自体のボタンを使って、またはそのIRリモートコントロールを介して、またはその重要性を理解することなくコンソールに単純にパススルーするリモートコントロールコマンドを介して、オン、オフすることも可能である。Address Z3..Z0ビットを使用することにより、コンソール200はそれぞれのスピーカのオン/オフ状態を監視することができる。これにより、コンソール200は、例えば、すべてのスピーカがオフの場合に電源オフにすることができる。
スピーカは、ユニット自体のボタンを使って、またはそのIRリモートコントロールを介して、またはその重要性を理解することなくコンソールに単純にパススルーするリモートコントロールコマンドを介して、オン、オフすることも可能である。Address Z3..Z0ビットを使用することにより、コンソール200はそれぞれのスピーカのオン/オフ状態を監視することができる。これにより、コンソール200は、例えば、すべてのスピーカがオフの場合に電源オフにすることができる。
８．７．２ スピーカの音源変更
同様に、スピーカは、コンソール200がそれと予期することなく、Zone1とZone2(またはローカルの音源)を切り替えることができる。同じAddressビットを監視することにより、コンソール200は、そのような変更を検出し、適切な処置を講じることができる(適切なオーディオ経路を電源オン/オフするなど)。
同様に、スピーカは、コンソール200がそれと予期することなく、Zone1とZone2(またはローカルの音源)を切り替えることができる。同じAddressビットを監視することにより、コンソール200は、そのような変更を検出し、適切な処置を講じることができる(適切なオーディオ経路を電源オン/オフするなど)。
8.8 スピーカストリームの切り替えの管理
スピーカは、コンソールからZone1またはZone2ネットワーク接続アナログ出力のいずれかを選択する機能を持つことができる。スピーカは、すべてのコンソールPass_Key_Codeメッセージ(Header 0x0D)およびOn/Offメッセージ(Header 0x01)のAddressバイトのZoneビットに反応することにより自動的にこの選択を行う。これらのメッセージは、RFリモートコントロール上のボタン押下の直接的結果としてスピーカに送信され、したがって、Zoneビットはリモートからメッセージを受け取ったとおり正確にセットされる(ただし、これらのビットは、リモートからスピーカに直接渡される)。On/Offメッセージは、ここでは、コンソールがすべてのリモートコントロールの音源ボタン押下(AM/FM、AUX、CD/DVDなど)に対する応答としてそのメッセージを送信し、その場合On/Offメッセージにより、音源が選択されたときにネットワーク接続スピーカはONおよびミュート解除の両方の状態になる。Pass_Key_Codeメッセージがローカル音源を再生するスピーカに送信されても、Localモードからスピーカが切り替わることはない。
Pass_Key_CodeメッセージがOn/OFFボタン引数とともにスピーカに渡されると、最後に再生された音源(NetworkまたはLocalのいずれか)でスピーカは電源オンになる。この場合にスピーカ側でネットワーク接続ストリーム/ゾーンを再生することを選択した場合、メッセージAddressで示されるストリームを選択する(最後に再生されたストリームとは反対に)。
スピーカは、コンソールからZone1またはZone2ネットワーク接続アナログ出力のいずれかを選択する機能を持つことができる。スピーカは、すべてのコンソールPass_Key_Codeメッセージ(Header 0x0D)およびOn/Offメッセージ(Header 0x01)のAddressバイトのZoneビットに反応することにより自動的にこの選択を行う。これらのメッセージは、RFリモートコントロール上のボタン押下の直接的結果としてスピーカに送信され、したがって、Zoneビットはリモートからメッセージを受け取ったとおり正確にセットされる(ただし、これらのビットは、リモートからスピーカに直接渡される)。On/Offメッセージは、ここでは、コンソールがすべてのリモートコントロールの音源ボタン押下(AM/FM、AUX、CD/DVDなど)に対する応答としてそのメッセージを送信し、その場合On/Offメッセージにより、音源が選択されたときにネットワーク接続スピーカはONおよびミュート解除の両方の状態になる。Pass_Key_Codeメッセージがローカル音源を再生するスピーカに送信されても、Localモードからスピーカが切り替わることはない。
Pass_Key_CodeメッセージがOn/OFFボタン引数とともにスピーカに渡されると、最後に再生された音源(NetworkまたはLocalのいずれか)でスピーカは電源オンになる。この場合にスピーカ側でネットワーク接続ストリーム/ゾーンを再生することを選択した場合、メッセージAddressで示されるストリームを選択する(最後に再生されたストリームとは反対に)。
９．０ メッセージ定義
９．１ 早見表
９．１ 早見表
９．２ コンソールにより送信されるメッセージ
以下のメッセージは、コンソール200により送信することができるメッセージ定義集の例である。
以下のメッセージは、コンソール200により送信することができるメッセージ定義集の例である。
９．２．１ POLLメッセージ(Header 0x00)
送信側:コンソール
総バイト数: 3
キュー優先度:低
送信側:コンソール
総バイト数: 3
キュー優先度:低
Poll Messageは、現在定義されている唯一の3バイトメッセージである。そのAddressバイトの4個の最上位ビットで、スピーカで再生する適切なオーディオZoneを識別する。4個の最下位ビットで、(スピーカのDIPスイッチで設定されたRoom Numberで)ポーリングされるスピーカを識別する。
Argumentは必要ないので、使われず、ネットワーク帯域幅が節約される。
Pollメッセージは、Poll Response情報を取得し、スピーカに他の重要なメッセージを渡す通常の機会を与えるために、実際には、単純なクエリ形式で送信される。
９．２．２ ON/OFFメッセージ(Header 0x0l)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
ON/OFF Messageは、オーディオ再生の準備のため完全電源オンにするか、またはセッションの後電源をオフにするようアドレス指定されたSmart Speaker(s)に通知する。注意:このコマンドは、リモート上の音源ボタンが押されたときにコンソールにより使用され、これにより、スピーカの完全電源オン、ミュート解除、所望のネットワーク入力ストリームの選択を行うようにできる。
スピーカの電源レールなどがミュート解除できるようになる前に(または、場合によっては、スピーカが他のコマンドを受け付けることができるようになるまで)整定するのにある程度の時間を要することが予想される。オンになった後、システムは、この問題に対し以下の3つの方法で対処することができる。
1.コンソールからスピーカに対し準備完了しているか問い合わせしてから(QUERY SPEAKER STATUSコマンド、ON/OFF Status引数を使用して)、スピーカモード、減衰レベルなどを構成するよう指令することができる。
2.スピーカは、ミュート解除の準備が整うまでSET SPEAKER MODEなどの後続のコマンドに応答しないことを単に選択することができる。
3.コンソールは、On/Offメッセージの送信から後続のメッセージの送信までの間に遅延(通常は約1秒)を設定することができる。
９．２．３ SET MAIN ATTENUATIONメッセージ(Header 0x02)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
Set Main Attenuationメッセージで、アドレス指定されたSmart Speaker(s)にそのマスター音量設定を示されているレベルに変更するよう指令する。注意:引数は、減衰のdBで表された新しいレベルを含み、0dBはスピーカの最大音量を表す。スピーカの利用可能なダイナミックレンジは、Query Speaker Info (Speaker Type)応答を通じて渡される。
９．２．４ SET SECONDARY LEVELSメッセージ(Header 0x03)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．５ SET EQ TYPE/TONE LEVELSメッセージ(Header 0x04)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．６ SET SPEAKER MODEメッセージ(Header 0x05)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．７ CONTROL EFFECTSメッセージ(Header 0x06)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．８ SELECT AUDIO INPUTメッセージ(Header 0x07)
送信側:コンソール
総バイト数: 4
キュー優先度:高
総バイト数: 4
キュー優先度:高
９．２．９ SELECT DECOMPRESSORメッセージ(Header 0x08)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．１０ SELECT POST PROCESSINGメッセージ(Header 0x09)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．１１ DOWNLOAD INFORMATIONメッセージ(Header 0x0A)
送信側:コンソール
総バイト数: 5-255
キュー優先度:中
送信側:コンソール
総バイト数: 5-255
キュー優先度:中
DOWNLOAD_INFORMATIONメッセージは、Smart Speakerパケット自体を介して最大250バイトまでのデータをスピーカに送信できる形式を持ち、ペイロードは好きなように定義することができる(ローカルチェックサムなどを含む)。スピーカVFDに直接書き込む、またはコンソールステータス(再生されている新しい音源、新しいトラック/局など)の変更をアナウンスする、このメッセージタイプの変種を定義することも可能である。
９．２．１２ QUERY SPEAKER INFOメッセージ(Header 0x0B)
送信側:コンソール
総バイト数: 4
キュー優先度:高
送信側:コンソール
総バイト数: 4
キュー優先度:高
９．２．１３ PASS KEY CODEメッセージ(Header 0x0D)
送信側:コンソール
総バイト数: 4
キュー優先度:中
送信側:コンソール
総バイト数: 4
キュー優先度:中
Pass Key Codeメッセージは、この場合、RFリモートコントロールボタンの押下をスピーカにパススルーするためにコンソールにより使用される。Argumentバイトは、RFリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。
９．３ スピーカによって送信されるメッセージ
以下は、スピーカ(ネットワークスレーブ)により送信されることが許されているメッセージの例である。
以下は、スピーカ(ネットワークスレーブ)により送信されることが許されているメッセージの例である。
９．３．１ POLL REPLYメッセージ(Header 0x80)
送信側:スピーカ
総バイト数: 4
キュー優先度:低
送信側:スピーカ
総バイト数: 4
キュー優先度:低
９．３．２ DOWNLOAD INFORMATIONメッセージ(Header 0x8A)
送信側:スピーカ
総バイト数: 5-255
キュー優先度:中
送信側:スピーカ
総バイト数: 5-255
キュー優先度:中
９．３．３ QUERY SPEAKER INFO REPLYメッセージ(Header 0x8C)
送信側:スピーカ
総バイト数: 4
キュー優先度:高
送信側:スピーカ
総バイト数: 4
キュー優先度:高
９．３．４ PASS KEY CODEメッセージ(Header 0x8D)
送信側:スピーカ
総バイト数: 4
キュー優先度:中
送信側:スピーカ
総バイト数: 4
キュー優先度:中
Pass Key Codeメッセージは、この場合、ローカルスピーカボタン押下を上流のコンソールに送信するためにスピーカにより使用される。Argumentバイトは、スピーカのローカルIRリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。
１０．０ 無線デバイス
無線デバイスを含むオーディオネットワーク制御システムの実施例では、無線デバイスは、無線チャネルを通じて送信されるメッセージの完全性に関する責任を負う。これは、コンソールから下流に向かってスピーカに送信されるメッセージ(「ダウンリンク」)とともに、それに対する応答として送り返されるメッセージ(「バックリンク」)に適用される。合意されているレベルのロバスト性を保証するために、トランシーバにより付加的な誤り防止/訂正機能が追加される。
無線デバイスを含むオーディオネットワーク制御システムの実施例では、無線デバイスは、無線チャネルを通じて送信されるメッセージの完全性に関する責任を負う。これは、コンソールから下流に向かってスピーカに送信されるメッセージ(「ダウンリンク」)とともに、それに対する応答として送り返されるメッセージ(「バックリンク」)に適用される。合意されているレベルのロバスト性を保証するために、トランシーバにより付加的な誤り防止/訂正機能が追加される。
コンソールからのポーリングは、無線リンクを介しては送信されない。その代わりに、無線スレーブが、それに接続されているスピーカをローカルでポーリングし、20ミリ秒毎に1回無線マスターに応答を送信する。無線マスターは、それらの応答をバッファリングし、ローカルで、適切なポーリングに対する応答としてそれらをコンソールに受け渡す。以下で詳細を述べる。既定の応答(Header 0x80)も、場合によってはクエリ応答がバックリンクを介して返されるまで、コンソールからスピーカへの他のすべての(つまり、より高い優先度の)メッセージに対する応答として無線マスターにより生成される。
スレーブデバイスでは、スピーカにはコンソールに接続されているのと「十分同じ」であるように見えるSmart Speakerインターフェイスを実装している。これは、コンソールと同様の方法でスピーカをポーリングすること、このポーリングに割り込みをかけて下流メッセージを即座にスピーカに渡すこと、およびすべてのポーリング応答情報を組み立てて、バックリンクを介してコンソールに送信することを含む。Slaveのポーリングは、1つのWireless Slaveがすべてのネットワーク接続スピーカ専用に割り当てられるというトポロジ的な利点があれば、いくぶん簡素化される。
１０．１ スレーブのローカルポーリングサイクル
コンソールにより生成されるポーリングはSlavesに送信されないため、それぞれのSlaveは、その関連するスピーカを自律的に識別し、ローカルポーリングサイクルを管理する。Wireless Slavesは、接続されている単一スピーカをポーリングするだけでよい-他のスピーカに対してローカルポーリングは不要である。接続されているスピーカのRoom Codeを判別するために、Wireless Slaveは、次のようにして、コンソール内に実装されるポーリングサイクルのより単純なバージョンを設定する。
コンソールにより生成されるポーリングはSlavesに送信されないため、それぞれのSlaveは、その関連するスピーカを自律的に識別し、ローカルポーリングサイクルを管理する。Wireless Slavesは、接続されている単一スピーカをポーリングするだけでよい-他のスピーカに対してローカルポーリングは不要である。接続されているスピーカのRoom Codeを判別するために、Wireless Slaveは、次のようにして、コンソール内に実装されるポーリングサイクルのより単純なバージョンを設定する。
1.Wireless Slaveは、応答のあるスピーカが見つかるまで可能なすべてのスピーカを連続的にポーリングする。
2.その後、Wireless Slaveは、20ミリ秒の速さでそのスピーカのみをポーリングする。
3.スピーカが応答を停止した場合、無線マスターは、応答スピーカが見つかるまで(新しいRoom Codeでありうる)可能なすべてのスピーカのポーリングを再び開始する。
20ミリ秒のバックリンク期間毎にそれに間に合うように1回のボーリング応答を確実に組み立てるために、SlaveによりWireless Slaveのローカルポーリング期間を同期させ、ポーリング交換がそれぞれのバックリンクメッセージの送信直前に実行されるようにする(約6ミリ秒早く開始し、バックリンクメッセージに含む応答を組み立てられるように時間に余裕を持たせる)。したがって、スピーカ高優先度メッセージ(ローカルボタン押下など)は、Slaveから無線マスターへの送信(初回)の機会が得られるまでに最大約20ミリ秒の待ち時間を被る。
１０．２ ローカルポーリングに対するコンソールメッセージの優先度
すでに概要を述べたように、コンソールメッセージの送出は、スピーカからポーリング情報を取り出すことよりも優先度が高い。したがって、Slaveが接続されているスピーカ向けのメッセージをコンソールから受信すると(例えば、PASS_KEY_CODEメッセージ)、メッセージは、ローカルポーリングサイクルのタイミングに関係なく、スピーカに即座にパススルーされなければならない。
すでに概要を述べたように、コンソールメッセージの送出は、スピーカからポーリング情報を取り出すことよりも優先度が高い。したがって、Slaveが接続されているスピーカ向けのメッセージをコンソールから受信すると(例えば、PASS_KEY_CODEメッセージ)、メッセージは、ローカルポーリングサイクルのタイミングに関係なく、スピーカに即座にパススルーされなければならない。
１０．３ スレーブのローカル再試行ルール
それぞれのSlaveは、再試行が使用されなければならない2つの状況を管理する必要がある。
それぞれのSlaveは、再試行が使用されなければならない2つの状況を管理する必要がある。
・ Slaveのローカルスピーカにパススルーされたメッセージに対しスピーカによる応答が行えない場合。
・ バックリンクを介してSlaveにより(スピーカから)コンソールに送信されたメッセージが無線マスターにより正常に受信されない場合(例えば、スピーカからのPASS_KEY_CODEメッセージ)。
第1の場合、Slaveは、スピーカへのコンソールのメッセージの即時再試行をローカルで管理する。1回の再試行のみが必須として定義される。ここでもまた、これは、この再試行がスピーカのスケジュールされたローカルポーリングに干渉する場合に受け入れ可能である。
第2の場合は、バックリンクを介して試行されたメッセージ転送の直後のWirelessマスターからSlaveへのある種の形態のフィードバックを想定する。このようなフィードバックは、次のWireless 20ミリ秒ポーリングサイクルのときに含めるように定義されなければならない。実際に、これは、Wirelessマスターからそれぞれの影響を受けるSlaveへのRequest for Retryの形をとらなければならない。SlaveがこのRequest for Retryを確認した場合、バックリンクを介して情報送信する次の機会に、もう一度、最後のスピーカメッセージの再送に有利になるようにWirelessマスターにポーリング情報を送信することを差し控えなければならない。この再試行メカニズムは、Wirelessマスターにメッセージを届けるために必要なだけ続けることが可能であり、Wirelessマスターの支配下になければならない。ここでは、100ミリ秒(5回の試行)がリミットとして適切である。スピーカポーリングは、再試行状況を通じて続行することができ、これにより、スピーカポーリング情報を更新し(バッファリングではなく上書き)、メッセージを(小さな)キューにバッファリングして、バックリンクを介して送信する次の機会を待つことができる。
１０．６ Wirelessマスターの一般的な役目
Wireless Masterは、説明されているように、スピーカ/Slavesから受信されたすべてのメッセージおよびポーリング情報による適切な時間内での応答により、実際には、そのスピーカ群にハード配線されているとコンソールに「思いこませる」ことにより、コンソールポーリングプロトコルの条件を満たす。後述のようにいくつかの特定の役目にはこれが欠けている。
Wireless Masterは、説明されているように、スピーカ/Slavesから受信されたすべてのメッセージおよびポーリング情報による適切な時間内での応答により、実際には、そのスピーカ群にハード配線されているとコンソールに「思いこませる」ことにより、コンソールポーリングプロトコルの条件を満たす。後述のようにいくつかの特定の役目にはこれが欠けている。
１０．６．１ ローカルで使用するようにスピーカのポーリング応答をバッファリングする
Wireless Masterは、スピーカからの高い優先度のメッセージが保留になっていない場合に、すべての接続スピーカについて、すべてのコンソールメッセージに対する応答としてPoll_Reply (0x80)メッセージを送信する。これらのPoll_Repliesを生成するために、Slavesのローカルポーリングサイクルから得られるバックリンクメッセージをバッファリングし、この情報を使用して、タイミングの制約条件の範囲内で適切な応答をフォーマットする。
Wireless Masterは、スピーカからの高い優先度のメッセージが保留になっていない場合に、すべての接続スピーカについて、すべてのコンソールメッセージに対する応答としてPoll_Reply (0x80)メッセージを送信する。これらのPoll_Repliesを生成するために、Slavesのローカルポーリングサイクルから得られるバックリンクメッセージをバッファリングし、この情報を使用して、タイミングの制約条件の範囲内で適切な応答をフォーマットする。
ポーリング情報は同じ状態変数の進行中の更新を表すので、それぞれのスピーカに対するポーリングステータスバッファは、メッセージ1つ分の深さしかなく、さらに新しいデータがスピーカから取り出される毎に絶えず更新される。Wirelessマスターは、与えられたスピーカから無効なポーリング応答データを受信した場合(無効なチェックサムなど)、Wirelessマスターはバッファ内に格納されている(古い)データを使用して、コンソールに応答することになる。Wirelessマスターが5秒以内に与えられたスピーカから有効なポーリング応答情報を受信できない場合、Wirelessマスターはそのスピーカに関連付けられているポーリングステータスバッファを空にし、コンソールによりポーリングされたときに差し控えていた応答を開始する。ONスピーカなどのリストからそのスピーカを削除することはコンソール側の役目である。
１０．６．２ ポーリング応答の代わりに高優先度スピーカメッセージを使用する
前のセクションで説明したように、スピーカは、コンソールメッセージに対し、保留になっている最高優先度戻りメッセージで応答する(Poll Repliesが既定値として使用される場合)。したがって、これをシミュレートするために、Wireless Masterは、Poll_Replyよりも優先度の高いメッセージが与えられたスピーカからいつ保留になったのかを識別し、そのスピーカに対する次のコンソールメッセージの後に、このメッセージを既定値のPoll_Replyの代わりに使用する。中優先度と高優先度のメッセージが保留になっている場合、高優先度メッセージが最初に送信されなければならない。
前のセクションで説明したように、スピーカは、コンソールメッセージに対し、保留になっている最高優先度戻りメッセージで応答する(Poll Repliesが既定値として使用される場合)。したがって、これをシミュレートするために、Wireless Masterは、Poll_Replyよりも優先度の高いメッセージが与えられたスピーカからいつ保留になったのかを識別し、そのスピーカに対する次のコンソールメッセージの後に、このメッセージを既定値のPoll_Replyの代わりに使用する。中優先度と高優先度のメッセージが保留になっている場合、高優先度メッセージが最初に送信されなければならない。
これらの高優先度メッセージをコンソールに渡しても、それぞれのスピーカに対するポーリングステータスバッファを破損しない。高優先度メッセージがコンソールに渡された後、WirelessマスターはPoll_Replyメッセージでの応答に戻らなければならない。
１０．６．３ 高優先度コンソールメッセージの役目
すでに述べたように、Wireless Masterは、すべてのコンソールメッセージに応答する。これは、コンソールメッセージの優先度に関係なく成立する(メッセージ定義を参照)。応答は、すでに説明されている767μ秒のウィンドウの範囲内で開始する。コンソールにいったん応答すると、Wirelessサブシステムでは、高い信頼性の下で中または高優先度コンソールメッセージをスピーカに送出する役割を持つが(再試行の管理を含む)、なぜかというと、コンソール側では、これ以降、それらのメッセージはスピーカによって受信されたとみなし、より高いレベルで再試行を管理できなくなる場合があるからである。
すでに述べたように、Wireless Masterは、すべてのコンソールメッセージに応答する。これは、コンソールメッセージの優先度に関係なく成立する(メッセージ定義を参照)。応答は、すでに説明されている767μ秒のウィンドウの範囲内で開始する。コンソールにいったん応答すると、Wirelessサブシステムでは、高い信頼性の下で中または高優先度コンソールメッセージをスピーカに送出する役割を持つが(再試行の管理を含む)、なぜかというと、コンソール側では、これ以降、それらのメッセージはスピーカによって受信されたとみなし、より高いレベルで再試行を管理できなくなる場合があるからである。
１０．６．４ クエリ交換時の役目
前のセクションで説明したように、コンソールは、特定のスピーカにクエリを送信すると、応答が返されるまで他のスピーカのポーリングを停止する。その代わりに、応答が保留中であるスピーカを連続してポーリングする。このような状況では、Wireless Masterは、以下のいずれかが生じるまでコンソールのポーリングに対する応答を単に続けるだけである。
前のセクションで説明したように、コンソールは、特定のスピーカにクエリを送信すると、応答が返されるまで他のスピーカのポーリングを停止する。その代わりに、応答が保留中であるスピーカを連続してポーリングする。このような状況では、Wireless Masterは、以下のいずれかが生じるまでコンソールのポーリングに対する応答を単に続けるだけである。
1.コンソール側で、他のスピーカのポーリングをあきらめて、また再開するか、または
2.クエリ応答が所望のスピーカから抜けてくる。Wirelessマスターは、これに、ポーリング応答よりも高い優先度を与え、したがって、それを次の有効なポーリングに対する応答としてコンソールに転送すべきである。
１０．６．５ スレーブへの再試行の要求
Wirelessバックリンクはダウンリンクよりも信頼性が劣る場合があるため、Slaveからの高優先度メッセージはWirelessマスターに破損した状態で到着する可能性がある。このような状況では、Wirelessマスターは、メッセージが無傷で転送されるまでSlaveに再試行を継続的に要求することができる。
Wirelessバックリンクはダウンリンクよりも信頼性が劣る場合があるため、Slaveからの高優先度メッセージはWirelessマスターに破損した状態で到着する可能性がある。このような状況では、Wirelessマスターは、メッセージが無傷で転送されるまでSlaveに再試行を継続的に要求することができる。
他の実施形態は、請求項の範囲内に収まる。
100…オーディオネットワーク制御システム
110…マスターデバイス
112A…スレーブデバイス
112A〜112D…スレーブデバイス
112Bおよび112C…スレーブデバイス
112D〜112F…スレーブデバイス
120…第1の部屋
122…第2の部屋
124…第3の部屋
130…マスターデバイス用のリモートコントロール
132…スレーブデバイス用のリモートコントロール
140…通信プロトコル
200…コンソール
202…制御データバス
204…オーディオインターフェイス
206…Turn On信号
208…ネットワーク接続スレーブデバイス
600…導電性シェル
110…マスターデバイス
112A…スレーブデバイス
112A〜112D…スレーブデバイス
112Bおよび112C…スレーブデバイス
112D〜112F…スレーブデバイス
120…第1の部屋
122…第2の部屋
124…第3の部屋
130…マスターデバイス用のリモートコントロール
132…スレーブデバイス用のリモートコントロール
140…通信プロトコル
200…コンソール
202…制御データバス
204…オーディオインターフェイス
206…Turn On信号
208…ネットワーク接続スレーブデバイス
600…導電性シェル
Claims (7)
- オーディオ通信システムの方法において、
１つ以上の有線オーディオデバイス用の有線ネットワーク上および１つ以上のスレーブ無線オーディオデバイス用の無線ネットワーク上で、マスターデバイスから複数のオーディオデバイスを制御するステップと、
前記有線オーディオデバイスの各々から、マスターデバイスからのポーリングメッセージに対する応答を受信するステップと、
マスターデバイスからのポーリングメッセージを待たずに、有線マスターが無線オーディオデバイスにハード配線されていると有線マスターに実質的に思い込ませるために、スレーブ無線オーディオデバイスから受信される全てのメッセージおよびポーリング情報によって適切な時間内に応答することによって、ローカル有線マスターとして動作するスレーブ無線オーディオデバイスのうちの１つからスレーブ無線オーディオデバイスの状態を示す総ポーリング情報をマスターデバイスにおいて受信するステップとを有していて、
前記ローカル有線マスターは、ポーリング応答を生成する全スレーブ無線オーディオデバイスを発見し、ローカル有線マスターによって予め決定されかつ確認されているように、予め設定されていた時間、マスターデバイスによる差し迫った周期的なポーリングと同時に起こる前記ポーリング応答の全てをバッファリングし、マスターデバイスによる全スレーブ無線オーディオデバイスに対するポーリング要求の発行の直後にマスターデバイスに到達するように、バッファリングされたポーリング応答を解放し、
前記ローカル有線マスターは、ポーリングの明示的なステップを実行し、全ポーリング応答情報を組み立てて、組み立てられたポーリング応答情報をマスターデバイスに送信する
ことを特徴とする方法。 - 総ポーリング情報を供給するマスターとして動作するスレーブ無線オーディオデバイスのうちの１つは、所定のサイクルで無線オーディオデバイスをローカルにポーリングすることを特徴とする請求項１に記載の方法。
- 少なくとも１つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを送信するステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。 - 少なくとも１つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを受信するステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。 - 少なくとも１つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを組み立てるステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。 - 前記メッセージを送信するステップを更に有していることを特徴とする請求項５に記載の方法。
- 少なくとも１つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークのためのプロトコルを記憶する一時的ではないコンピュータ読み出し可能な媒体を含むオーディオ通信ネットワークのための方法において、
前記プロトコルは、ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージ形式を含み、
メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/863,650 | 2004-06-08 | ||
| US10/863,650 US8214447B2 (en) | 2004-06-08 | 2004-06-08 | Managing an audio network |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005167514A Division JP2006033806A (ja) | 2004-06-08 | 2005-06-07 | オーディオネットワークの管理 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2012050136A true JP2012050136A (ja) | 2012-03-08 |
| JP5383775B2 JP5383775B2 (ja) | 2014-01-08 |
Family
ID=34980242
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005167514A Pending JP2006033806A (ja) | 2004-06-08 | 2005-06-07 | オーディオネットワークの管理 |
| JP2011243520A Expired - Fee Related JP5383775B2 (ja) | 2004-06-08 | 2011-11-07 | オーディオネットワークの管理 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005167514A Pending JP2006033806A (ja) | 2004-06-08 | 2005-06-07 | オーディオネットワークの管理 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US8214447B2 (ja) |
| EP (1) | EP1605637A3 (ja) |
| JP (2) | JP2006033806A (ja) |
| CN (1) | CN1708023B (ja) |
| HK (1) | HK1084269A1 (ja) |
Families Citing this family (152)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4020039B2 (ja) * | 2003-07-08 | 2007-12-12 | オンキヨー株式会社 | ネットワークａｖシステム |
| US8234395B2 (en) | 2003-07-28 | 2012-07-31 | Sonos, Inc. | System and method for synchronizing operations among a plurality of independently clocked digital data processing devices |
| US11294618B2 (en) | 2003-07-28 | 2022-04-05 | Sonos, Inc. | Media player system |
| US8086752B2 (en) | 2006-11-22 | 2011-12-27 | Sonos, Inc. | Systems and methods for synchronizing operations among a plurality of independently clocked digital data processing devices that independently source digital data |
| US9207905B2 (en) | 2003-07-28 | 2015-12-08 | Sonos, Inc. | Method and apparatus for providing synchrony group status information |
| US11650784B2 (en) | 2003-07-28 | 2023-05-16 | Sonos, Inc. | Adjusting volume levels |
| US11106424B2 (en) | 2003-07-28 | 2021-08-31 | Sonos, Inc. | Synchronizing operations among a plurality of independently clocked digital data processing devices |
| US8290603B1 (en) | 2004-06-05 | 2012-10-16 | Sonos, Inc. | User interfaces for controlling and manipulating groupings in a multi-zone media system |
| US11106425B2 (en) | 2003-07-28 | 2021-08-31 | Sonos, Inc. | Synchronizing operations among a plurality of independently clocked digital data processing devices |
| US7474677B2 (en) | 2003-08-12 | 2009-01-06 | Bose Corporation | Wireless communicating |
| US8442019B2 (en) * | 2003-08-12 | 2013-05-14 | Bose Corporation | Method and apparatus for avoiding wireless audio signal transmission interferences |
| US9977561B2 (en) | 2004-04-01 | 2018-05-22 | Sonos, Inc. | Systems, methods, apparatus, and articles of manufacture to provide guest access |
| US9374607B2 (en) | 2012-06-26 | 2016-06-21 | Sonos, Inc. | Media playback system with guest access |
| US8443038B2 (en) | 2004-06-04 | 2013-05-14 | Apple Inc. | Network media device |
| US20070110074A1 (en) | 2004-06-04 | 2007-05-17 | Bob Bradley | System and Method for Synchronizing Media Presentation at Multiple Recipients |
| US8797926B2 (en) | 2004-06-04 | 2014-08-05 | Apple Inc. | Networked media station |
| US10972536B2 (en) | 2004-06-04 | 2021-04-06 | Apple Inc. | System and method for synchronizing media presentation at multiple recipients |
| US8326951B1 (en) | 2004-06-05 | 2012-12-04 | Sonos, Inc. | Establishing a secure wireless network with minimum human intervention |
| US8868698B2 (en) | 2004-06-05 | 2014-10-21 | Sonos, Inc. | Establishing a secure wireless network with minimum human intervention |
| US20060080714A1 (en) * | 2004-10-12 | 2006-04-13 | Atkinson Lee W | Apparatus and method for facilitating connection of an electronic device with an audiovisual system |
| EP1900153B1 (en) * | 2005-07-04 | 2012-02-22 | VKR Holding A/S | System and method for operating a master unit and a plurality of slave units |
| EP2075954B1 (en) * | 2005-07-04 | 2011-05-11 | VKR Holding A/S | System comprising a master unit and a plurality of slave units for operating a plurality of devices |
| DE602005011871D1 (de) * | 2005-07-04 | 2009-01-29 | Vkr Holding As | System mit mindestens einer master-einheit und mehreren slave-einheiten |
| KR101135101B1 (ko) * | 2005-10-17 | 2012-04-16 | 엘지전자 주식회사 | 캔에서의 데이터 길이 코드를 이용한 데이터 필드 패딩방법 |
| US10013381B2 (en) * | 2006-08-31 | 2018-07-03 | Bose Corporation | Media playing from a docked handheld media device |
| US8483853B1 (en) | 2006-09-12 | 2013-07-09 | Sonos, Inc. | Controlling and manipulating groupings in a multi-zone media system |
| US9202509B2 (en) | 2006-09-12 | 2015-12-01 | Sonos, Inc. | Controlling and grouping in a multi-zone media system |
| US8788080B1 (en) | 2006-09-12 | 2014-07-22 | Sonos, Inc. | Multi-channel pairing in a media system |
| US9124767B2 (en) * | 2006-10-25 | 2015-09-01 | Microsoft Technology Licensing, Llc | Multi-DVR media content arbitration |
| JP4935345B2 (ja) * | 2006-12-25 | 2012-05-23 | ソニー株式会社 | コンテンツ再生システム、再生装置、再生制御方法及びプログラム |
| US8315724B2 (en) * | 2007-01-18 | 2012-11-20 | Minebea Co. Ltd. | Wireless audio streaming transport system |
| JP5129499B2 (ja) * | 2007-04-11 | 2013-01-30 | キヤノン株式会社 | 画像形成装置、画像形成装置の制御方法、プログラム、記憶媒体 |
| US8175306B2 (en) * | 2007-07-06 | 2012-05-08 | Cochlear Limited | Wireless communication between devices of a hearing prosthesis |
| WO2009008630A2 (en) * | 2007-07-06 | 2009-01-15 | Lg Electronics Inc. | Wireless network management procedure, station supporting the procedure, and frame format for the procedure |
| ATE536681T1 (de) * | 2007-10-04 | 2011-12-15 | Harman Becker Automotive Sys | Datennetzwerk mit zeitsynchronisationsmechanismus |
| US9154379B2 (en) * | 2007-10-25 | 2015-10-06 | Sercomm Corporation | Remote configuration of a hardware device module of a security system |
| KR101442169B1 (ko) * | 2007-11-27 | 2014-11-03 | 삼성전자주식회사 | 공개키 기반의 블루투스 스마트 키 시스템 및 동작 방법 |
| CN101188050B (zh) * | 2007-12-21 | 2013-04-17 | 康佳集团股份有限公司 | 一种双工遥控器 |
| US8364296B2 (en) * | 2008-01-02 | 2013-01-29 | International Business Machines Corporation | Method and system for synchronizing playing of an ordered list of auditory content on multiple playback devices |
| CN101227533B (zh) * | 2008-01-31 | 2011-09-14 | 华为技术有限公司 | 一种建立音频会议连接的方法和装置 |
| KR101537649B1 (ko) * | 2008-12-12 | 2015-07-22 | 삼성전자 주식회사 | 신호 처리 장치와 음향 기기 및 이의 제어 방법 |
| US20110022692A1 (en) * | 2009-07-24 | 2011-01-27 | Jeyhan Karaoguz | Method and system for determining and controlling user experience in a network |
| US8244927B2 (en) | 2009-10-27 | 2012-08-14 | Fairchild Semiconductor Corporation | Method of detecting accessories on an audio jack |
| GB2477751A (en) * | 2010-02-11 | 2011-08-17 | Keith Alistair Hamilton | Device & System for the control of Multi-Zone AV Equipment using TCP/IP |
| US20110252125A1 (en) * | 2010-04-09 | 2011-10-13 | Microsoft Corporation | Dynamic Syncing |
| US8892632B2 (en) | 2010-06-04 | 2014-11-18 | Microsoft Corporation | Client-server interaction frequency control |
| US8831234B2 (en) | 2010-07-23 | 2014-09-09 | Fairchild Semiconductor Corporation | Audio jack detection and configuration |
| US9768956B2 (en) * | 2010-07-28 | 2017-09-19 | General Motors Llc | Methods and systems for facilitating communications between vehicles and service providers |
| CN102457345A (zh) * | 2010-10-29 | 2012-05-16 | 杨林 | 带强切功能的寻址广播终端控制器 |
| US20120148075A1 (en) * | 2010-12-08 | 2012-06-14 | Creative Technology Ltd | Method for optimizing reproduction of audio signals from an apparatus for audio reproduction |
| US11265652B2 (en) | 2011-01-25 | 2022-03-01 | Sonos, Inc. | Playback device pairing |
| US11429343B2 (en) | 2011-01-25 | 2022-08-30 | Sonos, Inc. | Stereo playback configuration and control |
| KR101209037B1 (ko) * | 2011-05-25 | 2012-12-06 | 엠앤서비스 주식회사 | 콘텐츠 동시 재생 단말, 그 시스템 및 동시 재생 방법 |
| US9497559B2 (en) | 2011-07-22 | 2016-11-15 | Fairchild Semiconductor Corporation | MIC/GND detection and automatic switch |
| US9052810B2 (en) | 2011-09-28 | 2015-06-09 | Sonos, Inc. | Methods and apparatus to manage zones of a multi-zone media playback system |
| US9094706B2 (en) | 2011-10-21 | 2015-07-28 | Sonos, Inc. | Systems and methods for wireless music playback |
| US9729115B2 (en) | 2012-04-27 | 2017-08-08 | Sonos, Inc. | Intelligently increasing the sound level of player |
| US9949205B2 (en) * | 2012-05-26 | 2018-04-17 | Qualcomm Incorporated | Smart battery wear leveling for audio devices |
| US8995687B2 (en) | 2012-08-01 | 2015-03-31 | Sonos, Inc. | Volume interactions for connected playback devices |
| US9008330B2 (en) | 2012-09-28 | 2015-04-14 | Sonos, Inc. | Crossover frequency adjustments for audio speakers |
| US9318116B2 (en) * | 2012-12-14 | 2016-04-19 | Disney Enterprises, Inc. | Acoustic data transmission based on groups of audio receivers |
| US9510055B2 (en) | 2013-01-23 | 2016-11-29 | Sonos, Inc. | System and method for a media experience social interface |
| US9942661B2 (en) | 2013-05-14 | 2018-04-10 | Logitech Europe S.A | Method and apparatus for controlling portable audio devices |
| WO2014188227A1 (en) * | 2013-05-20 | 2014-11-27 | Thomson Licensing | Remote control programming using images |
| US9438193B2 (en) | 2013-06-05 | 2016-09-06 | Sonos, Inc. | Satellite volume control |
| US9654073B2 (en) | 2013-06-07 | 2017-05-16 | Sonos, Inc. | Group volume control |
| KR102090490B1 (ko) * | 2013-08-30 | 2020-03-18 | 삼성전자 주식회사 | 오디오 채널 설정 방법 및 시스템 |
| US9355555B2 (en) | 2013-09-27 | 2016-05-31 | Sonos, Inc. | System and method for issuing commands in a media playback system |
| US9231545B2 (en) | 2013-09-27 | 2016-01-05 | Sonos, Inc. | Volume enhancements in a multi-zone media playback system |
| US9720576B2 (en) | 2013-09-30 | 2017-08-01 | Sonos, Inc. | Controlling and displaying zones in a multi-zone system |
| US9288596B2 (en) | 2013-09-30 | 2016-03-15 | Sonos, Inc. | Coordinator device for paired or consolidated players |
| US9654545B2 (en) | 2013-09-30 | 2017-05-16 | Sonos, Inc. | Group coordinator device selection |
| US9078072B2 (en) * | 2013-10-07 | 2015-07-07 | Bose Corporation | Audio distribution |
| KR102088526B1 (ko) * | 2013-11-04 | 2020-04-14 | 삼성전자주식회사 | 스마트 홈 시스템을 제어하기 위한 방법 및 그 전자 장치 |
| US9300647B2 (en) | 2014-01-15 | 2016-03-29 | Sonos, Inc. | Software application and zones |
| US20150220498A1 (en) | 2014-02-05 | 2015-08-06 | Sonos, Inc. | Remote Creation of a Playback Queue for a Future Event |
| US9226073B2 (en) | 2014-02-06 | 2015-12-29 | Sonos, Inc. | Audio output balancing during synchronized playback |
| US9226087B2 (en) | 2014-02-06 | 2015-12-29 | Sonos, Inc. | Audio output balancing during synchronized playback |
| US9679054B2 (en) | 2014-03-05 | 2017-06-13 | Sonos, Inc. | Webpage media playback |
| US10587693B2 (en) | 2014-04-01 | 2020-03-10 | Sonos, Inc. | Mirrored queues |
| GB2536827B (en) * | 2014-05-09 | 2017-07-05 | Imagination Tech Ltd | Time stamp replication within a wireless network |
| US20150324552A1 (en) | 2014-05-12 | 2015-11-12 | Sonos, Inc. | Share Restriction for Media Items |
| US20150356084A1 (en) | 2014-06-05 | 2015-12-10 | Sonos, Inc. | Social Queue |
| US9348824B2 (en) | 2014-06-18 | 2016-05-24 | Sonos, Inc. | Device group identification |
| US11942095B2 (en) | 2014-07-18 | 2024-03-26 | Google Llc | Speaker verification using co-location information |
| US11676608B2 (en) | 2021-04-02 | 2023-06-13 | Google Llc | Speaker verification using co-location information |
| US9257120B1 (en) | 2014-07-18 | 2016-02-09 | Google Inc. | Speaker verification using co-location information |
| US9512954B2 (en) | 2014-07-22 | 2016-12-06 | Sonos, Inc. | Device base |
| US9671997B2 (en) | 2014-07-23 | 2017-06-06 | Sonos, Inc. | Zone grouping |
| US10209947B2 (en) | 2014-07-23 | 2019-02-19 | Sonos, Inc. | Device grouping |
| US9874997B2 (en) | 2014-08-08 | 2018-01-23 | Sonos, Inc. | Social playback queues |
| US10645130B2 (en) | 2014-09-24 | 2020-05-05 | Sonos, Inc. | Playback updates |
| US9667679B2 (en) | 2014-09-24 | 2017-05-30 | Sonos, Inc. | Indicating an association between a social-media account and a media playback system |
| US9959087B2 (en) | 2014-09-24 | 2018-05-01 | Sonos, Inc. | Media item context from social media |
| US9723038B2 (en) | 2014-09-24 | 2017-08-01 | Sonos, Inc. | Social media connection recommendations based on playback information |
| US9690540B2 (en) | 2014-09-24 | 2017-06-27 | Sonos, Inc. | Social media queue |
| WO2016049342A1 (en) | 2014-09-24 | 2016-03-31 | Sonos, Inc. | Social media connection recommendations based on playback information |
| US9860286B2 (en) | 2014-09-24 | 2018-01-02 | Sonos, Inc. | Associating a captured image with a media item |
| US9691270B1 (en) * | 2014-09-30 | 2017-06-27 | Apple Inc. | Automatically configuring a remote control for a device |
| US9773409B1 (en) | 2014-09-30 | 2017-09-26 | Apple Inc. | Automatically configuring a remote control for a device |
| US9318107B1 (en) | 2014-10-09 | 2016-04-19 | Google Inc. | Hotword detection on multiple devices |
| US9424841B2 (en) | 2014-10-09 | 2016-08-23 | Google Inc. | Hotword detection on multiple devices |
| US9330096B1 (en) | 2015-02-25 | 2016-05-03 | Sonos, Inc. | Playback expansion |
| US9329831B1 (en) | 2015-02-25 | 2016-05-03 | Sonos, Inc. | Playback expansion |
| US11209972B2 (en) | 2015-09-02 | 2021-12-28 | D&M Holdings, Inc. | Combined tablet screen drag-and-drop interface |
| US11113022B2 (en) | 2015-05-12 | 2021-09-07 | D&M Holdings, Inc. | Method, system and interface for controlling a subwoofer in a networked audio system |
| WO2016183263A1 (en) | 2015-05-12 | 2016-11-17 | D&M Holdings, Inc. | System and method for negotiating group membership for audio controllers |
| US10516718B2 (en) | 2015-06-10 | 2019-12-24 | Google Llc | Platform for multiple device playout |
| US10248376B2 (en) | 2015-06-11 | 2019-04-02 | Sonos, Inc. | Multiple groupings in a playback system |
| US10284417B2 (en) * | 2015-06-22 | 2019-05-07 | Arista Networks, Inc. | Method and system for sharing state between network elements |
| US9544701B1 (en) | 2015-07-19 | 2017-01-10 | Sonos, Inc. | Base properties in a media playback system |
| US10001965B1 (en) | 2015-09-03 | 2018-06-19 | Sonos, Inc. | Playback system join with base |
| US10356526B2 (en) | 2015-09-28 | 2019-07-16 | Razer (Asia-Pacific) Pte. Ltd. | Computers, methods for controlling a computer, and computer-readable media |
| CN106714008B (zh) * | 2015-11-13 | 2021-09-17 | 深圳兆日科技股份有限公司 | 音频通信方法、智能终端及音频设备 |
| CN105430570B (zh) * | 2015-11-27 | 2018-03-23 | 北京小鸟听听科技有限公司 | 播放方法及播放装置 |
| US9886234B2 (en) | 2016-01-28 | 2018-02-06 | Sonos, Inc. | Systems and methods of distributing audio to one or more playback devices |
| US9779735B2 (en) | 2016-02-24 | 2017-10-03 | Google Inc. | Methods and systems for detecting and processing speech signals |
| US9775069B1 (en) | 2016-08-24 | 2017-09-26 | Amazon Technologies, Inc. | System for configuring distributed audio output using a designated audio device |
| US9972320B2 (en) | 2016-08-24 | 2018-05-15 | Google Llc | Hotword detection on multiple devices |
| US9998294B1 (en) | 2016-08-24 | 2018-06-12 | Amazon Technologies, Inc. | System for distributed audio output using designated audio devices |
| US10158440B1 (en) * | 2016-08-24 | 2018-12-18 | Amazon Technologies, Inc. | System for configuring distributed audio output using an access point |
| US10712997B2 (en) | 2016-10-17 | 2020-07-14 | Sonos, Inc. | Room association based on name |
| WO2018085192A1 (en) | 2016-11-07 | 2018-05-11 | Google Llc | Recorded media hotword trigger suppression |
| US10149056B1 (en) | 2016-12-09 | 2018-12-04 | Amazon Technologies, Inc. | System for configuring audio devices to distribute audio data |
| US10412565B2 (en) * | 2016-12-19 | 2019-09-10 | Qualcomm Incorporated | Systems and methods for muting a wireless communication device |
| US10522137B2 (en) | 2017-04-20 | 2019-12-31 | Google Llc | Multi-user authentication on a device |
| US10395650B2 (en) | 2017-06-05 | 2019-08-27 | Google Llc | Recorded media hotword trigger suppression |
| US10783929B2 (en) | 2018-03-30 | 2020-09-22 | Apple Inc. | Managing playback groups |
| US10993274B2 (en) | 2018-03-30 | 2021-04-27 | Apple Inc. | Pairing devices by proxy |
| US11297369B2 (en) | 2018-03-30 | 2022-04-05 | Apple Inc. | Remotely controlling playback devices |
| US11102106B2 (en) | 2018-04-04 | 2021-08-24 | Arista Networks, Inc. | Dynamic flooding for link state protocols |
| US11671329B2 (en) | 2018-04-04 | 2023-06-06 | Arista Networks, Inc. | Computation of network flooding topologies |
| US10692496B2 (en) | 2018-05-22 | 2020-06-23 | Google Llc | Hotword suppression |
| US11218399B2 (en) | 2018-06-20 | 2022-01-04 | Arista Networks, Inc. | Embedded area abstraction |
| US10855572B2 (en) | 2018-06-20 | 2020-12-01 | Arista Networks, Inc. | Area abstraction extensions to routing protocols |
| US10614857B2 (en) | 2018-07-02 | 2020-04-07 | Apple Inc. | Calibrating media playback channels for synchronized presentation |
| US10789038B2 (en) | 2018-07-20 | 2020-09-29 | Logitech Europe S.A. | Content streaming apparatus and method |
| EP3981170A1 (en) | 2019-06-07 | 2022-04-13 | Sonos, Inc. | Automatically allocating audio portions to playback devices |
| CN114514756A (zh) * | 2019-07-30 | 2022-05-17 | 杜比实验室特许公司 | 音频设备的协调 |
| US11038704B2 (en) | 2019-08-16 | 2021-06-15 | Logitech Europe S.A. | Video conference system |
| US11258982B2 (en) | 2019-08-16 | 2022-02-22 | Logitech Europe S.A. | Video conference system |
| US11095467B2 (en) | 2019-08-16 | 2021-08-17 | Logitech Europe S.A. | Video conference system |
| US11088861B2 (en) | 2019-08-16 | 2021-08-10 | Logitech Europe S.A. | Video conference system |
| US11296948B2 (en) | 2020-01-09 | 2022-04-05 | Arista Networks, Inc. | Topology partition detection |
| CN111352888A (zh) * | 2020-02-28 | 2020-06-30 | 北京铁科英迈技术有限公司 | 异步收发器的中断信号产生方法及装置 |
| US10951858B1 (en) | 2020-03-30 | 2021-03-16 | Logitech Europe S.A. | Advanced video conferencing systems and methods |
| US10972655B1 (en) | 2020-03-30 | 2021-04-06 | Logitech Europe S.A. | Advanced video conferencing systems and methods |
| US10904446B1 (en) | 2020-03-30 | 2021-01-26 | Logitech Europe S.A. | Advanced video conferencing systems and methods |
| US10965908B1 (en) | 2020-03-30 | 2021-03-30 | Logitech Europe S.A. | Advanced video conferencing systems and methods |
| US11445457B2 (en) | 2020-09-21 | 2022-09-13 | Logitech Europe S.A. | Content distribution system |
| US11418559B2 (en) | 2020-09-21 | 2022-08-16 | Logitech Europe S.A. | Content distribution system |
| CN113015106B (zh) * | 2021-04-19 | 2023-04-21 | 南京中感微电子有限公司 | 广播组网的立体声播放方法、装置和电子设备 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003008600A (ja) * | 2001-06-25 | 2003-01-10 | Nec Corp | データ収集方式および方法 |
Family Cites Families (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| USRE28109E (en) * | 1969-02-28 | 1974-08-13 | Selective data handling apparatus | |
| FR2469751A1 (fr) * | 1979-11-07 | 1981-05-22 | Philips Data Syst | Processeur d'intercommunication du systeme utilise dans un systeme de traitement de donnees reparti |
| US4490782A (en) * | 1981-06-05 | 1984-12-25 | International Business Machines Corporation | I/O Storage controller cache system with prefetch determined by requested record's position within data block |
| JP2506969B2 (ja) * | 1988-08-03 | 1996-06-12 | 松下電器産業株式会社 | リモコン操作型送信機能付電子機器 |
| US5025486A (en) * | 1988-12-09 | 1991-06-18 | Dallas Semiconductor Corporation | Wireless communication system with parallel polling |
| US5101267A (en) * | 1989-08-07 | 1992-03-31 | Tv Answer, Inc. | Wide area real-time T-V audience polling system with local area stations linked by satellite |
| CA2023455A1 (en) | 1989-08-24 | 1991-02-25 | Richard J. Paynting | Multiple zone audio system |
| JP2689734B2 (ja) * | 1991-01-09 | 1997-12-10 | ヤマハ株式会社 | 音響装置 |
| US5293619A (en) * | 1991-05-30 | 1994-03-08 | Sandia Corporation | Method and apparatus for collaborative use of application program |
| US5625845A (en) * | 1992-10-13 | 1997-04-29 | International Business Machines Corporation | System for facilitating continuous, real-time, unidirectional, and asynchronous intertask and end-device communication in a multimedia data processing system using open architecture data communication modules |
| US5574979A (en) * | 1994-06-03 | 1996-11-12 | Norand Corporation | Periodic interference avoidance in a wireless radio frequency communication system |
| JP3681186B2 (ja) * | 1994-06-22 | 2005-08-10 | パイオニア株式会社 | リモートコントロールシステム |
| US5740435A (en) * | 1994-10-31 | 1998-04-14 | Sony Corporation | Data management apparatus and method for managing data of variable lengths recorded on a record medium |
| US6026429A (en) * | 1995-06-07 | 2000-02-15 | America Online, Inc. | Seamless integration of internet resources |
| US5737747A (en) * | 1995-10-27 | 1998-04-07 | Emc Corporation | Prefetching to service multiple video streams from an integrated cached disk array |
| US6061504A (en) * | 1995-10-27 | 2000-05-09 | Emc Corporation | Video file server using an integrated cached disk array and stream server computers |
| US5664221A (en) * | 1995-11-14 | 1997-09-02 | Digital Equipment Corporation | System for reconfiguring addresses of SCSI devices via a device address bus independent of the SCSI bus |
| US5996022A (en) * | 1996-06-03 | 1999-11-30 | Webtv Networks, Inc. | Transcoding data in a proxy computer prior to transmitting the audio data to a client |
| US5999610A (en) * | 1996-06-26 | 1999-12-07 | Telcordia Technologies, Inc. | Managing feature interactions in a telecommunications system such as an intelligent network |
| US6041393A (en) * | 1996-08-23 | 2000-03-21 | Hewlett-Packard Co. | Array padding for higher memory throughput in the presence of dirty misses |
| US5884046A (en) * | 1996-10-23 | 1999-03-16 | Pluris, Inc. | Apparatus and method for sharing data and routing messages between a plurality of workstations in a local area network |
| US5812529A (en) * | 1996-11-12 | 1998-09-22 | Lanquest Group | Method and apparatus for network assessment |
| US6141681A (en) * | 1997-03-07 | 2000-10-31 | Advanced Micro Devices, Inc. | Method of and apparatus for transferring and interpreting a data package |
| WO1999008420A1 (de) * | 1997-08-05 | 1999-02-18 | Siemens Aktiengesellschaft | Bedieneinrichtung zur bedienung eines netz-management-systems |
| US5922051A (en) * | 1997-05-14 | 1999-07-13 | Ncr Corporation | System and method for traffic management in a network management system |
| US6314479B1 (en) * | 1997-08-04 | 2001-11-06 | Compaq Computer Corporation | Universal multi-pin plug and display connector for standardizing signals transmitted between a computer and a display for a PC theatre interconnectivity system |
| US6553404B2 (en) * | 1997-08-08 | 2003-04-22 | Prn Corporation | Digital system |
| US6085263A (en) * | 1997-10-24 | 2000-07-04 | Compaq Computer Corp. | Method and apparatus for employing commit-signals and prefetching to maintain inter-reference ordering in a high-performance I/O processor |
| CA2220578A1 (en) * | 1997-11-10 | 1999-05-10 | Northern Telecom Limited | Distributed service network |
| US6127941A (en) * | 1998-02-03 | 2000-10-03 | Sony Corporation | Remote control device with a graphical user interface |
| JP4248028B2 (ja) * | 1998-04-22 | 2009-04-02 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 消費者用電子システムにおける機能の管理 |
| US6255961B1 (en) * | 1998-05-08 | 2001-07-03 | Sony Corporation | Two-way communications between a remote control unit and one or more devices in an audio/visual environment |
| US6393430B1 (en) * | 1998-05-08 | 2002-05-21 | Sony Corporation | Method and system for automatically recording music data files by using the hard drive of a personal computer as an intermediate storage medium |
| US20040095237A1 (en) * | 1999-01-09 | 2004-05-20 | Chen Kimball C. | Electronic message delivery system utilizable in the monitoring and control of remote equipment and method of same |
| US6363434B1 (en) * | 1999-03-30 | 2002-03-26 | Sony Corporation Of Japan | Method of managing resources within a network of consumer electronic devices |
| US6633547B1 (en) * | 1999-04-29 | 2003-10-14 | Mitsubishi Electric Research Laboratories, Inc. | Command and control transfer |
| US6389463B2 (en) * | 1999-06-16 | 2002-05-14 | Im Networks, Inc. | Internet radio receiver having a rotary knob for selecting audio content provider designations and negotiating internet access to URLS associated with the designations |
| US6275500B1 (en) * | 1999-08-09 | 2001-08-14 | Motorola, Inc. | Method and apparatus for dynamic control of talk groups in a wireless network |
| US6785704B1 (en) * | 1999-12-20 | 2004-08-31 | Fastforward Networks | Content distribution system for operation over an internetwork including content peering arrangements |
| US6785540B1 (en) * | 1999-11-30 | 2004-08-31 | Agilent Technologies, Inc. | Monitoring system and method implementing test configuration logic |
| CA2393936A1 (en) | 1999-12-23 | 2001-07-05 | Sony Electronics Inc. | Information gateway system and method |
| US6925484B2 (en) * | 2000-03-29 | 2005-08-02 | Matsushita Electric Industrial Co., Ltd. | Dynamic proxy server apparatus |
| US6810413B1 (en) * | 2000-06-30 | 2004-10-26 | Covad Communitions Group, Inc. | System and method for providing internet content using hybrid wireless and wire technologies at the end user site |
| US6829227B1 (en) * | 2000-10-27 | 2004-12-07 | Lucent Technologies Inc. | Dual polling media access control protocol for packet data in fixed wireless communication systems |
| FR2816146A1 (fr) * | 2000-10-27 | 2002-05-03 | Canon Kk | Procede et dispositif de gestion d'un reseau de communication |
| US20020072816A1 (en) * | 2000-12-07 | 2002-06-13 | Yoav Shdema | Audio system |
| US6778869B2 (en) * | 2000-12-11 | 2004-08-17 | Sony Corporation | System and method for request, delivery and use of multimedia files for audiovisual entertainment in the home environment |
| JP2002199474A (ja) | 2000-12-26 | 2002-07-12 | Kenwood Corp | Ｉｅｅｅ１３９４ネットワークシステム及びその管理方法 |
| US20020103873A1 (en) * | 2001-02-01 | 2002-08-01 | Kumaresan Ramanathan | Automating communication and information exchange |
| US20020108058A1 (en) * | 2001-02-08 | 2002-08-08 | Sony Corporation And Sony Electronics Inc. | Anti-theft system for computers and other electronic devices |
| US20020194596A1 (en) | 2001-06-18 | 2002-12-19 | Srivastava Gopal K. | Control of multiple AV-devices by a single master controller using infrared transmitted commands and bus transmitted commands |
| JP2003087883A (ja) | 2001-09-10 | 2003-03-20 | Canon Inc | ネットワーク接続機器の制御システム |
| JP3793093B2 (ja) * | 2002-01-21 | 2006-07-05 | アルパイン株式会社 | ディスクプレーヤ及びその記録内容情報表示方法 |
| JP3996413B2 (ja) | 2002-03-06 | 2007-10-24 | ヤマハ株式会社 | マルチゾーン用ａｖシステムの機能制御装置 |
| JP2003338947A (ja) | 2002-05-22 | 2003-11-28 | Pioneer Electronic Corp | 電子機器ネットワークシステム、電子機器制御装置、及び電子機器制御方法 |
| US8605623B2 (en) | 2002-05-31 | 2013-12-10 | Koninklijke Philips N.V. | Determining and configuring a communication path in a network |
| US20040078105A1 (en) * | 2002-09-03 | 2004-04-22 | Charles Moon | System and method for workflow process management |
| US8036200B2 (en) * | 2003-01-21 | 2011-10-11 | Avaya Inc. | Efficient polled frame exchange on a shared-communications channel |
| US7555559B2 (en) * | 2003-02-28 | 2009-06-30 | Onion Networks, KK | Parallel data transfer over multiple channels with data order prioritization |
| US7277417B2 (en) * | 2003-04-29 | 2007-10-02 | Broadcom Corporation | Low power protocol for wireless terminal peer-to-peer communications |
| ATE491290T1 (de) * | 2003-06-12 | 2010-12-15 | Camiant Inc | Dynamische dienstablieferung mit topologie- discovery für kommunikationsnetzwerke |
| US6973052B2 (en) * | 2003-12-19 | 2005-12-06 | Motorola, Inc. | Hybrid power save delivery method in a wireless local area network for real time communication |
| US7656892B2 (en) * | 2005-09-30 | 2010-02-02 | Intel Corporation | Method and apparatus of multi-entity wireless communication adapter |
| US7938727B1 (en) * | 2007-07-19 | 2011-05-10 | Tim Konkle | System and method for providing interactive content for multiple networked users in a shared venue |
-
2004
- 2004-06-08 US US10/863,650 patent/US8214447B2/en active Active
-
2005
- 2005-05-23 EP EP05104359A patent/EP1605637A3/en not_active Withdrawn
- 2005-06-07 JP JP2005167514A patent/JP2006033806A/ja active Pending
- 2005-06-08 CN CN2005100761569A patent/CN1708023B/zh not_active Expired - Fee Related
-
2006
- 2006-04-12 HK HK06104429.7A patent/HK1084269A1/xx not_active IP Right Cessation
-
2011
- 2011-11-07 JP JP2011243520A patent/JP5383775B2/ja not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003008600A (ja) * | 2001-06-25 | 2003-01-10 | Nec Corp | データ収集方式および方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1605637A2 (en) | 2005-12-14 |
| JP2006033806A (ja) | 2006-02-02 |
| CN1708023A (zh) | 2005-12-14 |
| EP1605637A3 (en) | 2008-04-16 |
| US20050289224A1 (en) | 2005-12-29 |
| CN1708023B (zh) | 2011-06-29 |
| US8214447B2 (en) | 2012-07-03 |
| JP5383775B2 (ja) | 2014-01-08 |
| HK1084269A1 (en) | 2006-07-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5383775B2 (ja) | オーディオネットワークの管理 | |
| JP6921162B2 (ja) | 低遅延オーディオを提供するシステム、方法、装置および生産物 | |
| US8175289B2 (en) | Digital audio distribution network | |
| JP5049652B2 (ja) | 通信システム、データの再生制御方法、コントローラ、コントローラの制御方法、アダプタ、アダプタの制御方法、およびプログラム | |
| JP6234519B2 (ja) | オーディオ再生デバイスを制御するシステム、方法、装置および製品 | |
| JP4797123B2 (ja) | 高品質低電力のワイヤレスオーディオシステム | |
| US6907458B2 (en) | Digital multi-room, multi-source entertainment and communications network | |
| US6611537B1 (en) | Synchronous network for digital media streams | |
| EP1589699A2 (en) | Systems and methods for integrated control within a home entertainment system | |
| US20020188762A1 (en) | Data structure for an entertainment and communications network | |
| US20090058707A1 (en) | Dual mode remote control system | |
| JP2016513289A (ja) | オーディオコンテンツを事前準備する方法 | |
| JP2015526949A (ja) | 赤外線信号を提供する方法及び装置 | |
| US20230069230A1 (en) | Switching between multiple earbud architectures | |
| US10367593B2 (en) | Architecture for a wireless media system | |
| WO2002091596A2 (en) | Digital multi-room, multi-source entertainment and communications network | |
| US20020188752A1 (en) | Control messaging for an entertainment and communications network | |
| WO2017094494A1 (ja) | システム、制御端末、制御方法、およびプログラム | |
| US20030165154A1 (en) | Digital media networking and arbitration system and method | |
| US20120070019A1 (en) | Methods for addressing equipment in tree networks | |
| WO2005050944A1 (ja) | ネットワーク回線を用いたアナログ信号入出力システム | |
| US8190797B2 (en) | Automatic source concentrator for a multimedia system | |
| KR101582472B1 (ko) | 무선 오디오 재생 방법 및 이를 실행하는 오디오 소스 | |
| TW202324387A (zh) | 智慧設備控制方法、閘道設備和智慧設備控制系統 | |
| JP4696269B2 (ja) | ネットワーク回線を用いたアナログ信号入出力システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121225 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130108 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20130408 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20130411 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130610 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130903 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131001 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |