JP2020521410A - リアルタイムオーディオおよびデータを提供するためのシステムおよび方法 - Google Patents

Abstract

データを１つまたは複数のクライアントコンピューティングデバイスに配信するコンピュータ化された方法は、サーバコンピューティングデバイスが第１の時間が開始で、データストリームを受信すること、サーバコンピューティングデバイスがデータストリームを処理して処理されたデータストリームを生成すること、サーバコンピューティングデバイスがサーバコンピューティングデバイスと電子通信する無線ネットワークを介して処理されたデータストリームを１つまたは複数のクライアントコンピューティングデバイスに送信すること、１つまたは複数のクライアントコンピューティングデバイス上にインストールされたアプリケーションが処理されたデータストリームを解釈して１つまたは複数のクライアントコンピューティングデバイスによる使用のためにデータストリームをリカバリングすることを含む。第１の時間と第２の時間との間のレイテンシは１００ミリ秒未満である。

Description

本発明は、概して、無線ネットワークを介したオーディオなどのデータのリアルタイム配信の分野に関する。より具体的には、本発明は、無線ネットワークを介して１つまたは複数のクライアントコンピューティングデバイスにリアルタイムデータを提供するシステムおよび方法に関し、例えば、ネットワークアクセスポイント（「ＡＰ」）を介してモバイルリスニングデバイスを所持するライブコンサートの参加者に拡張オーディオを提供するシステムおよび方法に関する。

コンサートまたはスピーチなどの従来のオーディオイベント設定では、参加者はパブリックアドレス（「ＰＡ」）システムを介して会場においてオーディオをリスニングする。この設定を使用すると、リスナーに届く音質はＰＡシステムの品質および会場の特定の特性によって制限される。例えば、会場のサイズ、形状、および雨または突風などの気象条件に対する影響の受けやすさは、ＰＡシステムから送信されるオーディオ信号を劣化させる可能性がある。さらに、特定のリスナー、特に、オーディオソースから遠く離れたリスナーは、ステージで見るものと聴くものとの間に非同期性を感じることがある。これらの理由により、多くのリスナーのオーディオエクスペリエンスは最適とは言い得ない。

１つまたは複数のこれらの問題に対処しようとして失敗した試みは、いくつか存在する。例えば、特許文献１は、ヘッドフォンを介してリスナーに補足オーディオ信号を配信して、プライマリブロードキャスト信号の歪みおよび劣化を打ち消すシステムを説明している。オーディオ入力（例えば、ギター、キーボード、マイクフォンオーディオ）は、オーディオミキサーで連結される。オーディオミキサーは、処理されたオーディオ信号をプライマリサウンドシステムに出力する。次に、プライマリサウンドシステムは、プライマリオーディオ信号を（例えば、ＰＡシステムを介して）ブロードキャストし、補足オーディオ信号がＷｉ−Ｆｉを介して遅延してリスナーに送信される。オーディオ信号間の遅延は、例えば、リスナーの位置に基づいて、または電子測定によって決定される。

このようなシステムには、いくつかの欠点がある。第一に、補足オーディオ信号を使用してプライマリオーディオ信号の欠陥を打ち消す精度は、システムエラーを同時に考慮しつつ、異なるソースから発生する２つの複雑な波形を一致させることの固有の困難性によって少なくとも制限される。その結果、衝突音や「エコー効果」が聞こえることとなる。第二に、そのようなシステムは、参加者がステージで見るものと聴くものとの間の不一致を軽減しない。これまで、高いリスナートラフィックを処理しながら、大半のまたは全てのリスナーに高品質のオーディオエクスペリエンスをリアルタイムで提供できる信頼性の高いソリューションは、いまだ実現されていない。

米国特許第８９３８０７８号明細書

本発明は、コンサート会場でライブ演奏される音楽などのライブオーディオをリスニングするエクスペリエンスを向上させるためのシステムおよび方法を含む。非圧縮オーディオ信号（例えば、リニアパルス符号変調（「ＬＰＣＭ」）としてエンコードされる）などのライブオーディオは、リスナーのモバイルデバイスに、リアルタイム（例えば、ユーザデータグラムプロトコル（「ＵＤＰ」））を介したリアルタイムトランスポートプロトコル（「ＲＴＰ」）接続を使用して）でストリーミングされ、これにより、リスナーは、従来のＰＡシステムを介してではなく、自身のお気に入りのヘッドフォン（例えば、無線ヘッドフォン、有線ヘッドフォン、イヤホン、リナックス（Ｌｉｎｕｘ（登録商標））専用オーディオハードウェアとすることができる）でライブオーディオを聴取することができる。ストリーミングされたオーディオは、ライブパフォーマンスに対してレイテンシが低いため（例えば、約１００ミリ秒未満、または任意選択で、約５０ミリ秒以下、およびいくつかの例では、約２０ミリ秒以下）、リスナーには知覚されないか、ほとんど知覚されない。本発明は、多くの（例えば、いくつかの実施形態では、数千、数万、または理論的に無限の）リスナーが、高密度の参加者のいる会場で同時にリスニングすることができるように拡張可能である。従って、各リスナーは、コンサート会場でＰＡシステムまたはスピーカーを聴取するエクスペリエンスよりも優れたエクスペリエンスを楽しむことができる。

一態様では、本発明は、１つまたは複数のクライアントコンピューティングデバイスにオーディオを配信するコンピュータ化された方法を含む。この方法は、オーディオサーバコンピューティングデバイスが、第１の時間が開始で、ライブオーディオ信号を受信することを含む。この方法はまた、オーディオサーバコンピューティングデバイスが、ライブオーディオ信号を処理して、ライブオーディオ信号のデータ表現を生成することを含む。この方法はまた、オーディオサーバコンピューティングデバイスが、オーディオサーバコンピューティングデバイスと電子通信する無線ネットワークを介して、ライブオーディオ信号のデータ表現を１つまたは複数のクライアントコンピューティングデバイスに送信することを含む。この方法は、１つまたは複数のクライアントコンピューティングデバイスが、ライブオーディオ信号のデータ表現を解釈して、解釈済みのオーディオ信号を生成することも含む。この方法は、１つまたは複数のクライアントコンピューティングデバイスが、解釈済みのオーディオ信号を第２の時間が開始で、ユーザリスニングデバイスに提供することも含む。第１の時間と第２の時間との間のレイテンシは１００ミリ秒未満である。

いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは５０ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは２０ミリ秒未満である。いくつかの実施形態では、オーディオはリアルタイムコンサートオーディオであり、１つまたは複数のクライアントコンピューティングデバイスはコンサート参加者のスマートフォンを含む。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、オーディオを受信するためのスタンドアロンハードウェアを含む。いくつかの実施形態では、無線ネットワークは、ユニキャスト、マルチキャスト、およびブロードキャストデータ送信モードのうちの１つまたは複数をサポートする。いくつかの実施形態では、マルチキャストモードが有効化され、マルチキャストＩＧＭＰスヌーピングが無線ネットワークに対して無効化される。いくつかの実施形態では、無線ネットワークのビーコン間隔は、１０〜１００ミリ秒に設定される。いくつかの実施形態では、無線ネットワークが２．４ＧＨｚ帯域を使用する場合、無線ネットワークのマルチキャスト送信速度は、１Ｍｂ／ｓ〜５４Ｍｂ／ｓに設定され、無線ネットワークが５ＧＨｚ帯域を使用する場合、６ＭＢ／ｓ〜５４ＭＢ／ｓに設定される。いくつかの実施形態では、無線ネットワークのＤＴＩＭ間隔は１または２に設定される。いくつかの実施形態では、無線ネットワークは、低レイテンシデータ送信を可能にする追加機能を含み、追加機能は、マルチキャストトラフィックを再優先順位付けする機能、不要なトラフィックを無視する機能、クライアントの省電力モード（ＰＳＭ：Ｐｏｗｅｒ Ｓａｖｅ Ｍｏｄｅ）を無効化する機能、アクセス分離を有効化する機能、デフォルトゲートウェイアドレスを０．０．０．０としてＤＨＣＰを介して１つまたは複数のクライアントコンピューティングデバイスにアドバタイズする機能、サービス品質ヘッダ情報をクライアントコンピューティングデバイスに送信する機能、ＰＳＭに入る選択されたクライアントコンピューティングデバイスを無視する機能、確認パケットの受信（例えば、ＩＥＥＥ８０２．１１規格による）に失敗した結果としてデータパケットを再送信しない機能のうちの少なくとも１つを含む。

いくつかの実施形態では、ライブオーディオ信号のデータ表現は、１つまたは複数のデータパケットを含む。いくつかの実施形態では、無線ネットワークは、データパケット損失を軽減するために各データパケットの複数の複製を送信する機能を含む。いくつかの実施形態では、ライブオーディオ信号のデータ表現を作成することは、ＡＡＣ、ＨＥ−ＡＡＣ ＭＰ３、ＭＰＥ ＶＢＲ、アップルのロスレス（Ａｐｐｌｅ Ｌｏｓｓｌｅｓｓ）、ＩＭＡ４、ＩＭＡ ＡＤＰＣＭ、またはＯｐｕｓの圧縮コーデックのいずれか１つを使用することを含む。いくつかの実施形態では、オーディオサーバコンピューティングデバイスは、クライアントコンピューティングデバイスによって提供される位置情報を使用して、クライアントコンピューティングデバイスに配信されるオーディオミックスを最適化する（例えば、ＡＰとサーバ、またはクライアントコンピューティングデバイスとサーバ、またはＡＰとクライアントとの間の距離、または３つの距離の組み合わせに基づいて、ＡＰとサーバとの間の距離に基づく静的補正を追加することにより、１つまたは複数の個々のクライアントを補正しないことを決定することにより、ＡＰにおいてブルートゥースビーコンを使用して、基準点からの距離を特定するためのクライアントコンピューティングデバイスのマイクを使用して、または無線三角測量を使用することにより）。いくつかの実施形態では、解釈されるオーディオ信号は、エコー効果を回避するために周囲または環境のオーディオを考慮して最適化される。いくつかの実施形態において、１つまたは複数のクライアントコンピューティングデバイスに配信されるオーディオは、２つ以上の同時ライブストリーミングオーディオ信号を含む。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、ユーザ指定の基準に従って２つ以上の同時ライブストリーミングオーディオ信号をミキシングするように構成される。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、解釈済みのオーディオ信号を、１つまたは複数のクライアントコンピューティングデバイスのマイクロフォン機器によって提供されるオーディオとミキシングするように構成される。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、解釈済みのオーディオ信号を、１つまたは複数のクライアントコンピューティングデバイスのカメラ機器によって提供されるビデオと同期するように構成される。いくつかの実施形態において、１つまたは複数のクライアントコンピューティングデバイスには、１つまたは複数のソーシャルネットワーキング機能（例えば、記録されたサウンドまたはビデオをソーシャルメディアプラットフォーム上で共有する）を含むソフトウェアがインストールされる。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、ユーザのリスニングデバイスにオーディオ周波数の大部分を提供し、パブリックアドレスシステムは、２０Ｈｚ〜１０００Ｈｚの範囲のオーディオトーンを提供する。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは、１つまたは複数のクライアントコンピューティングデバイスによって手動または自動でバッファリングされる。

別の態様では、本発明は、リスナーにオーディオを配信するためのシステムを特徴とする。このシステムは、第１の時間が開始で、ライブオーディオ信号を受信し、ライブオーディオ信号をライブオーディオ信号のデータ表現に変換するように構成されたオーディオサーバコンピューティングデバイスを含む。オーディオサーバコンピューティングデバイスは、オーディオハードウェアインタフェース（例えば、マルチチャネルまたはシングルチャネルのオーディオハードウェアインタフェース）と、オーディオハードウェアインタフェースと電子通信するサーバコンピュータと、サーバコンピュータ上にインストールされた専用のソフトウェアとを含み、専用のソフトウェアは、ハードウェアドライバおよびメディア処理ソフトウェアを含む。システムはまた、オーディオサーバコンピューティングデバイスのネットワークハードウェアと電子的に通信し、ライブオーディオ信号のデータ表現を送信するように構成された無線ネットワークを含む。システムは、無線ネットワークを介してライブオーディオ信号のデータ表現を受信し、ライブオーディオ信号のデータ表現を解釈して、解釈済みのオーディオ信号を生成し、解釈済みのオーディオ信号を第２の時間が開始で、１つまたは複数のユーザリスニングデバイスに提供するように構成される。１つまたは複数のクライアントコンピューティングデバイスはそれぞれ、ハードウェア無線ネットワークインタフェースと、ライブオーディオ信号のデータ表現を解釈して、解釈済みのオーディオ信号を生成するように構成されたクライアントコンピューティングデバイス上にインストールされたオーディオアプリケーションとを含む。第１の時間と第２の時間との間のレイテンシは１００ミリ秒未満である。

いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは５０ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは２０ミリ秒未満である。いくつかの実施形態では、オーディオはリアルタイムコンサートオーディオであり、１つまたは複数のクライアントコンピューティングデバイスはコンサート参加者のスマートフォンを含む。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、オーディオを受信するためのスタンドアロンハードウェアである。いくつかの実施形態では、無線ネットワークは、ユニキャスト、マルチキャスト、およびブロードキャストデータ送信モードのうちの１つまたは複数をサポートする。いくつかの実施形態では、マルチキャストモードが有効化され、マルチキャストＩＧＭＰスヌーピングが無線ネットワークに対して無効化される。いくつかの実施形態では、無線ネットワークのビーコン間隔は、１０〜１００ミリ秒に設定される。いくつかの実施形態では、無線ネットワークが２．４ＧＨｚ帯域を使用する場合、無線ネットワークのマルチキャスト送信速度は、１Ｍｂ／ｓ〜５４Ｍｂ／ｓに設定され、無線ネットワークが５ＧＨｚ帯域を使用する場合、６ＭＢ／ｓ〜５４ＭＢ／ｓに設定される。いくつかの実施形態では、無線ネットワークのＤＴＩＭ間隔は１または２に設定される。いくつかの実施形態では、無線ネットワークは、低レイテンシデータ送信を可能にする追加機能を含み、追加機能は、マルチキャストトラフィックを再優先順位付けする機能、不要なトラフィックを無視する機能、クライアントのＰＳＭを無効化する機能、アクセス分離を有効化する機能、デフォルトゲートウェイアドレスを０．０．０．０としてＤＨＣＰを介して１つまたは複数のクライアントコンピューティングデバイスにアドバタイズする機能、サービス品質ヘッダ情報をクライアントコンピューティングデバイスに送信する機能、ＰＳＭに入る選択されたクライアントコンピューティングデバイスを無視する機能、確認パケットの受信（例えば、ＩＥＥＥ８０２．１１規格による）に失敗した結果としてデータパケットを再送信しない機能のうちの少なくとも１つを含む。

いくつかの実施形態では、無線ネットワークは、データパケット損失を軽減するために各データパケットの複数の複製を送信する機能を含む。いくつかの実施形態では、ライブオーディオ信号のデータ表現を生成することは、ＡＡＣ、ＨＥ−ＡＡＣ ＭＰ３、ＭＰＥ ＶＢＲ、アップルロスレス（Ａｐｐｌｅ Ｌｏｓｓｌｅｓｓ）、ＩＭＡ４、ＩＭＡ ＡＤＰＣＭ、またはＯｐｕｓの圧縮コーデックのいずれか１つを使用することを含む。いくつかの実施形態において、オーディオサーバコンピューティングデバイスは、クライアントコンピューティングデバイスによって提供される位置情報を使用して、クライアントコンピューティングデバイスに配信されるオーディオミックスを最適化する。いくつかの実施形態では、解釈されるオーディオ信号は、エコー効果を回避するために周囲または環境のオーディオを考慮して最適化される。いくつかの実施形態において、１つまたは複数のクライアントコンピューティングデバイスに配信されるオーディオは、２つ以上の同時ライブストリーミングオーディオ信号を含む。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、ユーザ指定の基準に従って２つ以上の同時ライブストリーミングオーディオ信号をミキシングするように構成される。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、解釈済みのオーディオ信号を、１つまたは複数のクライアントコンピューティングデバイスのマイクロフォン機器によって提供されるオーディオとミキシングするように構成される。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、解釈済みのオーディオ信号を、１つまたは複数のクライアントコンピューティングデバイスのカメラ機器によって提供されるビデオと同期するように構成される。いくつかの実施形態において、１つまたは複数のクライアントコンピューティングデバイスには、１つまたは複数のソーシャルネットワーキング機能を含むソフトウェアがインストールされる。いくつかの実施形態では、１つまたは複数のクライアントコンピューティングデバイスは、ユーザのリスニングデバイスにオーディオの大部分を提供し、パブリックアドレスシステムは、２０Ｈｚ〜１０００Ｈｚの範囲のオーディオトーンを提供する。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは、１つまたは複数のクライアントコンピューティングデバイスによって手動または自動でバッファリングされる。

別の態様では、本発明は、クライアントコンピューティングデバイス上でストリーミングオーディオを再生する方法を特徴とする。この方法は、クライアントコンピューティングデバイスを無線ネットワークに接続することを含む。この方法は、クライアントコンピューティングデバイス上にインストールされたモバイルオーディオアプリケーションを起動することも含む。モバイルオーディオアプリケーションは、（１）オーディオストリームに対応する第１の組のデータパケットをオーディオサーバコンピューティングデバイスから受信し、（２）第１の組のデータパケットを解釈して、第２の組のデータパケットを含む解釈済みのオーディオストリームを生成し、（３）解釈済みのオーディオストリームをバッファリングするように構成される。この方法はまた、クライアントコンピューティングデバイスとの電子通信により解釈済みのオーディオストリームをユーザリスニングデバイスに出力することを含み、解釈済みのオーディオストリームの第２の組のデータパケットの各オーディオパケットの出力は、対応するオーディオパケットがオーディオサーバコンピューティングデバイスに入力されてから１００ミリ秒以内に行われる。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは５０ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは２０ミリ秒未満である。

別の態様では、本発明は、オーディオシステムによって生成されるストリーミングオーディオ信号のトータルレイテンシを最小化するための方法を特徴とする。この方法は、以下のオーディオシステムコンポーネント：オーディオサーバのオーディオハードウェアインタフェース、オーディオサーバのオーディオハードウェアインタフェースドライバ、オーディオサーバアプリケーション、無線ネットワークハードウェアインタフェースドライバを含むオーディオサーバの無線ネットワークスタック、オーディオサーバの無線ネットワークハードウェアインタフェース、イーサネット（登録商標）無線ネットワーク、無線ネットワークアクセスポート、無線ネットワーク、モバイルデバイスのハードウェア無線ネットワークインタフェース、ハードウェア無線ネットワークインタフェースドライバを含むモバイルオペレーティングシステムの無線ネットワークスタック、モバイルクライアントアプリケーション、オーディオハードウェアインタフェースドライバを含むモバイルオペレーティングシステム、モバイルデバイスのオーディオハードウェアインタフェースのうちの１つまたは複数（例えば、各々の）のレイテンシを個別に最小化することを含む。上記のオーディオシステムコンポーネントの各々のレイテンシの合計は、１００ミリ秒未満（または、いくつかの例では、は５０ミリ秒未満、場合によっては、２０ミリ秒未満）とすることができる。

別の態様では、本発明はオーディオサーバを含む。オーディオサーバは、オーディオハードウェアインタフェースと、オーディオハードウェアインタフェースと電子通信するサーバコンピュータと、サーバコンピュータ上にインストールされたオペレーティングシステムと、サーバコンピュータ上にインストールされた専用のソフトウェアと、専用のソフトウェアは、オーディオハードウェアインタフェースドライバおよびメディア処理ソフトウェアを含んでおり、サーバコンピュータと電子通信する無線ネットワークハードウェアとを含む。オーディオサーバは、（１）オーディオサーバに到達するライブオーディオ信号と、（２）オーディオサーバと通信しているユーザのリスニングデバイスによるリカバリングされたライブオーディオ信号の再生との間の１００ミリ秒未満のレイテンシを生成するように構成されている。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは５０ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは２０ミリ秒未満である。

いくつかの実施形態において、システムは、イベント中にユーザが収集したソーシャルネットワーク上の写真、ビデオ、および他のインタラクションを含むコンテンツの閲覧を含んでイベントをユーザが再現できるようにする他の機能を提供することができる。いくつかの実施形態では、ユーザがテキストおよび／または音声を使用して会場周辺の友人および人々と「プッシュツートーク」方式で通信し、関与することができるか、または群衆内で互いを発見することができる機能が含まれる。いくつかの実施形態では、チケットを販売し、ユーザがモバイルアプリケーションでチケットを直接購入できるようにする会社と提携することにより、イベントの前に１人または複数人のリスナーがコンサートに参加することができる。いくつかの実施形態では、技術は、マークされた関心点を伴う会場の地図、イベントのスケジュール、現在再生されている音楽に関連する他のメタデータ、および他の重要な会場固有の情報など、イベント中の会場に関する情報を提供する。いくつかの実施形態では、ミキシング効果が、ユーザを周辺環境により深く関与させるか、または再生を中断させる技術的な問題の影響を緩和するために含まれる。いくつかの実施形態において、会場の外でのストリーミングおよび過去に記録されたパフォーマンスのリスニングが可能であり、ライブイベントに参加するリスナーを引き付けることを超えるようにすることができる。いくつかの実施形態では、ユーザがインターネットを介して世界中のどこからでもライブパフォーマンスをリスニングすること、または記録された過去のライブパフォーマンスをリスニングすることを可能にするサービスが提供される。いくつかの実施形態では、クライアントコンピューティングデバイスは、会場のＰＡシステムからほとんどの音をロックアウトする「インイヤーモニタ」として機能するヘッドフォンを含む。いくつかの実施形態では、「カスタムミキシング」をコンサート参加者のモバイルデバイスに記録し、コンサートパフォーマンスのビデオと同期させることができる。

別の態様では、本発明は、１つまたは複数のクライアントコンピューティングデバイスにデータを配信するコンピュータ化された方法を特徴とする。この方法は、サーバが、第１の時間が開始で、データストリームを受信することを含む。この方法は、サーバが、データストリームを処理して、処理されたデータストリームを生成することを含む。この方法は、サーバが、サーバと電子通信する無線ネットワークを介して、処理されたデータストリームを１つまたは複数のクライアントコンピューティングデバイスに送信することを含む。この方法は、１つまたは複数のクライアントコンピューティングデバイス上にインストールされたアプリケーションが、処理されたデータストリームを解釈して、１つまたは複数のクライアントコンピューティングデバイスによる使用のためにデータストリームをリカバリングすることを含む。第１の時間と第２の時間との間のレイテンシは１００ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは５０ミリ秒未満である。いくつかの実施形態では、第１の時間と第２の時間との間のレイテンシは２０ミリ秒未満である。

いくつかの実施形態では、処理されたデータストリーム内の全てのブロードキャストおよび／またはマルチキャストフレームの「追加データ（ｍｏｒｅ ｄａｔａ）」フラグが「真」に設定される。いくつかの実施形態では、トラフィック指示マップ（ＴＩＭ：Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍａｐ）内のマルチキャストフラグは、全てのビーコンに対して設定され、それにより、無線ネットワークを通過するブロードキャストトラフィックおよび／またはマルチキャストトラフィックのバッファリングを無効化する。いくつかの実施形態では、ＭＡＣプロトコルデータユニットアグリゲーションは、無線ネットワークに対して無効化される。いくつかの実施形態では、この方法は、ＤＴＩＭカウントおよびＤＴＩＭ間隔に対して無効な値を設定することを含む。いくつかの実施形態では、方法は、全てのブロードキャストフレームおよび／またはマルチキャストフレームに「音声キュー（Ｖｏｉｃｅ Ｑｕｅｕｅ）」を使用することを含む。いくつかの実施形態では、方法は、処理されたデータストリームの全てのブロードキャストフレームおよび／またはマルチキャストフレームに対してＤＳＣＰ値を４６に設定することを含む。いくつかの実施形態では、方法は、無線ネットワークのオペレータが、ネットワークアクセスポイントのＤＴＩＭ間隔を第１の値に設定すること、無線ネットワークのオペレータが、無線ネットワークのＤＴＩＭカウントを第２の値に設定すること、無線ネットワークが、設定されたＤＴＩＭ間隔を含むビーコンを送信すること、および／または、無線ネットワークが、マルチキャストデータストリーム又はユニキャストデータストリームの少なくとも一方を１つまたは複数のクライアントコンピューティングデバイスに送信することを含み、第２の値は第１の値より大きい。

いくつかの実施形態では、この方法は、クライアントコンピューティングデバイスが、プリセットされたＤＴＩＭ間隔よりも高いＤＴＩＭカウントを含むビーコンメッセージを受信することを含む。いくつかの実施形態では、各クライアントコンピューティングデバイスのインターネットおよび／またはネットワーク上の他のクライアントコンピューティングデバイスからの分離は、リアルタイムデータの低レイテンシ送信を達成するのに役立つ。いくつかの実施形態において、無線ネットワークは、他の全てのトラフィックを迂回させる（例えば、利用可能な場合、モバイルデバイスのＬＴＥネットワークに）。いくつかの実施形態では、１つまたは複数のドライバに変更を加えて、ＰＳＭを有効化および無効化するとともに、他の機能（例えば、マルチキャストおよび／またはブロードキャスト）を制御するための単一コマンドを通過させることを可能にする。いくつかの実施形態では、方法は、特定のタイプの無線ネットワークトラフィックを再優先順位付けすること、および／または無視することを含む。具体的には、確立されたモードで機能するかどうかをドライバが通知する特定のコマンド（例えば、「エコー１」や「エコー０」のような覚えやすいもの）によって呼び出すことができる専用のファイルをＡＰ上に作成することができる。いくつかの実施形態では、（例えば、ハードウェアレジスタ設定を変更することによって）「仮想キャリアセンス」の処理を無効化して、ＡＰに特定の不要なフレームおよび／または不要なトラフィックを無視させることができる。

別の態様では、本発明は、クライアントコンピューティングデバイスにデータを配信するためのシステムを含む。システムは、データストリームを受信し、データストリームを処理されたデータストリームに変換するように構成されたサーバを含む。サーバは、データストリームを受信するためのインタフェースと、データストリームを受信するためのインタフェースと電子通信するサーバコンピュータと、サーバコンピュータ上にインストールされたオペレーティングシステムと、サーバコンピュータ上にインストールされた専用のソフトウェアと、専用のソフトウェアは、ハードウェアドライバとデータストリーム処理ソフトウェアとを含んでおり、サーバコンピュータと電子通信するネットワークハードウェアとを含む。システムは、サーバのネットワークハードウェアと通信し、処理されたデータストリームを送信するように構成された無線ネットワークアクセスポイントをも含む。サーバでデータストリームを受信してから、無線ネットワークアクセスポイントで処理されたデータストリームを送信するまでのレイテンシが１００ミリ秒未満である。いくつかの実施形態では、レイテンシは５０ミリ秒未満である。いくつかの実施形態では、レイテンシは２０ミリ秒未満である。

別の態様では、本発明は、クライアントコンピューティングデバイス上でストリーミングデータを受信する方法を含む。この方法は、クライアントコンピューティングデバイスが、無線ネットワークアクセスポイントに接続することを含む。この方法は、クライアントコンピューティングデバイスが、クライアントコンピューティングデバイス上にインストールされたソフトウェアアプリケーションを起動することを含む。ソフトウェアアプリケーションは、（１）無線ネットワークアクセスポイントと電子通信するサーバから、データストリームに対応する第１の組のデータパケットを受信し、（２）第１の組のデータパケットを解釈して、第２の組のデータパケットを含む解釈済みのデータストリームを生成し、（３）クライアントコンピューティングデバイスが、解釈済みのデータストリームをバッファリングし、解釈済みのデータストリームをクライアントが使用可能な形式で出力するように構成され、解釈済みのデータストリームの第２の組のデータパケットにおける各データパケットを出力することは、対応するデータパケットがサーバに入力されてから１００ミリ秒以内（または、いくつかの実施形態では、５０ミリ秒以内、または、いくつかの実施形態では、２０ミリ秒以内）に行われる。

別の態様では、本発明は、ストリーミングデータストリームの連続性を維持しつつ、ストリーミングデータシステムによって生成されるストリーミングデータストリームのトータルレイテンシを最小化する方法を含む。この方法は、以下のストリーミングデータシステムコンポーネント：サーバハードウェアインタフェース、サーバハードウェアインタフェースドライバ、サーバアプリケーション、ネットワークハードウェアインタフェースドライバを含むサーバネットワークスタック、サーバネットワークハードウェアインタフェース、イーサネットネットワーク、無線ネットワークアクセスポート、無線ネットワーク、モバイルデバイスのハードウェア無線ネットワークインタフェース、ハードウェア無線ネットワークインタフェースドライバを含むモバイルオペレーティングシステムのネットワークスタック、モバイルクライアントアプリケーション、モバイルオペレーティングシステム、およびモバイルデバイスのハードウェアインタフェースのうちの１つまたは複数（例えば、各々の）のレイテンシを個別に最小化することを含み、上記のストリーミングデータシステムコンポーネントの各々のレイテンシの合計が約１００ミリ秒未満であり、任意選択で、約５０ミリ秒以下、または任意選択で、約２０ミリ秒以下である。

別の態様では、本発明はストリーミングデータサーバを含む。ストリーミングデータサーバは、ハードウェアインタフェースデバイスと、ハードウェアインタフェースデバイスと通信するサーバコンピュータと、サーバコンピュータ上にインストールされたオペレーティングシステムと、サーバコンピュータ上にインストールされた専用ソフトウェアと、ハードウェアインタフェースドライバとデータ処理ソフトウェアを含む専用ソフトウェアと、サーバコンピュータと通信するネットワークハードウェアとを含む。ストリーミングデータサーバは、（１）ライブデータストリームがストリーミングデータサーバに到達してから、（２）ストリーミングデータサーバと通信しているユーザデバイスによるリカバリングされたデータストリームの再生までの間の１００ミリ秒未満、または任意選択で、５０ミリ秒未満、または任意選択で、２０ミリ秒未満のレイテンシを生成するように構成される。

別の態様では、本発明は、低レイテンシデータストリーミング用にネットワークアクセスポイントを構成する方法を含む。この方法は、ネットワークアクセスポイントのオペレータが、ネットワークアクセスポイントのＤＴＩＭ間隔を第１の値に設定すること、ネットワークアクセスポイントのオペレータが、ネットワークアクセスポイントのＤＴＩＭカウントを第２の値に設定すること、ネットワークアクセスポイントが、設定されたＤＴＩＭ間隔を含むビーコンを送信すること、および／またはネットワークアクセスポイントが、マルチキャストデータストリームまたはユニキャストデータストリームの少なくとも一方を１つまたは複数のオーディオクライアントに送信することを含み、第２の値は第１の値より大きい。いくつかの実施形態では、ＤＴＩＭ間隔およびＤＴＩＭカウントの設定は、１つまたは複数の所定のドライバ設定を再設定するように構成された単一のユーザコマンドを呼び出すことにより達成される。

別の態様では、本発明は、ネットワークアクセスポイントと通信するクライアントが、ネットワークアクセスポイントから低レイテンシのデータストリームを受信する方法を含む。この方法は、クライアントが、ＤＴＩＭ間隔よりも高いＤＴＩＭカウントを含むビーコンメッセージを受信すること、クライアントが、ＤＴＩＭカウントをネットワークアクセスポイントによる誤動作の指標として解釈すること、および／または、クライアントが、ＤＴＩＭ間隔で指定された期間よりも長い期間の間、アクティブを維持して、オーディオクライアントがスケジュールどおりに省電力モードに入るのを防止することを含む。

別の態様では、本発明は、ストリーミングオーディオをエンドユーザに配信するためのシステムを含む。システムは、（１）ライブオーディオ信号を受信し、ライブオーディオ信号をライブオーディオ信号のデータ表現に変換するように構成されたオーディオサーバを含む。オーディオサーバは、オーディオハードウェアインタフェースと、オーディオハードウェアインタフェースと通信するサーバコンピュータと、サーバコンピュータ上にインストールされたオペレーティングシステムと、サーバコンピュータ上にインストールされた専用のソフトウェアと、専用のソフトウェアは、ハードウェアドライバとメディア処理ソフトウェアとを含んでおり、サーバコンピュータと通信するネットワークハードウェアとを含み、システムは、（２）オーディオサーバのネットワークハードウェアと通信して、ライブオーディオ信号のデータ表現を送信するように構成された、ネットワークアクセスポイントを含む無線ネットワークと、（３）無線ネットワークを介してライブオーディオ信号のデータ表現を受信するように構成されたオーディオクライアントとを含む。オーディオクライアントは、ハードウェア無線ネットワークインタフェースと、ハードウェア無線ネットワークインタフェースと通信するモバイルデバイスと、モバイルデバイス上にインストールされたオペレーティングシステムと、モバイルデバイス上にインストールされ、ライブオーディオ信号のデータ表現を解釈して、解釈済みのオーディオ信号を生成するように構成されたオーディオアプリケーションと、モバイルデバイスと通信するオーディオ再生ハードウェアとを含み、オーディオ再生ハードウェアは、解釈済みのオーディオ信号をエンドユーザ向けに再生するように構成されている。オーディオサーバによるライブオーディオ信号の受信と、オーディオ再生ハードウェアによる解釈済みのオーディオ信号の配信との間のレイテンシは、リスナーには知覚できないか、または、最小限に知覚され、例えば、約１００ミリ秒未満であるか、または任意選択で、約５０ミリ秒以下であるか、または、任意選択で約２０ミリ秒以下である。ネットワークアクセスポイントは、ＤＴＩＭ間隔がネットワークアクセスポイントのＤＴＩＭカウントよりも低い値に設定されるように構成される。

レイテンシの概念は、オーディオシステムに関連する既知の問題である。リスナーが知覚する全体的なレイテンシに寄与する可能性のある多くの側面が存在し、レイテンシを測定および／または定義する多くの既知の方法があり、その方法のいくつかは本明細書で説明されている。本明細書では、一般にレイテンシはアナログレイテンシを参照するものと理解することができ、アナログレイテンシは、サーバ（例えば、オーディオサーバ）のアナログデジタルコンバータの入力ポイントからクライアント（例えば、オーディオをリスナーに提供するためのクライアントコンピューティングデバイス）におけるデジタルアナログコンバータの出力ポイントまで測定される。

本発明はまた、より一般的に、データをリアルタイムで送信する（例えば、オーディオ送信を含むがこれに限定されない）ためのシステムおよび方法を含むことができる。そのような目的ための適合性に寄与する機能に関する詳細な説明が必要である。

ＩＥＥＥ８０２．１１標準は、指定された周波数帯域での無線ローカルエリアネットワーク（ＷＬＡＮ）コンピュータ通信を実施するための一連の技術仕様である。ＰＳＭはＩＥＥＥ８０２．１１標準の機能であり、ＰＳＭによりＡＰと通信するステーション（例えば、モバイルデバイスまたは他の無線ネットワークデバイスなどの、ＩＥＥＥ８０２．１１プロトコルを使用する機能を備えたデバイス）は、所定の非アクティブ期間の後に無線アクティビティを中断し、定期的に「起動」して、ＡＰが宛先のトラフィックがあるかどうかを確認する。ＰＳＭの目的は、ネットワーク上にステーションに有用な情報がない場合に、ステーションがバッテリ電力を節約できるようにすることである。ステーションがスリープである間、ＡＰはそのステーション専用の情報をバッファリングする。ステーションが起動してＡＰでチェックインすると、ＡＰはバッファ内にある有用な情報を配信する。次に、ステーションは、次の所定の起動時間までスリープ状態に戻る。定期的にスリープすることにより、ステーションは電力を節約することが可能である。ＡＰは、またＡＰに接続されている少なくとも１つのステーション（例えば、トラフィックを受信することになっているステーション）がＰＳＭに入ると直ちにトラフィック（例えば、ブロードキャストトラフィックおよび／またはマルチキャストトラフィック）のバッファリングを開始し、ＰＳＭで動作しているステーションが受信するはずのデータを失わないことを保証する。

従来のＰＳＭ動作は、Ｗｉ−Ｆｉネットワークを介してリアルタイム（低レイテンシまたは「ほぼリアルタイム」の）データストリームを受信しようとするモバイルデバイスで重大な問題が発生する可能性がある。モバイルデバイスがリアルタイムデータストリームの受信の試行中にＰＳＭに入ると、リアルタイムデータストリームの一部が失われ、送信にギャップが生じる可能性がある。データパケットの送信は、リアルタイムデータストリームに対して非常に頻繁に行われるため、モバイルデバイスは、リアルタイムデータストリームを受信するときにスリープする時間がない。さらに、データが受信されるまでに失われたデータは、過去のものとなり、関連性がなくなるため、データの再送信はオプションではない。例えば、リアルタイムデータストリームがリアルタイムでリスナーに配信されるコンサートオーディオに対応しており、データストリームが中断され再送信された場合、モバイルデバイスがデータストリームを受信してリスナーのためにオーディオを再生するまでに、リスナーがステージ上で見るものに対応するのが遅すぎて、リアルタイムストリーミングのポイントが失われる。

多くのクライアントデバイス（例えば、モバイルデバイス、および／またはｉＯＳ（登録商標）ソフトウェアを実行しているデバイス）は、情報がネットワークを介してクライアントデバイスに特にアドレス指定されていない場合、所定の時間後に、自動的に（例えば、チップ製造業者による）ＰＳＭに入るようにプログラムされている。以前は、この問題を軽減する１つの方法は、ＡＰが全てのクライアントデバイスに対して、それらデバイスに特にアドレス指定されたデータがあることを通知する頻度を増加させることであった（例えば、ブロードキャストアドレスにアドレス指定されるか、クライアントがマルチキャストにサブスクライブすることによって）。このソリューションは、ビーコン間隔を低い値（例えば、ＰＳＭしきい値、または製造業者がＰＳＭに入るために設定した時間）に設定し、トラフィック指示メッセージの配信（ＤＴＩＭ：Ｄｅｌｉｖｅｒｙ ｏｆ Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）間隔を１に設定することにより実現することができる。ビーコン間隔を省電力しきい値以下に減少させることにより、従来のネットワークで低レイテンシの送信を実現することができる。しかしながら、このアプローチは、ビーコンフレームの周波数が非常に多くの空間を消費するため、データストリーム自体および／または他の重要なトラフィックのためにほとんど残されないという欠点がある。

リアルタイムデータストリーミングに関してＰＳＭで発生する問題は、ブロードキャストモードとマルチキャストモードの両方に適用される。ブロードキャストモードでは、データパケットはＡＰに接続されている全てのステーションにアドレス指定される。従って、ＡＰに接続されたステーションがＰＳＭに入ると直ちに、全てのブロードキャストトラフィックがバッファリングされる。マルチキャストモードでは、データパケットは、特定のマルチキャストグループに関心があることを登録しているステーションにアドレス指定される。従って、マルチキャストグループに関心があることを登録したステーションがＰＳＭに入ると直ちに、このマルチキャストグループのトラフィックがバッファリングされる。ステーションはＰＳＭに関して完全な自律性を有し、ＩＥＥＥ８０２．１１標準は、上記のビーコン間隔およびＤＴＩＭ間隔以外のＰＳＭ動作に関して、ＡＰがステーションに影響を与えるメカニズムを含んでいない。残念なことに、これにより、１つのステーションの動作がＡＰに接続されている全てのステーション（例えば、潜在的に無限の数のステーション）に影響する可能性がある最弱リンクの問題が発生する。この理由およびその他の理由により、ブロードキャストおよびマルチキャストトラフィックは、通常、可能な範囲で無線ネットワーク上で回避または最小化される。この最小化の例として、マルチキャストパケットは、２Ｍｂｐｓから最大５４Ｍｂｐｓまで変化する最低の利用可能な伝送レートで送信される。

本発明は、ブロードキャストおよび／またはマルチキャストトラフィックに関連する上記の問題を回避する方法で、ブロードキャストを大幅に利用することにより、この従来の知識に反する。特に、本発明は、（例えば、以下で詳細に説明するようにＰＳＭを戦略的に無効化することによって）Ｗｉ−Ｆｉネットワークを介したリアルタイムデータストリーミングを含み、これは、例えば、コンサート会場でライブ演奏される音楽などのライブオーディオをリスニングするエクスペリエンスを向上させるために使用することができる。

より具体的には、本発明は、ＡＰのみを変更することによって、ＰＳＭを無効化することを可能にする多数の解決策を含む。いくつかの実施形態では、変更は、特定の無線ネットワークインタフェースコントローラ（ＷＮＩＣ）、例えば、ブロードコム（Ｂｒｏａｄｃｏｍ）によって製造されたＷＮＩＣに対してカスタマイズされる。いくつかの実施形態では、ステーションがＰＳＭに入るのを防止するために、以下の１つまたは複数の変更をＡＰに行わせることができる。

１． 全てのブロードキャスト／マルチキャストフレームの「追加データ」フラグを「真」に設定する。追加データフラグは、送信するフレームがさらに存在していることを示す。全てのフレームに対してフラグを有効にすることにより、ブロードコムＷＮＩＣが追加のフレームを待機しているときに約４０ミリ秒間ＰＳＭに入ることが防止される。これは、少なくとも１つのフレームが４０ミリ秒毎に送信されると、ステーションがＰＳＭに入らないことを意味する。この動作は、ＡＰがトラフィックをバッファリングするときの標準動作に似ているため、この変更は、ＩＥＥＥ８０２．１１標準に違反しない。ＰＳＭのためにバッファリングされたトラフィックはビーコンに続いて送信され、全てのフレームには、最後のフレームを除き、追加データフラグが設定される。従って、ステーションは、追加データフラグが設定されていないフレームを受信するまで、アウェイク状態を維持する。

２． ＤＴＩＭカウントおよびＤＴＩＭ間隔に対して無効な値を設定する。ＤＴＩＭカウントおよびＤＴＩＭ間隔の両方は、ＰＳＭ動作に直接関連している。値が無効な場合（例えば、ＤＴＩＭカウントがＤＴＩＭ間隔以上である場合）、ステーションは、「誤動作」する可能性のあるＡＰからのトラフィックを失わないことを保証するために、ＰＳＭに入らないことを選択することができる。これにより、例えばブロードコムＷＮＩＣがＰＳＭに入るのを防止する。

３． 全てのビーコンのトラフィック指示マップ（ＴＩＭ）においてマルチキャストフラグを設定する。このフラグは、全てのビーコンの後にブロードキャストフレームまたはマルチキャストフレームが続くことを示し、これにより、ステーションがＰＳＭに入るのを防止することができる。

４． ブロードキャストおよび／またはマルチキャストトラフィックのバッファリングを無効化する。この変更により、一部のステーションがＰＳＭで動作している場合でも、ＡＰがブロードキャストトラフィックおよび／またはマルチキャストトラフィックをバッファリングすることを防止する。これにより、ＰＳＭで動作しているステーションで深刻なパケット損失が発生するが、残りのステーションは、例えば、リアルタイムでバッファリングすることなく動作することが可能となる。

さらに、本発明は、フレームの即時送信を保証する（従って、レイテンシおよび／またはジッタを最小化する）ＡＰへの多数の変更を含む。
１． 全てのブロードキャストフレームおよび／またはマルチキャストフレームに対して「音声キュー」を使用する。音声キューは、管理フレームを除き、最高の優先度を有する。全てのブロードキャストフレームおよび／またはマルチキャストフレームに対して音声キューを使用すると、優先順位の低いトラフィックよりも先にブロードキャストフレームおよび／またはマルチキャストフレームが送信される。

２． ＭＡＣプロトコルデータユニットアグリゲーション（Ａ−ＭＰＤＵ：ＭＡＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ Ａｇｇｒｅｇａｔｉｏｎ）を無効化する。Ａ−ＭＰＤＵはネットワークスループットを向上させるが、フレーム送信を遅延させる可能性がある。Ａ−ＭＰＤＵを無効化することは、フレームが直ちに送信されることに役立つ。

従って、本発明は、ＰＳＭの下で動作する標準的なＷＬＡＮと比較して、ブロードキャストトラフィックおよび／またはマルチキャストトラフィックのレイテンシおよび／またはジッタの最小化を可能にする。ＰＳＭで動作している場合、ブロードキャストトラフィックおよび／またはマルチキャストトラフィックはバッファリングされ、ビーコンの後に送信される。ビーコン間隔に関する標準値は１００ミリ秒であり、ＤＴＩＭ期間に関する標準値は１である。これは、ブロードキャストトラフィックおよび／またはマルチキャストトラフィックが１００ミリ秒毎に送信されることを意味し、これは、０ミリ秒から１００ミリ秒の範囲でＰＳＭによってレイテンシが導入されることを意味する。また、これにより、〜１００ミリ秒までの瞬時パケット遅延変動（ＩＰＤＶ：Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｐａｃｋｅｔ Ｄｅｌａｙ Ｖａｒｉａｔｉｏｎ）が発生する（例えば、ＲＦＣ３３９３で説明されているようなジッタ）。

本発明のこれらおよび他の態様は、添付の図面および特許請求の範囲と併せて、本発明の以下の説明からより容易に理解されるであろう。

本発明の例示的な実施形態による、リアルタイムデータ（例えば、オーディオ）配信のための技術を示す概略フロー図である。 本発明の例示的な実施形態による、リアルタイムデータ（例えば、オーディオ）配信システムのシステムアーキテクチャの概略図である。 本発明の例示的な実施形態による、リアルタイムデータ配信システム用の追加のシステムアーキテクチャの概略図である。 本発明の例示的な実施形態による、リアルタイムデータ配信システムのための追加のシステムアーキテクチャの概略図である。 本発明の例示的な実施形態による、モバイルストリーミングアプリケーション（例えば、図示されるようなオーディオストリームプレーヤー）の詳細な概略図である。 本発明の例示的な実施形態による、リアルタイムデータ配信（例えば、オーディオ）用のサーバラックの概略図である。 本発明の例示的な実施形態による、接続され、かつリアルタイムデータ（例えば、オーディオ）を配信するように準備された図４Ａのサーバラックの概略図である。 本発明の例示的な実施形態による、ライブリアルタイムオーディオサーバを示すライブセットアップを示す図である。 本発明の例示的実施形態による、ライブオーディエンスおよび複数の無線ネットワークアクセスポイントを示すライブセットアップの表示である。

図１は、本発明の例示的な実施形態による、リアルタイムデータ（例えば、オーディオ）配信のための技術を示す概略フロー図１０である。コンピュータ化された方法を使用して、例えば、無線ネットワーク１４を介してサーバ１２から１つまたは複数のクライアントコンピューティングデバイス１６にデータ（例えば、オーディオ）を配信することができる。方法は、サーバ１２（例えば、オーディオサーバコンピューティングデバイス）によって、第１の時間（ｔ１）が開始で、ライブオーディオ信号を受信することを含むことができる。方法は、サーバ１２によりライブオーディオ信号を処理することを含み、それにより、ライブオーディオ信号のデータ表現を作成することができる。方法は、オーディオサーバによって、ライブオーディオ信号のデータ表現をオーディオサーバと電子通信する無線ネットワーク１４を介して１つまたは複数のクライアントコンピューティングデバイス１６に送信することを含むことができる。方法は、１つまたは複数のクライアントコンピューティングデバイス１６によって、ライブオーディオ信号のデータ表現を解釈して、解釈済みのオーディオ信号を生成することを含むことができる。方法は、１つまたは複数のクライアントコンピューティングデバイス１６によって、解釈済みのオーディオ信号を、第２の時間（ｔ２）が開始で、ユーザリスニングデバイスに提供することを含むことができる。第１の時間と第２の時間との間のレイテンシは、１００ミリ秒未満、または任意選択で５０ミリ秒未満、または任意選択で２０ミリ秒未満である。無線ネットワーク１４は、１つまたは複数の無線アクセスポイントによって提供することができる。各アクセスポイント（ＡＰ）は、同時に２つ以上のネットワークをサポートすることができる。

図２Ａは、本発明の例示的な実施形態による、リアルタイムデータ（例えば、オーディオ）配信システム１００のシステムアーキテクチャの概略図である。図２Ａは、例えば、上記の図１に示した技術の特定のより細かい詳細を示している。一般に、システム１００は、サーバ（例えば、オーディオサーバ）１０２、ネットワーク１０４（例えば、Ｗｉ−Ｆｉおよびイーサネットモジュールおよび少なくとも１つのＡＰを含む）、およびクライアントコンピューティングデバイス（例えば、オーディオクライアント）１０６を含む。システム１００へのオーディオ入力（例えば、通常ＰＡシステム上で増幅され、かつブロードキャストされる、ステージ機器により提供されるライブオーディオ信号）は、オーディオサーバ１０２に提供される。オーディオサーバ１０２は、信号をサンプリングし、任意選択で、信号をエンコードして、少なくとも１つのオーディオクライアント１０６にネットワーク１０４を介して送信する。オーディオサーバ１０２は、イーサネット接続により（ネットワーク１０４内に含まれる）少なくとも１つのＷｉ−Ｆｉアクセスポイント（「ＡＰ」）と通信する。各オーディオクライアント１０６は、オーディオアプリケーション１２６がインストールされた携帯電話などのモバイルデバイス１２２と、ヘッドフォンなどのユーザリスニングデバイス１４２とを含む。各ユーザは、自身のモバイルデバイス（例えば、モバイルデバイス１２２）を使用して専用のオーディオＷｉ−Ｆｉネットワーク１０４に接続し、オーディオアプリケーション１２６を起動して、リスニングを開始する準備をする。オーディオアプリケーション１２６は、Ｗｉ−Ｆｉネットワーク１０４を介してライブオーディオストリームを受信し、ライブオーディオストリームをバッファリングし、モバイルデバイスのオーディオシステム１４２にデータを供給する。従って、システム１００は、リアルタイムオーディオ（例えば、ステージで演奏される音楽）をユーザのヘッドフォンに送信するようにオーディオのストリーミングを可能にする。

図２Ａは、オーディオサーバ１０２のいくつかの詳細なコンポーネントを示している。例えば、オーディオサーバ１０２は、オーディオハードウェアインタフェース１０８（例えば、マルチチャンネルオーディオハードウェアインタフェースを含む）を含む。オーディオハードウェアインタフェース１０８は、サウンドカードを含むことができる。いくつかの例では、サウンドカードは、ＲＭＥ ＨＤＳＰｅ ＭＡＤＩサウンドカードまたはフォーカスライトスカーレット（Ｆｏｃｕｓｒｉｔｅ Ｓｃａｒｌｅｔｔ）サウンドカードなど、プロフェッショナルな低レイテンシのハイエンドサウンドカードである。いくつかの例では、サウンドカードは、パーソナルコンピュータ上の組み込みサウンドカードである。オーディオサーバ１０２は、オーディオハードウェアインタフェース１０８と電子通信するサーバコンピュータ１１０をも含む。サーバコンピュータ１１０は、オーディオおよびネットワーキングハードウェアの要求に対応することができる任意のシステムであり得る。サーバコンピュータ１１０には、オペレーティングシステム、例えば、高いスレッド優先度および／またはリアルタイム動作のために改良されたカーネルを備えたリナックス（Ｌｉｎｕｘ）ベースのオペレーティングシステム１１２をインストールすることができる。サーバコンピュータ１１０は、ハードウェアドライバ（例えば、ＡＬＳＡハードウェアドライバ）およびオーディオ処理ソフトウェア１１６を含む特別なソフトウェア１１４をインストールすることもできる。オーディオ処理ソフトウェア１１６は、ジャックオーディオ（Ｊａｃｋａｕｄｉｏ）（図示したもの）を含むことができ、これは、ビット深度およびサンプルレート、バッファ設定およびルーティングを構成するように使用することができるか、または同一または類似の機能に関する独自のソフトウェアを使用することができる。オーディオ処理ソフトウェア１１６は、ジーストリーマー（ＧＳｔｒｅａｍｅｒ）１１８も含むことができるか、または、同一または類似の機能に関する独自のソフトウェアを使用することができ、ジーストリーマー１１８は、リアルタイムトランスポートプロトコル上でＬ１６ＰＣＭ（各サンプルが二の補数表記で符号化された１６ビット符号付き整数として表されるＬＰＣＭ）オーディオデータをパケット化し、かつ送信することができる。オーディオサーバ１０２は、サーバコンピュータ１１０と電子通信するネットワークハードウェア１２０をも含むことができる。ネットワークハードウェア１２０は、標準イーサネット接続を介した少なくとも１０Ｍｂ／秒の通信が可能な任意のハードウェアを含むことができる。追加のネットワークトラフィックを可能にするために、１００Ｍｂ／秒または１０００Ｍｂ／秒が好ましい。このセットアップにおいて、オーディオサーバ１００は、ライブオーディオ信号を受信し、ライブオーディオ信号に基づいてストリーミングオーディオ信号を作成する（例えば、ライブオーディオ信号を、対応するライブオーディオ信号のデータ表現を含むＲＴＰパケットに変換する）ように構成される。

ネットワーク１０４は、オーディオサーバ１０２のネットワークハードウェア１２０と電子的に通信し、ストリーミングオーディオ信号をオーディオクライアント（例えば、オーディオクライアント１０６）に送信するように構成される。ネットワーク１０４は、非限定的な例として、ブロードコム（Ｂｒｏａｄｃｏｍ）のＢＣＭ４３６６システムオンチップ（「ＳｏＣ」）、またはコンペックス（Ｃｏｍｐｅｘ）のＷＬＥ３５０ＮＸ無線ラジオを備えたＡＰＵ２ ＰＣＢ（インテル（Ｉｎｔｅｌ）ｘ８６）に基づくハードウェア無線ネットワークインタフェースを備えたエイスース（ＡＳＵＳ）ＲＴ−ＡＣ５３００ルータとすることができる。ネットワーク１０４は、例えば、ユニキャスト、マルチキャストおよび／またはブロードキャストなどの１つまたは複数のルーティング方式をサポートすることができる。加えて、特定のファームウェアを使用して、ネットワーク１０４の特定のパラメータを調整して、低レイテンシ送信を可能にすることができる。このようなパラメータは、マルチキャストの有効化、マルチキャストＩＧＭＰスヌーピングの無効化、および／またはビーコン時間、ＤＴＩＭ間隔、および／またはマルチキャストレートの設定を含む。さらに、ネットワーク１０４の特定の追加機能は、低レイテンシ動作に関して有効化することができる。このような機能は、マルチキャストトラフィックを再優先順位付けする機能、不要なトラフィックを無視する機能、およびクライアントＰＳＭを無効化する機能を含む。これらの設定および機能は、ファームウェアまたは標準のＷｉＦｉドライバでは利用可能ではない。

ユニキャストルーティング方式では、全てのオーディオクライアント（例えば、オーディオクライアント１０６）が「セッション」を開始し、続いてオーディオサーバ１０２から直接個別のオーディオストリームを受信する。これにより、サーバ１０２およびネットワーク１０４にスループットに関して大きな負荷がかかる。このルーティング方式では、サーバの処理能力および利用可能な帯域幅によってスケーラビリティが制限される。マルチキャスト／ブロードキャストルーティング方式下では、データは１回のみ送信され、各オーディオクライアント（例えば、オーディオクライアント１０６）は同じストリームを受信する。このルーティング方式では、スループットは、一定であり、かつクライアントの数に依存しない。各ルーティング方式には、潜在的な長所および短所がある。例えば、高品質のステレオオーディオを複数のクライアントにストリーミングする機能は、ユニキャストルーティング方式によって多くのスループットを消費する可能性がある。この影響は、非常に大きなスケーラビリティの可能性があるマルチキャストまたはブロードキャストルーティング方式を使用して軽減することができる。

一方、従来のマルチキャストおよびブロードキャストルーティング方式は、低速なクライアントに潜在的に対応するためにオーディオクライアントへの伝送レートを抑制することができ、従って、さらに能力の高いクライアントにも影響を与える付加されたレイテンシを使用して機能する。また、この効果は、伝送レートがオーディオストリームのビットレートより低い場合、ライブストリームを不安定にし、付加的なレイテンシは発生しないが、頻繁に可聴エラーが発生する。他の実施形態では、「最低」速度は、全体のレイテンシが約５０ｍｓでも送信するものに設定することができる。例えば、マルチキャスト送信速度は、６〜５６Ｍｂ／ｓ（例えば、１２ＭＢ／ｓまたは２４ＭＢ／ｓ）の間で設定することができ、これは、マルチキャストがＰＳＭのクライアントに送信される場合でも十分に高速である。いくつかの実施形態では、使用される無線周波数は５ＧＨｚのスペクトルであり、信号対雑音比は非常に高い必要がある。最良の結果を得るには、他のＷｉＦｉ無線信号で占有されているチャネルを避ける必要がある。２．４ＧＨｚのスペクトルも使用することができるが、多数のソースからの無線干渉が、この範囲で望ましくない結果を引き起こす可能性がある。

いくつかの実施形態では、ＡＰによって設定される「ビーコン間隔」は低い値（例えば、１３ミリ秒と２６ミリ秒との間、または１０ミリ秒と１００ミリ秒との間）に設定される。いくつかの実施形態において、システムは、トラフィック情報メッセージの配信（「ＤＴＩＭ」；Ｄｅｌｉｖｅｒｙ ｏｆ Ｔｒａｆｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｅｓｓａｇｅ）を使用して、利用可能なマルチキャストデータがあることを全てのクライアントに通信する。いくつかの実施形態では、「ＤＴＩＭ間隔」は、１または潜在的にそれよりも低く設定される。この設定により、各ビーコンでＤＴＩＭメッセージが全てのクライアントに送信される。いくつかの実施形態では、「エアタイムフェアネス（Ａｉｒｔｉｍｅ Ｆａｉｒｎｅｓｓ）」は無効化される。この動作により、マルチキャストに追加のジッタおよびネットワークの不安定性を生じさせる、ネットワーク上の他のクライアントに対するエアタイムにＡＰが対応することが保証される。いくつかの実施形態では、８０２．１１ｎが排他的に使用される。いくつかの実施形態では、８０２．１１ａｃが排他的に使用される。いくつかの実施形態では、クライアント間の通信を排除することにより追加のネットワークトラフィックを最小化する「ＡＰアイソレーション」が有効化され、これは、ジッタを低減し、ネットワークの安定性を向上させる。いくつかの実施形態では、ダイナミックホストコンフィギュレーションプロトコル（「ＤＨＣＰ」：Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を介して全てのクライアントにアドバタイズされるデフォルトゲートウェイアドレスは、０．０．０．０である。アドレスがローカルネットワークの範囲内にないため、クライアントは、（インターネットを含む）他のネットワーク宛てのパケットをルーティングすることができず、これにより、クライアントがインターネット上のサーバにアクセスしようとするのが防止され、クライアントによって生成されるローカルトラフィックが最小化される。対応デバイスでは、これにより、このトラフィックが追加のネットワークインタフェース（例えば、ＬＴＥ無線）に迂回され、デバイスがインターネット接続を維持することが可能となる。いくつかの実施形態において、広域ネットワーク（「ＷＡＮ」：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）接続は無効化される。これにより、ＡＰの負荷が最小化され、ジッタが減少し、ネットワークの安定性が向上する。

いくつかの実施形態では、サービス品質（「ＱｏＳ」：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）ヘッダ情報（通常はマルチキャストパケットに含まれない）を送信することにより、クライアントがＰＳＭに入るのを防止し、かつクライアントに高優先度データを警告することを支援することができ、これにより、クライアントのデータの処理を向上させることができる。いくつかの実施形態では、クライアントのネットワークインタフェース上でＰＳＭを無効化する技術が使用される。例えば、ネットワークを介して信号を送信してクライアントのＰＳＭを無効化するか、またはクライアントがインストールされたソフトウェアを使用して自身でＰＳＭを無効化し得る。ネットワークに接続されると、クライアントデバイスは、データの送受信にＷｉＦｉ無線を必要としなくなった場合にＰＳＭに入る。マルチキャスト中、ＰＳＭが有効化される頻度によって、これは問題となる可能性がある。ブロードキャストまたはマルチキャストデータ送信中、ＰＳＭは、通常、個々のデータパケットの受信の間に開始される。この操作は、ビーコン間隔やＤＴＩＭ期間などの要素によって決定される。この操作は、データをバッファリングできる場合に役立つが、一定のリアルタイムのバッファリングされていないデータストリームを送信する場合、障害になる可能性がある（例えば、ＰＳＭに入るデバイスは、間隔が長すぎると信号を一時的にカットオフすることができる）。この操作を緩和する方法は、ビーコン間隔を非常に短い期間（例えば、２０ｍｓ未満）に短縮することを含む。この解決策は、ＡＰにいくつかの追加オーバーヘッド（例えば、デバイスごとではなく全体的なオーバーヘッド）を生じさせ、パケット送信の信頼性を低下させる可能性がある。ＰＳＭを無効化することにより、クライアントは無線を遮断せず、信号は中断されない。いくつかの実施形態では、上述のように「ＤＴＩＭ間隔」を１以下に設定することは、クライアント上でＰＳＭを無効化するのにも役立つ。

いくつかの実施形態では、ＡＰは、ＰＳＭに入るクライアントを無視するように構成することができ、これにより、ＰＳＭで動作するネットワーク全体の問題を軽減することができるが、１つのクライアントでもＰＳＭで動作する場合に、ＰＳＭで動作している全てのクライアントを犠牲にしてレイテンシが増加し、大量のパケット（「ＡＣＫ」）が欠落する。さらに、マルチキャストを使用すると、ＩＥＥＥ８０２．１１の肯定応答パケットの欠落により、パケットは再送信されない。このアプローチには利点および欠点がある。利点の１つは、ＡＣＫパケットに関して、クライアントの数に比例して直線的に増加して、ネットワークのスケーラビリティに大きく影響を与え得る追加のスループットが必要とされないことである。さらに、再送信されたデータがデッドラインまでに到着するための時間を確保するために、システムのレイテンシを増やす必要がある。１つの欠点は、失われたデータが可聴ノイズまたは歪みとして認識され得ることである。いくつかの実施形態では、全てのパケットの複数の複製の送信は、パケットの損失を軽減するために使用され、クライアントは、完全なストリームを受信するために、送信される複数の複製から１つのパケットのみを正しく受信する必要がある。このアプローチは、パケット損失を軽減し、クライアントが損失または破損したパケットデータを受信する複数の機会を与える。

高い信頼性を達成し、かつある程度のスケーラビリティを維持するために、本発明は、「マルチユニキャスト」ルーティング方式を使用し、それにより、各クライアントには、（例えば、ネットワーク内の各固有のアドレスを介して）別々のユニキャストストリームが配信される。マルチキャストは使用されないため、ネットワークの速度は調整されず、ＰＳＭはシステムパフォーマンスに影響を与えない。このルーティング方式の制限は、ＡＰが全てのクライアントに対して別のデータストリーム（パケットのセット）を送信し、ネットワークスループットがクライアントの数に比例して増加することである。最終的に、クライアントの数は、ネットワークのスループットによって制限される。いくつかのテストでは、典型的なハイエンドアクセスポイントが、１つの５ＧＨｚのＷｉ−Ｆｉ無線チャネルで約２０クライアントへのＬＰＣＭエンコード、ステレオ、１６ビット、４８ ＫＨｚ、オーディオストリームのストリーミングを処理することができることが示されている。ジッラス（Ｘｉｒｒｕｓ）ＡＰを使用する場合、パフォーマンスの低下またはレイテンシの増加（＞８０ｍｓ）が生じる前に、無線チャネル毎に最大２０のクライアントが達成された。マルチチャネルアクセスポイントを使用すると、この能力は、アクセスポイントが対応可能な無線チャネルの数にまで拡大することができる。例えば、４チャネルアクセスポイントは、マルチユニキャストルーティング方式で約８０のクライアントを処理することができる。

この方法の別の制限は、各個々のクライアントへのシーケンシャルな送信の性質である。各クライアントに個別のパケットを送信する必要があるため、ＡＰがパケットを受信してからＡＰが最後のクライアントにパケットをディスパッチするまでの遅延は、クライアントの数に比例して増加する。この影響は、伝送レートを増加させることによりある程度緩和することができる。また、ＡＰは各パケットの複製を任意の順序で全てのクライアントに送信することができるが、現在の実施では全てのパケットに関して、順序が同じとなることが保証されないため、ネットワークに追加のジッタを発生させる可能性がある。その結果、ＡＰあたりのクライアント数が多くても、低レイテンシを維持するのは困難である。さらに、マルチキャストルーティング方式とは異なり、マルチユニキャストルーティング方式では、クライアントの数に比例して増加するネットワークスループットの増加を犠牲にして再送信を可能にするＡＣＫにより全てのパケットを確認する必要がある。これにより、レイテンシおよび不安定性が増加する。

各オーディオクライアント１０６は、ネットワーク１０４を介してストリーミングオーディオ信号を受信するように構成され得る。各オーディオクライアント１０６は、無線接続１２４およびインストールされたオーディオアプリケーション１２６を有するモバイルデバイス１２２を含む。オーディオアプリケーション１２６は、ストリーミングオーディオ信号を解釈して、解釈済みのオーディオ信号を生成するように構成される。オーディオアプリケーション１２６は、ネットワーク（例えば、ネットワークソケット）からオーディオストリームを受信するように構成されたリアルタイムオーディオ接続１２８と、オーディオフレームを取得してデコードし、再生可能なオーディオを生成するＬ１６ＰＣＭデペイローダー１３０（または同様の要素）と、再生に必要とされる前に、ＲＴＰパケットから抽出されたオーディオフレームをバッファリングするためのジッタバッファ１３２と、クロックドリフトを補償し、かつ十分な数のオーディオフレームがバッファにバッファされることを保証して、システムの様々なコンポーネントによって導入されるジッタを補償し、これによりレイテンシが減少した状態でオーディオストリームとモバイルアプリケーションによるローカル再生との間の同期を確実にするように構成されたクロック同期１３４と、モバイルアプリケーションによって提供されるオーディオ信号を周囲の音（例えば、ＰＡシステムによって生成される音）に可聴的に整合させるための遅延調整器１３６と、オーディオストリーム内の欠落データを補間および／または補完するように構成されたエラー隠蔽ツール１３８と、クライアントのオーディオハードウェアインタフェースにストリーミングオーディオを配信するための高頻度のコールバック用に構成されたオーディオハードウェアバッファ１４０との機能を含むことができる。オーディオクライアントは、モバイルデバイスと通信するオーディオ再生ハードウェア１４２をも有する。オーディオ再生ハードウェア１４２は、エンドユーザのために解釈済みのオーディオ信号を再生するように構成される。

上記の設定を使用すると、オーディオ信号がシステムに提供される時間（例えば、ステージで再生される音楽のオーディオ信号表現がオーディオサーバに到達する時刻）と、対応するオーディオ信号がモバイルデバイスのオーディオハードウェアインタフェースによって出力される時間（例えば、ユーザが自身のヘッドフォンでライブ音楽を聴取する直前）との間のトータルレイテンシが減少する（ステージ機器のレイテンシは無視されることに留意され、ブルートゥース（登録商標）を使用するヘッドセットなど、付加的なレイテンシを追加し得る特定のヘッドセットによって追加される潜在的なレイテンシも同様に無視されることに留意されたい）。「トータルレイテンシ」は、さらに、オーディオ信号が通過しなければならない（従って、トータルレイテンシに寄与し得る）以下のシステムコンポーネント：オーディオサーバのオーディオハードウェアインタフェース、オーディオサーバのオーディオハードウェアインタフェースドライバ、オーディオサーバのオペレーティングシステム、オーディオサーバアプリケーション、ネットワークハードウェアインタフェースドライバを含むオーディオサーバネットワークスタック、オーディオサーバのネットワークハードウェアインタフェース、イーサネットネットワーク、ネットワークアクセスポイント、ネットワーク、モバイルデバイスのハードウェア無線ネットワークインタフェース、ハードウェア無線ネットワークインタフェースドライバを含むモバイルオペレーティングシステムのネットワークスタック、モバイルクライアントアプリケーション（安定した再生のための追加のバッファリングを含む）、モバイルオペレーティングシステム、モバイルデバイスのオーディオハードウェアインタフェースドライバ、モバイルデバイスのオーディオハードウェアインタフェースに関連する個々のレイテンシに分類することができる。いくつかの実施形態では、レイテンシと信頼性との間に根本的なトレードオフが存在する。トータルレイテンシが低下すると、遅延の許容範囲およびエラー処理時間も低下する。従って、最適なリスニングエクスペリエンスを生成するには、これら２つの考慮事項の間で適切なバランスをとる必要がある。

一般に、トータルレイテンシは、リスナーが、観察されたイベント（例えば、バンドが歌ったり楽器を演奏すること）の視覚的エクスペリエンスと、ショーに伴うオーディオを視聴することとの間の非同期を知覚しないか、または最小限にしか知覚しないように十分に短くする必要がある。いくつかのテストおよび実験では、ユーザは最大５０ミリ秒までのレイテンシを許容可能に発見することが示されているが、可能であれば、このレイテンシを約２０ミリ秒以下に低下させることが望ましい。例えば、キャロット（Ｃａｒｏｏｔ）、アレキサンダー（Ａｌｅｘａｎｄｅｒ）、ワーナー（Ｗｅｒｎｅｒ）、クリスチャン（Ｃｈｒｉｓｔｉａｎ）著、「ネットワーク・ミュージック・パフォーマンス：問題、アプローチ、および視点（Ｎｅｔｗｏｒｋ Ｍｕｓｉｃ Ｐｅｒｆｏｒｍａｎｃｅ−Ｐｒｏｂｌｅｍ、Ａｐｐｒｏａｃｈｅｓ ａｎｄ Ｐｅｒｓｐｅｃｔｉｖｅｓ）」（オンラインにて入手可能で２０１７年４月２０日アクセスしたページhttp://www.carot.de/Docs/MITGV_AC_CW.pdfを参照）。しかしながら、状況によっては、５０ミリ秒（例えば、約１００ミリ秒）を超えるトータルレイテンシが許容可能であり得る。例えば、音源から一定の距離を超えて着座しているリスナーの場合、付加的なレイテンシはそれほど問題にならない。例示的な計算として、音は１秒あたり約１１２５フィート（３４２．９メートル）で伝搬するため、ステージから１００フィート（３０．４８メートル）で受信した音は、当然８９ミリ秒のレイテンシを伴う。ユーザのヘッドフォンが周囲の音を隠すのに効果がないいくつかの例では、付加的なレイテンシが必要となり得る。いくつかの実施形態では、本発明は、コンサート参加者の位置情報を使用して、コンサート参加者に配信する最適なオーディオミックスを決定する。例えば、位置情報を使用して、コンサートの参加者に関するＰＡのレイテンシを決定することができる。さらに、位置情報を使用して、コンサート会場の物理的な形状によってコンサート参加者が知覚するオーディオの歪みを特定して相殺することができる。

システムのレイテンシは、システムのコンポーネント間（例えば、オーディオストリーミングサーバのオーディオハードウェアインタフェースとオーディオサーバアプリケーションとの間、オーディオサーバアプリケーションとモバイルクライアントアプリケーションとの間（ＲＴＰパケットのペイロード長）、モバイルクライアントアプリケーションとモバイルデバイスのオーディオハードウェアインタフェースとの間）でオーディオデータを渡すために使用されるバッファ長によって拘束される。バッファ長が長いほど、バッファを満たすのに十分なデータを待機する必要があることに関連してレイテンシが長くなる。逆に、バッファ長が短いほど、システム全体でバッファを通過する頻度が高くなり、システムの負荷が増加し、ひいては（バッテリ駆動のモバイルデバイスには望ましくない）消費電力が増大する。さらに、システムのトータルレイテンシは、パイプライン全体で使用される最長のバッファ（最弱リンク問題）によって拘束される。従って、システム全体に亘ってバッファサイズを一致させて、トータルレイテンシを改善することなく不必要な負荷を回避することが望まれる。

いくつかの実施形態において、オーディオサーバアプリケーションは、等しいチャンクでオーディオデータ、例えば、Ｙミリ秒毎にＸフレームのオーディオデータ（オーディオのＹミリ秒を表現）を受信する。それに対応して、オーディオサーバは、Ｘフレームのオーディオデータを含むパケット（例えば、ＲＴＰパケット）を作成し、そのパケットをネットワークを介してディスパッチする。理論的には、各クライアントアプリケーションは、Ｙミリ秒毎に１つのパケットのデータを受信し、データをデバイスのオーディオハードウェアインタフェースに直ちに送信する必要がある。しかしながら、現実の世界では、ジッタがシステム１００の異なるコンポーネント（例えば、ネットワーク１０４）によって生成される。ジッタは、推定周期信号の真の周期性からの逸脱として定義することができる。上述したように、オーディオクライアントアプリケーション１２６は、この現象を補償するためのジッタバッファ１３２を含む。より具体的には、オーディオクライアントアプリケーション１２６は、受信したＸフレームのデータをジッタバッファに付加し、データを要求されたとおりにデバイスのオーディオハードウェアインタフェースにＸフレームずつ供給することができる。いくつかの実施形態では、Ｘの値は２５６であるが、任意選択で、１２８、６４、３２または１６などの他の値をとることができる。現実の世界では、ジッタバッファのサイズは、システムの実際のジッタに依存し、かつ動的に調整することができる。

いくつかの実施形態では、例えば、送信機へのユーザの近接性の変化および／または異なるソースの電磁干渉によって生じるネットワークのパフォーマンスの変化により、動作中に、システムのパフォーマンスが経時的に変化し得る。いくつかの実施形態では、システムは、クライアントベース毎の予測不可能なパフォーマンス変化に動的に適応する。特定のクライアントのシステムパフォーマンスが低下した場合、再生の安定性が失われるのを防止するために、このクライアントのレイテンシを増加させることができる。これに対応して、特定のクライアントのシステムパフォーマンスが向上した場合、リスニングエクスペリエンスを最適化するために、このクライアントのレイテンシを減少させることができる。

いくつかの実施形態において、システムは、ユーザデータグラムプロトコル（ＵＤＰ）上のリアルタイムトランスポートプロトコル（ＲＴＰ）を使用する。しかしながら、当業者は、多数の同様のプロトコルを代わりに使用することができることを認識するであろう。いくつかの実施形態では、（三条項修正ＢＳＤライセンス下で配布される）リブレ（Ｌｉｂｒｅ）ライブラリを使用して、ＲＴＰパケットを解析し、ＲＴＰヘッダおよびオーディオデータを抽出する。いくつかの実施形態では、ゼロ挿入エラー隠蔽技術（ｚｅｒｏ ｉｎｓｅｒｔｉｏｎ ｅｒｒｏｒ ｃｏｎｃｅａｌｍｅｎｔ ｔｅｃｈｎｉｑｕｅ）を使用して、欠落データを補うことができる。いくつかの実施形態では、システムの故障モードの認識および診断を支援するために、報告メカニズムおよび手順を実施することができる。サーバのハードウェアのクロックが各クライアントのハードウェアのクロックと異なる周波数を有するいくつかの実施形態では、クロック速度のわずかな差が経時的に累積して、同期から外れることとなる。そのような実施形態では、各オーディオクライアントは着信オーディオストリームを分析し、オーディオストリームのサンプルレートに一致するように自身の再生速度を調整する。

ＰＡシステムまたは競合する周囲のオーディオがあるいくつかの実施形態では、周囲のオーディオも、ステージおよび／または別のスピーカーシステムからのリスナーの距離に関連している関連のレイテンシを有する。「エコー」効果を回避するには、システムからの出力が周囲の音と一致することが望ましい。ユーザを会場に配置し、場所に基づいて必要なレイテンシを決定する様々な方法などを含む、様々な手法を使用して、再生を同期させることができる。例えば、ユーザのヘッドフォンに配置されたマイクからの音を分析し、それに応じて必要なオフセットを決定することができる。

いくつかの実施形態では、本発明は、サービス品質について報告する機能を含む。各クライアントは、レイテンシ、ジッタバッファ長、欠落パケット、パケットの再順序付け、バッファアンダーラン、オーディオハードウェアインタフェースへのオーディオデータの提供におけるレイテンシ、および／または結果として生じる再生の停止を含む再生品質の特定のパラメータに関して（例えば、連続的、継続的、定期的に、かつ／または周期的に）監視することができる。サービスの特定の側面の品質を説明する詳細なデータは、ネットワークを介して会場のオーディオサーバに（例えば、再生を妨害しない方法で）報告することができる。いくつかの実施形態では、オーディオサーバは、中央品質管理を可能にするために、蓄積されたデータをインターネットを介して外部のグローバルサーバに伝達する。

本発明は、リスナーのエクスペリエンスを高めるいくつかの追加機能のうちの少なくとも１つを含むことができる。いくつかの実施形態では、別個のオーディオストリームを同時にストリーミングするとともに、ユーザが好みに応じて異なるストリームをミキシングすることを可能にするユーザインタフェースを提供するためのサポートを提供することができる。例えば、ユーザは、ユーザのリスニングデバイスのマイクからのオーディオ入力をストリーミングされたオーディオとブレンドして、オーディオイベントに参加するより個人的なエクスペリエンスを再現し得る。いくつかの実施形態では、アプリケーションは、ソーシャルネットワーキング機能、例えば、ライブパフォーマンスのビデオを記録すること、モバイルデバイスのマイクからの入力ではなく、ストリーミングされた高品質オーディオを同期させること、および適用可能なソーシャルネットワーク上の記録を共有することの機能を組み込むことができる。いくつかの実施形態では、アプリケーションは、例えば、イベント中にユーザが収集したソーシャルネットワーク上の写真、ビデオ、および他のインタラクションを含むコンテンツ全体を閲覧することにより、ユーザがイベントを再現することができるようにする他の機能を提供することができる。いくつかの実施形態では、ユーザがテキストおよび／または音声を使用して会場周辺の友人および人々と「プッシュツートーク」方式で通信し、関与することができるか、または群衆内で互いを発見することができる機能が含まれる。

いくつかの実施形態では、本発明は、会場に関するチケット販売および情報の提供に関する機能を含む。特に、本発明は、チケットを販売する会社と提携し、ユーザがモバイルアプリケーションでチケットを直接購入できるようにすることにより、イベントの前にリスナーを参加させることができる。いくつかの実施形態では、本発明は、マークされた関心点を有する会場の地図、イベントのスケジュール、現在再生されている音楽に関連する他のメタデータ、および他の重要な会場固有の情報など、イベント中の会場に関する情報を提供する。

いくつかの実施形態では、本発明により、ユーザは、ユーザリスニングデバイスのマイクロフォンからの入力をミックスインし、音量を調整することができる。このようなミキシング効果は、ユーザを周辺環境により深く関与させるか、または再生を中断させる技術的な問題の影響を緩和するために望ましいものとすることができる。いくつかの実施形態では、本発明は、会場の外でのストリーミングおよび過去に記録されたパフォーマンスのリスニングを可能にして、それによって、ライブイベントに参加するリスナーのみを引き付けることを超えるようにすることができる。いくつかの実施形態では、ユーザがインターネットを介して世界中のどこからでもライブパフォーマンスをリスニングすること、または記録された過去のライブパフォーマンスをリスニングすることを可能にするサービスが提供される。

いくつかの実施形態において、本発明は、会場のＰＡシステムからほとんどの音をロックアウトする「インイヤーモニタ（ｉｎ−ｅａｒ ｍｏｎｉｔｏｒｓ）」として機能するヘッドフォンを含む。いくつかの実施形態では、ユーザリスニングデバイスは、リスナーが受信する音の大部分を提供し、一方、ＰＡシステムは「インイヤーモニタ」によって減衰されない低周波トーンのみを提供する。「インイヤー」モニタのイヤーチップは、現場でカスタム成形することができる。いくつかの実施形態では、「カスタムミキシング」をコンサート参加者のモバイルデバイスに記録し、コンサートパフォーマンスのビデオと同期させることができる。そのような実施形態は、それ以外に利用できない高品質のオーディオを有利に提供する。システムは、パフォーマンス要件を継続的に満たしていることを確認するために、監視および維持することができる。

圧縮コーデック（ＡＡＣ、ＨＥ−ＡＡＣ ＭＰ３、ＭＰＥ ＶＢＲ、アップルのロスレス（Ａｐｐｌｅ Ｌｏｓｓｌｅｓｓ）、ＩＭＡ４（ＩＭＡ ＡＤＰＣＭ）またはＯｐｕｓなど）が使用されるいくつかの実施形態では、オーディオストリーミングサーバアプリケーションは、送信されるべきペイロードを作成する前にオーディオデータをエンコードすることもできる。サーバ１０２またはクライアント１０６のいずれかでハードウェアエラーを発生させることなく、バッファあたりのフレーム数（「ＦｐＢ」：Ｆｒａｍｅｓ ｐｅｒ Ｂｕｆｆｅｒ）設定を可能な限り低い値に正確に設定するために特別な注意を払うことができる。システム１００は低いＦｐＢ（特定のオーディオハードウェアインタフェースを使用して１６ＦｐＢ程度の低さ）で動作するが、１２８ＦｐＢ（２．７ミリ秒のＬＰＣＭエンコード、ステレオ、１６ビット、４８ ＫＨｚオーディオデータ）が、最適な設定とすることができる（例えば、ジャックオーディオ（Ｊａｃｋａｕｄｉｏ）で使用される）。これにより、サーバのオーディオハードウェアインタフェース１０８とクライアントのオーディオハードウェアインタフェース１４２との両方で、最小のレイテンシを維持しながら、最低のエラー数で、オーディオ信号をアナログからデジタルに、デジタルからデジタルにアナログに変換することができる。このＦｐＢ設定は、パケットのペイロードの長さを決定するものである。

いくつかの実施形態では、音の物理的特性により、ストリームオーディオは、空中を伝搬する音響音と比較して「早い」ように思われる場合がある。技術的には、ストリームオーディオは、ソースに対してより正確にタイミング調整されるが（例えば、パフォーマンスの視覚的要素により密接に一致している）、ソースによって生成されるノイズと競合し得る。この効果は、ＰＡまたはその他の増幅システムもその時点で使用されている場合、負側に増強される。このエコー効果を補償するために、バッファ遅延をアプリケーションで手動または自動で設定し、リスナーが両方のオーディオ信号を受信したときに、このタイミングを一致させるように支援することができる。

いくつかの実施形態では、レイテンシまたはレイテンシに関連する他の量を測定することが有益である。測定は、オーディオ処理が可能なコンピュータ、マルチチャンネルサウンドカードインタフェース（最小で２つの入力および２つの出力）、およびインパルス応答測定ソフトウェア（例えば、ＳＭＡＡＲＴ８）の機器を使用して行うことができる。最適な測定のために、ステレオ構成を使用することができる（４つの入力および４つの出力を使用）が、モノラル測定でも正確な結果を提供することができる。いくつかの実施形態では、測定のプロセスは６つの基本的なステップに従う。第一に、パッチケーブルを使用して、オーディオハードウェアインタフェースの少なくとも１つの出力を１つの入力に接続する。これにより、オーディオインタフェースの出力から入力への「ループバック」が作成される（これはソフトウェアではなく、パッチケーブルを使用して行う必要がある。その理由は、ソフトウェアのパッチ適用によって、予測不可能な追加のレイテンシが発生する可能性があり、ハードウェアのアナログデジタルコンバータまたはデジタルアナログコンバータによって導入されるレイテンシは考慮されないからである。）。第二に、基準信号（例えば、ピンクノイズ、ピンクスイープ、正弦波トーン）を生成し、オーディオインタフェースの複数の出力にルーティングする。この信号は、「ループバック」として使用される上記の指示において出力にルーティングされる。さらに、この信号は、オーディオサーバの入力を供給する少なくとも１つの他の出力にルーティングすることができる。第三に、パッチケーブルを使用して、追加の出力（単数または複数）をオーディオサーバの入力に接続する。これにより、システムを介して基準トーンが送信される。第四に、パッチケーブルを使用して、クライアントのオーディオ出力を測定オーディオインタフェースのオーディオ入力に接続する。これで、測定オーディオインタフェースに接続される少なくとも２本のケーブルが存在していることになる。第五に、インパルス応答測定ソフトウェアを使用して、「基準」入力を、上記の「ループバック」チャンネル（単数または複数）に設定する。また、「測定」入力を、クライアントデバイスのオーディオ出力によって供給されるチャネル（単数または複数）に設定する。第六に、インパルス応答測定ソフトウェアを使用して、「基準」チャネルと「測定」チャネルとの間のオーディオレイテンシの差を測定する。これにより、（実質的にリアルタイムの、パッチケーブルを介したオーディオの速度を測定する）「ループバック」と、ストリーミングオーディオパス（本明細書さらに参照されるシステムを通過するのに要する時間）との間のレイテンシ測定が形成される。データ伝送速度の測定は、エンドユーザにアナログ信号を配信するために必要なエンコード、デコード、および追加の処理時間を含んでいないため、エンドユーザが知覚するレイテンシと必ずしも一致しない。

いくつかの実施形態では、実際の「マルチキャスト」複製の効率により、ＡＰに接続するクライアントの理論上の最大数は無限である。これは、任意のＡＰに関して、サービスを提供できるクライアントの数が範囲によってのみ制限され、かつＡＰに関連付けられているクライアントの数ではないことを意味する。これにより、任意のイベント、特にクライアントの密度が高い場合（典型的なスタジアムや講堂スタイルのイベントの場合）にサービスを提供するために必要なＡＰの数が大幅に削減される。これにより、コストおよび管理オーバーヘッドが削減される。

さらに、そのような実施形態では、ネットワークアーキテクチャ全体をさらに最適化することができる。通常、送信元から宛先ＡＰまで、ＡＰにストリームを複製するために必要な多数のネットワークデバイス（ルーターおよびスイッチ）が存在する。通常、このネットワークは、「ツリー」として編成され、各ステージは、ストリームを一定数のダウンストリームデバイスに対して複製することができる。各ＡＰは、潜在的に無制限の数のクライアントにサービスを提供することができるため、このようなデバイスの数および「ツリー」の深さを大幅に削減することができる。いくつかの実施形態では、ストリーミングコンピュータは、イベント全体にサービスを提供する１つのＡＰのみに接続することができる。これにより、レイテンシが削減されるとともに（ツリー内の各スイッチレベルでレイテンシが加えられるため）、ネットワークアーキテクチャの観点からコストが削減される。いくつかの実施形態では、冗長情報の代わりに電波が作成される。そのような実施形態は、無限のスケーラビリティを提供し、オーバーヒア状態（ｏｖｅｒｈｅａｒｄ）をより低減することができる。

いくつかの実施形態では、クライアントコンピューティングデバイスによって提供される位置情報を使用して、（ｉ）ＡＰとサーバとの間の距離に基づいて静的補正を追加すること、（ｉｉ）個々のクライアントを補正せず、デバイスとサーバとの間の距離、ブルートゥースビーコン、距離を特定するためのデバイスのマイク、無線三角測量を補正することのうちの少なくとも１つを含んでクライアントコンピューティングデバイスに配信されるオーディオミックスを最適化する。いくつかの実施形態では、今日、イヤホンは、単にＰＡシステムを隔離する。

図２Ａは単なる例示的なセットアップであり、図２Ｂおよび図２Ｃは、サーバ、ＷｉＦｉネットワーク、およびクライアント間の基本構成の追加の可能性を提供するために示されている。図２Ｂおよび図２Ｃは、本発明の例示的実施形態による、リアルタイムデータ配信システムの追加のシステムアーキテクチャの概略図である。図２Ｂおよび図２Ｃは、当業者に容易に明らかである顕著な相違を有する類似のシステム要素を示す。図２Ｂは、図２Ａと同様のセットアップを示している。構成要素は、オーディオのみならず、より一般的にデータに適用される。図２Ｃは、（ｉ）サーバがマルチデータストリームシナリオを含み、（ｉｉ）ＷｉＦｉネットワークアクセスポイントが別のアクセスポイントにブロードキャストでき、これはクライアントにブロードキャストして、メッシュネットワークを形成することができるという顕著な変更を有する別の同様のセットアップを示している。

上記したように、ＰＳＭに入るデバイスは、本発明の機能を妨げる可能性がある。従って、本発明では、ＡＰまたはＷｉＦｉネットワーク内に直接施された変更によってＰＳＭを無効化することができる。例えば、ＡＰは、ＰＳＭをリモートで無効化するよう指示するメッセージを全てのクライアントデバイスにビーコンで送信するように構成することができる。本発明は、デバイスによるＰＳＭの無効化を許可しないｉＯＳを実行するデバイスに特に有益である。特に、全てのｉＯＳデバイスは、モバイルデバイスがＡＰが「誤動作」していることを感知した場合にＰＳＭが無効化となる「フェイルセーフモード」を有するチップセットを使用している。例えば、ビーコンパケットでは、ＤＴＩＭ間隔内の現在のポイントに対応するＤＴＩＭカウントを、ＤＴＩＭ間隔自体よりも高くなるように（例えば、手動でまたは自動的に）設定することができる。このようなシナリオは、クライアントデバイスには誤った計算が行われたように見える。クライアントデバイスは、認識された誤計算をＡＰの問題の兆候として解釈することができる。潜在的なデータを見逃さないために、ｉＯＳ（および潜在的に他の）クライアントデバイスは、通常よりも長い時間アクティブを維持し、ＰＳＭを事実上無効化する。

上記のアプローチを使用すると、リアルタイムデータストリームは、主に一方向（例えば、ＡＰからクライアントデバイスど）に流れる。一般に、Ｗｉ−Ｆｉネットワーキングは、システム上の全てのデバイス間の不偏な通信に基づいており、単一ソースからのデータの同時受信の必要性は、あまりない。マルチキャストとブロードキャストは、利用可能な通信時間の大部分またはほとんどを消費する有害な性質のため、ほとんどのシステムは以前はこの状況を回避するように設計されていた。現在のシステムは、現在のアーキテクチャの回避策に相当するものを作成し、１つのＡＰから１つまたは複数（例えば、多数）のモバイルデバイスへの本質的に一方向のリアルタイムデータストリームを作成する。

いくつかの実施形態では、ビーコンパケットは、（例えば、クライアントデバイスの「ウェイクアップ」期間中）ＡＰ内の無線のドライバを介して操作される。いくつかの実施形態では、ＰＳＭの他にも、ＡＰが１つまたは複数のクライアントデバイスにリアルタイムデータストリーミングを可能にするという目標を進めるための最適化が行われる。例えば、システムは、最も優先順位の高いトラフィックとなるように、マルチキャストおよびブロードキャストアドレス指定されたパケットを再優先順位付けすることもできる。このアプローチは、ユニキャストトラフィックが何よりも優先されるＡＰの従来の機能とは対照的である。従来、ブロードキャストおよびマルチキャストパケットは最も低い優先順位と見なされ、それに応じた扱いを受け、その他の重要でないトラフィックはＡＰによって無視される。そのため、クライアントデバイスがネットワークを介して通信しようとすると、ＡＰはそれを無視して送信を継続する。

いくつかの実施形態では、各クライアントのインターネットおよびネットワーク上の他のクライアントデバイスからの分離は、リアルタイムデータの低レイテンシ送信を達成するのに役立つ。デバイス間の通信は、貴重な通信時間を消費し、多くのデバイスが無線ネットワークに加わるため、特に問題になる可能性がある。クライアントの分離は、通常、ＡＰの設定を調整することにより有効にすることができる。同じネットワーク上の別々のＡＰ間で通信するクライアントの問題を軽減するために、「ブリッジ分離モード」を有効にすることができる。これは、サーバ上のブリッジに割り当てられたＶＬＡＮのネットワークを作成し、各ＡＰにＶＬＡＮ番号を割り当てることにより実現することができる。サーバは、ネットワーク上の各ＡＰを他の各ＡＰから分離し、かつＡＰのみをサーバに認識させることにより、各ＶＬＡＮを分離することができる。

上記の構成では、Ｗｉ−Ｆｉネットワークは、クライアントデバイスによる通信を制限する。例えば、リアルタイムデータストリームの実行中は、従来のインターネットは、最適に動作しない（または、いくつかの例では、まったく動作しない）。いくつかの実施形態では、システムは、他の全てのトラフィックを迂回させる（例えば、利用可能な場合、モバイルデバイスのＬＴＥネットワークに）。いくつかの実施形態において、システムは、ネットワーク上の多数の（例えば、無限に近い）クライアントデバイスを許可する。追加のクライアントデバイスがネットワークに接続してＩＰアドレスを取得すると、本質的なトラフィックがわずかに増加するが、ブロードキャストアドレスに送信されるパケットを再優先順位付けすると、これらの通信はストリーミングパケット間の小さなギャップに制限される。いくつかの実施形態では、上記のシステムは複数のネットワークを必要としない。単一のサーバは、上記したＡＰを使用して高度にスケーラブルなネットワークを作成することができる。信号は、いずれかのＡＰへの受信範囲によってのみ制限される。この範囲は、単一のＡＰおよびセクターアンテナを使用して、キロメートル単位まで拡大することができる。

いくつかの実施形態では、１つまたは複数のドライバに変更を加えて、ＰＳＭを有効化および無効化するとともに、他の機能（例えば、マルチキャストおよび／ブロードキャストの再優先順位付け、および／または特定のタイプのトラフィックを無視すること）を制御するための単一のコマンドを通過させることを可能にする。具体的には、確立されたモードで機能するかどうかをドライバ（例えば、無線ドライバ）に通知する特定のコマンド（例えば、「エコー１」や「エコー０」のような覚えやすいもの）によって呼び出すことができる専用のファイルをＡＰ上に作成することができる。いくつかの実施形態では、（例えば、ハードウェアレジスタ設定を変更することによって）「仮想キャリアセンス」の処理を無効化して、ＡＰに、特定の不要なフレームおよび／または不要なトラフィックを無視させることができる。

図３は、本発明の例示的な実施形態による、モバイルストリーミングアプリケーション（例えば、オーディオストリームプレーヤー）２００の詳細な概略図である。いくつかの実施形態では、モバイルストリーミングアプリケーション２００は、４つの主要なコンポーネント、着信ＲＴＰパケットをリスニングし、それらを処理する役割を果たすＲＴＰ接続部２０２と、バッファリングを管理する役割を果たすバッファリングコントローラ２０４と、再生のためにオペレーティングシステムにオーディオデータを供給する役割を果たすレンダーコールバック２０６と、前の３つのコンポーネント間を仲介し、それらの間でメタデータと共にオーディオデータを渡す役割を果たすオーディオストリームプレーヤー２０８とを含む。ＲＴＰ接続部２０２は、ネットワークソケット２１０（例えば、ＵＤＰソケット）を作成し、ＲＴＰパケットを受信するためにネットワークソケット２１０を正しく設定し、ＲＴＰヘッダおよびペイロード（承認されたフォーマットでエンコードされたオーディオデータからなる）からシーケンス番号フィールドおよびタイムスタンプフィールドの両方を抽出するために、リブレ（Ｌｉｂｒｅ）ライブラリ２１２を使用して受信したＲＴＰパケットを解析する役割を果たす。シーケンス番号は、パケットが欠落したか、または間違った順序で配信されたかどうかを判断するために使用される。また、シーケンス番号をタイムスタンプと関連付けて、オーディオストリーミングサーバがフレームを省略したか、またはフレームを複数回送信したかどうかを判断することができる。さらに、ＲＴＰヘッダの他のフィールドを使用して、パケットを検証することができる。着信ＲＴＰパケットで発見された問題は、ロギングサブシステム（図示せず）に報告する必要がある。このサブシステムは、開発中と導入後の両方で、システムのパフォーマンスのトラブルシューティングおよび監視の両方に使用される。

タイムスタンプを伴うオーディオデータは、ＲＴＰ接続部２０２のコンポーネントからオーディオストリームプレーヤー２０８のオーディオフォーマットコンバータ２１４に転送される。オーディオフォーマットコンバータ２１４は、着信オーディオデータを、クライアントがオーディオデータを処理するために使用される承認されたフォーマットに変換する役割を果たす（正確なフォーマットは、モバイルデバイスのハードウェアおよびオペレーティングシステムによって異なり得るが、フォーマットはＬＰＣＭエンコーディングのタイプとすることができる）。次に、タイムスタンプを伴う変換されたオーディオデータは、バッファリングコントローラ２１６に転送される。バッファリングコントローラ２１６は、タイムスタンプを使用して、着信オーディオデータが以前に受信したオーディオデータと重複しているか（これはオーディオストリーミングサーバが正しく動作しない場合に発生する可能性がある）、または以前に受信したオーディオデータと着信オーディオデータとの間に不連続性があるか（例えば、パケットの欠落、またはオーディオストリーミングサーバがフレームをスキップした結果として）を確認する役割を果たす。重複するデータは破棄され、不連続性はエラー隠蔽アルゴリズムにより補間される必要がある。結果的に得られたデータは、バッファ（例えば、オーディオバッファ）に格納される必要がある。

上記したプロセスは、アプリケーションがＲＴＰパケットを受信するたびにトリガーされ、かつアプリケーションの残りのコード（独立した実行スレッド）とは独立して非同期に実行され得る。着信ＲＴＰパケットの処理の実施は、アプリケーションがオペレーティングシステムからＲＴＰパケットを受信する時間と、対応する処理されたオーディオデータがバッファに配置される時間との間の間隔を最小化するために、可能な限り効率的である必要がある。間隔は、システムのトータルレイテンシの一部を構成する。同様に、間隔の変動はシステムのジッタに影響するため、実施形態は予測可能な時間で実行する必要がある。間隔の最大値は、システムの最小トータルレイテンシを拘束する。不確定な時間を要する処理は起動されない必要がある（例えば、システムコールを必要とする処理の結果として割り当てられたＣＰＵ時間の現在の量を発生させることで、これは、これらに限定されないが、メモリ割り当て、ロックの取得、Ｉ／Ｏ処理の実行、オブジェクティブシー（Ｏｂｊｅｃｔｉｖｅ−Ｃ）ランタイムとのインタラクションなどを含む。）。システムのパフォーマンス要件を満たすために、バッファは、単一のプロデューサと単一のコンシューマでスレッドセーフなロックフリーの循環バッファとすることができる。

オーディオデータをバッファに供給するネットワークスレッド（例えば、ネットワークスレッド２２０）と対称的に、オーディオデータをバッファからオーディオハードウェアインタフェースにオペレーティングシステムのレンダーコールバック２０６を介して供給する役割を果たすアプリケーションの残りのコード（例えば、レンダーコールバックスレッド２２２）とは独立して非同期で実行する別個の実行スレッドが存在することができる。レンダーコールバック２０６がリアルタイムスレッド優先度で実行されると、（リアルタイムプログラミングのデッドラインの意味で）強制的なデッドラインが設けられる可能性があり、デッドラインの欠落は重大なシステム障害と見なされる。その時点でレンダーコールバック２０６によって要求されるフレームの数は変更可能であり、より高い値は、利用可能になるのに十分な数のフレームを待つ必要があることに関連してレイテンシを増加させ、より低い値はレンダーコールバック２０６の頻度を増加させ、これは、データを返すために利用可能な間隔を減少させ、モバイルデバイス上の負荷を増加させ、従って電力消費を増加させる。例えば、レンダーコールバック２０６が１２８フレームを一度に、かつサンプルレート４８ｋＨＺで要求すると、約１２８／４８ｋＨＺ＝２．６６７ｍｓごとにレンダーコールバック２０６がコールされる。これは、レンダーコールバック２０６が２．６６７ｍｓ以内に２．６６７ｍｓのオーディオデータを返す必要があることを意味する。レンダーコールバック２０６が要求されたオーディオデータを時間通りに返さない場合、オーディオハードウェアインタフェースは出力を駆動するためのデータを使い果たし、ユーザが可聴無音として知覚する振幅ゼロの信号で出力を駆動することができる。さらに、出力信号の振幅および関連する高周波応答における段階的な変化の結果として、可聴グリッチを引き起こす可能性がある。この種の障害は、フレームをスキップするレンダーコールバック２０６として現れ、それらをロギングサブシステムに報告することができる。従って、システムのトータルレイテンシを減らすために実行のネットワークスレッド２２０に推奨されるパフォーマンス要件は、実行のレンダーコールバックスレッド２２２に関連している。

レンダーコールバック２０６は、オペレーティングシステムによって提供されるハードウェアバッファをバッファ２１８からのオーディオデータで満たし、そのオーディオデータをコーラーに戻す役割を果たす。ハードウェアバッファを満たす前に、バッファ２１８からの余分なオーディオデータを必要に応じて破棄する必要がある（例えば、レンダーコールバック２０６がフレームをスキップした場合）。バッファ２１８内に、ハードウェアバッファ全体を満たすのに十分なオーディオデータがない場合（バッファアンダーラン）、残りのオーディオデータは、エラー隠蔽アルゴリズムによって補間される必要があり、その後、ストリームと同期を保つために（そうしないと、レイテンシが増加する）、（到着が遅すぎたか、または到着しておらず、よって、ＲＴＰ接続部によって補間される）等価量の期限切れの着信オーディオデータがバッファから廃棄される必要がある。バッファアンダーランは、ロギングサブシステムに報告することができる。

モバイルストリーミングアプリケーションにおけるバッファ２１８は、再生を開始する前に、空にすることができる。ユーザが再生の開始を要求した場合、ジッタを補償することができるようにバッファ２１８内にある量のオーディオデータを蓄積するために（その結果、人工的なレイテンシが発生し得る）、再生を開始する前に、バッファ２１８が事前準備される必要がある。モバイルストリーミングアプリケーションは、システムがどのように動作しているかを認識し得ないため、再生を開始する前に、システムのパフォーマンスを調べることなく（これにより、ユーザが再生の開始を要求した時間と再生の開始時間との間に大幅な遅延が生じ得ることになる）、不必要なレイテンシを追加することなく再生を中断しないことを保証するために必要なバッファ長（臨界バッファ長）を認識していない可能性がある。従って、初期バッファ長に使用される値は、デフォルト値、会場固有のデフォルト値、または過去のシステムパフォーマンスに基づいた推定値である。

バッファ長は、フレーム数で表すことができる。しかしながら、全ての着信ＲＴＰパケットには同じ数のフレームが含まれている必要があるため、代わりに、パケットの数で初期バッファ長を表すことが望ましい。初期バッファ長がＲＴＰパケットに含まれるフレーム数の倍数でない場合、バッファの事前準備をファイナライズするときに、いくつかのフレームを廃棄する必要があり得る。初期バッファ長が決定されると、オーディオストリームプレーヤーは、バッファリングコントローラ２１６を初期化し（バッファ２１８は初期化中、事前準備されていないものとしてマークされる）、かつＲＴＰ接続部２０２およびレンダーコールバック２０６を初期化する。バッファリングコントローラ２１６は、バッファ長が初期バッファ長に達する前に、無音（ゼロの値を持つ全てのフレーム）を表すオーディオデータを返すことができる。初期バッファ長に達すると、バッファリングコントローラ２１６は、バッファ２１８内の余分なデータ（もしあれば）を破棄し、バッファ２１８を事前準備完了としてマークすることができる。次に、オーディオデータが、バッファ２１８からレンダーコールバック２０６に返され始める。バッファ２１８は、再生が停止するまで事前準備状態を維持することができる。再生が停止すると、バッファ２１８の残りのオーディオデータは破棄され、バッファは事前準備されていないものとしてマークされる。

いくつかの実施形態において、システムは、クロックドリフトを考慮し、クロックドリフトを補償するための手段を実施する。全てのハードウェア電子時計は、周波数がわずかに異なるため、バッファ２１８からの読み出しおよびバッファ２１８への書き込みの頻度が等しくないため、オーディオを受信するクライアントのレイテンシは、経時的にドリフトする。モバイルデバイスのクロックがオーディオストリーミングサーバのクロックよりも高い周波数を有する場合、レイテンシおよびバッファ長が経時的にわずかに増加し、最終的にバッファ２１８がオーバーフローする可能性がある。それ以外に、モバイルデバイスのクロックがオーディオストリーミングサーバのクロックよりも低い周波数を有する場合、レイテンシおよびバッファ長は経時的に減少し、バッファ長が特定のバッファ長を下回ると、再生が中断し始める。

動的サンプルレート調整（「ＤＳＲＡ」：Ｄｙｎａｍｉｃ Ｓａｍｐｌｅ Ｒａｔｅ Ａｄｊｕｓｔｍｅｎｔ）は、バッファ長を所望のバッファ長（即ち、レイテンシ）に一定に保つことを目的としている。バッファオフセットは、バッファ長から所望のバッファ長を減算したもの（バッファ長−所望のバッファ長）として定義することができる。バッファオフセットは、常に可能な限りゼロに近づける必要がある。バッファオフセットの正の値は、バッファ内に所望のバッファ長よりも多くのフレームが存在することを示す。この場合、モバイルデバイスの再生速度を上げる必要がある。負のバッファオフセットは、バッファ内に所望のバッファ長より少ないフレームが存在することを示す。この場合、モバイルデバイスの再生速度を下げる必要がある。ＤＳＲＡは、モバイルデバイスの再生速度を操作することにより、常に、バッファオフセットを可能な限りゼロに近くに維持するように設計されたフィードバック制御システムである。

バッファ長の測定は、ジッタによって生じる予測不可能性を考慮した動的なプロセスである。瞬間的なバッファ長は、受信したフレームの数から再生したフレームの数を減算したもの（受信したフレーム−再生したフレーム）として定義することができる。受信したフレーム数および再生したフレーム数の両方は、対応するタイムスタンプに基づいて計算することができる（最後のタイムスタンプ＋最後に受信または要求したフレーム数−最初のタイムスタンプ）。また、タイムスタンプのオーバーフローの可能性を考慮する必要がある。しかしながら、オーディオデータがバッファに書き込まれるか、バッファから読み出されるたびに値が変化するため、瞬間的なバッファ長の値は不安定である。

クロックドリフトのないシステムでバッファ長がどのような挙動を示すかを考慮することは有益である。再生が開始されると、バッファ長は初期バッファ長に等しく、レンダーコールバック２０６は直ちにバッファ２１８からのオーディオデータの消費を開始するため、瞬間的なバッファ長は減少する。ある時点で、新たなオーディオデータが到着し、瞬間的なバッファ長が最終的に初期バッファ長に到達する。瞬間的なバッファ長は、ある値と初期バッファ長の値との間で変動する。従って、「スライディングウィンドウアルゴリズム」を使用して、直前に発生した瞬間的なバッファ長の最大値を発見することができる。ウィンドウの幅は、測定時の応答性を確保するために可能な限り短くする必要があるが、信頼性の高い測定値を提供するためには、最長変動の期間の少なくとも２倍にする必要がある。瞬間的なバッファ長の最大値または最小値を発見することができるように、操作の前後の値の両方を調べることにより、バッファへの書き込み時またはバッファからの読み出し時のみの瞬間的なバッファ長を測定することで十分である。この種のバッファ長の測定は、量子化ノイズの影響を受けるため、そのノイズを除去する必要がある。

ＤＳＲＡには、バッファオフセットに基づいて再生速度調整の範囲を決定するための伝達関数（ｔｒａｎｓｆｅｒ ｆｕｎｃｔｉｏｎ）が必要である。全てのオーディオ受信クライアントのシステムのパフォーマンスは、他の要因の中でも特に、電磁干渉の変化を含む環境における変化の結果として経時的に変化する。その結果、一定のバッファ長を有することは、一定のバッファ長が時間の大部分において高すぎるかまたは低すぎるかのいずれかであるために非実用的であり、その結果、冗長レイテンシが追加されるか、または最適でない再生品質がもたらされる。動的バッファリング調整（「ＤＢＡ」：Ｄｙｎａｍｉｃ Ｂｕｆｆｅｒｉｎｇ Ａｄｊｕｓｔｍｅｎｔ）は、臨界バッファ長を決定し、その臨界バッファ長に基づいてＤＳＲＡに対する所望のバッファ長を計算することを目的としている。ＤＢＡは、ＤＳＲＡの拡張機能であり、かつＤＳＲＡ上に構築される。ＤＢＡは、最大値に加えて、スライディングウィンドウアルゴリズムによって瞬間的なバッファ長の最小値を測定する必要がある。瞬間的なバッファ長の最小値および最大値の両方に基づいて、瞬間的なジッタの値は、瞬間的なバッファ長の最大値から最小値を減算することによって計算することができる（最大の瞬間的なバッファ長−最小の瞬間的なバッファ長）。

別のスライディングウィンドウアルゴリズムを使用して、直近の過去に発生した最大のジッタ（最悪のシナリオ）を計算することができる。ウィンドウの幅に関して適切な値を選択することは、バッファアンダーランの可能性と可能な限り最小のレイテンシを提供することとの間の妥協の問題である。ウィンドウの長さが比較的短い場合、オーディオ受信クライアントは、ジッタが減少した後、レイテンシを比較的迅速に低下させようとするが、これは、ジッタが再度増加した場合に、バッファアンダーランを引き起こす可能性がある。反対に、ウィンドウの幅が比較的長い場合、オーディオ受信クライアントは、ジッタの減少が一時的なアーティファクトとなる可能性を低くするために、レイテンシを減少させながら、より長く待機することとなる。より形式的には、臨界バッファ長は、最小の瞬間的なバッファ長がゼロ未満（バッファアンダーラン）にならないようにする最小バッファ長として定義することができる。欠落パケットはジッタと見なすことができないため、欠落パケットの結果である瞬間的なバッファ長の最小値を除外することが望ましい。所望のバッファ長は、臨界バッファ長に安全マージンバッファ長を加えたものとして定義できる。その設計の結果、ＤＢＡは、ユーザが知覚できない方法で再生の連続性を失うことなく、レイテンシを増減することが可能となる。

ジッタが経時的に徐々に増加する場合、ＤＢＡは、安全マージンバッファ長があるため、（変化の速度が十分に遅い場合）バッファアンダーランが発生する前に、ジッタを検出することが可能である。ＤＢＡは、再生速度を低下することにより、より高いジッタを補正するために余分なレイテンシを導入しようとすることができる。通常、再生速度の調整はピッチの可聴変化を回避するために大幅に制限されるが、いくつかの例では、可聴ピッチの変化を犠牲にして、バッファアンダーランおよびその結果として生じる再生の不連続を防止するために、再生速度を劇的に減少させることが有益である。

バッファアンダーラン、パケットの欠落、またはレンダーコールバック２０６のフレームのスキップが原因で再生の連続性が途切れた場合、再生の品質に実質的な影響を与えることなくステップレイテンシ変更（「ＳＬＣ」：Ｓｔｅｐ Ｌａｔｅｎｃｙ Ｃｈａｎｇｅ）を実行する可能性がある。ＳＬＣは、レイテンシを増加させるために無音の余分なフレームをストリームに挿入することによって、または再生が停止したときのレイテンシを低減するためにバッファ２１８からいくつかのフレームを破棄することによって動作する。ＳＬＣは、レイテンシが突然増加した場合にレイテンシバックオフ（「ＬＢ」：Ｌａｔｅｎｃｙ Ｂａｃｋｏｆｆ）を実施するのに最も有用である。ＬＢを使用すると、レイテンシが調整されるまで、ユーザは複数の中断（スタッタリング（ｓｔｕｔｔｅｒｉｎｇ））を経験するのではなく、再生時に１つの長い中断を経験することになる。

図４Ａは、本発明の例示的な実施形態によるリアルタイムデータ（例えば、オーディオ）配信のためのサーバラック４００の図である（例えば、図２Ｂで以前に示された単一データストリーム概略図のライブ実施形態を示す）。サーバラック４００は、サーバ４０２、オーディオインタフェース４０４、ネットワークスイッチ４０６、およびＸＬＲ入力（例えば、Ｌ／Ｒオーディオソース）４０８を含む。図４Ｂは、本発明の例示的な実施形態による、接続され、かつリアルタイムデータ（例えば、オーディオ）を配信するように準備された図４Ａのサーバラックの概略図である。図４Ｂは、ライブオーディオイベントの状況で本発明を実施するために図４Ａの要素と特定の他の要素との間で行われた特定の電気接続を示している。第一に、音源からのオーディオ入力は、図示されているポートに流れる。第二に、図に示すように、オーディオがデジタル化され、ＵＳＢを介してサーバに送信される。第三に、図に示すように、サーバは、パケット化されたデータ（例えば、オーディオデータ）をネットワークスイッチに転送する。第四に、ネットワークスイッチは、ネットワークアクセスポイントにデータを送信する。

図５は、本発明の例示的な実施形態によるライブリアルタイムオーディオサーバを示すライブセットアップ５００の表示である（例えば、図２Ｂで以前に示された単一データストリーム概略図のライブ実施形態を示す）。図５は、サーバコンピュータ５０２、複数のオーディオインタフェース５０４、５０６、５０８、５１２、５１６、５２４、サーバ５１０、ネットワークスイッチ５１４、５２２、および冗長サーバラック５２０を含む。

図６は、本発明の例示的実施形態による、ライブオーディエンスおよび複数の無線ネットワークアクセスポイント６０２を示すライブセットアップ６００の表示である。図示されているように、それぞれがクライアントコンピューティングデバイスを携帯している数千人の聴衆が、クライアントコンピューティングデバイスを介してショーを視聴している。例えば、手前にいる個人６０４は、ヘッドフォン６０６を介してコンサートを聴いている。

上記の技術は、オーディオビジュアルデータ、センサーデータ、アプリケーションデータ、およびその他のデータの送信を含むアプリケーションを含む、様々な産業に亘る多くの用途がある。これらは、低レイテンシおよび／または低ジッタ（例えば、標準のＷＬＡＮよりも最大１００ミリ秒短い）で多数のクライアントに送信される少量のデータを必要とするか、または少量のデータから恩恵を受けるシステムに特に適している。本発明はまた、データ送信が頻繁かつ周期的である用途に特に適している。レイテンシおよび／またはジッタが１００ミリ秒減少すると、同期を必要とするシステムに大きな影響を与える。例えば、人間の場合、オーディオとビジョンとの間の同期がとれていないとして、オーディオビジュアルコンテンツを視聴する場合に、レイテンシが知覚される。これにより、無線センサーネットワークおよびモノのインターネットなど、ＷＬＡＮを介して（特に、同期目的で）通信する必要がある分散システムに特に適している。いくつかの非限定的な事例を以下に詳細に説明する。

Ａ）ゲーム。本発明は、ゲーム目的のために多数のクライアントへのデータの同時送信を可能にする。例えば、クライアントデバイスがビンゴホールの中央ネットワークサーバに接続され、数字および文字が呼び出されると、サーバがクライアントデバイスをリアルタイムで更新する。他の例では、ＬＡＮゲームでは、クライアントアプリケーションが最小限のレイテンシで少量のデータを通信し、全てのプレーヤーが均一なエクスペリエンスを確保することが要求される。従来、レイテンシの数値は６０ミリ秒以上であるが、競技ゲームが普及するにつれて、３０ミリ秒未満のレイテンシの必要性が明らかになった。

いくつかの実施形態では、本発明を使用して、ゲームにおけるレイテンシを劇的に低減することができる。このようなシナリオでは、クライアントデバイス（例えば、電話、ラップトップ、またはゲームコンソール）は、必要なゲームサーバプロセスと共に本発明を実行するサーバと通信するネットワークに接続できる。サーバは、クライアントから報告されたデータを利用することができるのみならず、クライアントデバイスに情報をブロードキャストすることができる。本発明はシステムのスケーリング能力を向上させるので、プレーヤーの数（通常は６４人に制限される）を１００人以上に増加させることが可能となる。

Ｂ）公共／緊急ブロードキャストシステム。ネットワークＡＰは、コンテンツのプラットフォームおよび緊急ブロードキャストサービスとして機能するために高密度エリアで使用することができる。例えば、モールでは、本発明を使用して、緊急情報（ビジュアル、ビデオ、テキストベース、またはオーディオ）をブロードキャストする機能を備えた販売固有の広告（ビジュアル、ビデオ、テキストベース、またはオーディオ）を実行することができる。

この使用事例は、本発明の潜在的に無限のスケーラビリティを利用する。従来、高密度ＡＰでは、一度に５０以下のクライアントが接続してトラフィックを転送することを推奨しているが、本発明による単一のＡＰは、１，０００以上のクライアントを処理することができる。緊急時のシナリオでは、展開するハードウェアが少なくて済むため、このような状況では、労力、クッキーカッター、ローカルネットワークを少なくすることが可能となる。本発明を、（１）リアルタイムで集計可能なユーザの状況に関するデータを要求および受信し、（２）セルラータワーがダウンした場合でも、インターネットに依存する必要なく、ユーザ同士が互いに通信できるようにし、かつ／または（３）メッセージをグループにリアルタイムでブロードキャストするように使用することができる。このシナリオでは、クライアントは通常どおりに動作できるが、サーバから一定の音楽ストリームを取得する代わりに、ブロードキャストメッセージを受信することができる。同様に、データを一般的にサーバに報告する代わりに、メッセージを個人に直接送信することができる。

Ｃ）グループＡＲ／ＶＲエクスペリエンス。ネットワークは、集団的なＡＲおよびＶＲエクスペリエンス（例えば、多数の視聴者が同じデータを同時に受信するために着用できるサーバ対応メガネ）を提供することができる。ＶＲエクスペリエンスでは、ハードウェアの動きを視覚的なキュー（ｖｉｓｕａｌ ｃｕｅｓ）に同期させることは非常に重要である。現在、ほとんどのＶＲヘッドセットは、ユーザが吐き気を催さないように配線接続される必要がある。本発明は、配線無しで低レイテンシのＶＲエクスペリエンスを提供するために使用することができる。

このシナリオでは、ＶＲデバイスは小型の無線受信機を有することができ、処理ユニットがＶＲで画像、ビデオ、および／または音声を表示していても、基地局は、デバイス間で情報を送信するサーバとして機能する。ＡＲでは、表示デバイス（メガネなど）は、表示デバイス上で稼動するサーバを有することができ、ＡＲ対応オブジェクトはクライアントとして動作することができる。これは、オブジェクトと対話し、ユーザの没入感を損なうことなく、アクション（ＡＲ内でオブジェクトを移動させたり、オブジェクトと対話したりするなど）を実行することをユーザに要求する。どちらのシナリオでも、全てのデバイスはネットワークに接続される。

Ｄ）プライベートブロックチェーンの更新。マイニングクライアントは、プライベートＷｉＦｉブロックチェーン内の全ての非マイニングクライアントを更新することができる。プライベートブロックチェーンが機能するためには、クライアント間でデータを転送する必要がある。プライベートブロックチェーンの同期を維持するために、ネットワークを介してデータを無線で送信することができる。これらのブロックチェーン、または分散レジャー（ｄｉｓｔｒｉｂｕｔｅｄ ｌｅｄｇｅｒｓ）は、一般に公開されるのではなく、参加するために特別なアクセスまたは許可を必要とする。いくつかのプライベートブロックチェーンは、ハイパーレジャー（ｈｙｐｅｒｌｅｄｇｅｒ）、マルチチェーン（ｍｕｌｔｉｃｈａｉｎ）、テンダーミント（ｔｅｎｄｅｒｍｉｎｔ）、Ｒ３／コルダ（Ｒ３／ｃｏｒｄａ）、およびチェーンである。プライベートブロックチェーンとは、同じデータを複数のクライアントにリアルタイムで転送する必要がある、グーグル（Ｇｏｏｇｌｅ）またはアマゾン（Ａｍａｚｏｎ）などの企業が、独自の内部目的で使用するブロックチェーンである。

ブロックチェーンの発明が新たな用途を生み出し始めると、全てのデバイスがインターネットと常に通信していることを期待することは適切ではないかもしれない。しかしながら、これはブロックチェーンレジャーを最新の状態にするために必要または有益である。本発明を使用すると、中央デバイスおよび／または単一デバイスは、インターネット対応となり、かつレジャー情報をリアルタイムで転送することができる。例えば、デパートの販売タブレットを使用すると、プライベートブロックチェーンの発明により、個々の品目の在庫および販売を倉庫および店舗に亘って追跡することが可能となる。しかしながら、これらの全てのデバイス（店舗毎に５０以上）に対してインターネット対応の無線ネットワークを展開するには、コストがかかり、ほとんど必要とされないであろう。低レイテンシ通信では、更新オーバーヘッドに追加される時間は、ほんの僅かである（例えば、インターネット対応デバイスが更新を取得するのに２００ｍｓを要した場合、インターネット非対応デバイスは２２０ｍｓを要する。）。このシナリオでは、インターネット対応サーバは、ブロックチェーンレジャーの更新を専用ネットワークを介してクライアントデバイスにプッシュする。

Ｅ）手話翻訳。ネットワークは、ライブイベントでのリアルタイムの米国手話翻訳のために、ビデオデータをクライアントに同時に送信することができる。リアルタイムのオーディオ送信に加えて、本発明はクライアントにビデオをも送信することができる。このシナリオでは、ビデオ録画デバイスはＵＳＢを介してサーバにデータを送信する。サーバは、そのデータをネットワークを介してクライアントデバイスに転送し、手話ユーザ用のフィードを表示することができる。

Ｆ）ＳＭＰＴＥタイムコード／クリックトラック同期。タイムコードは、同期および識別のために単一のオーディオトラックでブロードキャストできるメディアメタデータの形式である。本発明は、このデータトラックを、同期コンテンツおよびタイムコードの無線配布のためのモバイルアプリケーションを介して無制限のモバイルデバイスに送信することができる。

Ｇ）ＭＩＤＩトリガー。本発明は、電子またはデジタルＭＩＤＩ対応デバイスへのＭＩＤＩデータの無線マルチキャストに対して使用して、電子音楽演奏の音および制御パラメータを遠隔的にトリガーすることができる。ＵＳＢ／ライトニング−ＭＩＤＩケーブルを使用すると、アプリケーションを介してモバイルデバイスを受信機として使用することができる。

Ｈ）ＣＶ／アナログシンセサイザ用のユーロラック（Ｅｕｒｏｒａｃｋ）。ＣＶ（制御電圧ゲート）は、外部シーケンサーを使用してシンセサイザー、ドラムマシン、およびその他の同様の機器を制御するためのアナログ方式である。本発明は、モバイルアプリケーションを使用して信号をモバイルデバイスにブロードキャストし、アナログ信号をリモート機器に無線で分配するために使用することができる。

Ｉ）ＤＭＸ照明。ＤＭＸは、ステージ照明および効果の制御に使用される。本発明は、（例えば、ＤＭＸコンバータへのＵＳＢを使用して）モバイルアプリケーションがインストールされた無制限のモバイルデバイスに信号を無線で送信するために使用することができる。

Ｊ）ショー／ライド制御システム。ショー／ライド制御システムは、パフォーマンスで使用されるデバイスのコントローラーを指す。これは、例えば、映画館のファンまたはランブルシート、ライブパフォーマンスでのライトアップスティックまたはリストバンドなどである。これらのデバイスは、ライブショー中に特定のイベントと同期する必要がある。本発明を使用することにより、デバイスはこれをリアルタイムで達成することができ、制御システムを従来のタイマーベースの展開からリアルタイムの展開に拡張する。

Ｋ）データ取得テレメトリー。ネットワーク内では、クライアントデバイスは指定された間隔で「チェックイン」し、あらゆる種類の関連データを報告することができる。ネットワークは、レポートポリシーを作成し、それをクライアントデバイスに配布して、多数のクライアントデバイスからのデータをリアルタイムで簡単に取得することを可能にする。

Ｌ）ライトフィールドビデオストリーム。ライトフィールドビデオストリームでは、あるソースからのビデオと別のソースからのライトフィールドデータとをリアルタイムで同期およびマージして、ライトフィールドビデオフレームを表示する必要がある。本発明は、メトロノームである超音波周波数を利用することができるとともに、ライトフィールドデータをサーバにストリーミングし、ビデオソースとマージさせることができる。一般的に、このデータのマージは、現在のところ、十分に短いレイテンシでライトフィールドまたはビデオデータを受信する方法がないため、ビデオの撮影後に行う必要がある。ネットワークはこの問題の解決に役立つ。

Ｍ）３６０ビデオピックステッチストリーム。手話のためのビデオ伝送と同様に、複数のビデオストリームは、クライアントデバイスによってリアルタイムで伝送およびスティッチされるか、またはサーバによって事前にスティッチされる。

Ｎ）ＩＭＡＧサイマルキャスト。ブロックチェーン更新モデルと同様に、サイマルキャストは、オーディオおよびビジュアルデータがインターネットを介して１つのソースにストリーミングされ、その後、インターネットに対応していない複数のソースにサイマルキャストされるシステムである。例えば、１つのバーに複数のプロジェクタがある場合、全てのプロジェクタから中央のＰＣにバーを渡ってケーブル配線するのではなく、ＰＣは、各プロジェクタに接続されたクライアントに専用のネットワークを介してデータをサイマルキャストすることができる。

Ｏ）マルチカメラブロードキャスト。この使用事例は３６０ビデオに類似しているが、３６０ビューを提供するためにビデオをつなぎ合わせる必要はない。
Ｐ）３ＤビジュアルおよびコンテンツへのＶＲ同期。リアルタイムで個別のシステムに同期することは、ＶＲ／ＡＲアプリケーションにおいて、例えば、視覚から運動への切断を防止するため必要であるか、または非常に望ましい。ライトフィールドシステムについて説明したのと同様に、超音波トーンは、集中型ソースまたはサーバにおいてネットワークを介して異なるシステムに同期させることができる。

Ｑ）非インターネット対応デバイスへのメッシュホップを介したインターネットデータ送信。より多くのデバイスがインターネット対応するようになると、全てのデバイスをネットワーク上に配置してインターネットアクセスを提供すると、ＷＡＮに負担がかかるようになる。この例としては、ＩｏＴデバイスがある。ブロックチェーンモデルと同様に、中央サーバ（例えば、スマートシングス（ＳｍａｒｔＴｈｉｎｇｓ）ハブなど）は、ＩｏＴデバイスにレポートポリシーおよびブロードキャストメッセージを通信することができ、ＩｏＴデバイスは、インターネットにアクセスするためのインフラストラクチャを提供する必要なく、インターネットに情報を投稿することができる。これにより、デバイスをインターネット対応にする必要がなくなるため、ネットワークのスケーリング機能やケーブル接続による密度についてあまり気にすることなく、デバイスがメッシュホップを介して通信できるようになる。

Ｒ）自動運転車の通信フレームワーク。自動運転車は、多数の運転パラメータを調整するために、車両全体に亘って何らかの形式の通信を提供する必要がある。車内に簡単なＷｉ−Ｆｉチップを埋め込むことで、車はネットワークに接続して放送を聴いたり、更新をリアルタイムで送信することができる。例えば、交通は単純に人間のレイテンシの融合である。運転者間の応答スタックの遅延により、結果としてストップアンドゴーの交通が発生する。このネットワークを使用すれば、自動運転車は変化を即座に通信することができ、高密度であっても、１００台離れた車は数秒以内に反応して、運転距離を調整することができる。ＶＲ／ＡＲでは、視覚から運動への切断を防止するために、リアルタイムで別々のシステムを同期させる必要がある。ライトフィールドシステムについて説明したものと同様に、超音波トーンは、集中型サーバにおいてネットワークを介して異なるシステムを同期させることができる。

特定の好ましい実施形態を参照して本発明を特に示し説明したが、以下の特許請求の範囲によって定義される本発明の技術思想および範囲から逸脱することなく、形態および詳細の様々な変更を行うことができることは、当業者によって理解されるべきである。明確にするために、「リアルタイム」でオーディオを配信することは、上記の特定のレイテンシ（例えば、最大約１００ミリ秒）を含みかつそれを考慮し、この目的に関して「リアルタイムに近い」と同義であることも理解されるべきである。

Claims (41)

1. データを１つまたは複数のクライアントコンピューティングデバイスに配信するコンピュータ化された方法であって、
   サーバコンピューティングデバイスが、第１の時間が開始で、データストリームを受信するステップと、
   前記サーバコンピューティングデバイスがデータストリームを処理して、処理されたデータストリームを生成するステップと、
   前記サーバコンピューティングデバイスが、前記サーバコンピューティングデバイスと電子通信する無線ネットワークを介して、処理されたデータストリームを前記１つまたは複数のクライアントコンピューティングデバイスに送信するステップと、
   前記１つまたは複数のクライアントコンピューティングデバイス上にインストールされたアプリケーションが、前記処理されたデータストリームを解釈して、前記１つまたは複数のクライアントコンピューティングデバイスによる使用のためにデータストリームをリカバリングするステップとを含み、
   前記第１の時間と第２の時間との間のレイテンシは１００ミリ秒未満である、方法。
2. 前記第１の時間と前記第２の時間との間のレイテンシが５０ミリ秒未満である、請求項１に記載の方法。
3. 前記第１の時間と前記第２の時間との間のレイテンシが２０ミリ秒未満である、請求項１に記載の方法。
4. 前記処理されたデータストリーム内の全てのブロードキャストフレームおよび／またはマルチキャストフレームの「追加データ」フラグが「真」に設定される、請求項１に記載の方法。
5. 前記処理されたデータストリームのトラフィック指示マップ（ＴＩＭ）内のマルチキャストフラグが、前記処理されたデータストリーム内の全てのビーコンに対して設定され、それにより、前記無線ネットワークを通過するブロードキャストトラフィックおよび／またはマルチキャストトラフィックのバッファリングを無効化する、請求項１に記載の方法。
6. ＭＡＣプロトコルデータユニットアグリゲーションが前記無線ネットワークに対して無効化される、請求項１に記載の方法。
7. 前記処理されたデータストリームのＤＴＩＭカウントおよびＤＴＩＭ間隔に対して無効な値を設定するステップをさらに含む、請求項１に記載の方法。
8. 前記処理されたデータストリームの全てのブロードキャストフレームおよび／またはマルチキャストフレームに対してＤＳＣＰ値を４６に設定するステップをさらに含む、請求項１に記載の方法。
9. 前記無線ネットワークのオペレータが、前記無線ネットワークのＤＴＩＭ間隔を第１の値に設定するステップと、前記無線ネットワークのオペレータが、前記無線ネットワークのＤＴＩＭカウントを第２の値に設定するステップと、前記無線ネットワークが、設定されたＤＴＩＭ間隔を含むビーコンを送信するステップと、前記無線ネットワークが、マルチキャストデータストリームまたはユニキャストデータストリームの少なくとも一方を１つまたは複数のクライアントコンピューティングデバイスに送信するステップとを含み、前記第２の値は前記第１の値より大きい、請求項１に記載の方法。
10. 前記クライアントコンピューティングデバイスが、予め設定されたＤＴＩＭ間隔よりも高いＤＴＩＭカウントを含む前記処理されたデータストリーム内のビーコンメッセージを受信するステップをさらに含む、請求項１に記載の方法。
11. 前記無線ネットワーク上の各クライアントコンピューティングデバイスは、前記無線ネットワーク上の他の全てのクライアントコンピューティングデバイスから隔離されている、請求項１に記載の方法。
12. 前記無線ネットワーク上の各クライアントコンピューティングデバイスは、インターネットから隔離されている、請求項１に記載の方法。
13. 前記無線ネットワークは、前記処理されたデータストリームとは別個の全てのネットワークトラフィックを迂回させる、請求項１に記載の方法。
14. ネットワークに関連する１つまたは複数のドライバに対して変更を加えて、ＰＳＭを有効化および無効化するための単一のコマンドを通過させることを可能にする、請求項１に記載の方法。
15. 前記無線ネットワークが、特定のタイプの無線ネットワークトラフィックを再優先順位付けし、かつ／または無視するステップをさらに含む、請求項１に記載の方法。
16. クライアントコンピューティングデバイスにデータを配信するためのシステムであって、
    データストリームを受信し、データストリームを処理されたデータストリームに変換するように構成されたサーバであって、
    データストリームを受信するためのインタフェースと、
    データストリームを受信するためのインタフェースと電子通信するサーバコンピュータと、
    前記サーバコンピュータ上にインストールされたオペレーティングシステムと、
    前記サーバコンピュータ上にインストールされた専用のソフトウェアと、前記専用のソフトウェアは、ハードウェアドライバおよびデータストリーム処理ソフトウェアを含み、
    前記サーバコンピュータと電子通信するネットワークハードウェアとを含む前記サーバと、
    前記サーバの前記ネットワークハードウェアと通信し、処理されたデータストリームを送信するように構成された無線ネットワークアクセスポイントとを備え、
    前記サーバでデータストリームを受信してから、前記無線ネットワークアクセスポイントで処理されたデータストリームを送信するまでのレイテンシが１００ミリ秒未満である、システム。
17. 前記レイテンシが５０ミリ秒未満である、請求項１６に記載のシステム。
18. 前記レイテンシが２０ミリ秒未満である、請求項１６に記載のシステム。
19. 第１の時間と第２の時間との間のレイテンシが５０ミリ秒未満である、請求項１６に記載のシステム。
20. 第１の時間と第２の時間との間のレイテンシが２０ミリ秒未満である、請求項１６に記載のシステム。
21. 前記処理されたデータストリーム内の全てのブロードキャストフレームおよび／またはマルチキャストフレームの「追加データ」フラグが「真」に設定される、請求項１６に記載のシステム。
22. 前記処理されたデータストリームのトラフィック指示マップ（ＴＩＭ）内のマルチキャストフラグが、前記処理されたデータストリーム内の全てのビーコンに対して設定され、それにより、無線ネットワークを通過するブロードキャストトラフィックおよび／またはマルチキャストトラフィックのバッファリングを無効化する、請求項１６に記載のシステム。
23. ＭＡＣプロトコルデータユニットアグリゲーションが無線ネットワークに対して無効化される、請求項１６に記載のシステム。
24. 前記処理されたデータストリームのＤＴＩＭカウントおよびＤＴＩＭ間隔に対して無効な値を設定することをさらに含む、請求項１６に記載のシステム。
25. 前記処理されたデータストリームの全てのブロードキャストフレームおよび／またはマルチキャストフレームに対してＤＳＣＰ値を４６に設定することをさらに含む、請求項１６に記載のシステム。
26. 無線ネットワークのオペレータが、前記無線ネットワークのＤＴＩＭ間隔を第１の値に設定すること、無線ネットワークのオペレータが、無線ネットワークのＤＴＩＭカウントを第２の値に設定すること、無線ネットワークが、設定されたＤＴＩＭ間隔を含むビーコンを送信すること、無線ネットワークが、マルチキャストデータストリームまたはユニキャストデータストリームの少なくとも一方を１つまたは複数のクライアントコンピューティングデバイスに送信することを含み、前記第２の値は前記第１の値より大きい、請求項１６に記載のシステム。
27. クライアントコンピューティングデバイスが、予め設定されたＤＴＩＭ間隔よりも高いＤＴＩＭカウントを含む処理されたデータストリーム内のビーコンメッセージを受信することをさらに含む、請求項１６に記載のシステム。
28. 無線ネットワーク上の各クライアントコンピューティングデバイスは、前記無線ネットワーク上の他の全てのクライアントコンピューティングデバイスから隔離されている、請求項１６に記載のシステム。
29. 無線ネットワーク上の各クライアントコンピューティングデバイスは、インターネットから隔離されている、請求項１６に記載のシステム。
30. 無線ネットワークは、前記処理されたデータストリームとは別個の全てのネットワークトラフィックを迂回させる、請求項１６に記載のシステム。
31. ネットワークに関連する１つまたは複数のドライバに対して変更を加えて、ＰＳＭを有効化および無効化するための単一のコマンドを通過させることを可能にする、請求項１６に記載のシステム。
32. 無線ネットワークが、特定のタイプの無線ネットワークトラフィックを再優先順位付けし、かつ／または無視することを含む、請求項１６に記載のシステム。
33. クライアントコンピューティングデバイス上でストリーミングデータを受信する方法であって、
    前記クライアントコンピューティングデバイスが、無線ネットワークアクセスポイントに接続するステップと、
    前記クライアントコンピューティングデバイスが、前記クライアントコンピューティングデバイスにインストールされたソフトウェアアプリケーションを起動するステップと、前記ソフトウェアアプリケーションは、（１）データストリームに対応する第１の組のデータパケットを前記無線ネットワークアクセスポイントと電子通信するサーバから受信し、（２）前記第１の組のデータパケットを解釈して、第２の組のデータパケットを含む解釈済みのデータストリームを生成し、（３）前記解釈済みのデータストリームをバッファリングするように構成されており、
    前記クライアントコンピューティングデバイスが、前記解釈済みのデータストリームをクライアントが使用可能な形式で出力するステップとを含み、前記解釈済みのデータストリームのデータパケットの前記第２の組のデータパケットにおける各データパケットを出力することは、対応するデータパケットがサーバに入力されてから１００ミリ秒以内に行われる、方法。
34. 前記レイテンシが５０ミリ秒未満である、請求項１６に記載のシステム。
35. 前記レイテンシが２０ミリ秒未満である、請求項１６に記載のシステム。
36. ストリーミングデータストリームの連続性を維持しつつ、ストリーミングデータシステムによって生成されるストリーミングデータストリームのトータルレイテンシを最小化する方法であって、以下のストリーミングデータシステムコンポーネントの各々、
    サーバハードウェアインタフェース、
    サーバハードウェアインタフェースドライバ、
    サーバアプリケーション、
    ネットワークハードウェアインタフェースドライバを含むサーバネットワークスタック、
    サーバネットワークハードウェアインタフェース、
    イーサネットネットワーク、
    無線ネットワークアクセスポート、
    無線ネットワーク、
    モバイルデバイスのハードウェア無線ネットワークインタフェース、
    ハードウェア無線ネットワークインタフェースドライバを含むモバイルオペレーティングシステムのネットワークスタック、
    モバイルクライアントアプリケーション、
    モバイルオペレーティングシステム、
    モバイルデバイスのハードウェアインタフェースのレイテンシを個別に最小化するステップを含み、
    前記ストリーミングデータシステムコンポーネントの各々のレイテンシの合計は約１００ミリ秒未満である、方法。
37. 前記レイテンシの合計が５０ミリ秒未満である、請求項３６に記載のシステム。
38. 前記レイテンシの合計が２０ミリ秒未満である、請求項３６に記載のシステム。
39. ストリーミングデータサーバであって、
    ハードウェアインタフェースデバイスと、
    前記ハードウェアインタフェースデバイスと通信するサーバコンピュータと、
    前記サーバコンピュータ上にインストールされたオペレーティングシステムと、
    前記サーバコンピュータ上にインストールされた専用のソフトウェアと、前記専用のソフトウェアは、ハードウェアインタフェースドライバおよびデータ処理ソフトウェアを含んでおり、
    前記サーバコンピュータと通信するネットワークハードウェアとを備え、
    前記ストリーミングデータサーバは、（１）前記ストリーミングデータサーバに到達するライブデータストリームと、（２）前記ストリーミングデータサーバと通信するユーザデバイスによりリカバリングされたデータストリームの再生との間に約１００ミリ秒未満のレイテンシを生成するように構成されている、ストリーミングデータサーバ。
40. 前記レイテンシが５０ミリ秒未満である、請求項３９に記載のシステム。
41. 前記レイテンシが２０ミリ秒未満である、請求項３９に記載のシステム。