(57)【要約】  カンファレンス中のオーディオを管理するための管理するための方法が、モバイルデバイスの第1のバッファにおいて、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信することを含む。方法はまた、モバイルデバイスの第2のバッファにおいて、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信することをも含む。方法は、モバイルデバイスの遅延コントローラにおいて制御信号を生成することをさらに含む。制御信号は、第1のバッファおよび第2のバッファに供給され、第1のバッファから出力される第1のバッファリング済みオーディオが、第2のバッファから出力される第2のバッファリング済みオーディオと同期される。
2018515009.tif 000002
【特許請求の範囲】
【請求項１】
カンファレンス中のオーディオを管理するための方法であって、
モバイルデバイスの第1のバッファにおいて、前記カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するステップと、
前記モバイルデバイスの第2のバッファにおいて、前記カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するステップと、
前記モバイルデバイスの遅延コントローラにおいて制御信号を生成するステップであって、前記制御信号が、前記第1のバッファおよび前記第2のバッファに供給され、前記第1のバッファから出力される第1のバッファリング済みオーディオが、前記第2のバッファから出力される第2のバッファリング済みオーディオと同期される、ステップと
を含む、方法。
【請求項２】
前記モバイルデバイスにおいて、前記第1のオーディオストリームの第1のタイムスタンプを前記第2のオーディオストリームの第2のタイムスタンプと比較するステップであって、前記第1のタイムスタンプおよび前記第2のタイムスタンプが共通クロックソースに基づく、ステップと、
前記モバイルデバイスにおいて、前記第1のタイムスタンプと前記第2のタイムスタンプとの間の時間差を決定するステップと
をさらに含む、請求項1に記載の方法。
【請求項３】
前記第1のタイムスタンプが前記第2のタイムスタンプよりも早い時刻を示す場合、前記制御信号が、前記第1のバッファリング済みオーディオの出力を前記時間差だけ遅延するように前記第1のバッファに指示する、請求項2に記載の方法。
【請求項４】
前記第2のタイムスタンプが前記第1のタイムスタンプよりも早い時刻を示す場合、前記制御信号が、前記第2のバッファリング済みオーディオの出力を前記時間差だけ遅延するように前記第2のバッファに指示する、請求項2に記載の方法。
【請求項５】
前記第1のバッファが第1のデジッタバッファを含み、前記第2のバッファが第2のデジッタバッファを含む、請求項1に記載の方法。
【請求項６】
前記モバイルデバイスの第1のデコーダにおいて、前記第1のバッファリング済みオーディオを復号化して、第1の復号化オーディオを生成するステップと、
前記モバイルデバイスの第2のデコーダにおいて、前記第2のバッファリング済みオーディオを復号化して、第2の復号化オーディオを生成するステップと
を含む、請求項1に記載の方法。
【請求項７】
前記モバイルデバイスにおいて、前記第1の復号化オーディオに対する第1の空間ステアリング演算を実施して、前記第1の復号化オーディオをスピーカから第1の角度に投射するステップと、
前記モバイルデバイスにおいて、前記第2の復号化オーディオに対する第2の空間ステアリング演算を実施して、前記第2の復号化オーディオを前記スピーカから第2の角度に投射するステップと
をさらに含む、請求項6に記載の方法。
【請求項８】
前記第1の空間ステアリング演算を実施する前記ステップが、前記第1の復号化オーディオに第1の頭部伝達関数(HRTF)を適用するステップを含み、前記第2の空間ステアリング演算を実施する前記ステップが、前記第2の復号化オーディオに第2のHRTFを適用するステップを含む、請求項7に記載の方法。
【請求項９】
前記第1の角度および前記第2の角度が、ユーザ定義の設定に基づく、請求項7に記載の方法。
【請求項１０】
モバイルデバイスのユーザに関連する頭部移動を検出したことに応答して、前記第1の角度および前記第2の角度をシフト量だけシフトするステップをさらに含む、請求項9に記載の方法。
【請求項１１】
前記第1の復号化オーディオの第1の利得を調整するステップと、
前記第2の復号化オーディオの第2の利得を調整するステップと
をさらに含む、請求項6に記載の方法。
【請求項１２】
前記第1の利得および前記第2の利得が、ユーザ定義の設定に基づいて調整される、請求項11に記載の方法。
【請求項１３】
前記第1のオーディオストリームが、ネットワークデバイスを介して前記第1のデバイスから前記第1のバッファに経路指定され、前記第2のオーディオストリームが、前記ネットワークデバイスを介して前記第2のデバイスから前記第2のバッファに経路指定される、請求項1に記載の方法。
【請求項１４】
前記ネットワークデバイスに第1の信号を供給して、前記第1のオーディオストリームの第1のビットレートを調整するステップと、
前記ネットワークデバイスに第2の信号を供給して、前記第2のオーディオストリームの第2のビットレートを調整するステップと
をさらに含む、請求項13に記載の方法。
【請求項１５】
前記第1のビットレートおよび前記第2のビットレートが、ユーザ定義の設定、前記モバイルデバイスのハードウェア能力、またはそれらの組合せに基づいて調整される、請求項14に記載の方法。
【請求項１６】
前記モバイルデバイス、前記第1のデバイス、および前記第2のデバイスがそれぞれ、Third Generation Partnership Project(3GPP)規格と互換性のあるユーザ機器(UE)を含む、請求項1に記載の方法。
【請求項１７】
前記第1のオーディオストリームが、前記モバイルデバイスのアンテナを介して受信される、請求項1に記載の方法。
【請求項１８】
前記第1のバッファ、前記第2のバッファ、および遅延コントローラが、前記モバイルデバイスのモデム内に含まれる、請求項1に記載の方法。
【請求項１９】
カンファレンス中のオーディオを管理するためのモバイルデバイスであって、
カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するように構成された第1のバッファと、
前記カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するように構成された第2のバッファと、
制御信号を生成するように構成された遅延コントローラであって、前記制御信号が、前記第1のバッファおよび前記第2のバッファに供給され、前記第1のバッファから出力される第1のバッファリング済みオーディオが、前記第2のバッファから出力される第2のバッファリング済みオーディオと同期される、遅延コントローラと
を備える、モバイルデバイス。
【請求項２０】
前記遅延コントローラが、
前記第1のオーディオストリームの第1のタイムスタンプを、前記第2のオーディオストリームの第2のタイムスタンプと比較することであって、前記第1のタイムスタンプおよび前記第2のタイムスタンプが共通クロックソースに基づく、比較すること、および
前記第1のタイムスタンプと前記第2のタイムスタンプとの間の時間差を決定すること
を行うように構成される、請求項19に記載のモバイルデバイス。
【請求項２１】
前記第1のタイムスタンプが前記第2のタイムスタンプよりも早い時刻を示す場合、前記制御信号が、前記第1のバッファリング済みオーディオの出力を前記時間差だけ遅延するように前記第1のバッファに指示する、請求項20に記載のモバイルデバイス。
【請求項２２】
前記第2のタイムスタンプが前記第1のタイムスタンプよりも早い時刻を示す場合、前記制御信号が、前記第2のバッファリング済みオーディオの出力を前記時間差だけ遅延するように前記第2のバッファに指示する、請求項20に記載のモバイルデバイス。
【請求項２３】
前記第1のバッファが第1のデジッタバッファを含み、前記第2のバッファが第2のデジッタバッファを含む、請求項19に記載のモバイルデバイス。
【請求項２４】
前記第1のバッファリング済みオーディオを復号化して、第1の復号化オーディオを生成するように構成された第1のデコーダと、
前記第2のバッファリング済みオーディオを復号化して、第2の復号化オーディオを生成するように構成された第2のデコーダと
をさらに備える、請求項19に記載のモバイルデバイス。
【請求項２５】
前記第1の復号化オーディオに対する第1の空間ステアリング演算を実施して、前記第1の復号化オーディオをスピーカから第1の角度に投射し、
前記第2の復号化オーディオに対する第2の空間ステアリング演算を実施して、前記第2の復号化オーディオを前記スピーカから第2の角度に投射する
ように構成された空間ステアリングプロセッサをさらに備える、請求項24に記載のモバイルデバイス。
【請求項２６】
前記第1の空間ステアリング演算を実施することが、前記第1の復号化オーディオに第1の頭部伝達関数(HRTF)を適用することを含み、前記第2の空間ステアリング演算を実施することが、前記第2の復号化オーディオに第2のHRTFを適用することを含む、請求項25に記載のモバイルデバイス。
【請求項２７】
前記遅延コントローラから前記制御信号を受信し、
前記制御信号に基づいて、前記第1のオーディオストリームに関連する第1のデータパケットを復号化し、または前記第1のデータパケットに対する復号化演算をバイパスする
ように構成された第1のデコーダと、
前記遅延コントローラから前記制御信号を受信し、
前記制御信号に基づいて、前記第2のオーディオストリームに関連する第2のデータパケットを復号化し、または前記第2のデータパケットに対する復号化演算をバイパスする
ように構成された第2のデコーダと
をさらに備える、請求項19に記載のモバイルデバイス。
【請求項２８】
前記第1のデコーダと前記第2のデコーダとが異なるデコーダである、請求項27に記載のモバイルデバイス。
【請求項２９】
前記第1のオーディオストリームを受信し、
前記第1のオーディオストリームを前記第1のバッファに供給する
ように構成されたアンテナをさらに備える、請求項19に記載のモバイルデバイス。
【請求項３０】
前記第1のバッファ、前記第2のバッファ、および前記遅延コントローラを含むモデムをさらに備える、請求項19に記載のモバイルデバイス。
【請求項３１】
カンファレンス中のオーディオを管理するための命令を含むコンピュータ可読記憶媒体であって、前記命令が、モバイルデバイス内のプロセッサによって実行されるとき、前記プロセッサに、
第1のバッファにおいて、前記カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信すること、
第2のバッファにおいて、前記カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信すること、および
遅延コントローラにおいて制御信号を生成することであって、前記制御信号が、前記第1のバッファおよび前記第2のバッファに供給され、前記第1のバッファから出力される第1のバッファリング済みオーディオが、前記第2のバッファから出力される第2のバッファリング済みオーディオと同期される、生成すること
を含む動作を実施させる、コンピュータ可読記憶媒体。
【請求項３２】
前記動作が、
前記第1のオーディオストリームの第1のタイムスタンプを、前記第2のオーディオストリームの第2のタイムスタンプと比較することであって、前記第1のタイムスタンプおよび前記第2のタイムスタンプが共通クロックソースに基づく、比較すること、および
前記第1のタイムスタンプと前記第2のタイムスタンプとの間の時間差を決定すること
をさらに含む、請求項31に記載のコンピュータ可読記憶媒体。
【請求項３３】
カンファレンス中のオーディオを管理するための装置であって、
カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するための手段と、
前記カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するための手段と、
制御信号を生成するための手段であって、前記制御信号が、前記第1のオーディオストリームを受信するための前記手段および前記第2のオーディオストリームを受信するための前記手段に供給され、前記第1のオーディオストリームを受信するための前記手段から出力される第1のバッファリング済みオーディオが、前記第2のオーディオストリームを受信するための前記手段から出力される第2のバッファリング済みオーディオと同期される、手段と
を備える、装置。
【請求項３４】
前記第1のバッファリング済みオーディオを復号化して、第1の復号化オーディオを生成するための手段と、
前記第2のバッファリング済みオーディオを復号化して、第2の復号化オーディオを生成するための手段と
をさらに備える、請求項33に記載の装置。
【請求項３５】
前記第1のオーディオストリームを受信するための前記手段、前記第2のオーディオストリームを受信するための前記手段、および前記制御信号を生成するための前記手段が、モバイルデバイス内に含まれる、請求項33に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権の主張
本願は、「CONFERENCE AUDIO MANAGEMENT」という名称の2016年3月29日出願の米国特許出願第15/083,974号、「CONFERENCE AUDIO MANAGEMENT AT A MOBILE DEVICE」という名称の2015年4月5日出願の米国仮特許出願第62/143,154号、および「CONFERENCE AUDIO MANAGEMENT」という名称の2015年4月7日出願の米国仮特許出願第62/144,033号の優先権を主張し、その内容全体が参照により組み込まれる。
【０００２】
本開示は、一般にはカンファレンスオーディオ管理に関する。
【背景技術】
【０００３】
技術の進歩の結果、コンピューティングデバイスはより小型に、より強力になっている。たとえば、現在、小型、軽量であり、ユーザによって容易に持ち運ばれるポータブルワイヤレス電話、携帯情報端末(PDA)、ページングデバイスなどのワイヤレスコンピューティングデバイスを含む様々なポータブルパーソナルコンピューティングデバイスが存在している。より具体的には、セルラー電話やインターネットプロトコル(IP)電話などのポータブルワイヤレス電話は、ワイヤレスネットワークを介して音声およびデータパケットを通信し得る。さらに、多くのそのようなワイヤレス電話は、その中に組み込まれた他のタイプのデバイスを含む。たとえば、ワイヤレス電話はまた、デジタルスチルカメラ、デジタルビデオカメラ、デジタルレコーダ、およびオーディオファイルプレーヤをも含み得る。
【０００４】
3つ以上の対応するワイヤレスデバイスに関連付けられた3人以上の参加者が、「カンファレンスコール」を使用して互いに通信し得る。カンファレンスコールの間に、第1のワイヤレスデバイスは、ネットワークミキサから「ミキシング済みオーディオストリーム」を受信し得る。たとえば、ネットワークミキサは、カンファレンスコールの各参加者からオーディオストリームを受信し得る。オーディオストリームを受信した後、ネットワークミキサは、第2のワイヤレスデバイスからのオーディオストリームを第3のワイヤレスデバイスからのオーディオストリームとミキシングして、ミキシング済みオーディオストリームを生成し、第1のワイヤレスデバイスに供給し得る。ミキシング済みオーディオストリームを生成するために、ネットワークミキサは、各着信オーディオストリームを復号化し、復号化オーディオストリームをミキシングし、ミキシング済み復号化オーディオストリームを再符号化する。しかしながら、ミキシング済みオーディオストリームを生成することに関連するオーディオ処理が遅延を導入し得る。さらに、カンファレンス参加者は中央ネットワークミキサからミキシング済みオーディオストリームを受信するので、参加者オーディオを個々に調整することは不可能であり得る。たとえば、当事者A、B、およびCがカンファレンス中である場合、ネットワークミキサは、当事者Bと当事者Cの両方からの音声を含む単一のミキシング済みストリームを当事者Aに供給するので、当事者Aは、利得調整または空間処理技法を使用して、当事者Bの音声を当事者Cの音声よりも強調することが不可能であり得る。
【発明の概要】
【課題を解決するための手段】
【０００５】
カンファレンス中のオーディオを管理するためのシステムおよび方法が開示される。特定の実装によれば、個々のカンファレンス参加者からのオーディオの調整を可能にするために、ネットワークミキサが、ミキシング済みストリームを生成する代わりに、個々のオーディオストリームを参加者に中継し得る。たとえば、3者カンファレンスでは、当事者Aが、当事者Bおよび当事者Cからの別々のオーディオストリームをそれぞれ受信し得る。しかしながら、ネットワーク条件の変動のために、当事者Bおよび当事者Cからのストリームが互いに同期されないことがあり、そのことによって、当事者Aのデバイスへの出力が一時的に誤ったものとなり得る。例示のために、当事者Bのストリームが遅延する場合、当事者Aは、当事者Bが述べた質問を、当事者Cによるその質問に対する答えを聴いた後に聴き得る。
【０００６】
本明細書で説明される技法によれば、モバイルデバイスが、バッファ管理を使用して、相異なるデバイスから受信したストリームを同期し得る。たとえば、第1のカンファレンス参加者からの第1のオーディオストリームが、モバイルデバイスの第1のバッファ(たとえば、デジッタバッファ)に供給され得、第2のカンファレンス参加者からの第2のオーディオストリームが、モバイルデバイスの第2のバッファに供給され得る。第1および第2のオーディオストリームの受信時に、遅延コントローラが、第1のオーディオストリームのタイムスタンプを第2のオーディオストリームのタイムスタンプと比較して、第1のカンファレンス参加者からのオーディオを第2のカンファレンス参加者からのオーディオと同期し得る。オーディオの同期は、カンファレンス中のThird Generation Partnership Project(3GPP)技術仕様(TS)26.114遅延要件を満たし得る。たとえば、遅延コントローラは、タイムスタンプに基づいて第1および第2のバッファに制御信号を供給し得、それによって、第1のバッファが、第1のオーディオストリームのリアルタイム転送プロトコル(RTP)パケットを出力するのとほぼ同時に、第2のバッファが、第2のオーディオストリームの対応するRTPパケットを出力する。
【０００７】
同期の後、第1のオーディオストリームおよび第2のオーディオストリームが別々に復号化されて、それぞれ第1の復号化オーディオおよび第2の復号化オーディオが生成され得る。第1および第2の復号化オーディオがミキシングされて、モバイルデバイスにおいてオーディオストリームが出力され得る。いくつかの実装では、第1の頭部伝達関数(HRTF)が第1の復号化オーディオに適用されて、第1の復号化オーディオの第1の利得が調整され、ユーザ定義の設定に基づいて第1の復号化オーディオが空間的にステアリングされ(たとえば、パンされ)得る。さらに、第2のHRTFが第2の復号化オーディオに適用されて、第2の復号化オーディオの第2の利得が調整され、ユーザ定義の設定に基づいて第2の復号化オーディオが空間的にステアリングされ得る。したがって、(ネットワークミキサにおいてオーディオストリームをミキシングして、得られるミキシング済みオーディオストリームをモバイルデバイスに供給するのではなく)モバイルデバイスに第1および第2のオーディオストリームを供給することは、モバイルデバイスが個々のオーディオストリームの特性(たとえば、利得特性および空間パニング特性)を制御することを可能にし得る。具体的には、オーディオパニングは、ミキシング利得を調整することによってレンダリングデバイスが参加者のオーディオレベルを変更または調整することを選ぶことを可能にし得る。さらに、オーディオ空間化は、レンダリングデバイスが参加者を空間的に分散させる(たとえば、仮想シーティング)ように様々なHRTFを選ぶことを可能にし得、そのことは、話者/ワード識別、および同時話者のケースでのより良い理解を改善し得る。さらに、ネットワークミキサにおいてオーディオストリームをミキシングすることに関連する遅延が低減され(たとえば、解消され)得る。
【０００８】
本明細書で説明される技法の一例によれば、カンファレンス中のオーディオを管理するための方法が、モバイルデバイスの第1のバッファにおいて、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信することを含む。方法はまた、モバイルデバイスの第2のバッファにおいて、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信することをも含む。方法は、モバイルデバイスの遅延コントローラにおいて制御信号を生成することをさらに含む。制御信号は、第1のバッファおよび第2のバッファに供給され、第1のバッファから出力される第1のバッファリング済みオーディオが、第2のバッファから出力される第2のバッファリング済みオーディオと同期される。
【０００９】
本明細書で説明される技法の別の例によれば、モバイルデバイスが、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するように構成された第1のバッファを含む。モバイルデバイスはまた、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するように構成された第2のバッファをも含む。モバイルデバイスは、制御信号を生成するように構成された遅延コントローラをさらに含む。制御信号は、第1のバッファおよび第2のバッファに供給され、第1のバッファから出力される第1のバッファリング済みオーディオが、第2のバッファから出力される第2のバッファリング済みオーディオと同期される。
【００１０】
本明細書で説明される技法の別の例によれば、非一時的コンピュータ可読媒体は、カンファレンス中のオーディオを管理するための命令を含む。命令は、モバイルデバイス内のプロセッサによって実行されるとき、プロセッサに動作を実施させる。動作は、第1のバッファにおいて、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信することを含む。動作は、第2のバッファにおいて、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信することをさらに含む。動作はまた、遅延コントローラにおいて制御信号を生成することをも含む。制御信号が第1のバッファおよび第2のバッファに供給され、第1のバッファから出力される第1のバッファリング済みオーディオが、第2のバッファから出力される第2のバッファリング済みオーディオと同期される。
【００１１】
本明細書で説明される技法の別の例によれば、装置が、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するための手段を含む。装置はまた、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するための手段をも含む。装置は、制御信号を生成するための手段をさらに含む。制御信号は、第1のオーディオストリームを受信するための手段および第2のオーディオストリームを受信するための手段に供給され、第1のオーディオストリームを受信するための手段から出力される第1のバッファリング済みオーディオが、第2のオーディオストリームを受信するための手段から出力される第2のバッファリング済みオーディオと同期される。
【００１２】
開示される実装のうちの少なくとも1つによってもたらされる特定の利点には、ネットワークミキサにおいてカンファレンスでの複数のオーディオストリームをミキシングすることに関連する遅延を低減することが含まれる。たとえば、ネットワークミキサでのオーディオミキシングをバイパスすることは、カンファレンス中の遅延を改善する(たとえば、低減する)。以下のセクションを含む本願全体を検討した後、本開示の他の実装、利点、および特徴が明らかとなるであろう。
【図面の簡単な説明】
【００１３】
【図１Ａ】カンファレンス中のオーディオを管理するように動作可能であるシステムを示す図である。
【図１Ｂ】カンファレンス中のオーディオを管理するように動作可能である別のシステムを示す図である。
【図１Ｃ】カンファレンス中のオーディオを管理するように動作可能である別のシステムを示す図である。
【図２Ａ】カンファレンス中のオーディオを管理するように動作可能であるモバイルデバイスの図である。
【図２Ｂ】図2Aのモバイルデバイスの別の実装である。
【図３】頭部伝達関数(HRTF)を使用して処理された復号化オーディオを示す図である。
【図４】HRTFおよび頭部追跡データを使用して処理された復号化オーディオを示す図である。
【図５】インターネットプロトコル(IP)マルチキャストセッションを使用してカンファレンス中のオーディオを管理するように動作可能であるシステムを示す図である。
【図６】カンファレンス中のオーディオを管理するための方法を示すフローチャートである。
【図７】図1A〜図6のシステム、図、および方法による信号処理動作を実施するように動作可能なモバイルデバイスのブロック図である。
【発明を実施するための形態】
【００１４】
図面を参照しながら本開示の特定の技法を説明する。説明では、図面全体にわたって共通の特徴が共通の参照番号で示される。
【００１５】
図1Aを参照すると、カンファレンス中のオーディオを管理するように動作可能であるシステム100の特定の実装が示されている。システム100は、モバイルデバイス102、第1のデバイス110、第2のデバイス120、第3のデバイス130、およびネットワークデバイス190を含む。一例では、モバイルデバイス102、第1のデバイス110、第2のデバイス120、および第3のデバイス130はそれぞれ、Third Generation Partnership Project(3GPP)規格と互換性のあるユーザ機器(UE)を含み得る。4者カンファレンスが図1Aに示されているが、代替実装では、4人より多い、または少ない当事者がカンファレンスに参加し得ることを理解されたい。
【００１６】
モバイルデバイス102、第1のデバイス110、第2のデバイス120、および第3のデバイス130は、カンファレンス(たとえば、オーディオカンファレンスコール)に参加中であり得る。ネットワークデバイス190は、あるデバイスから、カンファレンスコールに接続された各々の他のデバイスにオーディオ(たとえば、オーディオストリーム)を経路指定するように構成され得る。
【００１７】
例示のために、モバイルデバイス102は、モバイルデバイス102において符号化されるオーディオストリーム104を生成するように構成され得る。オーディオストリーム104は音声(たとえば、ユーザ音声)および/または背景雑音を含み得る。オーディオストリーム104はネットワークデバイス190に供給され得、ネットワークデバイス190は、オーディオストリーム104(またはそのトランスコード/処理済みバージョン)を他のデバイス110、120、130に経路指定し得る。第1のデバイス110は、第1のデバイス110において符号化される第1のオーディオストリーム114を生成するように構成され得る。第1のオーディオストリーム114は、カンファレンスの第1の参加者(たとえば、第1のデバイス110のユーザ)からの音声、および/または第1のデバイス110での背景雑音を含み得る。第1のオーディオストリーム114はネットワークデバイス190に供給され得、ネットワークデバイス190は、第1のオーディオストリーム114(またはそのトランスコード/処理済みバージョン)を他のデバイス102、120、130に経路指定し得る。第2のデバイス120は、第2のデバイス120において符号化される第2のオーディオストリーム124を生成するように構成され得る。第2のオーディオストリーム124は、カンファレンスの第2の参加者(たとえば、第2のデバイス120のユーザ)からの音声、および/または第2のデバイス120での背景雑音を含み得る。第2のオーディオストリーム124はネットワークデバイス190に供給され得、ネットワークデバイス190は、第2のオーディオストリーム124(またはそのトランスコード/処理済みバージョン)を他のデバイス102、110、130に経路指定し得る。第3のデバイス130は、第3のデバイス130において符号化される第3のオーディオストリーム134を生成するように構成され得る。第3のオーディオストリーム134は、カンファレンスの第3の参加者(たとえば、第3のデバイス130のユーザ)からの音声、および/または第3のデバイス130での背景雑音を含み得る。第3のオーディオストリーム134はネットワークデバイス190に供給され得、ネットワークデバイス190は、第3のオーディオストリーム134(またはそのトランスコード/処理済みバージョン)を他のデバイス102、110、120に経路指定し得る。
【００１８】
各オーディオストリーム104、114、124、134がカンファレンスの特定のユーザ/参加者からの音声を含むものとして説明されるが、別の例では、1つまたは複数のオーディオストリーム104、114、124、134は、カンファレンスの複数の参加者からの音声を含み得る。たとえば、デバイスのうちの2つ以上が互いに相対的に極めて近接し得、カンファレンスの複数の参加者からの音声を「ピックアップ」し得る。追加または代替として、オーディオストリームは、単一のユーザ機器(たとえば、単一のモバイルデバイス)に関連付けられた複数のカンファレンス参加者からの音声を含み得る。たとえば、複数のカンファレンス参加者が単一のモバイル(または固定)デバイス内に話し得、モバイル(または固定)デバイスは、複数のカンファレンス参加者からの音声を含むオーディオストリームを生成し得る。例示のために、第1のオーディオストリーム114は、複数のスピーカからの音声を含む単一のオーディオストリームであり得る。たとえば、4人の人々が第1のデバイス110内に話している場合、第1のオーディオストリーム114は、モノオーディオストリーム、ステレオオーディオストリーム、4チャネルオーディオストリーム(たとえば、スピーカ当たり1チャネル)などであり得る。
【００１９】
前述のように、ネットワークデバイス190は、デバイス110、120、130からモバイルデバイス102にそれぞれ符号化オーディオストリーム114、124、134を経路指定し得る。本明細書で説明される技法によれば、モバイルデバイス102は、オーディオミキシングがネットワークデバイス190においてバイパスされるようにオーディオミキシングを実施し得る。モバイルデバイス102でのオーディオミキシングが、図2Aに関連してより詳細に説明される。したがって、オーディオストリーム114、124、134を復号化し、復号化オーディオストリームをミキシングしてミキシング済みオーディオストリームを生成し、ミキシング済みオーディオストリームを再符号化して再符号化オーディオストリームを生成し、再符号化オーディオストリームをモバイルデバイス102に供給する代わりに、ネットワークデバイス190は、各符号化オーディオストリーム114、124、134をモバイルデバイス102に経路指定し得る。
【００２０】
一例によれば、ネットワークデバイス190は、他のデバイス102、110、120、130間のシグナリング活動を実施するための「マスタスイッチ」として動作し得る。たとえば、ネットワークデバイス190は、デバイス102、110、120、130から、それぞれオーディオストリーム104、114、124、134を受信し得、オーディオストリーム104、114、124、134を中継することに関連するビットレート制御をネゴシエートし得る。オーディオストリームの受信時に、ネットワークデバイス190は、特定のオーディオストリームが特定のデバイスに経路指定されるビットレートをネゴシエートし得る。例示的、非限定的な例として、ネットワークデバイス190は、第1のオーディオストリーム114がモバイルデバイス102に供給される第1のビットレートと、第2のオーディオストリーム124がモバイルデバイス102に供給される第2のビットレートと、第3のオーディオストリーム134がモバイルデバイス102に供給される第3のビットレートとを(モバイルデバイス102と)ネゴシエートし得る。ネットワークデバイス190はまた、個々のデバイス能力に基づいて信号(たとえば、オーディオストリーム)が通信され得る帯域幅(たとえば、アップリンク帯域幅およびダウンリンク帯域幅)をネゴシエートすることができ得る。たとえば、各デバイス102、110、120、130のコーダ/デコーダ(CODEC)能力に基づいて、ネットワークデバイス190は、オーディオストリームが特定のデバイスに供給される帯域幅をネゴシエートすることができ得る。
【００２１】
ネットワークデバイス190でのオーディオミキシングをバイパスし、個々のデバイス102、110、120、および130においてオーディオミキシングを実施することは、普通ならネットワークデバイス190でのオーディオ処理チェーンに関連付けられ得る品質劣化を低減し得る。たとえば、ネットワークデバイス190での復号化演算、ネットワークデバイス190でのミキシング演算、およびネットワークデバイス190での再符号化演算によるオーディオ品質劣化が低減され得る。したがって、(ネットワークデバイス190ではなく)個々のデバイス102、110、120、および130においてオーディオミキシングを実施することによって、タンデムコーディング演算およびトランスコーディング演算がバイパスされ得る。さらに、両耳知覚の損失が低減され得る。たとえば、第1のオーディオストリーム114がステレオオーディオストリームであり、他のオーディオストリーム124、134がモノオーディオストリームである場合、個々のオーディオストリーム114、124、134がモバイルデバイス102に送られる場合、モバイルデバイス102は、第1のオーディオストリーム114のステレオ品質を保持し得る。しかしながら、ネットワークデバイス190においてオーディオミキシング(たとえば、復号化、ミキシング、および再符号化)を実施し、モバイルデバイス102にミキシング済みオーディオストリームを供給することは、第1のオーディオストリーム114のステレオ品質が「失われる」可能性を増加させ得る。たとえば、ネットワークデバイス190がオーディオミキシング中に第1のオーディオストリーム114のステレオ品質を保持するという保証はないことがある。
【００２２】
さらに、ネットワークデバイス190でのオーディオミキシングをバイパスすることは、オーディオ処理チェーン(たとえば、トランスコーディングチェーン)内の遅延を低減し得る。たとえば、ネットワークデバイス190においてオーディオミキシングを実施することは、オーディオ処理チェーンに遅延を追加するデジッタバッファをネットワークデバイス190がサポートすることを必要とし得る。ネットワークデバイス190でのオーディオミキシングをバイパスすることによって複数の再符号化も回避され得る。たとえば、モバイルデバイス102に対するミキシング済みストリームを生成するために、ネットワークデバイス190は、オーディオストリーム114、124、134を含む(またはそれから生成される)ミキシング済みオーディオストリームを再符号化し得る。別の例として、第1のデバイス110に対するミキシング済みストリームを生成するために、ネットワークデバイス190は、オーディオストリーム104、124、134を含む(またはそれから生成される)ミキシング済みオーディオストリームを再符号化し得る。他のデバイス120、130にミキシング済みオーディオを供給するために、同様の再符号化演算が実施され得る。システム100は、ネットワークデバイス190でのオーディオミキシングをバイパスすることによってそのような再符号化演算を回避し得る。
【００２３】
特定の実装では、図2A〜図4に関して説明されるように、モバイルデバイス102は、オーディオストリーム114、124、134に個別化頭部伝達関数(HRTF)を適用し得る。したがって、HRTFを使用して空間ステアリングが実施され得、「従来の」ステレオオーディオ機能を超える多重チャネルオーディオ(たとえば、左チャネルオーディオ、右チャネルオーディオ、またはそれらの組合せ)が可能となる。さらに、図2Aおよび図4に関して説明されるように、ネットワークデバイス190でのオーディオミキシングをバイパスすることは、モバイルデバイス102での頭部追跡特徴に基づく空間ステアリングを可能にし得る。カンファレンスがオーディオストリームおよびビデオストリームを含むシナリオでは、ビデオがネットワークデバイス190などのネットワークデバイスにおいてトランスコードされない場合、ネットワークデバイス190でのオーディオミキシングをバイパスすることはまた、モバイルデバイス102がオーディオおよびビデオを同期することを可能にし得る。
【００２４】
特定の実装では、記載のシステムおよび方法は、様々な技法を使用して実施され得る、コンファレンシングのためのオーディオ/ビデオ同期をサポートし得る。オーディオ/ビデオ同期の一例によれば、オーディオストリームおよび対応するビデオストリームは、ネットワークデバイス190においてトランスコードされ得る。オーディオ/ビデオ同期の別の例によれば、各デバイス102、110、120、130からのビデオストリームが、ネットワークデバイス190によってシステム100内の他のデバイスに中継され得、各デバイス102、110、120、130からのオーディオストリーム104、114、124、134が、ネットワークデバイス190においてトランスコードされ、ミキシング済みオーディオストリームが生成され得る。たとえば、ネットワークデバイス190は、オーディオストリーム114、124、134を含む(またはそれから生成される)ミキシング済みオーディオストリームを生成し得、ミキシング済みオーディオストリームをモバイルデバイス102に送り得る。ネットワークデバイス190はビデオストリームに対するトランスコーディング演算をバイパスするので、モバイルデバイス102に中継される(デバイス110、120、130に関連する)個々のビデオストリームは、デバイス110、120、130から生成されたタイムスタンプを有するRTPパケットを含み得る。しかしながら、ミキシング済みオーディオストリームは、ネットワークデバイス190でのトランスコーディング演算のために、ビデオストリームのタイムスタンプとは異なるタイムスタンプを有し得る。モバイルデバイス120は、ビデオストリームのタイムスタンプと、ミキシング済みオーディオストリームのタイムスタンプとの間の遅延を決定(たとえば、追跡)し得る。遅延を決定した後、モバイルデバイス102は、ミキシング済みオーディオストリームおよび/またはビデオストリームを調整して、オーディオとビデオとを同期し得る。
【００２５】
オーディオ/ビデオ同期の別の例によれば、各デバイス102、110、120、130からのビデオストリームが、ネットワークデバイス190によってシステム100内の他のデバイスに中継され得、各デバイス102、110、120、130からのオーディオストリーム104、114、124、134も、ネットワークデバイス190によってシステム100内の他のデバイスに中継され得る。この例によれば、オーディオおよびビデオについてのトランスコーディング演算が、ネットワークデバイス190においてバイパスされる。ビデオストリームおよびオーディオストリーム104、114、124、134が別々のRTPパケット内で送られるので、RTPビデオパケットと対応するRTPオーディオパケットとの間のドリフト(たとえば、遅延)があり得る。たとえば、第1のオーディオストリーム114のRTPオーディオパケットと、第1のデバイス110からの対応するRTPビデオパケットとは、異なるタイムスタンプを有し得る。RTPオーディオパケットおよび対応するRTPビデオパケットの受信時に、モバイルデバイス102は、RTPオーディオパケットと、対応するRTPビデオパケットとを同期し得る。
【００２６】
本明細書で説明される技法によれば、モバイルデバイス102は、ユーザ定義の設定、モバイルデバイス102のハードウェア能力、またはそれらの組合せに基づいて、カンファレンス中にモバイルデバイス102に供給される各オーディオストリーム114、124、134のビットレートおよび/または帯域幅を「ネゴシエートする」(たとえば、セッション記述プロトコル(SDP)ネゴシエーションを調整または実施する)ことができ得る。例示のために、モバイルデバイス102は、ネットワークデバイス190に第1の信号(図示せず)を供給して、第1のオーディオストリーム114がモバイルデバイス102に供給される第1のビットレートを調整し、ネットワークデバイス190に第2の信号(図示せず)を供給して、第2のオーディオストリーム124がモバイルデバイス102に供給される第2のビットレートを調整し、かつ/またはネットワークデバイス190に第3の信号(図示せず)を供給して、第3のオーディオストリーム134がモバイルデバイス102に供給される第3のビットレートを調整し得る。例示的、非限定的な例として、モバイルデバイス102は、モバイルデバイス102のユーザが、(たとえば、第1のデバイス110を使用しているカンファレンス参加者からの音声を強調するために)第1のオーディオストリーム114について、他のオーディオストリーム124、134よりも高い品質(たとえば、より高い帯域幅)を好むことを示すネットワークデバイス190信号を送り得る。
【００２７】
別の実装によれば、システム100内の各デバイスは、(たとえば、ネットワークデバイス190でのネゴシエーションをバイパスして)システム100内の他のデバイスと直接的にビットレートおよび/または帯域幅をネゴシエートし得る。非限定的な例として、モバイルデバイス102は、第1のオーディオストリーム114がモバイルデバイス102に供給される第1のビットレートを調整するように、第1のデバイス110と直接的にネゴシエートし得る。この非限定的な例によれば、ネットワークデバイス190は「管理デバイス」として動作し、着信オーディオストリーム104、114、124、134が受信されているビットレートを監視し得る。しかしながら、ネットワークデバイス190ではなく、デバイス102、110、120、130においてネゴシエーションが実施される。
【００２８】
特定のシナリオでは、ネットワークデバイス190は、「パケットバンドラ」として動作し得、システム100内の特定のデバイスについてのRTPパケットをバンドルし得る。例示のために、ネットワークデバイス190は、オーディオストリーム104、第2のオーディオストリーム124、および第3のオーディオストリーム134(たとえば、のパケット)を、第1のデバイス110に供給されるべき「バンドル化パケット」としてバンドルし得る。ネットワークデバイス190は、バンドル化パケット内にRTPヘッダを挿入し得、バンドル化パケットを第1のデバイス110に送り得る。このシナリオによれば、第1のデバイス110は、単一のデジッタバッファを利用して、ネットワークデバイス190から受信したバンドル化(RTP)パケットのストリームを処理し得る。ネットワークデバイス190は、バンドル化パケット内のデバイス識別子(ID)を割り当てて、どのオーディオストリーム104、124、134が各デバイス102、120、130に関連付けられたかに関して、第1のデバイス110内の処理要素に命令し得る。たとえば、バンドル内の各パケットは、パケットがどのデバイスによって生成されたかの識別子を含み得る。特定の実装では、バンドル内のパケットは、それ自体のタイムスタンプを含み得る。全体として、バンドルは、タイムスタンプを含むことがあり、または含まないことがある。したがって、特定の実装では、デジッタバッファ管理は、図2Aを参照しながらさらに説明されるように、イントラストリームタイムスタンプならびにインターストリームタイムスタンプを利用することを含み得る。
【００２９】
一例では、オーディオストリーム114、124、134を受信するためのモバイルデバイス102での帯域幅は、所与の時刻でのアクティブスピーカ数に依存し得る。たとえば、モバイルデバイス102(たとえば、帯域幅制限)のハードウェア能力に基づいて、モバイルデバイス102は、ネットワークデバイス190からオーディオを受信し、処理することについての帯域幅制限を有し得る。所与の時刻でのアクティブスピーカ数が増加するにつれて、モバイルデバイス102での利用可能なリソース(たとえば、ハードウェア)帯域幅は低下し得る。
【００３０】
帯域幅制限を緩和するために、カンファレンスは、所与の時刻でのアクティブスピーカ数を削減するように「自動制御」し得る。通常、同時に多くのアクティブスピーカは存在せず、そうでない場合、カンファレンス会話について行くことがますます困難になり得る。特定のデバイスでの参加者が所与の時刻において話していない場合、デバイスによって生成される、対応するオーディオストリーム内のデータフレームは、中断伝送(DTX)データフレームを含み得、背景雑音特性を示す、比較的低いビットレート(たとえば、約0.3キロビット/秒(kbps))を有し得る。たとえば、第1のデバイス110での第1の参加者が所与の時刻に無音である場合、第1のオーディオストリーム114の平均データレートは、8フレームごとに2.4kbpsフレームを送ることに基づいて、約0.3kbpsであり得る(たとえば、2.4kbps/8=0.3kbps)。
【００３１】
アクティブスピーカが、8フレームごとの頻度のプロトコルの信号インジケータ(SID)に従ってアップリンクビットレート13.2kbpsを有すると仮定する。1つの非限定的な例では、プロトコルは、エンハンスドボイスサービス(EVS:Enhanced Voice Service)プロトコルであり得る。1つのアクティブスピーカがあるとき(たとえば、第1のデバイス110での第1の参加者)、第1のデバイス110についての平均アップリンクビットレートは13.2kbpsであり得、他のデバイス102、120、130の各々についての平均アップリンクビットレートは0.3kbps(たとえば、DTXビットレート)であり得る。したがって、平均合計アップリンクネットワーク帯域幅は、約13.2+0.3+0.3+0.3=14.1kbpsであり得る。オーディオミキシングが(ネットワークデバイス190ではなく)参加者デバイスにおいて実施されるとき、モバイルデバイス102に対するダウンリンクビットレートは13.8kbpsであり、第1のデバイス110に対する平均ダウンリンクビットレートは0.9kbpsであり、第2のデバイス120に対する平均ダウンリンクビットレートは13.8kbpsであり、第3のデバイス130に対する平均ダウンリンクビットレートは13.8kbpsである。したがって、平均合計ダウンリンクビットレートは約42.3kbpsであり得る。平均合計ダウンリンクビットレートは、ミキシングがネットワークデバイス190において実施されるときの平均合計ダウンリンクビットレート未満であり得る。
【００３２】
カンファレンスの2人の参加者が所与の時刻において話しているとき、各アクティブスピーカは平均アップリンクビットレート13.2kbpsを有し得る。第1のデバイス110での第1の参加者と、第2のデバイス120での第2の参加者とが所与の時刻において話している場合、第1のデバイス110についての平均アップリンクビットレートは13.2kbpsであり得、第2のデバイス120についての平均アップリンクビットレートは13.2kbpsであり得る。他のデバイス102、130の各々についての平均アップリンクビットレートは0.3kbps(たとえば、DTXビットレート)であり得る。したがって、平均合計アップリンクネットワーク帯域幅は約27kbpsであり得る。オーディオミキシングが(ネットワークデバイス190ではなく)参加者デバイスにおいて実施されるとき、モバイルデバイス102に対する平均ダウンリンクビットレートは26.7kbpsであり、第1のデバイス110に対する平均ダウンリンクビットレートは13.8kbpsであり、第2のデバイス120に対する平均ダウンリンクビットレートは13.8kbpsであり、第3のデバイス130に対する平均ダウンリンクビットレートは26.7kbpsである。したがって、平均合計ダウンリンクビットレートは約82kbpsであり得る。ミキシングがネットワークデバイス190において実施されるとき、平均合計ダウンリンクビットレートは平均合計ダウンリンクビットレート未満であり得る。
【００３３】
前述のように、カンファレンスの「自動制御」の性質に加えて、モバイルデバイス102は、ユーザ定義の設定に基づいてダウンリンク帯域幅を削減するようにネットワークデバイス190に信号を送り得る。非限定的な例として、モバイルデバイス102のユーザが、第1のデバイス110の第1の参加者が何を言わなければないかを聴きたくない場合、ユーザは、モバイルデバイス102での帯域幅制限に関する制約を低減するために、より低いビットレート(たとえば、例示的、非限定的な例として9.6kbpsなどの、「次の」削減されたアクティブフレームコーディングレート)において第1のオーディオストリーム114を供給するようにネットワークデバイス190にシグナリングし得る。具体的には、オーディオについてのこの暗黙的フロア制御は、設定、およびレンダリングデバイスからネットワークデバイスへのシグナリングに基づき得る。たとえば、モバイルデバイス内のマルチストリームクライアントが、所与の時刻において同時に復号化することができるよりも多くのオーディオストリームを受信することが可能にされ得る。そのようなケースでは、端末内のマルチストリームクライアントは、どのストリームを優先順位付けさせるか、どれを無視するかを選ぶための手段を有し得る。この選択は、どのストリームがDTXモードにないかに基づいて行われ得る。メディアストリームはまた、オーディオストリームのアクティブレベルまたは音量に基づいて優先順位付けされ得る。しかしながら、このことは、最も音が大きいストリームを決定するために、各ストリームからのメディアの復号化を必要とする。あるいは、メディアストリームのサブセットが周期的に復号化され得、メディアストリーム当たりのアクティブレベルおよびフレームエネルギーの長期統計が、どのオーディオストリームを復号化するかを決定するために先験的に使用され得る。優先順位付けストリームは、レンダリングのために空間的にさらにミキシングされ得る。
【００３４】
オーディオミキシングが、ネットワークデバイス190ではなく、モバイルデバイス102において実施されるので、モバイルデバイス102は、受信した各オーディオストリーム114、124、134からのオーディオを同期して、カンファレンスの全体的オーディオ品質を保持するように構成され得る。そのような同期動作は、(たとえば、異なるオーディオストリームについての異なるネットワーク条件による)オーディオストリーム114、124、134を受信する際の変化する遅延量を補償するために使用され得る。図2Aに関してより詳細に説明されるように、モバイルデバイス102は、受信した各オーディオストリーム114、124、134から受信したオーディオを同期するために制御信号を生成するように構成される「遅延コントローラ」を含み得る。たとえば、遅延コントローラは、フレーム誤り率(FER)を満たすために、対応するオーディオストリーム114、124、134を受信する(モバイルデバイス102内の)各デジッタバッファについての平均遅延がほぼ同一となるように動作し得る。非限定的な例として、遅延コントローラは、デジッタバッファについての平均遅延が3フレーム、5フレーム、7フレームなどであることを保証し得る。
【００３５】
図1Aのシステム100は、モバイルデバイス102において(同様に、デバイス110、120、130において)オーディオ処理(たとえば、ミキシング)を実施することによって、普通ならネットワークデバイス190でのオーディオ処理チェーンに関連付けられ得る品質劣化を低減し得る。たとえば、ネットワークデバイス190での復号化演算、ネットワークデバイス190でのミキシング演算、およびネットワークデバイス190での再符号化演算によるオーディオ品質劣化が低減され得る。したがって、個々のデバイス102、110、120、130においてオーディオミキシングを実施することによって、トランスコーディング演算がバイパスされ得る。
【００３６】
図1Bを参照すると、カンファレンス中のオーディオを管理するように動作可能である別のシステム153の特定の実装が示されている。システム153は、モバイルデバイス102、第1のデバイス110、第2のデバイス120、および第3のデバイス130を含む。
【００３７】
システム153は、図1Aのシステム100とほぼ同様に動作し得る。しかしながら、システム153内のオーディオストリーム104、114、124、134が、中央ネットワーキングシステム(たとえば、図1Aのネットワークデバイス190)なしにデバイスからデバイスに経路指定され得る。したがって、ネットワークデバイス190での経路指定に関連する遅延が、図1Bのシステム153では低減され得る。
【００３８】
図1Cを参照すると、カンファレンス中のオーディオを管理するように動作可能である別のシステム170の特定の実装が示されている。システム170は、モバイルデバイス102、第1のデバイス110、第2のデバイス120、第3のデバイス130、第4のデバイス140、第5のデバイス150、およびゲートウェイ180(たとえば、ネットワークミキサ)を含む。一実装によれば、ゲートウェイ180はモバイルデバイスであり得る。別の実装によれば、ゲートウェイ180は固定デバイスであり得る。
【００３９】
図1Cの例示では、第4のデバイス140および第5のデバイス150はレガシーデバイスである。たとえば、レガシーデバイス140、150は、(たとえば、レガシーデバイス140、150でのリソース制約のために)他のデバイス102、110、120、130に関して図1A〜図1Bで説明される方式で複数のオーディオストリームのオーディオミキシングを実施することができないことがある。むしろ、レガシーデバイス140、150は、他のデバイスのオーディオストリーム104、114、124、134を含む(またはそれから生成される)単一のオーディオストリーム(たとえば、ミキシング済みオーディオストリーム184)を受信するように構成され得る。例示のために、ネットワークデバイス190は、ゲートウェイ180にオーディオストリーム104、114、124、134を中継し得る。ゲートウェイ180は、オーディオストリーム104、114、124、134に関するオーディオミキシングを実施して、ミキシング済みオーディオストリーム184を生成し得る。ミキシング済みオーディオストリーム184を生成した後、ゲートウェイ180は、ミキシング済みオーディオストリーム184を第4のデバイス140および第5のデバイス150に中継し得る。
【００４０】
第4のデバイス140は、第4のデバイス140において符号化される第4のオーディオストリーム144を生成するように構成され得る。第4のオーディオストリーム144は音声(たとえば、ユーザ音声)および/または背景雑音を含み得る。第4のオーディオストリーム144は、ゲートウェイ180に供給され得、ゲートウェイ180は、第4のオーディオストリーム144(またはそのトランスコード/処理済みバージョン)をネットワークデバイス190に経路指定し得、ネットワークデバイス190は、第4のオーディオストリーム144(またはそのトランスコード/処理済みバージョン)を他のデバイス102、110、120、130に経路指定し得る。第5のデバイス150は、第5のデバイス150において符号化される第5のオーディオストリーム154を生成するように構成され得る。第5のオーディオストリーム154は音声(たとえば、ユーザ音声)および/または背景雑音を含み得る。第5のオーディオストリーム154はゲートウェイ180に供給され得、ゲートウェイ180は、オーディオストリーム154(またはそのトランスコード/処理済みバージョン)をネットワークデバイス190に経路指定し得、ネットワークデバイス190は、第5のオーディオストリーム154(またはそのトランスコード/処理済みバージョン)を他のデバイス102、110、120、130に経路指定し得る。
【００４１】
図1Cは、ゲートウェイ180が第4のオーディオストリーム144および第5のオーディオストリーム154を別々のオーディオストリームとして経路指定することを示すが、別の実装では、ゲートウェイ180は、第4のオーディオストリーム144および第5のオーディオストリーム154に関するオーディオミキシングを実施して、ミキシング済みオーディオストリームを生成し得る。ミキシング済みオーディオストリームは、ネットワークデバイス190に経路指定され得、ネットワークデバイス190は、ミキシング済みオーディオストリームを他のデバイス102、110、120、130に中継し得る。
【００４２】
さらに、図1Cは、第4のデバイス140および第5のデバイス150が同一のミキシング済みオーディオストリーム184を受信することを示すが、別の実装では、第4のデバイス140および第5のデバイス150は、異なるミキシング済みオーディオストリームを受信し得る。たとえば、第4のデバイス140によって受信されるミキシング済みオーディオストリームは、それぞれデバイス102、110、120、130、150からのオーディオストリーム104、114、124、134、154を含み得る(またはそれから生成され得る)。したがって、ゲートウェイ180は、第5のオーディオストリーム154を他のオーディオストリーム104、114、124、134とミキシングして、ミキシング済みオーディオストリームを第4のデバイス140に供給するように構成され得る。同様に、第5のデバイス150によって受信されるミキシング済みオーディオストリームは、それぞれデバイス102、110、120、130、140からのオーディオストリーム104、114、124、134、144を含み得る(またはそれから生成され得る)。したがって、ゲートウェイ180は、第4のオーディオストリーム144を他のオーディオストリーム104、114、124、134とミキシングして、ミキシング済みオーディオストリームを第5のデバイス150に供給するように構成され得る。
【００４３】
図2Aを参照すると、モバイルデバイス102の特定の実装が示されている。モバイルデバイス102は、遅延コントローラ202、第1のバッファ210、第1のデコーダ212、第2のバッファ220、第2のデコーダ222、第3のバッファ230、第3のデコーダ232、空間ステアリングプロセッサ240、および頭部追跡モジュール250を含む。図2Aはモバイルデバイス102の構成要素を示すが、カンファレンスに関連付けられた他のデバイス110、120、130内に類似の構成要素が含まれ得ることに留意されたい。
【００４４】
一例では、各バッファ210、220、230は、対応するオーディオストリームをバッファリングするように構成されるデジッタバッファであり得る。たとえば、第1のバッファ210は、カンファレンスの第1の参加者に関連付けられた第1のデバイス110から第1のオーディオストリーム114(たとえば、第1のリアルタイム転送プロトコル(RTP)パケット)を受信し得、第2のバッファ220は、カンファレンスの第2の参加者に関連付けられた第2のデバイス120から第2のオーディオストリーム124(たとえば、第2のRTPパケット)を受信し得、第3のバッファ230は、カンファレンスの第3の参加者に関連付けられた第3のデバイス130から第3のオーディオストリーム134(たとえば、第3のRTPパケット)を受信し得る。別の実装によれば、第1のバッファ210は、図1Aのネットワークデバイス190から第1のオーディオストリーム114を受信し得、第2のバッファ220は、ネットワークデバイス190から第2のオーディオストリーム124を受信し得、第3のバッファ230は、ネットワークデバイス190から第3のオーディオストリーム134を受信し得る。この実装(たとえば、「ネットワークリレー」実装)によれば、第1のバッファ210によって受信された第1のオーディオストリーム114のRTPタイムスタンプが、第1のデバイス110によって与えられたRTPタイムスタンプと同一であり、第2のバッファ220によって受信された第2のオーディオストリーム124のRTPタイムスタンプが、第2のデバイス120によって与えられたRTPタイムスタンプと同一であり、第3のバッファ230によって受信された第3のオーディオストリーム134のRTPタイムスタンプが、第3のデバイス130によって与えられたRTPタイムスタンプと同一である。
【００４５】
図2Aのモバイルデバイス102が、3つの対応するオーディオストリーム114、124、134のための3つのバッファ210、220、230を含むように示されているが、図1Aに関して上記で説明されたように、代替実装では、図1Aのネットワークデバイス190は、オーディオストリーム114、124、134のパケットをバンドルして、バンドル化オーディオストリームを生成し得、バンドル化オーディオストリームの各パケットは、バンドルパケットについてのRTPヘッダに加えて、個々のオーディオストリーム114、124、134からのパケットを含む。このシナリオでは、モバイルデバイス102は、バンドル化オーディオストリームのパケットを受信するように構成される単一のバッファ(たとえば、単一のデジッタバッファ)を利用し得る。たとえば、バンドル化オーディオストリームのパケットは、RTPヘッダと、第1のデバイス110に割り当てられた第1のIDによって識別される(第1のオーディオストリーム114に対応する)第1のRTPパケットと、第2のデバイス120に割り当てられた第2のIDによって識別される(第2のオーディオストリーム124に対応する)第2のRTPパケットと、第3のデバイス130に割り当てられた第3のIDによって識別される(第3のオーディオストリーム134に対応する)第3のRTPパケットとを含み得る。バンドル化パケットについてのRTPヘッダはタイムスタンプを含み得る。代替または追加として、第1、第2、第3のRTPパケットは、それ自体のRTPヘッダおよびタイムスタンプを含み得る。
【００４６】
第1のバッファ210は、第1のオーディオストリーム114をバッファリングし、第1のデコーダ212に第1のバッファリング済みオーディオ214を出力するように構成され得る。第2のバッファ220は、第2のオーディオストリーム124をバッファリングし、第2のデコーダ222に第2のバッファリング済みオーディオ224を出力するように構成され得る。第3のバッファ230は、第3のオーディオストリーム134をバッファリングし、第3のデコーダ232に第3のバッファリング済みオーディオ234を出力するように構成され得る。各バッファ210、220、230は参照遅延計算アルゴリズム(RDCA:reference delay calculation algorithm)を含み得る。たとえば、第1のバッファ210は第1のRDCA211を含み得、第2のバッファ220は第2のRDCA221を含み得、第3のバッファ230は第3のRDCA231を含み得る。各RDCA211、221、231は、命令を実行する(たとえば、対応するバッファ210、220、230内の)プロセッサによって実装され得る。各バッファ210、220、230についての遅延は、対応するRDCA211、221、231に基づき得る。以下で説明されるように、遅延コントローラ202は、FERを満たすために各バッファ210、220、230についての平均遅延がほぼ同一となるように動作し得る。たとえば、遅延コントローラ202は、第1のバッファリング済みオーディオ214、第2のバッファリング済みオーディオ224、および第3のバッファリング済みオーディオ234がほぼ同期されることを保証するために、各RDCA211、221、231を修正するように構成され得る。
【００４７】
遅延コントローラ202(たとえば、デジッタバッファシンクロナイザ)は、各バッファ210、220、230に供給される制御信号204を生成するように構成され得る。制御信号204に基づいて、バッファ210、220、230は、第1のバッファリング済みオーディオ214、第2のバッファリング済みオーディオ224、および第3のバッファリング済みオーディオ234の出力を同期し得る。あるいは、異なる制御信号が、バッファ210、220、230の各々に供給され得る。一実装によれば、遅延コントローラ202は、各バッファ210、220、230内の遅延を決定し得る。たとえば、第1のRDCA211に基づいて、第1のバッファ210は、第1のバッファ210内の第1の遅延を決定し得、フィードバック信号205を介して、第1の遅延に関連する情報を遅延コントローラ202に供給し得る。第2のバッファ220は、第2のRDCA221に基づいて第2のバッファ220内の第2の遅延を決定し得、フィードバック信号205を介して、第2の遅延に関連する情報を遅延コントローラ202に供給し得る。さらに、第3のバッファ230は、第3のRDCA231に基づいて第3のバッファ230内の第3の遅延を決定し得、フィードバック信号205を介して、第3の遅延に関連する情報を遅延コントローラ202に供給し得る。第1、第2、および第3の遅延は、個々のオーディオストリーム内のイントラストリームタイムスタンプに基づいて決定され得る。非限定的な例として、第1の遅延は、第1のオーディオストリーム114内のRTPタイムスタンプに基づき得る(たとえば、第1の遅延は、他のオーディオストリーム124、134内のRTPタイムスタンプとは無関係であり得る)。
【００４８】
遅延コントローラ202は、第1、第2、および第3の遅延についての情報を使用して、制御信号204を生成し得る。単一の制御信号が図2Aに示されているが、第1の制御信号が第1のバッファ210に供給され得、第2の制御信号が第2のバッファ220に供給され得、第3の制御信号が第3のバッファ230に供給され得る。制御信号204(または複数の制御信号)は、各バッファ210、220、230がほぼ同様の平均遅延を有するように、「加速し」、遅延を増大させ、または現遅延を維持するように各バッファ210、220、230に命令し得る。バッファを「加速する」ことは、1つまたは複数のフレームを「ドロップする」ようにバッファに命令することを含み得る。例示のために、第1のバッファ210は、2つのフレームの平均遅延を有し得、第2のバッファ220は、4つのフレームの平均遅延を有し得、第3のバッファ230は、6つのフレームの平均遅延を有し得る。これらの統計に基づいて、遅延コントローラ202は、各バッファ210、220、230が約4フレームの平均遅延を有するように、第1のバッファ210にその平均遅延を2フレームだけ増大させるように命令し、第2のバッファ220にその平均遅延を維持するように命令し、第3のバッファ230にその平均遅延を2フレームだけ加速するように命令し得る。さらに、バッファリソースが遅延調整に基づいて再割振りされ得る。たとえば、第1のバッファ210がその平均遅延を2フレームだけ増大させる必要があり、第3のバッファ230がその遅延を2フレームだけ削減する必要があるので、第3のバッファ230と第1のバッファ210との間でバッファリソースが再割振りされ得る。
【００４９】
したがって、遅延コントローラ202は、イントラストリームタイムスタンプに加えてインターストリームタイムスタンプを使用して、各バッファ210、220、230の遅延を調整し得る。たとえば、各バッファ210、220、230についての遅延が、各バッファ210、220、230の平均遅延を比較することに基づいて調整され得、各バッファ210、220、230の平均遅延は、対応するオーディオストリーム114、124、134のRTPタイムスタンプに基づく。例示的、非限定的な例として、3つのデバイス「A」、「B」、および「C」から受信した様々なRTPパケットのタイムスタンプが、t(A,1)、t(A,2)、t(A,3)...t(A,N);t(B,1)、t(B,2)、t(B,3)...t(B,N);t(C,1)、t(C,2)、t(C,3)...t(C,N)であり得る。イントラストリームタイムスタンプは、同一のRTPストリームの2つのパケット間の時間差(たとえば、t(A,2)およびt(A,1))に対応し得る。遅延コントローラ202は、ストリーム内の平均遅延およびストリーム間のインターストリーム遅延を決定および/または使用して、制御信号204を生成し得る。
【００５０】
別の実装によれば、遅延コントローラ202は、第1のオーディオストリーム114(たとえば、第1のRTPパケット)の第1のタイムスタンプ、第2のオーディオストリーム124(たとえば、第2のRTPパケット)の第2のタイムスタンプ、および第3のオーディオストリーム134(たとえば、第3のRTPパケット)の第3のタイムスタンプを比較し得る。一例では、第1、第2、および第3のタイムスタンプは、102、110、120、および130に(たとえば、タイミングサーバまたは他のクロックソースによって)供給される共通クロックソース(たとえば、グローバルクロックソース)に基づき得る。オーディオストリーム114、124、134のタイムスタンプは、図1Aのネットワークデバイス190によって変更されずに、モバイルデバイス102によって受信され得る。遅延コントローラ202は、第1のタイムスタンプと第2のタイムスタンプとの間の第1の時間差、第2のタイムスタンプと第3のタイムスタンプとの間の第2の時間差、および第3のタイムスタンプと第1のタイムスタンプとの間の第3の時間差を決定し得る。
【００５１】
特定の実装では、遅延コントローラ202は、相異なるバッファからの個々のパケットを比較することに基づいて時間差を決定する。たとえば、第1の時間差は、第1のバッファ210内の「最初期の」パケット(たとえば、出力されるべき次のパケット)のタイムスタンプと、第2のバッファ220内の最初期のパケットのタイムスタンプとの差に対応し得る。同様に、第2の時間差は、第2のバッファ220内の最初期のパケットのタイムスタンプと、第3のバッファ230内の最初期のパケットのタイムスタンプとの間の差に対応し得る。第3の差は、第3のバッファ230内の最初期のパケットのタイムスタンプと、第1のバッファ210内の最初期のパケットのタイムスタンプとの差に対応し得る。
【００５２】
時間差に基づいて、遅延コントローラ202は、バッファリング済みオーディオ214、224、234がそれぞれバッファ210、220、230からいつ出力されるかを制御するための制御信号204を生成し得、その結果、バッファリング済みオーディオ214、224、234が同期される。たとえば、制御信号204(または前述の複数の制御信号)は、同一のタイムスタンプを有するバッファ210、220、および230内のパケット/フレームを、そのようなパケット/フレームがモバイルデバイス102によって実際にいつ受信されたかの如何にかかわらず、ほぼ同時に出力させ得る。パケットがバッファ210、220、230のうちの1つから出力された後、遅延コントローラ202は、時間差のうちの1つまたは複数を再計算し、それに応じて制御信号204を修正し得る。バッファリング済みオーディオ214、224、234を同期するための制御信号204を生成することによって、遅延コントローラ202は、バッファ210、220、230にわたって平均遅延を同程度にすることなどによって、バッファ210、220、230の各々がカンファレンス中の3GPP技術仕様(TS)26.114平均遅延要件を満たすのを援助し得る。
【００５３】
第1のバッファリング済みオーディオ214を第2のバッファリング済みオーディオ224と同期する非限定的な例示として、第1のタイムスタンプが第2のタイムスタンプよりも早い時刻を示す場合、遅延コントローラ202は、第1のバッファリング済みオーディオ214(たとえば、第1のバッファリング済みオーディオ214の次のパケット)の出力を第1の時間差だけ遅延するように第1のバッファ210に(制御信号204を介して)指示し得る。第2のタイムスタンプが第1のタイムスタンプよりも早い時刻を示す場合、遅延コントローラ202は、第2のバッファリング済みオーディオ224(たとえば、第2のバッファリング済みオーディオ224の次のパケット)の出力を第1の時間差だけ遅延するように第2のバッファ220に(制御信号204を介して)指示し得る。
【００５４】
したがって、遅延コントローラ202は、TS26.114最小性能ジッタバッファ管理(JBM)遅延要件がマルチセッション(たとえば、カンファレンス)中に満たされるように、各々の個々のバッファ210、220、230の性能を監視するように構成され得る。さらに、遅延コントローラ202は、「バッファ処理」が効率的に実施されるように、各バッファ210、220、230内のRDCA211、221、231に追加のタイムスタンプ調整情報を供給し得る。前述のように、遅延コントローラ202は、各バッファ210、220、230内で実行中のRDCA211、221、231から、フィードバック信号205を介してイントラタイムスタンプ特性を受信し得、遅延コントローラ202は、バッファ210、220、230を管理する際にそのような情報を使用し得る。したがって、バッファ遅延を管理するための「閉ループ」方法が実装され得る。
【００５５】
第1のバッファリング済みオーディオ214を受信したことに応答して、第1のデコーダ212は、第1のバッファリング済みオーディオ214を復号化して、第1の復号化オーディオ216を生成し得る。第1の復号化オーディオ216は空間ステアリングプロセッサ240に供給され得る。しかしながら、第1のバッファリング済みオーディオ214内のフレームが(たとえば、背景雑音および/または無音に対応する)DTX(またはNODATA)フレームである場合、第1のデコーダ212での復号化演算がバイパスされ、電力消費が削減され、処理リソースが節約され得る。復号化演算がフレームについてスキップされるとき、以前に復号化されたアクティブフレームについての復号化状態/メモリが、次のアクティブなフレームをその後で復号化する際に使用するために維持され得る。第2のバッファリング済みオーディオ224を受信したことに応答して、第2のデコーダ222は、第2のバッファリング済みオーディオ224を復号化して、第2の復号化オーディオ226を生成し得る。第2の復号化オーディオ226も、空間ステアリングプロセッサ240に供給され得る。第2のバッファリング済みオーディオ224内のフレームがDTX(またはNODATA)フレームである場合、第2のデコーダ222での復号化演算がバイパスされ、電力消費が削減され、処理リソースが節約され得る。第3のバッファリング済みオーディオ234を受信したことに応答して、第3のデコーダ232は、第3のバッファリング済みオーディオ234を復号化して、第3の復号化オーディオ236を生成し得る。第3の復号化オーディオ236は、空間ステアリングプロセッサ240にさらに供給され得る。第3のバッファリング済みオーディオ234内のフレームがDTXフレームである場合、第3のデコーダ232での復号化演算がバイパスされ、電力消費が削減され、処理リソースが節約され得る。特定の実装では、モバイルデバイス102は、RTPパケット長に基づいてフレーム(たとえば、パケット)がDTX(またはNODATA)フレームであるかどうかを決定し得る。
【００５６】
空間ステアリングプロセッサ240は、第1の復号化オーディオ216に対する第1の空間ステアリング演算を実施して、第1の復号化オーディオ216をスピーカから第1の角度(α1)に投射するように構成され得る。たとえば、空間ステアリングプロセッサ240は、第1の復号化オーディオ216に第1のHRTF242を適用して、第1の角度(α1)に従って第1の復号化オーディオ216をステアリング(たとえば、パン)し得る。第1の角度(α1)に従って第1の復号化オーディオ216をステアリングすることの例示が図3に示されている。第1のHRTF242はまた、空間ステアリングプロセッサ240によって使用され、第1の復号化オーディオ216の第1の利得が調整され得る。一実装によれば、第1の利得および第1の角度(α1)は、モバイルデバイス102でのユーザ定義の設定に基づいて調整され得る。たとえば、第1のデバイス110に関連付けられた第1の参加者からの音声がカンファレンスの他の参加者に関連付けられた音声よりも重要であるとユーザが判定する場合、ユーザは、第1の復号化オーディオ216の第1の利得を増加させるようにモバイルデバイス102に指示し得る。ユーザ指示に基づいて、空間ステアリングプロセッサ240は、第1のHRTF242を使用して、第1の復号化オーディオ216の第1の利得を増加させ得る。
【００５７】
空間ステアリングプロセッサ240はまた、第2の復号化オーディオ226に対する第2の空間ステアリング演算を実施して、第2の復号化オーディオ226をスピーカから第2の角度(α2)に投射するように構成され得る。たとえば、空間ステアリングプロセッサ240は、第2の復号化オーディオ226に第2のHRTF244を適用して、第2の角度(α2)に従って第2の復号化オーディオ226をステアリング(たとえば、パン)し得る。第2の角度(α2)に従って第2の復号化オーディオ226をステアリングすることの例示が図3に示されている。第2のHRTF244はまた、空間ステアリングプロセッサ240によって使用され、第2の復号化オーディオ226の第2の利得が調整され得る。一実装によれば、第2の利得および第2の角度(α2)は、モバイルデバイス102でのユーザ定義の設定に基づいて調整され得る。たとえば、第2のデバイス120に関連付けられた第2の参加者からの音声がカンファレンスの他の参加者に関連付けられた音声よりも重要ではないとユーザが判定する場合、ユーザは、第2の復号化オーディオ226の第2の利得を低減する(または第2の復号化オーディオ226をミュートする)ようにモバイルデバイス102に指示し得る。ユーザ指示に基づいて、空間ステアリングプロセッサ240は、第2のHRTF244を使用して、第2の復号化オーディオ226の第2の利得を低減し得る。
【００５８】
空間ステアリングプロセッサ240はまた、第3の復号化オーディオ236に対する第3の空間ステアリング演算を実施して、第3の復号化オーディオ236をスピーカから第3の角度(α3)に投射するように構成され得る。たとえば、空間ステアリングプロセッサ240は、第3の復号化オーディオ236に第3のHRTF246を適用して、第3の角度(α3)に従って第3の復号化オーディオ236をステアリング(たとえば、パン)し得る。第3の角度(α3)に従って第3の復号化オーディオ236をステアリングすることの例示が図3に示されている。第3のHRTF246はまた、空間ステアリングプロセッサ240によって使用され、第3の復号化オーディオ236の第3の利得が調整され得る。一実装によれば、第3の利得および第3の角度(α3)は、モバイルデバイス102でのユーザ定義の設定に基づいて調整され得る。たとえば、第3のデバイス130に関連付けられた第3の参加者からの音声がカンファレンスの他の参加者に関連付けられた音声よりも重要ではないとユーザが判定する場合、ユーザは、第3の復号化オーディオ236の第3の利得を低減する(または第3の復号化オーディオ236をミュートする)ようにモバイルデバイス102に指示し得る。ユーザ指示に基づいて、空間ステアリングプロセッサ240は、第3のHRTF246を使用して、第3の復号化オーディオ236の第3の利得を低減し得る。
【００５９】
各HRTF242、244、246は汎用であり、またはモバイルデバイス102のユーザによって「個別化」され得る。たとえば、着信オーディオストリーム114、124、134の数に基づいて、モバイルデバイス102のハードウェア能力に基づいて、ユーザは、特定のオーディオストリーム114、124、134が投射されるべき位置(たとえば、角度)を指示し得る。したがって、第1のHRTF242は第2のHRTF244とは異なり得、第2のHRTF244は第3のHRTF246とは異なり得る。たとえば、ユーザは、「スピーカ」の左側(たとえば、ユーザの知覚されるリスニングフィールド)に第1の復号化オーディオ216を投射するように(第1のHRTF242を介して)モバイルデバイス102に指示し、スピーカの右側に第2の復号化オーディオ226を投射するように(第2のHRTF244を介して)モバイルデバイス102に指示し、中央に第3の復号化オーディオ236を投射するように(第3のHRTF246を介して)モバイルデバイス102に指示し得る。別の実装では、ネットワークミキサ(たとえば、図1Aのネットワークデバイス190)がオーディオミキシングを実施している場合、ユーザは、特定のHRTFを使用するようにネットワークミキサに指示し得る。たとえば、ネットワークデバイス190または別のネットワークミキサにHRTFを実装し得、HRTFは、カンファレンスセットアップ中にネゴシエートされ得る。
【００６０】
したがって、空間ステアリングプロセッサ240は、復号化オーディオ216、226、236にそれぞれHRTF242、244、246を適用して、復号化オーディオ216、226、236を空間的にステアリングし得、それによって、復号化オーディオ216、226、236に関連付けられたカンファレンス参加者が、特定の構成で空間的に分散しているように見える。HRTF242、244、246は、モバイルデバイス102においてオーディオパニングを実施するように使用され得る。カンファレンスの複数の参加者が話しているとき、オーディオパニングは、モバイルデバイス102のユーザに対する「疲労」を低減し得る。たとえば、第1の参加者(たとえば、第1の復号化オーディオ216に関連付けられた参加者)と、第3の参加者(たとえば、第3の復号化オーディオ236に関連する参加者)とが同時に話している場合、オーディオパニングは、第1の参加者がある位置において話しており、第3の参加者が別の位置において話しているようにユーザに見えるようにさせ得、そのことは、ユーザが受ける疲労を低減し得る。
【００６１】
オーディオパニングはまた、HRTFミキシングの前に(たとえば、以下で説明されるように、ステレオ信号270を生成する前に)モバイルデバイス102のユーザが参加者のオーディオレベル(たとえば、利得)を変更することを可能にし得る。たとえば、モバイルデバイス102のユーザは、他の参加者のオーディオと比較して、第1の参加者のオーディオ(たとえば、第1の復号化オーディオ216)により高い重要性を与え得、各HRTF242、244、246内のミキシング利得を選択的に調整し得る。一例では、複数の参加者が同時に話しているとき、モバイルデバイス102のユーザは、第1の復号化オーディオ216を除いて、復号化オーディオ226、236のすべてをミュートし得る。図1Aに関して説明されたように、モバイルデバイス102のユーザはまた、モバイルデバイス102の話者プリファレンスおよびハードウェア能力に基づいて、各オーディオストリーム114、124、134についてのビットレートおよびオーディオ帯域幅を管理するようにネットワークデバイス190にシグナリングし得る。
【００６２】
特定の実装では、モバイルデバイス102での空間処理が、頭部追跡データ(たとえば、モバイルデバイス102のユーザに関連付けられた頭部移動を示すデータ)に基づいてさらに改善され得る。たとえば、頭部追跡モジュール250は、モバイルデバイス102のユーザの頭部のシフト(たとえば、回転)を追跡し得る。たとえば、頭部追跡モジュール250は、ユーザの頭部の向きを追跡し、(たとえば、その向きのシフト量(β)を示す)信号を空間ステアリングプロセッサ240に供給し得る。空間ステアリングプロセッサは、復号化オーディオ216、226、236がスピーカにおいて投射されるそれぞれの角度に対処するように、シフト量(β)だけ各HRTF242、244、246を調整し得る。したがって、空間ステアリングプロセッサ240は、第1の角度(α1)およびシフト量(β)を第1のHRTF242についての入力として使用し、第2の角度(α2)およびシフト量(β)を第2のHRTF244についての入力として使用し、第3の角度(α3)およびシフト量(β)を第3のHRTF246についての入力として使用し得る。
【００６３】
空間ステアリングプロセッサ240は、それぞれのHRTF242、244、246によって調整される各復号化オーディオ216、226、236を含むステレオ信号270を出力(たとえば、スピーカに供給)し得る。図2Aは、ステレオ信号270が空間ステアリングプロセッサ240によって出力されることを示すが、別の実装では、空間ステアリングプロセッサ240が3つのモノ信号(図示せず)を出力し得る。たとえば、第1のモノ信号は、第1のHRTF242によって調整される第1の復号化オーディオ216を含み得、第2のモノ信号は、第2のHRTF244によって調整される第2の復号化オーディオ226を含み得、第3のモノ信号は、第3のHRTF246によって調整される第3の復号化オーディオ236を含み得る。
【００６４】
図2Aのモバイルデバイス102は、バッファリング済みオーディオ214、224、234を同期することによってカンファレンス中の3GPPTS26.114遅延要件を満たし得る。たとえば、遅延コントローラ202は、対応するオーディオストリーム114、124、134のRTPパケット内のタイムスタンプに基づいてバッファリング済みオーディオ214、224、234を同期するための制御信号204を生成し得る。さらに、カンファレンスの複数の参加者が同時に話しているとき、モバイルデバイス102は、オーディオパニングが「疲労」を低減することを可能にし得る。たとえば、モバイルデバイス102は、復号化オーディオ216、226、236を空間的にステアリングし得、それによって、復号化オーディオ216、226、236に関連付けられたカンファレンス参加者が、空間的に分散するように見える。
【００６５】
図2Bを参照すると、モバイルデバイス102の別の実装が示されている。図2Aに示される構成要素に加えて、図2Bに示されるモバイルデバイス102は、第Nのバッファ280と、第Nのデコーダ282と、空間ステアリングプロセッサ240内に実装される第NのHRTF284とを含み得る。したがって、記載のシステムおよび方法によれば、デバイスは、(たとえば、バンドル化RTPストリームを処理するケースでは)単一のデジッタバッファ、2つのデジッタバッファ、3つのデジッタバッファ、またはN個のデジッタバッファ(たとえば、Nは4以上の整数である)を利用し得る。たとえば、Nが7に等しい場合、図2Bに示されるモバイルデバイス102は、(7つの対応するオーディオストリームを受信するように構成された)7つのバッファと、7つのデコーダと、空間ステアリングプロセッサ240内に実装された7つのHRTFとを含み得る。
【００６６】
第Nのバッファ280は、バッファ210、220、230とほぼ同様に動作し得る。たとえば、第Nのバッファは、カンファレンス内のデバイスから(または図1Aのネットワークデバイス190から)第Nのオーディオストリーム292を受信し、制御信号204を基づいて第Nのバッファリング済みオーディオ294を出力するように構成され得る。第Nのバッファリング済みオーディオ294は、それぞれ他のバッファ210、220、230からのバッファリング済みオーディオ214、224、234と同期され得る。第Nのデコーダ282は、デコーダ212、222、232とほぼ同様に動作し得る。たとえば、第Nのデコーダ232は、第Nのバッファリング済みオーディオ294を復号化して、第Nの復号化オーディオ296を生成し得る。第Nの復号化オーディオ296は空間ステアリングプロセッサ240に供給され得る。空間ステアリングプロセッサ240はまた、第Nの復号化オーディオ296に対する第Nの空間ステアリング演算を実施して、第Nの復号化オーディオ296をスピーカから第Nの角度(αN)に投影するように構成され得る。たとえば、空間ステアリングプロセッサ240は、第NのHRTF284を第Nの復号化オーディオ296に適用して、第Nの角度(αN)に従って第Nの復号化オーディオ296をステアリング(たとえば、パン)し得る。
【００６７】
図3を参照すると、HRTF242、244、246を適用した後の復号化オーディオ216、226、236の空間配置の一例を示す図が示されている。特定の実装では、HRTF242、244、246は、「好ましい」仮想スピーカ位置割当てに基づいて事前計算され得る。たとえば、第1のHRTF242は、スピーカの左側から来る(たとえば、第1の角度(α1)から来る)かのように知覚されるように第1の復号化オーディオ216を空間的にステアリングし得る。同様に、第2のHRTF244は、スピーカの左中央側から来る(たとえば、第2の角度(α2)から来る)ように知覚されるように第2の復号化オーディオ226を空間的にステアリングし得、第3のHRTF246は、スピーカの右側から来る(たとえば、第3の角度(α3)から来る)かのように知覚されるように第3の復号化オーディオ236を空間的にステアリングし得る。図2Aに関して説明されたように、HRTF242、244、246はまた、他のスピーカと比較して「好ましい」スピーカを強調するための利得制御をも含み得る。
【００６８】
図4を参照すると、HRTF242、244、246、および頭部追跡データを適用した後の復号化オーディオ216、226、236の空間配置の一例を示す図が示されている。図4では、頭部追跡モジュール250は、シフト量(β)だけシフトされたユーザの頭部を検出し得る。頭部追跡情報に基づいて、図4に示されるように、空間ステアリングプロセッサ240は、復号化オーディオ216、226、236を含む音場をシフト量(β)だけシフトし得る。したがって、モバイルデバイス102のユーザがユーザの頭部をシフトするとき、図3に示される復号化オーディオ216、226、236の知覚がほぼ不変となり得る。
【００６９】
図5を参照すると、インターネットプロトコル(IP)マルチキャストセッションを使用してカンファレンス中のオーディオを管理するように動作可能であるシステム500の特定の実装が示されている。システム500は、モバイルデバイス102、第1のデバイス110、および第2のデバイス120を含む。
【００７０】
動作の特定の実装によれば、モバイルデバイス102は、第1のデバイス110とともに呼出しを開始し得る。その後で、モバイルデバイス102は、第1のデバイス110が第2のデバイス120とのマルチキャストセッションを開始するためのセッション記述プロトコル(SDP)参照を開始し得る。第2のデバイス120はまた、モバイルデバイス102とのセッションを開始し得る。特定の実装では、N個のノードがカンファレンスに参加している場合、メディア当たりN*(N-1)個のセッションが開始され得る(たとえば、3個のノードについて、オーディオのために3*2=6個のセッションが開始され得、ビデオのために別の3*2=6個のセッションが開始され得る)。図5のマルチキャストセッションでは、図1Aのネットワークデバイス190などの暗黙的ネットワークデバイスがない。したがって、セッション開始プロトコル(SIP)シグナリングおよびSDPネゴシエーションは、各デバイス102、110、120によってサポートされるCODECに基づき得る。SIPシグナリングおよびSDPネゴシエーションは、オーディオCODEC、ビットレート、オーディオ帯域幅などを選択するために使用され得る。
【００７１】
一実装によれば、デバイス102、110、120のうちの1つまたは複数が、利用可能なハードウェアリソースに基づいてゲートウェイ(たとえば、ネットワークゲートウェイ)として動作し得る。デバイスがゲートウェイとして動作する場合、CODEC要件が緩和され得る。たとえば、第1のデバイス110のCODECがモバイルデバイス102からのオーディオストリーム104を復号化するための互換性がない場合、第2のデバイス120は、ゲートウェイとして動作してオーディオストリーム104を復号化し、第1のデバイス110によってサポートされるフォーマットにオーディオストリームを再符号化し、再符号化オーディオストリームを第1のデバイス110に供給し得る。
【００７２】
図6を参照すると、カンファレンス中のオーディオを管理するための方法600のフローチャートが示されている。方法600は、図1A〜2Bのモバイルデバイス102、図1A〜1Cの第1のデバイス110、図1A〜1Cの第2のデバイス120、および図1A〜1Cの第3のデバイス130、またはそれらの組合せによって実施され得る。
【００７３】
方法600は、602で、モバイルデバイスの第1のバッファにおいて、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信することを含む。たとえば、図2Aを参照すると、第1のバッファ210は、第1のデバイス110から第1のオーディオストリーム114(たとえば、RTPパケット)を受信し得る。
【００７４】
方法600はまた、604で、モバイルデバイスの第2のバッファにおいて、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信することをも含み得る。たとえば、図2Aを参照すると、第2のバッファ220は、第2のデバイス120から第2のオーディオストリーム124(たとえば、RTPパケット)を受信し得る。
【００７５】
606で、制御信号がモバイルデバイスの遅延コントローラにおいて生成され得る。制御信号は、第1のバッファおよび第2のバッファに供給され、第1のバッファから出力される第1のバッファリング済みオーディオが、第2のバッファから出力される第2のバッファリング済みオーディオと同期され得る。たとえば、図2Aを参照すると、遅延コントローラ202は、第1のオーディオストリーム114の(たとえば、最初期のパケットの)第1のタイムスタンプを、第2のオーディオストリーム124の(たとえば、最初期のパケットの)第2のタイムスタンプと比較し、第1のタイムスタンプと第2のタイムスタンプとの間の時間差を決定し得る。第1のタイムスタンプが第2のタイムスタンプよりも早い時刻を示す場合、制御信号204は、第1のバッファリング済みオーディオ214を第2のバッファリング済みオーディオ224と同期するための時間差だけ、第1のバッファリング済みオーディオ214の出力を遅延するように第1のバッファ210に指示し得る。第2のタイムスタンプが第1のタイムスタンプよりも早い時刻を示す場合、制御信号204は、第1のバッファリング済みオーディオ214を第2のバッファリング済みオーディオ224と同期するための時間差だけ、第2のバッファリング済みオーディオ224の出力を遅延するように第2のバッファ220に指示し得る。遅延コントローラは、参加者AおよびBからのパケット[A1,A2,...]とパケット[B1,B2,...]との間のインターパケット到着時刻を考慮に入れ、参加者Aおよび参加者Bからのメディアをバッファリングするために必要な、様々なデジッタバッファ深さを推定し得るとともに、パケット損失(またはジッタが誘発した隠蔽)を低く維持し、3GPPTS26.114の最小性能要件を満たす。たとえば、参加者Aが、不十分な無線通信路条件にあり得、低ジッタの、高いパケット損失レートを有し、参加者Bが、非常に低いパケット損失レートであるが、高ジッタの、良好な無線通信路条件にある。遅延コントローラは、参加者AおよびBからのパケットのジッタ/損失特性を考慮に入れ、たとえば、参加者Bからのパケットについてより大きいバッファ深さを割り当て、したがって全パケット損失は、参加者Aが受ける損失のそれを超えない。上記の遅延コントローラ機構はまた、3つ以上のメディアストリームを受信することを含むケースに対して拡張され得る。
【００７６】
一実装によれば、方法600は、モバイルデバイスの第1のデコーダにおいて、第1のバッファリング済みオーディオを復号化して、第1の復号化オーディオを生成することをさらに含み得る。たとえば、図2Aを参照すると、第1のデコーダ212は、第1のバッファリング済みオーディオ214を復号化して、第1の復号化オーディオ216を生成し得る。方法600はまた、モバイルデバイスの第2のデコーダにおいて、第2のバッファリング済みオーディオを復号化して、第2の復号化オーディオを生成することをも含み得る。たとえば、図2Aを参照すると、第2のデコーダ222は、第2のバッファリング済みオーディオ224を復号化して、第2の復号化オーディオ226を生成し得る。
【００７７】
一実装によれば、方法600は、第1の復号化オーディオに対する第1の空間ステアリング演算を実施して、第1の復号化オーディオ216をスピーカから第1の角度に投射することを含み得る。たとえば、図2Aを参照すると、空間ステアリングプロセッサ240は、第1の復号化オーディオ216に対する第1の空間ステアリング演算を実施して、第1の復号化オーディオ216をスピーカから第1の角度(α1)に投射し得る。例示のために、空間ステアリングプロセッサ240は、第1の復号化オーディオ216に第1のHRTF242を適用して、第1の角度(α1)に従って第1の復号化オーディオ216をステアリング(たとえば、パン)し得る。第1のHRTF242はまた、空間ステアリングプロセッサ240によって使用され、第1の復号化オーディオ216の第1の利得が調整され得る。
【００７８】
方法600の一実装によれば、第1のデコーダが遅延コントローラから制御信号を受信し得、第2のデコーダも遅延コントローラから制御信号を受信し得る。第1のデコーダは、制御信号に基づいて第1のオーディオストリームに関連する第1のデータパケットを復号化し、または制御信号に基づいて第1のデータパケットに対する復号化演算をバイパスし得る。同様に、第2のデコーダは、制御信号に基づいて第2のオーディオストリームに関連する第2のデータパケットを復号化し、または制御信号に基づいて第2のデータパケットに対する復号化演算をバイパスし得る。一実装によれば、第1のデコーダと第2のデコーダとは異なるデコーダである。第1のデコーダは、すべてのカンファレンス参加者によってサポートされ得、第2のデコーダは、カンファレンス参加者のサブセットによってサポートされ得る。別の実装によれば、第1のデコーダおよび第2のデコーダは、相異なるモードで動作する類似のデコーダを含む。
【００７９】
方法600はまた、第2の復号化オーディオに対する第2の空間ステアリング演算を実施して、第2の復号化オーディオをスピーカから第2の角度に投射することをも含み得る。たとえば、図2Aを参照すると、空間ステアリングプロセッサ240は、第2の復号化オーディオ226に対する第2の空間ステアリング演算を実施して、第2の復号化オーディオ226をスピーカから第2の角度(α2)に投射し得る。例示のために、空間ステアリングプロセッサ240は、第2の復号化オーディオ226に第2のHRTF244を適用して、第2の角度(α2)に従って第2の復号化オーディオ226をステアリング(たとえば、パン)し得る。第2のHRTF244はまた、空間ステアリングプロセッサ240によって使用され、第2の復号化オーディオ226の第2の利得が調整され得る。
【００８０】
一実装によれば、方法600は、ネットワークデバイスに第1の信号を供給して、第1のオーディオストリームの第1のビットレートを調整することを含み得る。たとえば、図1Aおよび図2Aを参照すると、ネットワークデバイス190は、第1のオーディオストリーム114を第1のデバイス110からモバイルデバイス102の第1のバッファ210に経路指定し得、ネットワークデバイス190は、第2のオーディオストリーム124を第2のデバイス120からモバイルデバイス102の第2のバッファ220に経路指定し得る。モバイルデバイス102は、ネットワークデバイス190に第1の信号を供給して、第1のオーディオストリーム114がモバイルデバイス102に供給される第1のビットレートを調整し得る。方法600はまた、ネットワークデバイスに第2の信号を供給して、第2のオーディオストリームの第2のビットレートを調整することをも含み得る。たとえば、図1Aを参照すると、モバイルデバイス102は、ネットワークデバイス190に第2の信号を供給して、第2のオーディオストリーム124がモバイルデバイス102に供給される第2のビットレートを調整し得る。
【００８１】
図6の方法600は、バッファリング済みオーディオ214、224、234を同期することによってカンファレンス中の3GPPTS26.114遅延要件を満たし得る。たとえば、遅延コントローラ202は、対応するオーディオストリーム114、124、134のRTPパケット内のタイムスタンプに基づいてバッファリング済みオーディオ214、224、234を同期するための制御信号204を生成し得る。さらに、方法600は、カンファレンスの複数の参加者が同時に話しているとき、オーディオパニングが「疲労」を低減することを可能にし得る。たとえば、方法600は、復号化オーディオ216、226、236の空間的ステアリングを可能にし得、それによって、復号化オーディオ216、226、236に関連付けられたカンファレンス参加者が、空間的に分散するように見える。
【００８２】
いくつかの例では、図6の方法600が、中央演算処理装置(CPU)、DSP、コントローラなどの処理装置のハードウェア(たとえば、FPGAデバイス、ASICなど)を介して、ファームウェアデバイスを介して、またはそれらの任意の組合せを介して実装され得る。一例として、図6の方法600は、図7に関して説明されるように、命令を実行するプロセッサによって実施され得る。
【００８３】
図7を参照すると、モバイルデバイス102の特定の例示的実装のブロック図が示されている。特定の実装では、デバイス102はプロセッサ706(たとえば、CPU)を含む。モバイルデバイス102は、1つまたは複数の追加のプロセッサ710(たとえば、1つまたは複数のDSP)を含み得る。
【００８４】
モバイルデバイス102は、メモリ732と、アンテナ742に結合されたワイヤレスコントローラ740とを含み得る。ワイヤレスコントローラ740は、図2A〜2Bの遅延コントローラ202と、図2A〜図2Bの第1のバッファ210と、図2A〜図2Bの第1のデコーダ212と、図2A〜図2Bの第2のバッファ220と、図2A〜図2Bの第2のデコーダ222と、図2A〜図2Bの第3のバッファ230と、図2A〜図2Bの第3のデコーダ232と、図2A〜図2Bの空間ステアリングプロセッサ240とを含む。図2A〜図2Bの遅延コントローラ202の論理はまた、プロセッサ706、あるいは1つまたは複数の追加のプロセッサ710内に実装され得る。したがって、ワイヤレスコントローラ740内の第1のバッファ210は、アンテナ742を介して第1のオーディオストリーム114を受信するように構成され得、ワイヤレスコントローラ740内の第2のバッファ220は、アンテナ742を介して第2のオーディオストリーム124を受信するように構成され得、ワイヤレスコントローラ740内の第3のバッファ230は、アンテナ742を介して第3のオーディオストリーム134を受信するように構成され得る。カンファレンス中の3GPPTS26.114遅延要件を満たすために、前述のように、制御信号(図示せず)がバッファ210、220、230に供給され、バッファ210、220、230から出力されるバッファリング済みオーディオが同期され得る。
【００８５】
モバイルデバイス102は、ディスプレイコントローラ726に結合されたディスプレイ728を含み得る。スピーカ736、マイクロフォン738、またはその両方が、CODEC734に結合され得る。CODEC734は、デジタル-アナログ変換器(DAC)702およびアナログ-デジタル変換器(ADC)704を含み得る。一例では、空間ステアリングプロセッサの出力(たとえば、ステレオ信号)が、さらなる処理のために1つまたは複数の追加のプロセッサ710に供給され、CODEC734に供給され得る。ステレオ信号は、DAC702を介してアナログ信号に変換され、スピーカ736において出力され得る。
【００８６】
メモリ732は、図6の方法600を実施するために、プロセッサ706、プロセッサ710、CODEC734、ワイヤレスコントローラ740およびその構成要素、またはそれらの組合せによって実行可能な命令760を含み得る。メモリ732、あるいはプロセッサ706、プロセッサ710、ワイヤレスコントローラ740、および/またはCODEC734のうちの1つまたは複数の構成要素は、コンピュータ(たとえば、CODEC734内のプロセッサ、プロセッサ706、および/またはプロセッサ710)によって実行されるとき、図6の方法600をコンピュータに実施させる命令(たとえば、命令760)を含む非一時的コンピュータ可読媒体であり得る。
【００８７】
遅延コントローラ202、バッファ210、220、230、デコーダ212、222、232、および空間ステアリングプロセッサ240がワイヤレスコントローラ740の内部にあるものとして示されているが、別の実装では、バッファ210、220、230、デコーダ212、222、232、または空間ステアリングプロセッサ240のうちの1つまたは複数は、CODEC734、プロセッサ710、1つまたは複数の追加のプロセッサ706、またはモバイルデバイス102の別の構成要素の内部にあり得る。
【００８８】
特定の実装では、モバイルデバイス102は、移動局モデム(MSM)などのシステムインパッケージまたはシステムオンチップデバイス722内に含まれ得る。特定の実装では、プロセッサ706、プロセッサ710、ディスプレイコントローラ726、メモリ732、CODEC734、およびワイヤレスコントローラ740は、システムインパッケージまたはシステムオンチップデバイス722内に含まれ得る。特定の実装では、タッチスクリーンおよび/またはキーパッドなどの入力デバイス730と、電源744とは、システムオンチップデバイス722に結合される。さらに、特定の実装では、図7に示されるように、ディスプレイ728、入力デバイス730、スピーカ736、マイクロフォン738、アンテナ742、および電源744は、システムオンチップデバイス722の外部にある。しかしながら、ディスプレイ728、入力デバイス730、スピーカ738、マイクロフォン736、アンテナ742、および電源744の各々は、インターフェースやコントローラなどのシステムオンチップデバイス722の構成要素に結合され得る。例示的な例では、モバイルデバイス102は、移動体通信デバイス、スマートフォン、セルラーフォン、ラップトップコンピュータ、コンピュータ、タブレットコンピュータ、携帯情報端末、ディスプレイデバイス、テレビジョン、ゲーミングコンソール、音楽プレーヤ、ラジオ、デジタルビデオプレーヤ、光ディスクプレーヤ、同調器、カメラ、ナビゲーションデバイス、デコーダシステム、エンコーダシステム、またはそれらの任意の組合せに対応する。
【００８９】
図7は、モバイルデバイス102の構成要素を示すが、本明細書で説明される他のデバイス(たとえば、図1A〜1Cの第1のデバイス110、図1A〜図1Cの第2のデバイス120、および/または図1A〜図1Cの第3のデバイス130)は、モバイルデバイス102についての図7に示されるのと同様の構成要素を含み得る。
【００９０】
本開示の追加の実装が、本明細書で付録の形で提示される。そのような実装が、図1A〜7を参照しながら図示され、説明されたいくつかの実装の代わりに、またはそれに加えて利用され得ることを理解されたい。
【００９１】
記載の実装とともに、カンファレンスの第1の参加者に関連付けられた第1のデバイスから第1のオーディオストリームを受信するための手段を含む装置が開示される。たとえば、第1のオーディオストリームを受信するための手段は、図2A〜図2Bおよび図7の第1のバッファ210、図7のワイヤレスコントローラ740、第1のオーディオストリームを受信するように構成された1つまたは複数のデバイス(たとえば、非一時的コンピュータ可読記憶媒体の命令を実行するプロセッサ)、またはそれらの任意の組合せを含み得る。
【００９２】
装置はまた、カンファレンスの第2の参加者に関連付けられた第2のデバイスから第2のオーディオストリームを受信するための手段をも含み得る。たとえば、第2のオーディオストリームを受信するための手段は、図2A〜図2Bおよび図7の第2のバッファ220、図7のワイヤレスコントローラ740、第2のオーディオストリームを受信するように構成された1つまたは複数のデバイス(たとえば、非一時的コンピュータ可読記憶媒体の命令を実行するプロセッサ)、またはそれらの任意の組合せを含み得る。
【００９３】
装置はまた、制御信号を生成するための手段をも含み得る。制御信号は、第1のオーディオストリームを受信するための手段および第2のオーディオストリームを受信するための手段に供給され、第1のオーディオストリームを受信するための手段から出力される第1のバッファリング済みオーディオが、第2のオーディオストリームを受信するための手段から出力される第2のバッファリング済みオーディオと同期される。たとえば、制御信号を生成するための手段は、図2A〜図2Bおよび図7の遅延コントローラ202、図7のワイヤレスコントローラ740、図7のプロセッサ706、図7の1つまたは複数の追加のプロセッサ710、制御信号を生成するように構成された1つまたは複数のデバイス(たとえば、非一時的コンピュータ可読記憶媒体の命令を実行するプロセッサ)、またはそれらの任意の組合せを含み得る。
【００９４】
本明細書で開示される実装とともに説明される様々な例示的論理ブロック、構成、モジュール、回路、およびアルゴリズムステップが、電子ハードウェア、ハードウェアプロセッサなどの処理デバイスによって実行されるコンピュータソフトウェア、またはその両方の組合せとして実装され得ることを当業者ならさらに理解されよう。様々な例示的構成要素、ブロック、構成、モジュール、回路、およびステップが、その機能の点で上記で一般的に説明された。そのような機能がハードウェアとして実装されるか、それとも実行可能なソフトウェアとして実装されるかは、特定の応用例、およびシステム全体に課される設計制約に依存する。当業者は、特定の各機能について様々な方式で記載の機能を実装し得るが、そのような実装決定が、本開示の範囲からの逸脱を引き起こすと解釈されるべきではない。
【００９５】
本明細書で開示される実装に関連して説明された方法またはアルゴリズムのステップは、ハードウェアとして直接的に、プロセッサによって実行されるソフトウェアモジュールとして、またはその2つの組合せとして実施され得る。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、磁気抵抗ランダムアクセスメモリ(MRAM)、スピントルク転送MRAM(STT-MRAM)、フラッシュメモリ、読取り専用メモリ(ROM)、プログラマブル読取り専用メモリ(PROM)、消去可能プログラマブル読取り専用メモリ(EPROM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、レジスタ、ハードディスク、取外し可能ディスク、コンパクトディスク読取り専用メモリ(CD-ROM)などのメモリデバイス内に常駐し得る。プロセッサがメモリデバイスから情報を読み取り、メモリデバイスに情報を書き込むことができるように、例示的メモリデバイスがプロセッサに結合される。代替として、メモリデバイスはプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC内に常駐し得る。ASICはコンピューティングデバイスまたはユーザ端末内に常駐し得る。代替として、プロセッサおよび記憶媒体は、コンピューティングデバイスまたはユーザ端末内の別個の構成要素として常駐し得る。
【００９６】
開示される実装の先の説明は、開示される実装を当業者が作成または使用することを可能にするように与えられる。これらの実装に対する様々な修正が当業者には容易に明らかとなり、本開示の範囲から逸脱することなく、本明細書で定義される原理は、他の実装に適用され得る。したがって、本開示は、本明細書に示される実装に限定されず、以下の特許請求の範囲によって定義される原理および新規な特徴に適合する、可能な最も広い範囲が与えられるべきである。
【符号の説明】
【００９７】
100  システム
102  モバイルデバイス
104  オーディオストリーム
110  第1のデバイス
114  第1のオーディオストリーム
120  第2のデバイス
124  第2のオーディオストリーム
130  第3のデバイス
134  第3のオーディオストリーム
140  第4のデバイス
144  第4のオーディオストリーム
150  第5のデバイス
153  システム
154  第5のオーディオストリーム
170  システム
180  ゲートウェイ
184  ミキシング済みオーディオストリーム
190  ネットワークデバイス
202  遅延コントローラ
204  制御信号
205  フィードバック信号
210  第1のバッファ
211  第1のRDCA
212  第1のデコーダ
214  第1のバッファリング済みオーディオ
216  第1の復号化オーディオ
224  第2のバッファリング済みオーディオ
226  第2の復号化オーディオ
234  第3のバッファリング済みオーディオ
236  第3の復号化オーディオ
220  第2のバッファ
221  第2のRDCA
222  第2のデコーダ
230  第3のバッファ
231  第3のRDCA
232  第3のデコーダ
240  空間ステアリングプロセッサ
242  第1のHRTF
244  第2のHRTF
246  第3のHRTF
250  頭部追跡モジュール
270  ステレオ信号
280  第Nのバッファ
282  第Nのデコーダ
284  第NのHRTF
292  第Nのオーディオストリーム
294  第Nのバッファリング済みオーディオ
296  第Nの復号化オーディオ
702  デジタル-アナログ変換器(DAC)
704  アナログ-デジタル変換器(ADC)
706  プロセッサ
710  プロセッサ
726  ディスプレイコントローラ
728  ディスプレイ
730  入力デバイス
732  メモリ
734  CODEC
736  スピーカ
738  マイクロフォン
740  ワイヤレスコントローラ
742  アンテナ
744  電源
760  命令
【図１Ａ】
2018515009.tif 000003
【図１Ｂ】
2018515009.tif 000004
【図１Ｃ】
2018515009.tif 000005
【図２Ａ】
2018515009.tif 000006
【図２Ｂ】
2018515009.tif 000007
【図３】
2018515009.tif 000008
【図４】
2018515009.tif 000009
【図５】
2018515009.tif 000010
【図６】
2018515009.tif 000011
【図７】
2018515009.tif 000012
【国際調査報告】
2018515009.tif 000013
2018515009.tif 000014