JP2023120182A - オーディオデバイスのコーディネーション - Google Patents

オーディオデバイスのコーディネーション Download PDF

Info

Publication number
JP2023120182A
JP2023120182A JP2023076015A JP2023076015A JP2023120182A JP 2023120182 A JP2023120182 A JP 2023120182A JP 2023076015 A JP2023076015 A JP 2023076015A JP 2023076015 A JP2023076015 A JP 2023076015A JP 2023120182 A JP2023120182 A JP 2023120182A
Authority
JP
Japan
Prior art keywords
audio
smart
examples
application
chasm
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023076015A
Other languages
English (en)
Inventor
エヌ． ディキンズ，グレン
N Dickins Glenn
リチャード ポール トーマス，マーク
Richard Paul Thomas Mark
ジェイ． シーフェルド，アラン
J Seefeldt Alan
ビー． ランド，ジョシュア
B Lando Joshua
アルテアガ，ダニエル
Arteaga Daniel
メダグリア ディオニシオ，カルロス
Medaglia Dyonisio Carlos
グナワン，デイビッド
Gunawan David
ジェイ． カートライト，リチャード
J Cartwright Richard
グラハム ハインズ，クリストファー
Graham Hines Christopher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dolby International AB
Dolby Laboratories Licensing Corp
Original Assignee
Dolby International AB
Dolby Laboratories Licensing Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/929,215 external-priority patent/US11659332B2/en
Application filed by Dolby International AB, Dolby Laboratories Licensing Corp filed Critical Dolby International AB
Publication of JP2023120182A publication Critical patent/JP2023120182A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R5/00—Stereophonic arrangements
    • H04R5/04—Circuit arrangements, e.g. for selective connection of amplifier inputs/outputs to loudspeakers, for loudspeaker detection, or for adaptation of settings to personal preferences or hearing impairments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R3/00—Circuits for transducers, loudspeakers or microphones
    • H04R3/12—Circuits for transducers, loudspeakers or microphones for distributing signals to two or more loudspeakers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/165—Management of the audio stream, e.g. setting of volume, audio stream path
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/08—Speech classification or search
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R1/00—Details of transducers, loudspeakers or microphones
    • H04R1/20—Arrangements for obtaining desired frequency or directional characteristics
    • H04R1/32—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only
    • H04R1/326—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only for microphones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R1/00—Details of transducers, loudspeakers or microphones
    • H04R1/20—Arrangements for obtaining desired frequency or directional characteristics
    • H04R1/32—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only
    • H04R1/40—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only by combining a number of identical transducers
    • H04R1/403—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only by combining a number of identical transducers loud-speakers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R1/00—Details of transducers, loudspeakers or microphones
    • H04R1/20—Arrangements for obtaining desired frequency or directional characteristics
    • H04R1/32—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only
    • H04R1/40—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only by combining a number of identical transducers
    • H04R1/406—Arrangements for obtaining desired frequency or directional characteristics for obtaining desired directional characteristic only by combining a number of identical transducers microphones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R27/00—Public address systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R3/00—Circuits for transducers, loudspeakers or microphones
    • H04R3/005—Circuits for transducers, loudspeakers or microphones for combining the signals of two or more microphones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04S—STEREOPHONIC SYSTEMS 
    • H04S7/00—Indicating arrangements; Control arrangements, e.g. balance control
    • H04S7/30—Control circuits for electronic adaptation of the sound field
    • H04S7/302—Electronic adaptation of stereophonic sound system to listener position or orientation
    • H04S7/303—Tracking of listener position or orientation
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/08—Speech classification or search
    • G10L2015/088—Word spotting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R2227/00—Details of public address [PA] systems covered by H04R27/00 but not provided for in any of its subgroups
    • H04R2227/005—Audio distribution systems for home, i.e. multi-room use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R2420/00—Details of connection covered by H04R, not provided for in its groups
    • H04R2420/07—Applications of wireless loudspeakers or wireless microphones

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Health & Medical Sciences (AREA)
  • Otolaryngology (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Medical Informatics (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computational Linguistics (AREA)
  • Circuit For Audible Band Transducer (AREA)
  • Stereophonic System (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

【課題】複数のスマートオーディオデバイスに対し、オーディオセッションマネージャによって、それぞれのメディアエンジン能力にしたがってスマートオーディオデバイスを制御するシステム及び方法を提供する。【解決手段】連続階層オーディオセッションマネージャ（ＣＨＡＳＭ）４０１は、アプリケーション制御信号４３０～４３２を用いて各スマートオーディオデバイス４２０～４２２にそれぞれのスマートオーディオデバイス通信リンクを介して送信されたオーディオセッションマネジメント制御信号を介して、それぞれのメディアエンジンのメディアエンジン能力にしたがって複数のスマートオーディオデバイスを制御する。ＣＨＡＳＭは、オーディオセッションマネジメント制御信号を各スマートオーディオデバイスに送信する。ＣＨＡＳＭは、ゲートウェイとして機能する。【選択図】図４

Description

［関連出願への相互参照］
本願は、２０１９年１２月１８日付け出願の米国仮特許出願第６２／９４９，９９８号、２０２０年３月１９日付け出願の米国仮特許出願第６２／９９２，０６８号、２０１９年１２月１８日付け出願の欧州特許出願第１９２１７５８０．０号、２０１９年７月３０日付け出願のスペイン特許出願Ｐ２０１９３０７０２号、２０２０年２月７日付け出願の米国仮特許出願第６２／９７１，４２１号、２０２０年６月２５日付け出願の米国仮特許出願第６２／７０５，４１０号、２０２０年７月３０日付け出願の米国仮特許出願第６２／８８０，１１４号、２０２０年６月２３日付け出願の米国仮特許出願第６２／７０５，３５１号、２０１９年７月３０日付け出願の米国仮特許出願第６２／８８０，１１５号、２０２０年６月１２日付け出願の米国仮特許出願第６２／７０５，１４３号、２０１９年７月３０日付け出願の米国仮特許出願第６２／８８０，１１８号、２０２０年７月１５日付け出願の米国特許出願第１６／９２９，２１５号、２０２０年７月２０日付け出願の米国仮特許出願第６２／７０５，８８３号、２０１９年７月３０日付け出願の米国仮特許出願第６２／８８０，１２１号、および２０２０年７月２０日付け出願の米国仮特許出願第６２／７０５，８８４号に基づく優先権を主張するものであり、各出願の開示内容をすべて本願に援用する。
本開示は、スマートオーディオデバイスを含み得るオーディオデバイスをコーディネート（coordinate）（オーケストレート（orchestrate））および実装するためのシステム
および方法に関する。
オーディオデバイス（スマートオーディオデバイスを含むが、それらに限定されない）は、広く用いられており、多くの家庭において一般的な要素になりつつある。オーディオデバイスを制御する既存のシステムおよび方法は利益を提供するが、改善されたシステムおよび方法が望まれる。
［表記および命名］
特許請求の範囲を含む本開示全体を通じて、「スピーカ」および「ラウドスピーカ」は、単一のスピーカフィードによって駆動される任意の音響放射トランスデューサ（またはトランスデューサのセット）を表すように同義的に使用される。典型的なヘッドフォンセットは、２つのスピーカを含む。スピーカは、単一の共通のスピーカフィードまたは複数のスピーカフィードによって駆動されるような、複数のトランスデューサ（例えばウーファーとツイーター）を含むように実装され得る。いくつかの例においては、スピーカフィード（単数または複数）は、場合によっては、異なるトランスデューサに接続された異なる回路ブランチにおいて異なる処理を受けることもある。
特許請求の範囲を含む本開示全体を通じて、信号またはデータに対して演算（例えば、信号またはデータに対するフィルタリング、スケーリング、変換、またはゲインの適用）を「行う」という表現は、信号またはデータに対して直接演算を行うこと、または信号またはデータの処理済みバージョン（例えば、演算の実行を受ける前に予備フィルタリングまたは前処理されたバージョンの信号）に対して演算を行うことの意味において広義で使用される。
特許請求の範囲を含む本開示全体を通じて、「システム」という表現は、デバイス、システム、またはサブシステムの意味において広義で使用される。例えば、デコーダを実装
するサブシステムは、デコーダシステムと呼ばれることがあり、そのようなサブシステムを含むシステム（例えば、複数の入力に応答してＸ個の出力信号を生成するシステムであって、入力のうちＭ個をサブシステムが生成し、他のＸ－Ｍ個の入力が外部ソースから受信される）は、デコーダシステムとも呼ばれ得る。
特許請求の範囲を含む本開示全体を通じて、「プロセッサ」という用語は、データ（例えば、オーディオ、またはビデオもしくは他の画像データ）に対する演算を実行するためにプログラマブルであるかまたは他の方法で（例えば、ソフトウェアまたはファームウェアによって）構成可能なシステムまたはデバイスの意味において広義で使用される。プロセッサの例としては、フィールドプログラマブルゲートアレイ（または他の構成可能な集積回路またはチップセット）、オーディオまたは他のサウンドデータに対してパイプライン化処理を行うようにプログラムおよび／または他の方法で構成されたデジタルシグナルプロセッサ、プログラマブルな汎用プロセッサまたはコンピュータ、およびプログラマブルなマイクロプロセッサチップまたはチップセットなどが挙げられる。
特許請求の範囲を含め、本開示全体において、「接続する」または「接続された」という用語は、直接的接続または間接的接続のいずれを意味してもよいように使用される。したがって、第１のデバイスが第２のデバイスに接続された場合、その接続は、直接接続によるものであっても、または他のデバイスおよび接続を介する間接接続によるものであってもよい。
本明細書において、「スマートデバイス」は、一般にＢｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅ、ニアフィールド通信、ＷｉＦｉ、ライトフィデリティ（ＬｉＦｉ）、３Ｇ、４Ｇ、５Ｇなどの様々なワイヤレスプロトコルを介して、１つ以上の他のデバイス（またはネットワーク）と通信するように構成され、ある程度インタラクティブにおよび／または自律的に動作可能である電子デバイスである。いくつかの顕著なタイプのスマートデバイスは、スマートフォン、スマートカー、スマートサーモスタット、スマートドアベル、スマートロック、スマート冷蔵庫、ファブレットおよびタブレット、スマートウォッチ、スマートバンド、スマートキーチェーンならびにスマートオーディオデバイスである。「スマートデバイス」という用語はまた、人工知能などのユビキタスコンピューティングのいくつかのプロパティを奏するデバイスを指し得る。
本明細書中において、「スマートオーディオデバイス」という表現は、単一目的オーディオデバイスまたは多目的オーディオデバイス（例えば、バーチャルアシスタント機能の少なくともいくつかの態様を実装するオーディオデバイス）であるスマートデバイスを表すために用いられる。単一目的オーディオデバイスとは、少なくとも１つのマイクロフォンを含むかそれに接続される（かつオプションとして少なくとも１つのスピーカおよび／または少なくとも１つのカメラも含むかそれに接続される）デバイス（例えば、スマートスピーカ、テレビ（ＴＶ）または携帯電話）であり、単一の目的を達成するために概してまたは主として設計されているデバイスである。例えばＴＶは典型的には、番組素材からのオーディオを再生することができる（再生できると考えられている）が、ほとんどの場合、現代のＴＶは、何らかのオペレーティングシステムを実行し、その上で、テレビを見るためのアプリケーションを含む複数のアプリケーションがローカルに実行される。同様に、携帯電話機のオーディオ入力と出力は多くのことを行い得るが、これらは当該電話機上で実行されているアプリケーションによって提供されている。この意味で、スピーカ（単数または複数）およびマイクロフォン（単数または複数）を有する単一目的オーディオデバイスは、スピーカおよびマイクロフォンを直接使用するためのローカルアプリケーションおよび／またはサービスを実行するように構成されることが多い。ゾーンすなわちユーザー設定されたエリアにわたってオーディオの再生を実現するためにグループ化するように構成された、単一目的オーディオデバイスもある。
１つの通常タイプの多目的オーディオデバイスは、バーチャルアシスタント機能の少なくともいくつかの態様を実装するが、バーチャルアシスタント機能の他の態様は、その多目的オーディオデバイスが通信するように構成される１つ以上のサーバなどの１つ以上の他のデバイスによって実装され得るオーディオデバイスである。そのような多目的オーディオデバイスは、本明細書において、「バーチャルアシスタント」と呼ばれ得る。バーチャルアシスタントは、少なくとも１つのマイクロフォンを含むか、または、それに接続された（かつ、必要に応じて、また、少なくとも１つのスピーカおよび／または少なくとも１つのカメラを含むか、または、それに接続された）デバイス（例えば、スマートスピーカまたはバーチャルアシスタント一体化デバイス）である。いくつかの例において、バーチャルアシスタントは、ある意味においてクラウドイネーブルド（ｃｌｏｕｄ－ｅｎａｂｌｅｄ）であるか、またはそうでなければ、バーチャルアシスタント自体内または上で完全には実装されないアプリケーションに対して複数のデバイス（バーチャルアシスタントとは異なる）を利用する能力を提供し得る。換言すると、バーチャルアシスタント機能の少なくともいくつかの態様、例えば、音声認識機能は、バーチャルアシスタントがインターネットなどのネットワークを介して通信し得る１つ以上のサーバまたは他のデバイスによって（少なくとも部分的に）実装され得る。複数のバーチャルアシスタントが、例えば、非常に離散的かつ条件的に定義された方法で、協働することがあってもよい。例えば、２つ以上のバーチャルアシスタントが、それらの１つ（例えばウェイクワードを聞いたことを最も確信している１つ）が、そのウェイクワードに応答するという意味において、協働し得る。いくつかの実施態様では、複数のコネクテッドバーチャルアシスタントが、１つのメインアプリケーションによって管理される一種の集合体を形成してもよい。その１つのメインアプリケーションは、バーチャルアシスタントであり得る（または、バーチャルアシスタントを含むかまたは実装し得る）。
本明細書中において、「ウェイクワード」とは、任意の音（例えば、人間によって発せられた単語、または他の何らかの音）の意味において広義で使用される。スマートオーディオデバイスは、（スマートオーディオデバイスに含まれるか接続された少なくとも１つのマイクロフォン、または少なくとも１つの他のマイクロフォンを用いた）音の検出（「聞き取り（hearing））に応答して、目覚めるよう構成される。この文脈において「目覚
める（awake）」とは、デバイスがサウンドコマンドを待つ（すなわち、耳を立てている
）状態に入ることを表す。いくつかの例において、本明細書において「ウェイクワード」と呼ばれ得るものは、複数のワード、例えばフレーズを含み得る。本明細書において、「ウェイクワード」は、広い意味において、任意の音（例えば、人が発声するワード、または何らかの他の音）を表すために使用される。ここで、スマートオーディオデバイスは、その音の検出（「聞く」）（スマートオーディオデバイス内の、もしくは、それに接続された少なくとも１つのマイクロフォン、または、少なくとも１つの他のマイクロフォンを使用して）に応答して呼び起こされる（awake）ように構成される。この状況において、
「呼び起こされる」は、デバイスが音コマンドを待機する（換言すると、聴こうとしている）状態に入ることを表す。いくつかの場合において、本明細書において「ウェイクワード」と呼ばれるものは、１ワードよりも多く、例えば、語句（phrase）を含み得る。
本明細書中において、「ウェイクワード検出器」という表現は、リアルタイムのサウンド（例えば、発話）特徴と学習済みモデルとの間の整合性を連続的に探索するように構成されたデバイス（またはデバイスを構成するための命令を含むソフトウェア）を表す。典型的には、ウェイクワードイベントは、ウェイクワードが検出された確率が事前に定義された閾値を超えているとウェイクワード検出器によって判断されるたびに、トリガされる。例えば閾値は、誤受入率と誤拒否率との間の良好な妥協点を与えるように調整された所定の閾値であってもよい。ウェイクワードイベントの後、デバイスはコマンドに耳を立てる状態（「目覚めた（awakened）」状態または「アテンティブネス（attentiveness）
」状態と呼ばれることがある）に入り、この状態において、受け取ったコマンドをより大規模でより計算集約的な認識器に渡し得る。
［概要］
１クラスの実施形態において、オーディオデバイス（スマートオーディオデバイスを含み得る）は、連続階層オーディオセッションマネージャ（Continuous Hierarchical Audio Session Manager（ＣＨＡＳＭ））を使用してコーディネートされる。いくつかの開示
の実装例において、ＣＨＡＳＭの少なくともいくつかの態様は、本明細書において「スマートホームハブ」と呼ばれるものによって実装され得る。いくつかの例によると、ＣＨＡＳＭは、オーディオ環境の特定のデバイスによって実装され得る。いくつかの場合において、ＣＨＡＳＭは、オーディオ環境の１つ以上のデバイスによって実行され得るソフトウェアを介して、少なくとも部分的に、実装され得る。いくつかの実施形態において、デバイス（例えば、スマートオーディオデバイス）は、発見可能な日和見的にオーケストレートされた分散型オーディオサブシステム（Discoverable Opportunistically Orchestrated Distributed Audio Subsystem（ＤＯＯＤＡＤ））と本明細書において呼ばれることも
あるネットワーク接続可能素子またはサブシステム（例えば、ネットワーク接続可能メディアエンジンおよびデバイスプロパティディスクリプタ）を含み、複数（例えば、多数）のデバイス（例えば、ＤＯＯＤＡＤを含むスマートオーディオデバイスまたは他のデバイス）は、ＣＨＡＳＭによって一括して管理されるか、または、オーケストレートされた機能を達成する他の方式によって動かされる（例えば、最初に購入された際にデバイスに対して既知または意図されたものに取って代わる）。本明細書において、ＣＨＡＳＭ対応（enabled）オーディオシステムの、開発のアーキテクチャ、ならびに、オーディオ機能の
表現および制御に適切な制御言語の両方を説明する。また、本明細書において、オーケストレーションの言語を説明し、オーディオのデバイス（または、ルート）を直接的に参照せずに集合的なオーディオシステムに対処するための機能素子および機能差を説明する。また、オーディオを人および場所へ、かつ、それらからオーケストレーションおよびルーティングすることの考えに対して特有の、オーディオの持続性セッション、デスティネーション、優先づけ、およびルーティング、ならびに、承認（acknowledgment）を求めることを説明する。
本開示の態様は、開示された方法またはそのステップのいずれかの実施形態を行うように構成された（例えば、プログラムされた）システム、および、開示された方法またはそのステップのいずれかの実施形態を行うためのコード（例えば、それを行うことが実行可能なコード）を格納するデータの非一時的な格納を実装する有体の非一時的なコンピュータ読み取り可能媒体（例えば、ディスクまたは他の有体のストレージ媒体）を含む。例えば、いくつかの実施形態は、開示された方法またはそのステップのうちの１つ以上にしたがって、データに対して様々な演算のいずれかを行うように、ソフトウェアまたはファームウェアを用いてプログラムされたか、および／またはそうではなく、構成された、プログラム可能な汎用プロセッサ、デジタル信号プロセッサ、またはマイクロプロセッサであることが可能であるか、または、それを含むことが可能である。そのような汎用プロセッサは、入力装置と、メモリと、それに対してアサートされるデータに応答して、開示された方法（またはそのステップ）のより多くを行うようにプログラムされた（および／またはそうではなく、構成された）処理サブシステムとを含むコンピュータシステムであり得るか、または、それを含み得る。
本開示の少なくともいくつかの態様は、方法を介して実装され得る。いくつかの場合において、方法は、本明細書において開示されるような制御システムによって、少なくとも
部分的に、実装され得る。いくつかのそのような方法は、オーディオ環境のオーディオシステムのためのオーディオセッションマネジメントを含み得る。
いくつかのそのような方法は、オーディオシステムの、オーディオセッションマネージャと少なくとも第１のスマートオーディオデバイスとの間に第１のスマートオーディオデバイス通信リンクを確立することを含む。いくつかの例において、第１のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれでもよいし、または、いずれを含んでもよい。いくつかのそのような例において、第１のスマートオーディオデバイスは、１つ以上のラウドスピーカを含む。いくつかのそのような方法は、オーディオセッションマネージャと、第１のアプリケーションを実行する第１のアプリケーションデバイスとの間に第１のアプリケーション通信リンクを確立することを含む。
いくつかのそのような方法は、オーディオセッションマネージャによって、第１のスマートオーディオデバイスの第１のメディアエンジンの１つ以上の第１のメディアエンジン能力を決定することを含む。いくつかの例において、第１のメディアエンジンは、第１のスマートオーディオデバイスによって受信された１つ以上のオーディオメディアストリームを管理し、第１のメディアエンジンサンプルクロックにしたがって１つ以上のオーディオメディアストリームに対して第１のスマートオーディオデバイス信号処理を行うように構成される。
いくつかのそのような例において、方法は、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することを含む。いくつかのそのような方法は、第１のメディアエンジン能力にしたがって第１のスマートオーディオデバイスを制御することを含む。いくつかの実装例によると、制御することは、オーディオセッションマネージャによって、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介してなされる。いくつかのそのような例において、オーディオセッションマネージャは、第１のメディアエンジンサンプルクロックを参照せずに、第１のオーディオセッションマネジメント制御信号を第１のスマートオーディオデバイスに送信する。
いくつかの実装例において、第１のアプリケーション通信リンクは、第１のアプリケーションデバイスからの第１のルート開始リクエストに応答して確立され得る。いくつかの例によると、第１のアプリケーション制御信号は、第１のメディアエンジンサンプルクロックを参照せずに、第１のアプリケーションから送信され得る。いくつかの例において、第１のオーディオセッションマネジメント制御信号は、第１のスマートオーディオデバイスに、第１のメディアエンジンの制御をオーディオセッションマネージャに代理（delegate）させ得る。
いくつかの例によると、オーディオセッションマネージャ以外のデバイスまたは第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。しかし、いくつかの場合において、第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。
いくつかの例において、第１のスマートオーディオデバイスは、特定の目的のオーディオセッションマネージャを含み得る。いくつかのそのような例によると、オーディオセッションマネージャは、特定の目的のオーディオセッションマネージャと、第１のスマートオーディオデバイス通信リンクを介して通信し得る。いくつかのそのような例によると、オーディオセッションマネージャは、１つ以上の第１のメディアエンジン能力を特定の目
的のオーディオセッションマネージャから取得し得る。
いくつかの実装例によると、オーディオセッションマネージャは、第１のメディアエンジンを制御するすべてのアプリケーションに対してゲートウェイとして機能し得るが、これは、アプリケーションが第１のスマートオーディオデバイス上で動作するか、または、他のデバイス上で動作するかにかかわらない。
いくつかのそのような方法はまた、少なくとも、第１のオーディオソースに対応する第１のオーディオストリームを確立することを含み得る。第１のオーディオストリームは、第１のオーディオ信号を含み得る。いくつかのそのような例において、少なくとも第１のオーディオストリームを確立することは、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、少なくとも第１のオーディオストリームを確立させることを含み得る。
いくつかの例において、そのような方法はまた、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにするレンダリング処理を含み得る。いくつかの例において、レンダリング処理は、第１のオーディオセッションマネジメント制御信号に応答して、第１のスマートオーディオデバイスによって行われ得る。
いくつかのそのような方法はまた、第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、第１のスマートオーディオデバイスと、オーディオ環境の１つ以上の他のスマートオーディオデバイスのそれぞれとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかのそのような方法はまた、第１のスマートオーディオデバイスに、生のマイクロフォン信号、処理されたマイクロフォン信号、レンダリングされたオーディオ信号、および／または、レンダリングされていないオーディオ信号を、１つ以上の他のスマートオーディオデバイスにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、そのような方法はまた、オーディオセッションマネージャと、ホームオーディオシステムの少なくとも第２のスマートオーディオデバイスとの間に第２のスマートオーディオデバイス通信リンクを確立することを含み得る。第２のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれでもよいし、いずれを含んでもよい。第２のスマートオーディオデバイは、１つ以上のマイクロフォンを含み得る。いくつかのそのような方法はまた、オーディオセッションマネージャによって、第２のスマートオーディオデバイスの第２のメディアエンジンの１つ以上の第２のメディアエンジン能力を決定することを含み得る。第２のメディアエンジンは、マイクロフォンデータを１つ以上のマイクロフォンから受信し、マイクロフォンデータに対して第２のスマートオーディオデバイス信号処理を行うように構成され得る。いくつかのそのような方法はまた、第２のメディアエンジン能力にしたがって、オーディオセッションマネージャによって、第２のスマートオーディオデバイス通信リンクを介して第２のスマートオーディオデバイスに送信された第２のオーディオセッションマネージャ制御信号を介して、第２のスマートオーディオデバイスを制御することを含み得る。
いくつかのそのような例によると、第２のスマートオーディオデバイスを制御することはまた、第２のスマートオーディオデバイスに、第２のスマートオーディオデバイスと第１のスマートオーディオデバイスとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかの例において、第２のスマートオーディオデバイスを制御することは、第２のスマートオーディオデバイスに、処理されたおよび／または処理されていないマイクロフォンデータを第２のメディアエンジンから第１のメディアエンジ
ンにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、第２のスマートオーディオデバイスを制御することは、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することと、第２のオーディオセッションマネージャ制御信号を第１のアプリケーション制御信号にしたがって決定することとを含み得る。
代替として、または、付加として、いくつかのオーディオセッションマネジメント方法は、第１のアプリケーションを実装する第１のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信することを含む。いくつかの例において、第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示し、第１のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第１の人物に対応するが、第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第１のルート開始リクエストに対応する第１のルートを確立することを含む。いくつかの例によると、第１のルートを確立することは、オーディオ環境内の少なくとも第１の人物の第１の位置を決定することと、第１のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第１のオーディオセッションを開始または予定することとを含む。
いくつかの例によると、第１のルート開始リクエストは、第１のオーディオセッション優先度（priority）を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１の接続（connectivity）モードを含み得る。例えば、第１の接続モードは、同期（synchronous）接続モード、トランザクション（transactional）接続モード、または予定（scheduled）接続モードであり得る。
いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１の人物から承認が要求されることになるかどうかの指示を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１のオーディオセッション目標（goal）を含み得る。例えば、第１のオーディオセッション目標は、理解可能（intelligibility）、オーディオ
品質、空間忠実（spatial fidelity）、可聴（audibility）、不可聴（inaudibility）および／またはプライバシーを含み得る。
いくつかのそのような方法は、第１のルートに対して第１の持続（persistent）ユニークオーディオセッション識別子を決定することを含み得る。そのような方法は、第１の持続ユニークオーディオセッション識別子を第１のデバイスに送信することを含み得る。
いくつかの例によると、第１のルートを確立することは、環境内の少なくとも１つのデバイスに、少なくとも、第１のルートに対応する第１のメディアストリームを確立させることを含み得る。第１のメディアストリームは、第１のオーディオ信号を含む。いくつかのそのような方法は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、オーディオセッションの第１のステージに対して第１の人物の第１の向き（orientation）を決定することを含み得る。いくつかのそのような例
によると、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリ
ングされるようにすることは、第１の人物の第１の位置および第１の向きに対応する第１の基準空間モードを決定することと、第１の基準空間モードに対応するオーディオ環境内のラウドスピーカの第１の相対アクティベーション（activation）を決定することとを含み得る。
いくつかのそのような方法は、第１のオーディオセッションの第２のステージに対して第１の人物の第２の位置および／または第２の向きを決定することを含み得る。いくつかのそのような方法は、第２の位置および／または第２の向きに対応する第２の基準空間モードを決定することと、第２の基準空間モードに対応するオーディオ環境内のラウドスピーカの第２の相対アクティベーションを決定することとを含み得る。
いくつかの例によると、方法は、第２のアプリケーションを実装する第２のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第２のオーディオセッションに対して第２のルートを開始するための第２のルート開始リクエストを受信することを含み得る。第２のルート開始リクエストは、第２のオーディオソースおよび第２のオーディオ環境デスティネーションを示し得る。第２のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第２の人物に対応し得る。いくつかの例において、第２のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第２のルート開始リクエストに対応する第２のルートを確立すること含み得る。いくつかの実装例において、第２のルートを確立することは、オーディオ環境内の少なくとも第２の人物の第１の位置を決定することと、第２のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第２のオーディオセッションを開始することとを含み得る。いくつかの例において、第２のルートを確立することは、少なくとも、第２のルートに対応する第２のメディアストリームを確立することを含み得る。第２のメディアストリームは、第２のオーディオ信号を含む。いくつかのそのような方法は、第２のオーディオ信号が第２のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含み得る。いくつかの例によると、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープ（ｗａｒｐ）することを含み得る。代替として、または、付加として、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。
いくつかの例において、第１のルート開始リクエストは、オーディオ環境の少なくとも第１のエリアを第１のルートソースまたは第１のルートデスティネーションとして示し得る。いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１のサービス（例えば、音楽提供サービスまたはポッドキャスト提供サービスなどのオンラインコンテンツ提供サービス）を第１のオーディオソースとして示し得る。
本明細書に記載の動作、機能および／または方法のうちの一部またはすべては、１つ以上の非一時的な媒体に格納された命令（例えば、ソフトウェア）にしたがって１つ以上の
デバイスによって行われ得る。そのような非一時的な媒体は、本明細書に記載されるようなメモリデバイスを含み得る。メモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）デバイス、読み出し専用メモリ（ＲＯＭ）デバイスなどを含むが、これらに限定されない。このように、本開示に記載の主題のいくつかの革新的な態様は、格納されたソフトウェアを有する１つ以上の非一時的な媒体内に実装できる。
例えば、ソフトウェアは、オーディオ環境のオーディオシステムのためのオーディオセッションマネジメントを含む１つ以上の方法を行うために、１つ以上のデバイスを制御するための命令を含み得る。いくつかのそのような方法は、オーディオシステムの、オーディオセッションマネージャと少なくとも第１のスマートオーディオデバイスとの間に第１のスマートオーディオデバイス通信リンクを確立することを含む。いくつかの例において、第１のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれでもよいし、いずれを含んでもよい。いくつかのそのような例において、第１のスマートオーディオデバイスは、１つ以上のラウドスピーカを含む。いくつかのそのような方法は、オーディオセッションマネージャと、第１のアプリケーションを実行する第１のアプリケーションデバイスとの間に第１のアプリケーション通信リンクを確立することを含む。
いくつかのそのような方法は、オーディオセッションマネージャによって、第１のスマートオーディオデバイスの第１のメディアエンジンの１つ以上の第１のメディアエンジン能力を決定することを含む。いくつかの例において、第１のメディアエンジンは、第１のスマートオーディオデバイスによって受信された１つ以上のオーディオメディアストリームを管理し、第１のメディアエンジンサンプルクロックにしたがって１つ以上のオーディオメディアストリームに対して第１のスマートオーディオデバイス信号処理を行うように構成される。
いくつかのそのような例において、方法は、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することを含む。いくつかのそのような方法は、第１のメディアエンジン能力にしたがって第１のスマートオーディオデバイスを制御することを含む。いくつかの実装例によると、制御することは、オーディオセッションマネージャによって、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介してなされる。いくつかのそのような例において、オーディオセッションマネージャは、第１のメディアエンジンサンプルクロックを参照せずに、第１のオーディオセッションマネジメント制御信号を第１のスマートオーディオデバイスに送信する。
いくつかの実装例において、第１のアプリケーション通信リンクは、第１のアプリケーションデバイスからの第１のルート開始リクエストに応答して確立され得る。いくつかの例によると、第１のアプリケーション制御信号は、第１のメディアエンジンサンプルクロックを参照せずに、第１のアプリケーションから送信され得る。いくつかの例において、第１のオーディオセッションマネジメント制御信号は、第１のスマートオーディオデバイスに、第１のメディアエンジンの制御をオーディオセッションマネージャに代理させ得る。
いくつかの例によると、オーディオセッションマネージャ以外のデバイスまたは第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。しかし、いくつかの場合において、第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。
いくつかの例において、第１のスマートオーディオデバイスは、特定の目的のオーディオセッションマネージャを含み得る。いくつかのそのような例によると、オーディオセッションマネージャは、第１のスマートオーディオデバイス通信リンクを介して特定の目的のオーディオセッションマネージャと通信し得る。いくつかのそのような例によると、オーディオセッションマネージャは、１つ以上の第１のメディアエンジン能力を特定の目的のオーディオセッションマネージャから取得し得る。
いくつかの実装例によると、オーディオセッションマネージャは、第１のメディアエンジンを制御するすべてのアプリケーションのためのゲートウェイとして機能し得るが、これは、アプリケーションが第１のスマートオーディオデバイス上で動作するか、または、他のデバイス上で動作するかにかかわらない。
いくつかのそのような方法はまた、少なくとも、第１のオーディオソースに対応する第１のオーディオストリームを確立することを含み得る。第１のオーディオストリームは、第１のオーディオ信号を含み得る。いくつかのそのような例において、少なくとも第１のオーディオストリームを確立することは、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、少なくとも第１のオーディオストリームを確立させることを含み得る。
いくつかの例において、そのような方法はまた、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにするレンダリング処理を含み得る。いくつかの例において、レンダリング処理は、第１のオーディオセッションマネジメント制御信号に応答して、第１のスマートオーディオデバイスによって行われ得る。
いくつかのそのような方法はまた、第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、第１のスマートオーディオデバイスと、オーディオ環境の１つ以上の他のスマートオーディオデバイスのそれぞれとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかのそのような方法はまた、第１のスマートオーディオデバイスに、生のマイクロフォン信号、処理されたマイクロフォン信号、レンダリングされたオーディオ信号および／またはレンダリングされていないオーディオ信号を１つ以上の他のスマートオーディオデバイスにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、そのような方法はまた、オーディオセッションマネージャと、ホームオーディオシステムの少なくとも第２のスマートオーディオデバイスとの間に第２のスマートオーディオデバイス通信リンクを確立することを含み得る。第２のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれでもよいし、いずれを含んでもよい。第２のスマートオーディオデバイスは、１つ以上のマイクロフォンを含み得る。いくつかのそのような方法はまた、オーディオセッションマネージャによって、第２のスマートオーディオデバイスの第２のメディアエンジンの１つ以上の第２のメディアエンジン能力を決定することを含み得る。第２のメディアエンジンは、マイクロフォンデータを１つ以上のマイクロフォンから受信し、マイクロフォンデータに対して第２のスマートオーディオデバイス信号処理を行うように構成され得る。いくつかのそのような方法はまた、第２のメディアエンジン能力にしたがって、オーディオセッションマネージャによって、第２のスマートオーディオデバイス通信リンクを介して第２のスマートオーディオデバイスに送信された第２のオーディオセッションマネージャ制御信号を介して、第２のスマートオーディオデバイスを制御することを含み得る。
いくつかのそのような例によると、第２のスマートオーディオデバイスを制御すること
はまた、第２のスマートオーディオデバイスに、第２のスマートオーディオデバイスと第１のスマートオーディオデバイスとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかの例において、第２のスマートオーディオデバイスを制御することは、第２のスマートオーディオデバイスに、処理されたおよび／または処理されていないマイクロフォンデータを、第２のメディアエンジンから第１のメディアエンジンにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、第２のスマートオーディオデバイスを制御することは、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することと、第２のオーディオセッションマネージャ制御信号を第１のアプリケーション制御信号にしたがって決定することとを含み得る。
代替として、または、付加として、ソフトウェアは、オーディオ環境のオーディオシステムのためのオーディオセッションマネジメントを含む１つ以上の他の方法を行うために１つ以上のデバイスを制御するための命令を含み得る。いくつかのそのようなオーディオセッションマネジメント方法は、第１のアプリケーションを実装する第１のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信すること含む。いくつかの例において、第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示し、第１のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第１の人物に対応するが、第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第１のルート開始リクエストに対応する第１のルートを確立することを含む。いくつかの例によると、第１のルートを確立することは、オーディオ環境内の少なくとも第１の人物の第１の位置を決定することと、第１のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定すること、第１のオーディオセッションを開始または予定することとを含む。
いくつかの例によると、第１のルート開始リクエストは、第１のオーディオセッション優先度を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１の接続モードを含み得る。例えば、第１の接続モードは、同期接続モード、トランザクション接続モード、または予定接続モードであり得る。
いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１の人物から承認が要求されることになるかどうかの指示を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１のオーディオセッション目標を含み得る。例えば、第１のオーディオセッション目標は、理解可能、オーディオ品質、空間忠実、可聴、不可聴および／またはプライバシーを含み得る。
いくつかのそのような方法は、第１のルートに対して第１の持続ユニークオーディオセッション識別子を決定することを含み得る。そのような方法は、第１の持続ユニークオーディオセッション識別子を第１のデバイスに送信することを含み得る。
いくつかの例によると、第１のルートを確立することは、環境内の少なくとも１つのデバイスに、少なくとも、第１のルートに対応する第１のメディアストリームを確立させることを含み得る、第１のメディアストリームは、第１のオーディオ信号を含む。いくつかのそのような方法は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号
にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、オーディオセッションの第１のステージに対して第１の人物の第１の向きを決定することを含み得る。いくつかのそのような例によると、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることは、第１の人物の第１の位置および第１の向きに対応する第１の基準空間モードを決定することと、第１の基準空間モードに対応するオーディオ環境内のラウドスピーカの第１の相対アクティベーションを決定することとを含み得る。
いくつかのそのような方法は、第１のオーディオセッションの第２のステージに対して第１の人物の第２の位置および／または第２の向きを決定することを含み得る。いくつかのそのような方法は、第２の位置および／または第２の向きに対応する第２の基準空間モードを決定することと、第２の基準空間モードに対応するオーディオ環境内のラウドスピーカの第２の相対アクティベーションを決定することとを含み得る。
いくつかの例によると、方法は、第２のアプリケーションを実装する第２のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第２のオーディオセッションに対して第２のルートを開始するための第２のルート開始リクエストを受信することを含み得る。第２のルート開始リクエストは、第２のオーディオソースおよび第２のオーディオ環境デスティネーションを示し得る。第２のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第２の人物に対応し得る。いくつかの例において、第２のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第２のルート開始リクエストに対応する第２のルートを確立すること含み得る。いくつかの実装例において、第２のルートを確立することは、オーディオ環境内の少なくとも第２の人物の第１の位置を決定することと、第２のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第２のオーディオセッションを開始することとを含み得る。いくつかの例において、第２のルートを確立することは、少なくとも、第２のルートに対応する第２のメディアストリームを確立することを含み得る。第２のメディアストリームは、第２のオーディオ信号を含む。いくつかのそのような方法は、第２のオーディオ信号が第２のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含み得る。いくつかの例によると、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープすることを含み得る。代替として、または、付加として、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。
いくつかの例において、第１のルート開始リクエストは、オーディオ環境の少なくとも第１のエリアを第１のルートソースまたは第１のルートデスティネーションとして示し得る。いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１のサービス（例えば、音楽提供サービスまたはポッドキャストサービスなどのオンラインコンテ
ンツ提供サービス）を第１のオーディオソースとして示し得る。
いくつかの実装例において、装置（または、システム）は、インタフェースシステムと、制御システムとを含み得る。制御システムは、１つ以上の汎用シングルまたはマルチチッププロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブルロジックデバイス、ディスクリートゲートもしくはトランジスタロジック、ディスクリートハードウェアコンポーネント、またはそれらの組み合わせを含み得る。
いくつかの実装例において、制御システムは、本明細書において開示された方法のうちの１つ以上を実装するように構成され得る。いくつかのそのような方法は、オーディオ環境のオーディオシステムのためのオーディオセッションマネジメントを含み得る。いくつかのそのような例によると、制御システムは、本明細書においてオーディオセッションマネージャと呼ばれ得るものを実装するように構成され得る。
いくつかのそのような方法は、オーディオセッションマネージャ（例えば、オーディオセッションマネージャを実装しているデバイス）と、オーディオシステムの少なくとも第１のスマートオーディオデバイスとの間に第１のスマートオーディオデバイス通信リンクを確立することを含む。いくつかの例において、第１のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれであってもよく、または、それらのいずれを含んでもよい。いくつかのそのような例において、第１のスマートオーディオデバイスは、１つ以上のラウドスピーカを含む。いくつかのそのような方法は、オーディオセッションマネージャと、第１のアプリケーションを実行する第１のアプリケーションデバイスとの間に第１のアプリケーション通信リンクを確立することを含む。
いくつかのそのような方法は、オーディオセッションマネージャによって、第１のスマートオーディオデバイスの第１のメディアエンジンの１つ以上の第１のメディアエンジン能力を決定することを含む。いくつかの例において、第１のメディアエンジンは、第１のスマートオーディオデバイスによって受信された１つ以上のオーディオメディアストリームを管理し、第１のメディアエンジンサンプルクロックにしたがって、１つ以上のオーディオメディアストリームに対して第１のスマートオーディオデバイス信号処理を行うように構成される。
いくつかのそのような例において、方法は、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することを含む。いくつかのそのような方法は、第１のメディアエンジン能力にしたがって第１のスマートオーディオデバイスを制御することを含む。いくつかの実装例によると、制御することは、オーディオセッションマネージャによって、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介してなされる。いくつかのそのような例において、オーディオセッションマネージャは、第１のメディアエンジンサンプルクロックを参照せずに、第１のオーディオセッションマネジメント制御信号を第１のスマートオーディオデバイスに送信する。
いくつかの実装例において、第１のアプリケーション通信リンクは、第１のアプリケーションデバイスからの第１のルート開始リクエストに応答して確立され得る。いくつかの例によると、第１のアプリケーション制御信号は、第１のメディアエンジンサンプルクロックを参照せずに、第１のアプリケーションから送信され得る。いくつかの例において、第１のオーディオセッションマネジメント制御信号は、第１のスマートオーディオデバイ
スに、第１のメディアエンジンの制御をオーディオセッションマネージャに代理させ得る。
いくつかの例によると、オーディオセッションマネージャ以外のデバイスまたは第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。しかし、いくつかの場合において、第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。
いくつかの例において、第１のスマートオーディオデバイスは、特定の目的のオーディオセッションマネージャを含み得る。いくつかのそのような例によると、オーディオセッションマネージャは、特定の目的のオーディオセッションマネージャと、第１のスマートオーディオデバイス通信リンクを介して通信し得る。いくつかのそのような例によると、オーディオセッションマネージャは、１つ以上の第１のメディアエンジン能力を特定の目的のオーディオセッションマネージャから取得し得る。
いくつかの実装例によると、オーディオセッションマネージャは、第１のメディアエンジンを制御するすべてのアプリケーションのためのゲートウェイとして機能し得るが、これは、アプリケーションが第１のスマートオーディオデバイス上で動作するか、または、他のデバイス上で動作するかにかかわらない。
いくつかのそのような方法はまた、少なくとも、第１のオーディオソースに対応する第１のオーディオストリームを確立することを含み得る。第１のオーディオストリームは、第１のオーディオ信号を含み得る。いくつかのそのような例において、少なくとも第１のオーディオストリームを確立することは、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、少なくとも第１のオーディオストリームを確立させることを含み得る。
いくつかの例において、そのような方法はまた、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにするレンダリング処理を含み得る。いくつかの例において、レンダリング処理は、第１のオーディオセッションマネジメント制御信号に応答して、第１のスマートオーディオデバイスによって行われ得る。
いくつかのそのような方法はまた、第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、第１のスマートオーディオデバイスと、オーディオ環境の１つ以上の他のスマートオーディオデバイスのそれぞれとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかのそのような方法はまた、第１のスマートオーディオデバイスに、生のマイクロフォン信号、処理されたマイクロフォン信号、レンダリングされたオーディオ信号および／またはレンダリングされていないオーディオ信号を１つ以上の他のスマートオーディオデバイスにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、そのような方法はまた、オーディオセッションマネージャと、ホームオーディオシステムの少なくとも第２のスマートオーディオデバイスとの間に第２のスマートオーディオデバイス通信リンクを確立することを含み得る。第２のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれでもよいし、いずれを含んでもよい。第２のスマートオーディオデバイスは、１つ以上のマイクロフォンを含み得る。いくつかのそのような方法はまた、オーディオセッションマネージャによって、第２のスマートオーディオデバイスの第２のメディアエンジンの１つ以上の第２のメディアエンジン能力を決定することを含み得る。第２のメディアエン
ジンは、マイクロフォンデータを１つ以上のマイクロフォンから受信し、マイクロフォンデータに対して第２のスマートオーディオデバイス信号処理を行うように構成され得る。いくつかのそのような方法はまた、第２のメディアエンジン能力にしたがって、オーディオセッションマネージャによって、第２のスマートオーディオデバイス通信リンクを介して第２のスマートオーディオデバイスに送信された第２のオーディオセッションマネージャ制御信号を介して、第２のスマートオーディオデバイスを制御することを含み得る。
いくつかのそのような例によると、第２のスマートオーディオデバイスを制御することはまた、第２のスマートオーディオデバイスに、第２のスマートオーディオデバイスと第１のスマートオーディオデバイスとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。いくつかの例において、第２のスマートオーディオデバイスを制御することは、第２のスマートオーディオデバイスに、処理されたおよび／または処理されていないマイクロフォンデータを第２のメディアエンジンから第１のメディアエンジンにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、第２のスマートオーディオデバイスを制御することは、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することと、第２のオーディオセッションマネージャ制御信号を第１のアプリケーション制御信号にしたがって決定することとを含み得る。
代替として、または、付加として、制御システムは、１つ以上の他のオーディオセッションマネジメント方法を実装するように構成され得る。いくつかのそのようなオーディオセッションマネジメント方法は、第１のアプリケーションを実装する第１のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信することを含む。いくつかの例において、第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示し、第１のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第１の人物に対応するが、第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第１のルート開始リクエストに対応する第１のルートを確立することを含む。いくつかの例によると、第１のルートを確立することは、オーディオ環境内の少なくとも第１の人物の第１の位置を決定することと、第１のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第１のオーディオセッションを開始または予定することとを含む。
いくつかの例によると、第１のルート開始リクエストは、第１のオーディオセッション優先度を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１の接続モードを含み得る。例えば、第１の接続モードは、同期接続モード、トランザクション接続モード、または予定接続モードであり得る。
いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１の人物から承認が要求されることになるかどうかの指示を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１のオーディオセッション目標を含み得る。例えば、第１のオーディオセッション目標は、理解可能、オーディオ品質、空間忠実、可聴、不可聴および／またはプライバシーを含み得る。
いくつかのそのような方法は、第１のルートに対して第１の持続ユニークオーディオセ
ッション識別子を決定することを含み得る。そのような方法は、第１の持続ユニークオーディオセッション識別子を第１のデバイスに送信することを含み得る。
いくつかの例によると、第１のルートを確立することは、環境内の少なくとも１つのデバイスに、少なくとも、第１のルートに対応する第１のメディアストリームを確立させることを含み得る、第１のメディアストリームは、第１のオーディオ信号を含む。いくつかのそのような方法は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、オーディオセッションの第１のステージに対して第１の人物の第１の向きを決定することを含み得る。いくつかのそのような例によると、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることは、第１の人物の第１の位置および第１の向きに対応する第１の基準空間モードを決定することと、第１の基準空間モードに対応するオーディオ環境内のラウドスピーカの第１の相対アクティベーションを決定することとを含み得る。
いくつかのそのような方法は、第１のオーディオセッションの第２のステージに対して第１の人物の第２の位置および／または第２の向きを決定することを含み得る。いくつかのそのような方法は、第２の位置および／または第２の向きに対応する第２の基準空間モードを決定することと、第２の基準空間モードに対応するオーディオ環境内のラウドスピーカの第２の相対アクティベーションを決定することとを含み得る。
いくつかの例によると、方法は、第２のアプリケーションを実装する第２のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第２のオーディオセッションに対して第２のルートを開始するための第２のルート開始リクエストを受信することを含み得る。第２のルート開始リクエストは、第２のオーディオソースおよび第２のオーディオ環境デスティネーションを示し得る。第２のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第２の人物に対応し得る。いくつかの例において、第２のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかのそのような方法は、オーディオセッションマネージャを実装するデバイスによって、第２のルート開始リクエストに対応する第２のルートを確立すること含み得る。いくつかの実装例において、第２のルートを確立することは、オーディオ環境内の少なくとも第２の人物の第１の位置を決定することと、第２のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第２のオーディオセッションを開始することとを含み得る。いくつかの例において、第２のルートを確立することは、少なくとも、第２のルートに対応する第２のメディアストリームを確立することを含み得る。第２のメディアストリームは、第２のオーディオ信号を含む。いくつかのそのような方法は、第２のオーディオ信号が第２のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
いくつかのそのような方法は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含み得る。いくつかの例によると、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープすることを含み得る。代替として、または、付加として、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１の
レンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。
いくつかの例において、第１のルート開始リクエストは、オーディオ環境の少なくとも第１のエリアを第１のルートソースまたは第１のルートデスティネーションとして示し得る。いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１のサービス（例えば、音楽提供サービスまたはポッドキャストサービスなどのオンラインコンテンツ提供サービス）を第１のオーディオソースとして示し得る。
本明細書に記載の主題の１つ以上の実装例の詳細を添付の図面および以下の記載において説明する。他の特徴、態様および利点は、明細書、図面および特許請求の範囲から明らかになるであろう。なお、以下の図の相対的な寸法は、正確な縮尺で描かれていないことがある。
図面の簡単な説明
図１Ａは、オーディオ環境内の人物およびスマートオーディオデバイスの例を図示する。 図１Ｂは、図１Ａのシナリオを変更したものの図である。 図１Ｃは、本開示の実施形態にしたがう。 図２Ａは、従来のシステムのブロック図である。 図２Ｂは、図２Ａに示されたデバイスを変更したものの例を図示する。 図２Ｃは、一開示の実装例のブロック図である。 図２Ｄは、連続階層オーディオセッションマネージャ（ＣＨＡＳＭ）とインタラクションする複数のアプリケーションの例を図示する。 図３Ａは、一例に係る図１Ａのデバイス１０１の詳細を図示するブロック図である。 図３Ｂは、一例に係る図１Ｂの実施例の詳細を図示する。 図３Ｃは、オーディオ環境の２つのオーディオデバイスオーケストレートするＣＨＡＳＭの例を図示するブロック図である。 図４は、他の開示された実施形態を例示するブロック図である。 図５は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。 図６は、本開示の様々な態様を実装することができる装置のコンポーネントの例を図示するブロック図である。 図７は、一例に係るＣＨＡＳＭのブロックを図示するブロック図である。 図８は、一例に係る図７に図示されたルーティングテーブルの詳細を図示する。 図９Ａは、オーケストレーションの言語におけるルート開始リクエストの文脈自由文法の例を表す。 図９Ｂは、オーディオセッション目標の例を与える。 図１０は、一例に係るルートを変更するためのリクエストについてのフローを図示する。 図１１Ａは、ルートを変更するためのリクエストについてのフローのさらなる例を図示する。 図１１Ｂは、ルートを変更するためのリクエストについてのフローのさらなる例を図示する。 図１１Ｃは、ルートを削除するためのフローの例を図示する。 図１２は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。 図１３は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。 図１４は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。 図１５は、いくつかの実装例に係る、オーディオ環境に新たに導入される１つ以上のオーディオデバイスに対する自動セットアップ処理のブロックを含むフロー図である。 図１６は、いくつかの実装例に係る、バーチャルアシスタントアプリケーションをインストールするための処理のブロックを含むフロー図である。 図１７は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。 図１８Ａは、最小限バージョンの実施形態のブロック図である。 図１８Ｂは、さらなる特徴を有する別の（より能力の高い）実施形態を図示する。 図１９は、図６、図１８Ａまたは図１８Ｂに示されたような装置またはシステムによって行われ得る方法の一例の概要を示すフロー図である。 図２０は、ひと続きのリビング空間の間取り図の例を示す。 図２１は、ひと続きのリビング空間の間取り図の例を示す。 図２２は、空間音楽ミックスおよびバーチャルアシスタント応答の同時再生を与えるマルチストリームレンダラの例を図示する。 図２３は、空間音楽ミックスおよびバーチャルアシスタント応答の同時再生を与えるマルチストリームレンダラの例を図示する。 図２４は、パーティにおける多くの人物に対し、リビングルームおよびキッチンにおけるすべてのスピーカ上で空間音楽ミックスが最適に再生されている開始点の例を図示する。 図２５は、ベッドルームにおいて眠ろうとしている乳児の例を図示する。 図２６は、さらなるオーディオストリームの再生の例を図示する。 図２７は、図１８Ａに図示されたマルチストリームレンダラの周波数／変換ドメイン例を図示する。 図２８は、図１８Ｂに図示されたマルチストリームレンダラの周波数／変換ドメイン例を図示する。 図２９は、この例においてリビング空間である聴取環境の間取り図を図示する。 図３０は、図２９に図示されたリビング空間における複数の異なる聴取位置および向きに対して、基準空間モードにおいて、空間オーディオをフレキシブルにレンダリングする例を図示する。 図３１は、図２９に図示されたリビング空間における複数の異なる聴取位置および向きに対して、基準空間モードにおいて、空間オーディオをフレキシブルにレンダリングする例を図示する。 図３２は、図２９に図示されたリビング空間における複数の異なる聴取位置および向きに対して、基準空間モードにおいて、空間オーディオをフレキシブルにレンダリングする例を図示する。 図３３は、図２９に図示されたリビング空間における複数の異なる聴取位置および向きに対して、基準空間モードにおいて、空間オーディオをフレキシブルにレンダリングする例を図示する。 図３４は、２人の聴取者が聴取環境の異なる位置内にいる場合の基準空間モードレンダリングの例を図示する。 図３５は、聴取者の位置および向きに関するユーザ入力を受け取るためのＧＵＩの例を図示する。 図３６は、ある環境内の３つのオーディオデバイス間の幾何学的関係の例を図示する。 図３７は、図３６に図示された環境内の３つのオーディオデバイス間の幾何学的関係の別の例を図示する。 図３８は、図３６および３７に図示された三角形の両方を図示するが、対応するオーディオデバイスおよび環境のその他の特徴は図示しない。 図３９は、３つのオーディオデバイスによって形成される三角形の内角を推定する例を図示する。 図４０は、図６に図示されるような装置によって行われ得る方法の一例の概要を示すフロー図である。 図４１は、ある環境内の各オーディオデバイスが複数の三角形の頂点である例を図示する。 図４２は、フォーワードアラインメント処理の一部の例を与える。 図４３は、フォーワードアラインメント処理中に生じたオーディオデバイス位置の複数の推定値の例を図示する。 図４４は、リバースアラインメント処理の一部の例を与える。 図４５は、リバースアラインメント処理中に生じたオーディオデバイス位置の複数の推定値の例を図示する。 図４６は、オーディオデバイスの推定位置および実際の位置の比較を図示する。 図４７は、図６に図示されるような装置によって行われ得る方法の別の例の概要を示すフロー図である。 図４８Ａは、図４７のいくつかのブロックの例を図示する。 図４８Ｂは、聴取者角度向きデータを決定するさらなる例を図示する。 図４８Ｃは、聴取者角度向きデータを決定するさらなる例を図示する。 図４８Ｄは、図４８Ｃを参照して説明する方法にしたがって、オーディオデバイス座標に対して、適切な回転を決定する例を図示する。 図４９は、本開示の様々な態様を実装することができるシステムのコンポーネントの例を図示するブロック図である。 図５０Ａは、再生リミット閾値および対応する周波数の例を図示する。 図５０Ｂは、再生リミット閾値および対応する周波数の例を図示する。 図５０Ｃは、再生リミット閾値および対応する周波数の例を図示する。 図５１Ａは、ダイナミックレンジ圧縮データの例を示すグラフである。 図５１Ｂは、ダイナミックレンジ圧縮データの例を示すグラフである。 図５２は、聴取環境の空間ゾーンの例を図示する。 図５３は、図５２の空間ゾーン内のラウドスピーカの例を図示する。 図５４は、図５３の空間ゾーンおよびスピーカに重ねられた呼び空間位置の例を図示する。 図５５は、本明細書において開示されたような装置またはシステムによって行われ得る方法の一例の概要を示すフロー図である。 図５６Ａは、いくつかの実施形態にしたがって実装できるシステムの例を図示する。 図５６Ｂは、いくつかの実施形態にしたがって実装できるシステムの例を図示する。 図５７は、実施形態にしたがって、ある環境（例えば、ホーム）において実装されたシステムのブロック図である。 図５８は、図５７のモジュール５７０１の例示の実施形態の要素のブロック図である。 図５９は、図５７のモジュール５７０１の別の例示の実施形態（図５９において５９００と標識される）およびその動作のブロック図である。 図６０は、別の例示の実施形態のブロック図である。
実施形態の詳細な説明
多くの実施形態を開示する。これらの実施形態をどのように実装するかは、当業者にとって本開示から明らかとなるであろう。
現在、設計者は、オーディオデバイスを、エンターテインメント、通信および情報サービスを混合させたものであり得るオーディオに対する単一のインタフェースポイントとして考える。通知およびボイス制御のためにオーディオを使用することは、視覚または身体的な介入を回避するという利点を有する。拡大するデバイス風景は、より多くのシステムが我々の１対の耳を競い合いながら、断片化される。ウェアラブル拡張オーディオが利用可能になり始めたが、理想の広汎性のオーディオパーソナルアシスタントを可能にする方向へ収斂しているようには見えないし、我々の周囲の多くのデバイスをシームレスなキャプチャ、接続および通信のために使用することが可能なっていない。
デバイスをブリッジするためのサービスを開発し、位置、コンテキスト、コンテンツ、タイミングおよびユーザの好み（ｐｒｅｆｅｒｅｎｃｅ）をより良く管理することが有用である。これとともに、１セットの規格、インフラストラクチャおよびＡＰＩは、ユーザの周囲のあるオーディオ空間への統合（ｃｏｎｓｏｌｉｄａｔｅｄ）アクセスへのより良いアクセスを可能にし得る。ベーシックオーディオ入力出力を管理し、オーディオデバイスの特定のアプリケーションへの接続を可能にするある種のオペレーティングシステムを考える。この考えおよび設計は、インタラクティブなオーディオトランスポートの骨組みを形成し、例えば、改善の急速で有機的な開発を可能にし、他へのデバイスに依存しないオーディオ接続を提供するサービスを提供する。
オーディオインタラクションの範囲は、リアルタイム通信、非同期チャット、アラート、音声文字変換（ｔｒａｎｓｃｒｉｐｔｉｏｎ）、履歴、アーカイブ、音楽、推奨、リマインダ、促進およびコンテキストを意識した支援を含む。本明細書において一体的アプローチを容易にし、インテリジェントなメディアフォーマットを実装し得るプラットフォームを開示する。プラットフォームは、ユビキタスなウェアラブルオーディオを含み得るか、もしくは、実装し得るか、および／または、ユーザの位置づけ、最良の使用のための１つ以上の（例えば、集合の）オーディオデバイスの選択、アイデンティティ、プライバシー、適時性、地理的位置、ならびに／または、トランスポート、格納、検索およびアルゴリズム実行のためのインフラストラクチャの管理を実装し得る。本開示のいくつかの態様は、アイデンティティ、優先度（ランク）およびユーザの好みの尊重（respecting）、例えば、聞くことの所望度および聞かれることの値を管理することを含み得る。不要なオーディオのコストは、高い。本発明者らは、「オーディオのインターネット」が安全および信頼の一体要素を提供または実装し得ると考える。
単一目的オーディオデバイスおよび多目的オーディオデバイスのカテゴリーは、厳密には直交しないが、あるオーディオデバイス（例えば、スマートオーディオデバイス）のスピーカ（単数または複数）およびマイクロフォン（単数または複数）は、スマートオーディオデバイスによって可能にされるか、または、それに取りつけられる（または、それによって実装される）機能に割り当てられ得る。しかし、典型的には、オーディオデバイスのスピーカおよび／またはマイクロフォンは個別に考えられ（オーディオデバイスとは異なる）、ひとまとまりの中に付加され得るという意味はない。
本明細書において、抽象的な意味でローカルなオーディオデバイス（それぞれは、スピーカおよびマイクロフォンを含み得る）のいずれに対しても独立して存在する集合的なオーディオプラットフォームに対して、ローカルなオーディオデバイスが通知され、利用可
能にされるオーディオデバイス接続性のカテゴリーを説明する。また、集合的なオーディオデバイスのオーケストレーションおよび利用についてのこのアイデアの実現に向けた設計手法およびステップ群を実装する、少なくとも１つの発見可能な日和見的にオーケストレートされた分散型オーディオサブシステム（ＤＯＯＤＡＤ）を含む実施形態を説明する。
本開示のいくつかの実施形態の適用および結果を示すために図１Ａを参照して簡単な例を説明する。
図１Ａは、オーディオ環境内の人物およびスマートオーディオデバイスの例を示す。この例において、オーディオ環境１００は、ホームオーディオ環境である。
図１Ａのシナリオにおいて、人物（１０２）は、マイクロフォンを用いてユーザのボイス（声）（１０３）をキャプチャすることができ、かつ、スピーカ再生（１０４）が可能であるスマートオーディオデバイス（１０１）を有する。ユーザは、デバイス１０１からかなり離れたところで話し得るが、これは、デバイス１０１の二重（duplex）能力を限定する。
図１Ａにおいて、標識された要素は、以下の通りである。
●１００．スマートオーディオデバイスの使用シナリオ例を図示するオーディオ環境。椅子に座っている人物１０２がデバイス１０１と対話している。
●１０１．スピーカ（単数または複数）を介したオーディオ再生およびマイクロフォン（単数または複数）からのオーディオキャプチャが可能なスマートオーディオデバイス。
●１０２．デバイス１０１を使用して、オーディオ体験に参加している人物（ユーザまたは聴取者とも呼ばれる）。
●１０３．デバイス１０１に話しかけている人物１０２によって発せられた音。
●１０４．デバイス１０１のスピーカ（単数または複数）から再生されたオーディオ。
このように、この例において、図１Ａは、この場合、通信のための電話デバイスであるスマートオーディオデバイス（１０１）を有する在宅の人物（１０２）の図である。デバイス１０１は、人物１０２が聞いたオーディオを出力でき、また、人物１０２からの音（１０３）をキャプチャできる。しかし、デバイス１０１は、人物１０２からある程度距離が離れているので、デバイス１０１上のマイクロフォンは、デバイス１０１から出力されたオーディオ越しに人物１０２を聞くという課題を有する（エコー問題として知られる課題）。この問題を解決する従来技術は、典型的には、エコーキャンセルを使用する。エコーキャンセルは、完全二重アクティビティ（ダブルトーク、すなわち、双方向の同時のオーディオ）によって大きく限定される処理の形態である。
図１Ｂは、図１Ａのシナリオを変更したものの図である。この例において、第２のスマートオーディオデバイス（１０５）はまた、オーディオ環境１００内に存在する。スマートオーディオデバイス１０５は、人物１０２の近くに置かれているが、オーディオを出力する機能を有するように設計されている。いくつかの例において、スマートオーディオデバイス１０５は、少なくとも部分的に、バーチャルアシスタントを実装し得る。
現在、人物１０２（図１Ａ）は、第２のスマートオーディオデバイス１０５を取得しているが、デバイス１０５（図１Ｂに示す）は、第１のデバイス（１０１）の目的とは完全に別の特定の目的（１０６）を行うことができるだけである。この例において、２つのスマートオーディオデバイス（１０１および１０５）は、ユーザと同じ音響空間にいるにも
かかわらず、情報を共有し、体験をオーケストレートすることができない。
図１Ｂにおいて、標識された要素は、以下の通りである。
●１００～１０４．図１Ａを参照。
●１０５．スピーカ（単数または複数）を介したオーディオ再生およびマイクロフォン（単数または複数）からのオーディオキャプチャが可能なさらなるスマートオーディオデバイス。
●１０６．デバイス１０５のスピーカ（単数または複数）を介したオーディオの再生。
オーディオ通話（ｃａｌｌ）を電話（１０１）からこのスマートオーディオデバイス（１０５）にペアリングまたはシフトすることが可能であり得るが、これは、これまでユーザの介入および詳細な構成なしには可能でなかった。したがって、図１Ｂに図示されたシナリオは、２つの独立したオーディオデバイスがあり、それぞれが非常に特定のアプリケーションを行う状況である。この例において、スマートオーディオデバイス１０５は、デバイス１００よりも最近に購入された。スマートオーディオデバイス（１０５）は、特定の目的のために購入され、箱から出された状態で、その特定の目的（単数または複数）のために有用なだけであり、オーディオ環境１００において既に存在し、通信デバイスとして使用中のデバイス（１０１）に即座に価値を付加するものではない。
図１Ｃは、本開示の実施形態に係る図である。この例において、スマートオーディオデバイス１０５は、スマートオーディオデバイス１００よりも最近に購入された。
図１Ｃの実施形態において、スマートオーディオデバイス１０１および１０５は、オーケストレーションが可能である。オーケストレーションのこの例において、スマートオーディオデバイス（１０５）は、スマートオーディオデバイス１０１が音１０４をスピーカ（単数または複数）から再生する際に、スマートオーディオデバイス（１０１）に関与する通話のために、人物１０２のボイス（１０３Ｂ）を聞き取るのにより良い位置に置かれている。
図１Ｃにおいて、標識された要素は、以下の通りである。
●１００～１０４．図１Ａを参照。
●１０５．図１Ｂを参照。
●１０３Ｂ．スマートオーディオデバイス（１０５）のマイクロフォン（単数または複数）は、ユーザにより近いので、人物１０２が発する音は、スマートオーディオデバイス（１０５）によってより良くキャプチャされる。
図１Ｃにおいて、新たなスマートオーディオデバイス１０５は、デバイス１０５内のマイクロフォンがスマートオーディオデバイス（１０１）上で動作したアプリケーションをサポートするように機能できるように、何らかの方法（その例は、本明細書に記載される）で検出される。図１Ｃの新たなスマートオーディオデバイス１０５は、ある意味において図１Ｃのデバイス１０１（本開示のいくつかの態様にしたがって）とともにコーディネートまたはオーケストレートされ、図１Ｃに図示された状況に対する優れたマイクロフォンとして、人物１０２に対するスマートオーディオデバイス１０５の近さ（proximity）
が日和見的に（opportunistically）検出または評価される。図１Ｃにおいて、オーディ
オ１０４は、相対的により離れたスピーカフォン１０１から出ている。しかし、電話１０１に送られるべきオーディオ１０３Ｂは、ローカルなスマートオーディオデバイス１０５によってキャプチャされる。いくつかの実施形態において、ルーティングの複雑さおよびスマートオーディオデバイス１０５の能力を考慮すると、異なるスマートオーディオデバイスのコンポーネントのこの日和見的な使用法は、通話を与えるために電話１０１および
／またはアプリケーションが使用されることなく、可能にされる。むしろ、いくつかのそのような例において、発見、ルーティングおよびそのような能力の利用のために、階層的なシステムが実装され得る。
抽象的な連続階層オーディオセッションマネージャ（ＣＨＡＳＭ）の概念のより詳細については後述するが、それのいくつかの実施例は、アプリケーションが管理デバイス、デバイス接続性、同期デバイス使用、ならびに／またはデバイスレベリングおよびチューニングの完全な詳細を知る必要なく、オーディオ能力をアプリケーションに与えることができる。ある意味において、この手法では、アプリケーションを正常に動作させるデバイス（少なくとも１つのスピーカおよび少なくとも１つのマイクロフォンを有する）がオーディオ体験の制御を放棄していることが分かる。しかし、部屋においてスピーカおよび、重要には、マイクロフォンの数が人の数よりもはるかに大きい場合は、オーディオの多くの問題の解決策は、関係する人物に最も近いデバイス（そのようなアプリケーションのために通常に使用されるデバイスでなくてもよい）の位置を検出するステップを含み得ることが分かる。
オーディオトランスデューサ（スピーカおよびマイクロフォン）に対する１つの考え方は、オーディオトランスデューサは、オーディオが人物の口からアプリケーションへ行くルートにおける一ステップと、アプリケーションから人物の耳へのルートにおけるリターンステップを実装することができると言うことである。この意味において、デバイスを日和見的に活用し、任意のデバイス上でオーディオサブシステムとインタラクションしてオーディオを出力するか、または、入力オーディオを得ることによって、オーディオを送るか、または、ユーザからオーディオをキャプチャする必要のある任意のアプリケーションを改善できる（または、少なくとも悪化させないようにできる）ことが理解できる。そのような決定およびルーティングは、いくつかの例において、デバイスおよびユーザが移動するか、応答可能（available）になるか、または、システムから除かれるかする場合に
、連続的になされ得る。この点に関して、本明細書において開示された連続階層オーディオセッションマネージャ（ＣＨＡＳＭ）が有用である。いくつかの実装例において、発見可能な日和見的にオーケストレートされた分散型オーディオサブシステム（ＤＯＯＤＡＤ）をまとめてＣＨＡＳＭ内に含めることができるか、または、ＤＯＯＤＡＤをまとめてＣＨＡＳＭとともに使用できる。
いくつかの開示された実施形態は、オーディオを人物および場所へ、ならびに、人物および場所からルーティングするために設計された集合的なオーディオシステムの概念を実装する。これは、オーディオのデバイスからの入力および出力、そしてデバイスの一括管理に一般に関する従来の「デバイス中心」の設計から脱却する。
次に、図２Ａ～２Ｄを参照し、本開示のいくつかの例示の実施形態を説明する。まず、通信機能を有するデバイスを説明する。この場合、例えば、ドアベルオーディオインターコムデバイスを考える。ドアベルオーディオインターコムデバイスは、アクティベートされると、ローカルなデバイスからあるリモートユーザへの完全二重オーディオリンクを生成するローカルアプリケーションを開始する。このモードにおけるデバイスの基本機能は、スピーカ、マイクロフォンを管理し、双方向ネットワークストリームを介してスピーカ信号およびマイクロフォン信号を中継することである。これは、本明細書において、「リンク」と呼ばれ得る。
図２Ａは、従来のシステムのブロック図である。この例において、スマートオーディオデバイス２００Ａの動作は、媒体（２１２）および制御情報（２１３）をメディアエンジン（２０１）へおよびそれから送信するアプリケーション（２０５Ａ）を含む。メディアエンジン２０１およびアプリケーション２０５Ａの両方は、スマートオーディオデバイス
２００Ａの制御システムによって実装され得る。この例によると、メディアエンジン２０１は、オーディオ入力（２０３）および出力（２０４）を管理する役割を有し、かつ、信号処理および他のリアルタイムのオーディオタスクを行うように構成され得る。また、アプリケーション２０５Ａは、他のネットワーク入力および出力接続性（２１０）を有し得る。
図２Ａにおいて、標識された要素は、以下の通りである。
●２００Ａ．特定目的スマートオーディオデバイス。
●２０１．アプリケーション２０５Ａから入力されるリアルタイムのオーディオメディアストリームの管理、ならびにマイクロフォン入力およびスピーカ出力に対する信号処理の役割を有するメディアエンジン。信号処理の例は、アコースティックエコーキャンセル、自動ゲイン制御、ウェイクワード検出、リミッタ、ノイズ抑制、ダイナミックビームフォーミング、音声認識、損失性フォーマットへの符号化／復号化、ボイスアクティビティ検出および他の分類器（classifier）などを含み得る。この状況において、「リアルタイム」という用語は、例えば、デバイス２００Ａによって実装されるアナログ－デジタルコンバータ（ＡＤＣ）からのオーディオのブロックをサンプリングするのにかかる時間内にオーディオのブロックの処理が完了されることが必要であることを指し得る。例えば、特定の実装例において、オーディオのブロックは、長さが１０～２０ｍｓであり、４８０００サンプル／秒でサンプリングされた４８０～９６０個の連続したサンプルを含み得る。
●２０３．マイクロフォン入力。音響情報を検知でき、複数のＡＤＣによってメディアエンジン（２０１）とのインタフェースがとられる１つ以上のマイクロフォンからの入力。
●２０４．スピーカ出力。音響エネルギーを再生でき、複数のデジタル－アナログコンバータ（ＤＡＣ）および／または増幅器によってメディアエンジン（２０１）とのインタフェースがとられる１つ以上のスピーカからの入力。
●２０５Ａ．デバイス２００Ａ上で動作するアプリケーション（「アプリ」）。アプリは、ネットワークから来るメディアおよびネットワークへ行くメディアを取り扱い、メディアストリームをメディアエンジン２０１に送信およびメディアエンジン２０１から受信する役割を有する。この例において、アプリ２０５Ａはまた、メディアエンジンによって送受信される制御情報を管理する。アプリ２０５Ａの例は、以下を含む：
〇インターネットに接続し、パケットをマイクロフォンからウェブサービスへストリーミングするウェブカム内の制御ロジック。
〇タッチスクリーンを介してユーザとのインタフェースをとる会議電話。タッチスクリーンによって、ユーザは、電話番号をダイヤルすること。コンタクトリストを閲覧すること、音量を変えること、通話を開始および終了することができる
〇音楽ライブラリから音楽を再生できる、スマートスピーカ内のボイス駆動アプリケーション。
●２１０．デバイス２００Ａをネットワークに接続するオプションのネットワーク接続（例えば、ＷｉＦｉまたはＥｔｈｅｒｎｅｔまたは４Ｇ／５Ｇセルラー電波を介してインターネットへ）。ネットワークは、ストリーミングメディアトラフィックを搬送し得る。
●２１２．メディアエンジン（２０１）へおよびそれからストリーミングされたメディアストリーム。例えば、特定目的電話会議デバイス内のアプリ２０５Ａは、ネットワーク
（２１０）からリアルタイムトランスポートプロトコル（Real-time Transport Protocol（ＲＴＰ））パケットを受信し、ヘッダを取り出し、Ｇ．７１１ペイロードを処理および再生のためにメディアエンジン２０１に送り得る。いくつかのそのような例において、アプリ２０５Ａは、メディアエンジン２０１からＧ．７１１ストリームを受信し、ネットワーク（２１０）を介したアップストリーム配信のためのＲＴＰパケットをパッキングする役割を有し得る。
●２１３．メディアエンジン（２０１）を制御するための、アプリ２０５Ａへおよびそれから送信された制御信号。例えば、ユーザがユーザインタフェース上の音量上げボタンを押した場合、アプリ２０５Ａは、再生信号（２０４）を増幅するために、制御情報をメディアエンジン２０１に送信する。特定目的デバイス２００Ａにおいて、メディアエンジン（２０１）の制御は、メディアエンジンを外部から制御する能力のないローカルアプリ（２０５Ａ）のよって行われるのみである。
図２Ｂは、図２Ａに示されたデバイスの変形例を示す。オーディオデバイス２００Ｂは、第２のアプリケーションを実行できる。例えば、第２のアプリケーションは、セキュリティシステム用のドアベルデバイスからオーディオを連続的にストリーミングするアプリケーションであり得る。この場合、単一方向だけのネットワークストリームを制御する第２のアプリケーションを用い、同じオーディオサブシステム（図２Ａを参照して記載）が使用され得る。
この例において、図２Ｂは、情報を特定目的オーディオセッションマネージャ（Specific Purpose Audio Session Manager（ＳＰＡＳＭ））を介してメディアエンジン２０２（デバイス２００Ｂのメディアエンジン）に送信する２つのアプリケーションまたは「アプリ」（アプリ２０５Ｂおよびアプリ２０６）をホストすることができる特定目的スマートオーディオデバイス（２００Ｂ）のブロック図である。ＳＰＡＳＭをアプリ２０５Ｂおよび２０６に対するインタフェースとして用いると、ネットワークメディアは、この場合、メディアエンジン２０２に直接流れることができる。ここで、メディア２１０は、第１のアプリ（２０６）へおよびそれからのメディアであり、メディア２１１は、第２のアプリ（２０５Ｂ）に対するメディアである。
本明細書において、ＳＰＡＳＭ（または、特定目的オーディオセッションマネージャ）とい用語は、単一タイプの機能のためのオーディオチェーンを実装するように構成された（デバイスの）要素またはサブシステムを表すために使用される。デバイスは、その単一型の機能を提供するために製造された。ＳＰＡＳＭは、デバイスの動作モードの変化を実装するために、再構成される必要があり得る（例えば、オーディオシステム全体を分解することによることを含む）。例えば、ほとんどのラップトップにおけるオーディオは、ＳＰＡＳＭとして、または、それを使用して実装される。ここで、ＳＰＡＳＭは、特定の機能のための任意の所望の単一目的オーディオチェーンを実装するように構成される（かつ、再構成可能である）。
図２Ｂにおいて、標識された要素は以下の通りである。
●２００Ｂ．２つのアプリ（アプリ２０５Ｂおよびアプリ２０６）をホストする特定目的オーディオセッションマネージャ（ＳＰＡＳＭ）２０７Ｂを有するスマートオーディオデバイス
●２０２～２０４．図２Ａを参照。
●２０５Ｂ、２０６．ローカルなデバイス２００Ｂ上で動作するアプリ。
●２０７Ｂ．オーディオ処理を管理し、デバイス２００Ｂのメディアエンジン（２０２）の能力を露見させる役割を有する特定目的オーディオセッションマネージャ。各アプリ（２０６または２０５Ｂ）とＳＰＡＳＭ２０７Ｂとの線引きは、異なるアプリがどのように異なるオーディオ能力を使用することを所望するかを示す（例えば、アプリは、異なるサンプリングレートまたは異なる数の入力および出力を必要とし得る）。すべてのオーディオ能力は、ＳＰＡＳＭによって、異なるアプリについて露見され、かつ、管理される。ＳＰＡＳＭのある限定は、ＳＰＡＳＭが特定の目的のために設計され、ＳＰＡＳＭが知る動作を行うことができるだけということである。
●２１０．第１のアプリ（２０５Ｂ）に対してネットワークへおよびそれからストリーミングされるメディア情報。ＳＰＡＳＭ（２０７Ｂ）は、メディアの流れがメディアエンジン（２０２）に直接ストリーミングされることを可能にする。
●２１１．第２のアプリ（２０６）に対してネットワークへストリーミングされるメディア情報。この例において、アプリ２０６は、受信すべきメディアストリームを一切有さない。
●２１４ メディアエンジンの機能を管理するためにＳＰＡＳＭ（２０７Ｂ）およびメディアエンジン（２０２）へおよびそれから送信される制御情報。
●２１５、２１６．アプリ（２０５Ｂ、２０６）およびＳＰＡＳＭ（２０７Ｂ）へおよびそれから送信される制御情報。
ＳＰＡＳＭ２０７Ｂを図２Ｂのデバイス２００Ｂの別個のサブシステムとして含むことは、設計において人為的なステップを実装するように見え得る。実際には、それは、単一目的オーディオデバイス設計の観点からは不必要な作業であり得るものを含まない。ＣＨＡＳＭ（後述）の価値の大半は、ネットワーク効果として可能にされ、（ある意味で）ネットワーク内のノードの数の二乗としてスケーリングされる。しかし、スマートオーディオデバイス内にＳＰＡＳＭ（例えば、図２ＢのＳＰＡＳＭ２０７Ｂ）を含むことは、利点と価値を有し、以下を含む：
－ＳＰＡＳＭ２０７Ｂによる制御の抽象化（abstraction）によって、複数のアプリケ
ーションが同じデバイス上で動作することをより容易に可能にする、
－ＳＰＡＳＭ２０７Ｂは、オーディオデバイスに密接に接続され、ネットワークストリーム接続性をＳＰＡＳＭ２０７Ｂに直接に導入することによって、ネットワークを介したオーディオデータと物理的な入力および出力音との間の遅延を低減する。例えば、ＳＰＡＳＭ２０７Ｂは、スマートオーディオデバイス２００Ｂにおけるより低い層（より低いＯＳＩまたはＴＣＰ／ＩＰ層など）であって、デバイスドライバ／データリンク層により近いか、または、下の物理的なハードウェア層にある層において存在し得る。ＳＰＡＳＭ２０７Ｂがより高い層に実装されたとすると、例えば、デバイスオペレーティングシステム内で動作するアプリケーションとして実装されたとすると、そのような実装例は、レイテンシと言うペナルティを受ける可能性がある。なぜなら、オーディオデータは、低レベル層からオペレーティングシステムを介してアプリケーション層にまで戻るようにコピーされる必要があり得るからである。そのような実装例のさらに悪い特徴の可能性として、レイテンシが変動可能または予測不可能であり得る。
－この設計は、アプリケーションレベルの前に、より低いオーディオレベルでのより大きな相互接続性のために用意ができている。
オペレーティングシステムがＳＰＡＳＭを動作させるスマートオーディオデバイスにお
いて、いくつかの例において、多くのアプリは、スマートオーディオデバイスのスピーカ（単数または複数）およびマイクロフォン（単数または複数）への共有されたアクセスを取得し得る。オーディオストリーム（単数または複数）を送受信する必要のないＳＰＡＳＭを導入することによって、いくつかの例によると、メディアエンジンは、非常に低いレイテンシについて最適化され得る。なぜなら、メディアエンジンは、制御ロジックから分離されているからである。ＳＰＡＳＭを有するデバイスは、アプリケーションがさらなるメディアストリーム（例えば、図２Ｂのメディアストリーム２１０および２１１を確立することを可能にし得る。この利点は、メディアエンジン機能をＳＰＡＳＭの制御ロジックから分離させたことによる。この構成は、図１Ａおよび２Ａに示された状況に対して対照的である。図１Ａおよび２Ａにおいては、メディアエンジンは、特定のアプリケーション専用であり、独立型である。これらの例において、デバイスは、例えば、図２Ｂに図示するように、ＳＰＡＳＭを含むことによって可能にされるさらなるデバイスへ／からさらなる低レイテンシ接続性を有するようには設計されていなかった。いくつかのそのような例において、図１Ａおよび２Ａに図示されるようなデバイスが独立型に設計されたとすると、オーケストレーションを提供するために、容易に、例えば、アプリケーション２０５Ａを更新することは、可能でないであろう。しかし、いくつかの例において、デバイス２００Ｂは、オーケストレーション対応（orchestration-ready)に設計される。
次に、図２Ｃを参照し、通知（advertising）および制御を可能にする（スマートオー
ディオデバイスの）ＳＰＡＳＭ自体のいくつかの開示された実施形態の態様を説明する。ＳＰＡＳＭにより、ネットワーク内の他のデバイスおよび／またはシステムは、プロトコルを利用してデバイスのオーディオ能力をより良く理解することができるようになり、セキュリティおよび使用性の観点から適用可能な場合、オーディオストリームが直接にそのデバイスに接続されることを可能にし、スピーカ（単数または複数）で再生され得るか、または、マイクロフォン（単数または複数）から取得され得る。この場合、オーディオを連続的にデバイスからストリーミングする能力をセットアップするための第２のアプリケーションは、例えば、上記の監視ストリーム（例えば、２１１）をストリーミング出力するようにメディアエンジン（例えば、２０２）を制御するためにアプリケーションをローカルで動作させる必要がないことがわかる。
図２Ｃは、一開示の実装例のブロック図である。この例において、２つ以上のアプリのうちの少なくとも１つのアプリ（例えば、図２Ｃのアプリ２０５Ｂ）がスマートオーディオデバイス２００Ｃ以外のデバイス、例えば、例えば、クラウドベースサービスを実装する１つ以上のサーバによって、スマートオーディオデバイス２００Ｃが存在するオーディオ環境内の別のデバイスによって、などで実装される。したがって、別のコントローラ（この例において、図２ＣのＣＨＡＳＭ２０８Ｃ）は、オーディオ体験を管理することを求められる。この実装例において、ＣＨＡＳＭ２０８Ｃは、リモートアプリ（単数または複数）と、オーディオ能力を有するスマートオーディオデバイス（２００Ｃ）との間のギャップを埋めるコントローラである。様々な実施形態において、ＣＨＡＳＭ（例えば、図２ＣのＣＨＡＳＭ２０８Ｃ）は、デバイス、または、デバイスのサブシステム（例えば、ソフトウェアにおいて実装される）として実装され得る。ここで、ＣＨＡＳＭであるか、または、それを含むデバイスは、１つ以上の（例えば、多くの）スマートオーディオデバイスと異なる。しかし、いくつかの実装例において、ＣＨＡＳＭは、オーディオ環境の１つ以上のデバイスによって実行されることが場合により可能であるソフトウェアを介して実装され得る。いくつかのそのような実装例において、ＣＨＡＳＭは、オーディオ環境の１つ以上の１つ以上のスマートオーディオデバイスによって実行されることが場合により可能であるソフトウェアを介して実装され得る。図２Ｃにおいて、ＣＨＡＳＭ２０８Ｃは、デバイス２００Ｃのオーディオ入力（２０３）および出力（２０４）を制御するメディアエンジン（２０２）へのアクセスを得るために、デバイス２００ＣのＳＰＡＳＭ（すなわち、図２ＣのＳＰＡＳＭ２０７Ｃ）とコーディネートする。
本明細書において、「ＣＨＡＳＭ」という用語は、複数（例えば、１集合）のデバイス（スマートオーディオデバイスを含み得るが、それらに限定されない）が利用可能にされ得るマネージャ（例えば、オーディオセッションマネージャ、例えば、現行のオーディオセッションマネージャであるか、または、それを実装するデバイス）を表すために使用される。いくつかの実装例によると、ＣＨＡＳＭは、連続的に（少なくとも、本明細書において「ルート」と呼ばれるものが実装されている時間において）少なくとも１つのソフトウェアアプリケーションに対してルーティングおよび信号処理を調節できる。アプリケーションは、特定の実装例に応じて、オーディオ環境のデバイスのいずれかの上で実装されてもよいし、されなくてもよい。換言すると、ＣＨＡＳＭは、オーディオ環境内の１つ以上のデバイスによって実行されている１つ以上のソフトウェアアプリケーションおよび／またはオーディオ環境外の１つ以上のデバイスによって実行されている１つ以上のソフトウェアアプリケーションに対するオーディオセッションマネージャ（本明細書において、「セッションマネージャ」とも呼ばれる）を実装し得るか、または、それとして構成され得る。ソフトウェアアプリケーションは、本明細書において、「アプリ」と呼ばれることもある。
いくつかの例において、ＣＨＡＳＭを使用した結果、オーディオデバイスは、そのオーディオデバイスの制作者および／または製造者によって想定されていなかった目的のために使用されてしまうことがあり得る。例えば、スマートオーディオデバイス（少なくとも１つのスピーカおよびマイクロフォンを含む）は、スマートオーディオデバイスがスピーカフィード信号および／またはマイクロフォン信号をオーディオ環境内の１つ以上の他のオーディオデバイスに与えるモードに入り得る。なぜなら、アプリ（例えば、スマートオーディオデバイスと異なる別のデバイス上に実装される）は、ＣＨＡＳＭ（スマートオーディオデバイスに接続される）に、オーディオ環境の複数のオーディオデバイスからのスピーカおよび／またはマイクロフォンを含み得るすべての利用可能なスピーカおよび／またはマイクロフォン（または、ＣＨＡＳＭによって選択された１グループの利用可能なスピーカおよび／またはマイクロフォン）を見つけ出し、使用することを要求する。多くのそのような実装例において、アプリケーションは、デバイス、スピーカおよび／またはマイクロフォンを選択する必要がない。なぜなら、ＣＨＡＳＭがこの機能を提供することになるからである。いくつかの例において、アプリケーションは、どの特定のオーディオデバイスがアプリケーションによってＣＨＡＳＭに与えられるコマンドを実装することに関係しているかを知らなくてもよい（例えば、ＣＨＡＳＭは、そのオーディオデバイスをアプリケーションに示さなくてもよい）。
図２Ｃにおいて、標識された要素は、以下の通りである。
●２００Ｃ．ＣＨＡＳＭ（２０８Ｃ）を介してローカルアプリ（２０６）およびリモートアプリ（２０５Ｂ）を動作させるセッションマネージャである特定目的スマートオーディオデバイス。
●２０２～２０４．図２Ａを参照。
●２０５Ｂ．例えば、ＣＨＡＳＭ２０８Ｃがインターネットを介して通信するように構成されるサーバ上、またはオーディオ環境の別のデバイス（デバイス２００Ｃと異なるデバイス、例えば、携帯電話などの別のスマートオーディオデバイス）上で、デバイス２００Ｃからリモートで動作するアプリ。いくつかの例において、アプリ２０５Ｂは、第１のデバイス上で実装され得、ＣＨＡＳＭ２０８Ｃは、第２のデバイス上で実装され得る。ここで、第１のデバイスおよび第２のデバイスの両方は、デバイス２００Ｃと異なる。
●２０６．デバイス２００Ｃ上でローカルに動作するアプリ。
●２０７Ｃ．メディアエンジン（２０２）とインタフェースをとることに加えて、ＣＨＡＳＭ２０８Ｃからの制御入力を管理できるＳＰＡＳＭ。
●２０８Ｃ．アプリ（２０５Ｂ）がデバイス２００Ｃのメディアエンジン（２０２）のオーディオ能力、入力（２０３）および出力（２０４）を利用できるようにする連続階層オーディオセッションマネージャ（ＣＨＡＳＭ）。この例において、ＣＨＡＳＭ２０８Ｃは、ＳＰＡＳＭ２０７Ｃからのメディアエンジン（２０２）の少なくとも部分制御を得ることによって、ＳＰＡＳＭ（２０７Ｃ）を介して、そうするように構成される。
●２１０～２１１．図２Ｃを参照。
●２１７．メディアエンジンの機能を管理するために、ＳＰＡＳＭ（２０７Ｂ）およびメディアエンジン（２０２）へおよびそれから送信される制御情報。
●２１８．ローカルアプリ２０６を実装するためのローカルアプリ２０６およびＳＰＡＳＭ（２０７Ｃ）へおよびそれからの制御情報。いくつかの実装例において、そのような制御情報は、本明細書において開示されるようなオーケストレーションの言語に従い得る。
●２１９．メディアエンジン２０２の機能を制御するための、ＣＨＡＳＭ（２０８Ｃ）およびＳＰＡＳＭ（２０７Ｃ）へおよびそれからの制御情報。そのような制御情報は、いくつかの場合において、制御情報２１７と同じか、または、それに類似し得る。しかし、いくつかの実装例において、制御情報２１９は、より低いレベルの詳細を有し得る。なぜなら、いくつかの例において、デバイスに特定的な詳細は、ＳＰＡＳＭ２０７Ｃに代理され得るからである。
●２２０．アプリ（２０５Ｂ）とＣＨＡＳＭ（２０８Ｃ）との間の制御情報。いくつかの例において、この制御情報は、本明細書においてオーケストレーションの言語と呼ばれるもので表され得る。
制御情報２１７は、例えば、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御信号を含み得る。この制御信号は、出力ラウドスピーカフィード（単数または複数）の出力レベルを調節する効果、例えば、デシベル単位のゲイン調節、または線形スカラー値を有する。出力ラウドスピーカフィード（単数または複数）に適用されるイコライゼーションカーブ（単数または複数）の変更など。いくつかの例において、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御情報２１７は、例えば、パラメータ的に記述された（ベーシックフィルタ段の直列の組み合わせとして）か、または、特定の周波数におけるゲイン値の列挙の表として表された新たなイコライゼーションカーブを与えることによって、出力ラウドスピーカフィード（単数または複数）に適用されるイコライゼーションカーブ（単数または複数）を変更する効果を有する制御信号を含み得る。いくつかの例において、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御情報２１７は、例えば、ソースフィードをラウドスピーカフィードに組み合わせるために使用される混合行列を与えることによって、複数のオーディオソースフィードを出力ラウドスピーカフィードにレンダリングするアップミックスまたはダウンミックス処理を変更する効果を有する制御信号を含み得る。いくつかの例において、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御情報２１７は、例えば、オーディオコンテンツのダイナミックレンジを変更するなどの、出力ラウドスピーカフィード（単数または複数）に適用されるダイナミックス処理を変更する効果を有する制御信号を含み得る。
いくつかの例において、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御情報２１７は、メディアエンジンに提供されている１セットのメディアストリームに対する変更を示し得る。いくつかの例において、ＳＰＡＳＭ２０７Ｃからメディアエンジン２０２への制御情報２１７は、他のメディアエンジンまたはメディアコンテンツの他のソース（例えば、クラウドベースのストリーミングサービス）を用いてメディアストリームを確立または終了させる必要性を示し得る。
いくつかの場合において、制御情報２１７は、ウェイクワード検出情報などの、メディアエンジン２０２からＳＰＡＳＭ２０７Ｃへの制御信号を含み得る。そのようなウェイクワード検出情報は、いくつかの場合において、ウェイクワード確信度値、または、推定（ｐｒｏｂａｂｌｅ）ウェイクワードが検出されたことを示すメッセージを含み得る。いくつかの例において、ウェイクワード確信度値は、一期間あたり一回（例えば、１００ｍｓあたり１回、１５０ｍｓあたり１回、２００ｍｓあたり１回など）送信され得る。
いくつかの場合において、メディアエンジン２０２からの制御情報２１７は、ＳＰＡＳＭ、ＣＨＡＳＭまたは別のデバイス（例えば、クラウドベースサービスのデバイス）が、どのコマンドが発せられているかを決定するために復号化（例えば、ビタビ復号化）を行うことを可能にする音声認識電話確率を含み得る。いくつかの場合において、メディアエンジン２０２からの制御情報２１７は、音圧力レベル（ＳＰＬ）計測器からのＳＰＬ情報を含み得る。いくつかのそのような例によると、ＳＰＬ情報は、例えば、１秒ごとに１回、半秒ごとに１回、Ｎ秒またはＮミリ秒ごとに１回などの時間間隔で送信され得る。いくつかのそのような例において、ＣＨＡＳＭは、例えば、デバイスが同じ部屋に存在するかどうか、および／または、デバイスが同じ音を検出しているかどうかを決定するなどの、複数のデバイスにわたるＳＰＬ計測器の測定値に相関があるかどうかを決定するように構成され得る。
いくつかの例によると、メディアエンジン２０２からの制御情報２１７は、例えば、背景ノイズの推定、到来方向（direction of arrival（ＤＯＡ））情報の推定、ボイスアクティビティ検出を介した音声存在の指示、現在のエコーキャンセル能力などの、メディアエンジンが利用可能なメディアストリームとして存在するマイクロフォンフィードから得られる情報を含み得る。いくつかのそのような例において、ＤＯＡ情報は、オーディオ環境内のオーディオデバイスの音響マッピングを行い、いくつかのそのような例において、オーディオ環境の音響マップを作成するように構成されたアップストリームＣＨＡＳＭ（または、別のデバイス）に与えられ得る。いくつかのそのような例において、ＤＯＡ情報は、ウェイクワード検出イベントに対応づけられ得る。いくつかのそのような実装例において、ＤＯＡ情報は、ウェイクワードを発声したユーザの位置を特定するために音響マッピングを行うように構成されたアップストリームＣＨＡＳＭ（または、別のデバイス）に与えられ得る。
いくつかの例において、メディアエンジン２０２からの制御情報２１７は、例えば、どのアクティブなメディアストリームが利用可能であるかに関する情報、線形時間（linear-time）メディアストリーム（例えば、テレビ番組、映画、ストリーミングビデオ）内の
時間位置、アクティブなメディアストリームに結びついたレイテンシなどの現在のネットワーク能力に関連する情報、信頼性情報（例えば、パケット損失統計）などの、ステータス情報を含み得る。
図２Ｃのデバイス２００Ｃの設計は、本開示の態様にしたがう様々な様態で拡張され得る。図２ＣのＳＰＡＳＭ２０７Ｃの機能は、ローカルなメディアエンジン２０２を制御するための１セットのフック（hook）または機能を実装することであることが見て取れ得る
。したがって、デバイス２００Ｃは、オーディオデバイスを接続し、ネットワークストリーム、信号処理を行い、デバイス２００Ｃのローカルアプリケーション（単数または複数）およびまたオーディオセッションマネージャの両方からのコンフィグレーションコマンドに応答することができるメディアエンジンにより近いもの（例えば、デバイス２００Ａまたはデバイス２００Ｂの機能よりも近い）として考えられ得る。この場合、オーディオセッションマネージャを支援するために、デバイスがそれ自体についての情報（例えば、メモリデバイスに格納され、かつ、オーディオセッションマネージャが利用可能である）を有することが重要である。この情報の簡単な例は、スピーカの数、スピーカ（単数または複数）の能力、ダイナミックス処理情報、マイクロフォンの数、マイクロフォン配置および感度についての情報などを含む。
図２Ｄは、ＣＨＡＳＭとインタラクションする複数のアプリケーションの例を図示する。図２Ｄに図示の例において、スマートオーディオデバイスに対してローカルなアプリ（例えば、スマートオーディオデバイス２００Ｄのメモリ内に格納されたアプリ２０６）を含むすべてのアプリは、スマートオーディオデバイス２００Ｄに関与する機能を提供するために、ＣＨＡＳＭ２０８Ｄとのインタフェースをとる必要がある。この例において、ＣＨＡＳＭ２０８Ｄがインタフェースを引き継いでいるので、スマートオーディオデバイス２００Ｄは、そのプロパティ２０７Ｄを通知するか、または、プロパティをＣＨＡＳＭ２０８Ｄに対して利用可能にする必要があるだけであり、ＳＰＡＳＭは、必要でなくなる。これにより、ＣＨＡＳＭ２０８Ｄは、アプリに対してオーディオセッションなどの体験をオーケストレートするための主コントローラとされる。
図２Ｄにおいて、標識された要素は、以下の通りである。
●２００Ｄ．ローカルアプリ２０６を実装するスマートオーディオデバイス。ＣＨＡＳＭ２０８Ｂは、ローカルアプリ（２０６）およびリモートアプリ（２０５Ｂ）を動作させる。
●２０２～２０４．図２Ａを参照。
●２０５Ｂ．スマートオーディオデバイス２００Ｄからリモートで（換言すると、スマートオーディオデバイス２００Ｄとは別のデバイス上で）動作するアプリケーション（かつ、この例において、ＣＨＡＳＭ２０８Ｄからもリモートで動作する）。いくつかの例において、アプリケーション２０５Ｂは、ＣＨＡＳＭ２０８Ｄが、例えば、インターネットまたはローカルなネットワークを介して通信するように構成されたデバイスによって実行され得る。いくつかの例において、アプリケーション２０５Ｂは、別のスマートオーディオデバイスなどのオーディオ環境の別のデバイスに格納され得る。いくつかの実装例によると、アプリケーション２０５Ｂは、携帯電話などの、オーディオ環境内へまたはその外へ移動され得る移動型デバイス上に格納され得る。
●２０６．スマートオーディオデバイス２００Ｄ上でローカルに動作するアプリ。しかし、それに対して、制御情報（２２３）は、ＣＨＡＳＭ２０８Ｄへおよび／またはそれから送信される。
●２０７Ｄ．プロパティディスクリプタ。ＣＨＡＳＭ２０８Ｄがメディアエンジン２０２の管理を担当している状態で、スマートオーディオデバイス２００Ｄは、簡単なプロパティディスクリプタの代わりにＳＰＡＳＭを代用できる。この例において、ディスクリプタ２０７Ｄは、入力および出力の数、可能なサンプルレート、および信号処理コンポーネントなどのメディアエンジン２０２の能力をＣＨＡＳＭに示す。いくつかの例において、ディスクリプタ２０７Ｄは、例えば、１つ以上のラウドスピーカのタイプ、サイズおよび
数を示すデータ、１つ以上のラウドスピーカの能力に対応するデータ、オーディオデータが１つ以上のラウドスピーカによって再生される前にメディアエンジン２０２がオーディオデータに適用することになるダイナミックス処理に関するデータなどの、スマートオーディオデバイス２００Ｄの１つ以上のラウドスピーカに対応するデータを示し得る。いくつかの例において、ディスクリプタ２０７Ｄは、メディアエンジン２０２（または、より一般には、スマートオーディオデバイス２００Ｄの制御システム）が、スマートオーディオデバイス２００Ｄおよび／またはオーディオ環境の他のオーディオデバイスによって再生されるべきオーディオデータをレンダリングすることなどの、環境内のオーディオデバイスのコーディネーションに関する機能を提供するように構成されているかどうか、ＣＨＡＳＭ２０８Ｄの機能を現在提供している（例えば、デバイスのメモリ内に格納されたＣＨＡＳＭソフトウェアにしたがって）デバイスがオフにされたか、またはそうでなければ、機能を停止した場合に、スマートオーディオデバイス２００Ｄの制御システムがＣＨＡＳＭ２０８Ｄの機能を実装できるかどうか、などを示し得る。
●２０８Ｄ．この例において、ＣＨＡＳＭ２０８Ｄは、すべてのアプリ（ローカルまたはリモートにかかわらず）がメディアエンジン２０２とインタラクションするためのゲートウェイとして機能する。ローカルアプリ（例えば、アプリ２０６）でさえもＣＨＡＳＭ２０８Ｄを介してローカルなメディアエンジン２０２へのアクセスを取得する。いくつかの場合において、ＣＨＡＳＭ２０８Ｄは、オーディオ環境の単一のデバイス内にのみ、例えば、ワイヤレスルータ、スマートスピーカなどに格納されたＣＨＡＳＭソフトウェアを介して、実装され得る。しかし、いくつかの実装例において、オーディオ環境の複数のデバイスがＣＨＡＳＭ機能の少なくともいくつかの態様を実装するように構成され得る。いくつかの例において、オーディオ環境の１つ以上のスマートオーディオデバイスなどの、オーディオ環境内の１つ以上の他のデバイスの制御システムは、ＣＨＡＳＭ２０８Ｄの機能を現在提供しているデバイスがオフにされたか、またはそうでなければ、機能を停止した場合に、ＣＨＡＳＭ２０８Ｄの機能を実装することが可能であり得る。
●２１０～２１１．図２Ｃを参照。
●２２１．ＣＨＡＳＭ２０８Ｄとメディアエンジン２０２との間で（例えば、それらへおよびそれらから）送信される制御情報。
●２２２．メディアエンジン２０２の能力を示すために、プロパティディスクリプタ２０７ＤからＣＨＡＳＭに送信されるデータ。
●２２３．ローカルアプリ２０６とＣＨＡＳＭ２０８との間で送信される制御情報。
●２２４．リモートアプリ２０５ＢとＣＨＡＳＭ２０８Ｄとの間で送信される制御情報。
次に、さらなる実施形態を説明する。いくつかのそのような実施形態を実装するために、まず、特定の目的のために単一のデバイス（通信デバイスなど）が設計およびコーディングされる。そのようなデバイスの例は、図１Ｃのスマートオーディオデバイス１０１である。スマートオーディオデバイス１０１は、図３Ｃに図示するように実装され得る。背景として、図１Ａおよび図１Ｂのデバイス１０１の実装例も説明する。
図３Ａは、一例に係る図１Ａのデバイス１０１の詳細を図示するブロック図である。ユーザのボイス１０３は、マイクロフォン３０３によってキャプチャされ、ローカルアプリ３０８Ａは、デバイス１０１のネットワークインタフェースを介して受信されたネットワークストリーム３１７を管理し、メディアストリーム３４１を管理し、および制御信号３
４０をメディアエンジン３０１Ａに与える役割を有する。
図３Ａにおいて、標識された要素は、以下の通りである。
１０１、１０３～１０４．図１Ａを参照。
３０１Ａ．アプリ３０８Ａから入力されるリアルタイムのオーディオメディアストリームを管理する役割を有するメディアエンジン。
３０３．マイクロフォン。
３０４．ラウドスピーカ。
３０８Ａ．ローカルアプリ。
３１７．ネットワークへおよびそれからのメディアストリーム。
３４０．アプリ３０８Ａおよびメディアエンジン３０１Ａへおよびそれらから送信される制御情報。
３４１．アプリ３０８Ａへおよびそれから送信されるメディアストリーム。
図３Ｂは、一例に係る図１Ｂの実施例の詳細を図示する。この例において、図１Ｂのデバイス１０５および図１Ｂのデバイス１０１の実装例を示す。この場合、両方のデバイスは、ＳＰＡＳＭの抽象化を介して制御される汎用のまたはフレキシブルなメディアエンジンが存在するという意味において、「オーケストレーション対応」となることを目的として設計される。
図３Ｂにおいて、第２のデバイス１０５の出力１０６は、第１のデバイス１０１の出力１０４に関係せず、デバイス１０１のマイクロフォン３０３への入力１０３は、デバイス１０５の出力１０６をキャプチャする可能性があり得る。この例において、デバイス１０５および１０１はオーケストレートされた様態では機能し得ない。
図３Ｂにおいて、標識された要素は、以下の通りである。
１０１、１０３～１０６．図１Ｂを参照。
３０１、３０３～３０４．図３Ａを参照。
３０２．デバイス１０５のメディアエンジン。
３０５．デバイス１０５のマイクロフォン。
３０６．デバイス１０５のラウドスピーカ。
３０８Ｂ．デバイス１０１のローカルアプリ。
３１２Ｂ．デバイス１０１のためのＳＰＡＳＭ。
３１４Ｂ．デバイス１０５のためのＳＰＡＳＭ。
３１７．ネットワークへおよびそれからのメディアストリーム。
３２０．デバイス１０５のためのローカルアプリ。
３２１．アプリ３０８ＢとＳＰＡＳＭ３１２Ｂとの間で送信される制御情報。
３２２．ＳＰＡＳＭ３１２Ｂとメディアエンジン３０１との間で送信される制御情報。
３２３．アプリ３２０とＳＰＡＳＭ３１４Ｂとの間で（それらへおよびそれらから）送信される制御情報。
３２４．ＳＰＡＳＭ３１４Ｂとメディアエンジン３０２との間で（それらへおよびそれらから）送信される制御情報。
３２５．ネットワークからメディアエンジン３０２内へのメディアストリーム。
図３Ｃは、オーディオ環境の２つのオーディオデバイスをオーケストレートするＣＨＡＳＭの例を図示するブロック図である。上記検討に基づき、ＣＨＡＳＭがデバイス１０１およびデバイス１０５の変形例上で、または、別のデバイス上で動作する状態で、図３Ｂのシステムが使用される状況がＣＨＡＳＭによってより良く管理されるであろう（例えば、図３Ｃの実施形態と同様に）ことが理解されるべきである。ＣＨＡＳＭ３０７を使用す
ると、いくつかの例において、電話１０１上のアプリケーション３０８は、そのオーディオデバイス１０１を直接制御することを停止し、すべてのオーディオの制御をＣＨＡＳＭ３０７に委ねる。いくつかのそのような例によると、マイクロフォン３０５からの信号は、マイクロフォン３０３からの信号よりも小さいエコーを含み得る。ＣＨＡＳＭ３０７は、いくつかの例において、マイクロフォン３０５からの信号がマイクロフォン３０３からの信号よりも小さいエコーを含むことを、マイクロフォン３０５の方が人物１０２により近いとの推定に基づいて、推論し得る。いくつかのそのような例において、ＣＨＡＳＭは、デバイス１０５上のマイクロフォン３０５からの生のマイクロフォン信号または処理されたマイクロフォン信号をネットワークストリームとして電話デバイス１０１にルーティングすることを活用し得る。これらのマイクロフォン信号は、人物１０２に対してより良いボイス通信体験を達成するために、ローカルなマイクロフォン３０３からの信号よりも優先して使用され得る。
いくつかの実装例によると、ＣＨＡＳＭ３０７は、例えば、人物１０２の位置をモニタリングすること、デバイス１０１および／またはデバイス１０５の位置をモニタリングすることなどによって、これが最良の構成であり続けることを確実にすることができる。いくつかの例において、ＣＨＡＳＭ３０７は、これが最良の構成であり続けることを確実にすることができる。いくつかのそのような例によると、ＣＨＡＳＭ３０７は、低レート（例えば、低ビットレート）データおよび／またはメタデータのやりとりを介して、これが最良の構成であり続けることを確実にすることができる。ほんの少量の情報がデバイス間で共有された状態において、例えば、人物１０２の位置を追跡できる。情報がデバイス間において低ビットレートでやりとりされている場合、限定された帯域を考慮することは、あまり問題とならないかもしれない。デバイス間でやりとりされ得る低ビットレート情報の例は、例えば、「フォローミー（follow me）」実装例を参照して記載される、マイク
ロフォン信号から得られる情報を含むが、それに限定されない。どのデバイスのマイクロフォンがより高い音声対エコー比を有するかを決定することを決定することに有用であり得る低ビットレート情報の一例は、ある期間中に、例えば、最後の１秒の間に、オーディオ環境内の複数のオーディオデバイスのそれぞれ上のローカルなラウドスピーカによって出射された音によって引き起こされたＳＰＬの推定値である。ラウドスピーカ（単数または複数）からより大きなエネルギーを放射するオーディオデバイスは、ラウドスピーカ（単数または複数）によって引き起こされたエコーを超えるオーディオ環境内の他の音のうちのより少量しかキャプチャしない可能性がある。どのデバイスのマイクロフォンがより高い音声対エコー比を有するかを決定することを決定するのに有用であり得る低ビットレート情報の他の例は、各デバイスの音響エコーキャンセラのエコー予測におけるエネルギー量である。高い量の予測エコーエネルギーは、オーディオデバイスのマイクロフォン（単数または複数）がエコーによって圧倒されている可能性を示す。いくつかのそのような例において、音響エコーキャンセラがキャンセルできないであろういくつかのエコーが存在し得る（このとき、音響エコーキャンセラが既に収束していると仮定する）。いくつかの例において、ＣＨＡＳＭ３０７は、マイクロフォン３０５に問題があること、または、マイクロフォン３０５が存在しないことの情報が何かによって提供された場合にデバイス１０１を制御してローカルなマイクロフォン３０３からのマイクロフォン信号を使用して再開するように、継続して準備し得る。
図３Ｃは、デバイス１０１上で動作するアプリ３０８をデバイス１０５に対してコーディネートするために使用される基礎のシステムの例を図示する。この例において、ＣＨＡＳＭ３０７は、ユーザのボイス１０３Ｂがデバイス１０５のマイクロフォン３０５内にキャプチャされるようにし、キャプチャされたオーディオ３１６がデバイス１０１のメディアエンジン３０１において使用されるようにし、他方、ラウドスピーカ出力１０４が第１のデバイス１０１から来る。これにより、デバイス１０１および１０５にわたり、ユーザ１０２に対して体験がオーケストレートされる。
図３Ｃにおいて、標識された要素は、以下の通りである。
１０１、１０３Ｂ、１０４、１０５．図１Ｃを参照。
３０１～３０６．図３Ｂを参照。
３０７．ＣＨＡＳＭ。
３０９．ＣＨＡＳＭ３０７とメディアエンジン３０２との間の制御情報。
３１０．ＣＨＡＳＭ３０７とメディアエンジン３０１と間の制御情報。
３１１．ＣＨＡＳＭ３０７とアプリ３０８との間（それらへおよびそれらから）の制御情報。
３１２Ｃ．デバイス１０１のデバイスプロパティディスクリプタ。
３１３．デバイスプロパティディスクリプタ３１２ＣからＣＨＡＳＭ３０７への制御情報および／またはデータ。
３１４Ｃ．デバイス１０５のデバイスプロパティディスクリプタ。
３１５．デバイスプロパティディスクリプタ３１４ＣからＣＨＡＳＭ３０７への制御情報および／またはデータ。
３１６．デバイスメディアエンジン３０２からデバイスメディアエンジン３０１へのメディアストリーム。
３１７．ネットワークへおよびネットワークからメディアエンジン３０１へのメディアストリーム。
いくつかの実施形態において、スマートオーディオデバイスとインタラクションするために（例えば、各スマートオーディオデバイスのそれぞれへおよびそれから制御情報を送信および受信するために）ＤＯＯＤＡＤがＣＨＡＳＭ（例えば、ＣＨＡＳＭ３０７）に含まれる場合、および／または、ＣＨＡＳＭ（例えば、後述の図４のＣＨＡＳＭ４０１、またはＣＨＡＳＭ３０７）と動作するためにＤＯＯＤＡＤが提供される場合（例えば、例えば、デバイス１０１および１０５などのデバイスのサブシステムとして、ここで、これらのデバイスは、例えば、ＣＨＡＳＭ３０７を実装するデバイスなどのＣＨＡＳＭを実装するデバイスとは別である）、ＳＰＡＳＭを必要とすること（１つ以上のスマートオーディオデバイスのそれぞれにおいて）は、オーディオ能力を通知する（ＣＨＡＳＭへ）スマートオーディオデバイスの動作、およびオーディオ機能について単一の抽象的な制御ポイント（例えば、ＣＨＡＳＭ）に委ねるアプリケーションによって置き換えられる。
図４は、他の開示された実施形態を例示するブロック図である。図４の設計は、重要な抽象化を導入する。重要な抽象化とは、いくつかの実装例において、アプリケーションは、直接に選択または制御する必要がなく、およびいくつかの場合において、アプリケーションは、どの特定のオーディオデバイスがアプリケーションに関する機能を行うことに関与するか、そのようなオーディオデバイスの特定の能力などに関する情報が与えられなくてもよいことである。
図４は、３つの別個の物理的なオーディオデバイス４２０、４２１、および４２２を含むシステムのブロック図である。この例において、各デバイスは、発見可能な日和見的にオーケストレートされた分散型オーディオサブシステム（ＤＯＯＤＡＤ）を実装し、アプリケーション（４１０～４１２）を動作させているＣＨＡＳＭ４０１によって制御される。この例によると、ＣＨＡＳＭ４０１は、アプリケーション４１０～４１２のそれぞれに対するメディア要求を管理するように構成される。
図４において、標識された要素は、以下の通りである：
４００．３つの異なるデバイスにわたってオーケストレートされたオーディオシステムの例。デバイス４２０、４２１および４２２はそれぞれ、ＤＯＯＤＡＤ（ＤＵＤＡＤ）を実装する。ＤＯＯＤＡＤを実装するデバイス４２０、４２１および４２２のそれぞれは
、それ自体がＤＯＯＤＡＤと呼ばれることもある。この例において、各ＤＯＯＤＡＤは、図４におけるＤＯＯＤＡＤであるか、または、それを実装するデバイスそれ自体が関連のアプリケーションを実装しないが、デバイス１０１がアプリケーション３０８を実装する点で、図３Ｃのスマートオーディオデバイス１０１と異なるスマートオーディオデバイスである（または、それによって実装される）、
４０１．ＣＨＡＳＭ、
４１０～４１２．この例において、異なるオーディオ要求を有するアプリ。いくつかの例において、アプリ４１０～４１２のそれぞれは、オーディオ環境のデバイス、または、オーディオ環境に配置されることのある移動型デバイス上に格納され得るか、あるいは、それによって実行可能であり得る、
４２０～４２２．発見可能な日和見的にオーケストレートされた分散型オーディオサブシステム（ＤＯＯＤＡＤ）を実装し、各ＤＯＯＤＡＤが別個の物理的なスマートオーディオデバイス内で動作するスマートオーディオデバイス、
４３０、４３１および４３２．アプリ４１０、４１１、および４１２間（それらへおよびそれらから）で、および、ＣＨＡＳＭ４０１に送信される制御情報、
４３３、４３４および４３５．ＤＯＯＤＡＤ４２０～４２２およびＣＨＡＳＭ４０１へおよびそれらから送信される制御情報、
４４０、４４１および４４２．メディアエンジン、
４５０、４５１および４５２．デバイスプロパティディスクリプタ。この例において、ＤＯＯＤＡＤ４２０～４２２がこれらのデバイスプロパティディスクリプタをＣＨＡＳＭ４０１に与えるように構成される、
４６０～４６２．ラウドスピーカ、
４６３～４６５．マイクロフォン、
４７０．メディアエンジン４４２を出てネットワークへ向かうメディアストリーム、
４７１．メディアエンジン４４１からメディアエンジン４４２へのメディアストリーム、
４７２．メディアエンジン４４１からメディアエンジン（４４０）へのメディアストリーム、
４７３．データセンターの１つ以上のサーバによってインターネットを介してメディアエンジン４４１に提供されるクラウドベースサービスなどの、ネットワークを介してメディアを提供するためのクラウドベースサービスからのメディアストリーム、
４７４．メディアエンジン４４１からクラウドベースサービスへのメディアストリーム、
４７７．１つ以上の音楽ストリーミングサービス、映画ストリーミングサービス、テレビショーストリーミングサービス、ポッドキャストプロバイダなどを含み得る１つ以上のクラウドベースサービス。
図４は、複数のオーディオデバイスがオーディオ体験を作成するためにルーティングを行う可能性のあるシステムのブロック図である。この例によると、メディアストリーム４７１をメディアエンジン４４２に提供しており、かつ、メディアストリーム４７２をメディアエンジン４４０に提供しているスマートオーディオデバイス４２１のメディアエンジン４４１によって、メディアストリーム４７３に対応するオーディオデータが受信されている。いくつかのそのような実装例によると、メディアエンジン４４１は、メディアエンジン４４１のサンプルクロックにしたがってメディアストリーム４７３を処理し得る。そのサンプルクロックは、本明細書において「メディアエンジンサンプルクロック」と呼ばれ得るものの例である。
いくつかのそのような例において、ＣＨＡＳＭ４０１は、メディアストリーム４７３の取得および処理に関する処理について、制御情報４３４を介して、命令および情報をメディアエンジン４４１に与えていてもよい。そのような命令および情報は、本明細書におい
て「オーディオセッションマネジメント制御信号」と呼ばれ得るものの例である。
しかし、いくつかの実装例において、ＣＨＡＳＭ４０１は、メディアエンジン４４１のメディアエンジンサンプルクロックを参照せずに、オーディオセッションマネジメント制御信号を送信し得る。そのような例は、例えばＣＨＡＳＭ４０１がメディアのオーディオ環境のオーディオデバイスへの送信を同期させる必要がないので、有利である可能性がある。その代わりに、いくつかの実装例において、そのような同期化はいずれも、上記の例におけるスマートオーディオデバイス４２１などの別のデバイスに代理され得る。
いくつかのそのような実装例によると、ＣＨＡＳＭ４０１は、アプリケーション４１０、アプリケーション４１１またはアプリケーション４１２からの制御情報４３０、４３１または４３２に応答してメディアストリーム４７３を取得および処理することに関するオーディオセッションマネジメント制御信号をメディアエンジン４４１に与えていてもよい。そのような制御情報は、本明細書において「アプリケーション制御信号」と呼ばれ得るものの例である。いくつかの実装例によると、アプリケーション制御信号は、メディアエンジン４４１のメディアエンジンサンプルクロックを参照せずに、アプリケーションからＣＨＡＳＭ４０１に送信し得る。
いくつかの例において、ＣＨＡＳＭ４０１は、オーディオ処理情報を、それにしたがい処理メディアストリーム４７３に対応するオーディオを処理するための命令とともに、メディアエンジン４４１に与え得る。オーディオ処理情報は、レンダリング情報を含むが、それに限定されない。しかし、いくつかの実装例において、ＣＨＡＳＭ４０１を実装するデバイス（または、本明細書の別の箇所に記載したスマートホームハブの機能などの類似の機能を実装するデバイス）は、少なくともあるオーディオ処理機能を提供するように構成され得る。いくつかの例を以下に与える。いくつかのそのような実装例において、ＣＨＡＳＭ４０１は、オーディオデータを受信および処理し、処理された（例えば、レンダリングされた）オーディオデータをオーディオ環境のオーディオデバイスに与えるように構成され得る。
図５は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。方法５００のブロックは、本明細書に記載の他の方法と同様に、必ずしも記載の順序で行われない。ある実装例において、方法５００のブロックの１つ以上は、同時に行われ得る。例えば、いくつかの場合において、ブロック５０５および５１０は、同時に行われ得る。さらに、方法５００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法５００のブロックは、１つ以上のデバイスによって行われ得る。そのようなデバイスは、図６に図示の後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）。
いくつかの実装例によると、方法５００のブロックは、例えばＣＨＡＳＭなどの本明細書においてオーディオセッションマネージャと呼ばれるものを実装するデバイスによって、少なくとも部分的に、行われ得る。いくつかのそのような例において、方法５００のブロックは、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１によって、少なくとも部分的に、行われ得る。より詳細には、いくつかの実装例において、方法５００のブロックにおいて呼ばれる「オーディオセッションマネージャ」の機能は、ＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１によって、少なくとも部分的に、行われ得る。
この例によると、ブロック５０５は、第１のアプリケーションを実行する第１のアプリ
ケーションデバイスと、オーディオ環境のオーディオセッションマネージャとの間に第１のアプリケーション通信リンクを確立することを含む。いくつかの例において、第１のアプリケーション通信リンクは、オーディオ環境内での使用に適切な任意の適切なワイヤレス通信プロトコルを介して生成され得る。そのようなワイヤレス通信プロトコルは、Ｚｉｇｂｅｅ、ＡｐｐｌｅのＢｏｎｊｏｕｒ（Ｒｅｎｄｅｚｖｏｕｓ）、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（Ｂｌｕｅｔｏｏｔｈ ＬＥ）、５Ｇ、４Ｇ、３Ｇ、Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ（ＧＰＲＳ）、Ａｍａｚｏｎ Ｓｉｄｅｗａｌｋ、ＮｏｒｄｉｃのＲＦ２４Ｌ０１チップ内のカスタムプロトコルなどである。いくつかの例において、第１のアプリケーション通信リンクは、「ハンドシェイク」処理に応答して確立され得る。「ハンドシェイク」処理は、いくつかの例において、第１のアプリケーションデバイスによってオーディオセッションマネージャを実装しているデバイスに送信された「ハンドシェイク開始」を介して開始され得る。いくつかの例において、第１のアプリケーション通信リンクは、第１のアプリケーションデバイスからの本明細書において「ルート開始リクエスト」と呼ばれ得るものに応答して確立され得る。便宜的に、第１のアプリケーションデバイスからのルート開始リクエストは、ルート開始リクエストが「第１のアプリケーションデバイス」に対応することを示すために、本明細書において「第１のルート開始リクエスト」と呼ばれ得る。換言すると、「第１の」という用語は、特定の実装例に応じて、この文脈において時間的な意味を有してもよいし、有さなくてもよい。
１つのそのような例において、第１のアプリケーション通信リンクは、図４のアプリケーション４１０が実行されているデバイスとＣＨＡＳＭ４０１との間に確立され得る。いくつかのそのような例において、第１のアプリケーション通信リンクは、アプリケーション４１０が実行されているデバイスから第１のルート開始リクエストをＣＨＡＳＭ４０１が受信したことに応答して確立され得る。アプリケーション４１０が実行されているデバイスは、例えば、スマートオーディオ環境のオーディオデバイスであり得る。いくつかの場合において、アプリケーション４１０が実行されているデバイスは、携帯電話であり得る。アプリケーション４１０は、ＣＨＡＳＭ４０１を介して、例えば音楽、テレビ番組、映画などのメディアにアクセスするために使用され得る。いくつかの場合において、メディアは、クラウドベースサービスを介したストリーミングに利用可能である。
「ルート」によって意味されるものの様々な例を以下に詳細に説明する。一般に、ルートは、オーディオセッションマネージャによって管理されることになるオーディオセッションのパラメータを示す。ルート開始リクエストは、例えば、オーディオソースおよびオーディオ環境デスティネーションを示し得る。オーディオ環境デスティネーションは、いくつかの場合において、オーディオ環境内の少なくとも１人の人物に対応し得る。いくつかの場合において、オーディオ環境デスティネーションは、オーディオ環境のエリアまたはゾーンに対応し得る。
しかし、ほとんどの場合において、オーディオ環境デスティネーションは、オーディオ環境においてメディアを再生することに関与することになるいずれの特定のオーディオデバイスも示すことにならない。その代わりに、アプリケーション（アプリケーション４１０など）は、例えば、特定のタイプのメディアがオーディオ環境内の特定の人物に対して利用可能とされるべきであるとするルート開始リクエストを与え得る。様々な開示の実装例において、オーディオセッションマネージャは、例えば、どのオーディオデバイスがメディアに関連するオーディオデータを取得、レンダリングおよび再生することに関与することになるかを決定することなど、どのオーディオデバイスがルートに関与することになるかを決定する役割を有することになる。いくつかの実装例において、オーディオセッションマネージャは、ルートに関与することになるオーディオデバイスが変化したか（例えば、意図されるメディアの受信側である人物が位置を変更したとの決定に応じて）を決定
し、対応するデータ構造を更新することなどの役割を有することになる。詳細な例を以下に説明する。
この例において、ブロック５１０は、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することを含む。図４を再度参照する。いくつかの例において、アプリケーション制御信号は、アプリ４１０とＣＨＡＳＭ４０１との間で（それらへおよびそれらから）送信される制御情報４３０に対応し得る。いくつかの例において、第１のアプリケーション制御信号は、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ４０１）がルートを開始した後に送信され得る。しかし、いくつかの場合において、第１のアプリケーション制御信号は、第１のルート開始リクエストに対応し得る。いくつかのそのような例において、ブロック５０５および５１０は、少なくとも部分的に、同時に行われ得る。
この例によると、ブロック５１５は、オーディオセッションマネージャと、スマートオーディオ環境の少なくとも第１のオーディオデバイスとの間に第１のスマートオーディオデバイス通信リンクを確立することを含む。この例において、第１のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれであってもよく、または、それらのいずれを含んでもよい。この実装例によると、第１のスマートオーディオデバイスは、１つ以上のラウドスピーカを含む。
いくつかの例において、上述したように、第１のアプリケーション制御信号および／または第１のルート開始リクエストは、ルートに関与することになるいずれの特定のオーディオデバイスも示さない。いくつかのそのような例によると、方法５００は、オーディオ環境のどのオーディオデバイスが少なくとも最初にルートに関与することになるかを決定する（例えば、オーディオセッションマネージャによって）ブロック５１５より前に処理を含み得る。
例えば、図４のＣＨＡＳＭ４０１は、オーディオデバイス４２０、４２１および４２２が少なくとも最初にルートに関与することになると決定し得る。図４に図示の例において、ブロック５１５の第１のスマートオーディオデバイス通信リンクは、オーディオセッションマネージャ（この例において、ＣＨＡＳＭ４０１）スマートオーディオデバイス４２１の間に確立され得る。第１のスマートオーディオデバイス通信リンクは、ＣＨＡＳＭ４０１とスマートオーディオデバイス４２１との間に示された図４の破線に対応し得る。第１のスマートオーディオデバイス通信リンクを介して制御情報４３４が送信される。いくつかのそのような例において、第１のスマートオーディオデバイス通信リンクは、オーディオ環境内での使用に適切な任意の適切なワイヤレス通信プロトコルを介して生成され得る。そのようなワイヤレス通信プロトコルは、Ａｐｐｌｅ Ａｉｒｐｌａｙ、Ｍｉｒａｃａｓｔ、Ｂｌａｃｋｆｉｒｅ、Ｂｌｕｅｔｏｏｔｈ ５、リアルタイムトランスポートプロトコル（ＲＴＰ）などである。
図５に示される例において、ブロック５２０は、オーディオセッションマネージャによって、第１のスマートオーディオデバイスの第１のメディアエンジンの１つ以上の第１のメディアエンジン能力を決定することを含む。この例によると、第１のメディアエンジンは、第１のスマートオーディオデバイスによって受信された１つ以上のオーディオメディアストリームを管理し、第１のメディアエンジンサンプルクロックにしたがって１つ以上のオーディオメディアストリームに対して第１のスマートオーディオデバイス信号処理を行うように構成される。上記の例において、ブロック５２０は、例えば、デバイスプロパティディスクリプタ４５１をＣＨＡＳＭ４０１に与えることによって、ＣＨＡＳＭ４０１がメディアエンジン４４１の１つ以上の能力に関する情報をスマートオーディオデバイス
４２１から受信することを含み得る。いくつかの実装例によると、ブロック５２０は、ＣＨＡＳＭ４０１がスマートオーディオデバイス４２１の１つ以上のラウドスピーカの能力に関する情報を受信することを含み得る。いくつかの例において、ＣＨＡＳＭ４０１は、例えば、方法５００のブロック５０５、５１０および／または５１５より前に、予めこの情報の一部または全部を決定しておいてもよい。
この例によると、ブロック５２５は、オーディオセッションマネージャによって、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介して、第１のメディアエンジン能力にしたがって第１のスマートオーディオデバイスを制御することを含む。いくつかの例によると、第１のオーディオセッションマネジメント制御信号は、第１のスマートオーディオデバイスに、第１のメディアエンジンの制御をオーディオセッションマネージャに代理させ得る。この例において、オーディオセッションマネージャは、第１のメディアエンジンサンプルクロックを参照せずに、第１のオーディオセッションマネジメント制御信号を第１のスマートオーディオデバイスに送信する。いくつかのそのような例において、第１のアプリケーション制御信号は、第１のメディアエンジンサンプルクロックを参照せずに、第１のアプリケーションからオーディオセッションマネージャに送信され得る。
ブロック５２５の一例において、ＣＨＡＳＭ４０１は、メディアストリーム４７３を受信するようにメディアエンジン４４１を制御し得る。いくつかのそのような例において、第１のオーディオセッションマネジメント制御信号を介して、ＣＨＡＳＭ４０１は、メディアエンジン４４１に、メディアストリーム４７３が受信され得るウェブサイトに対応するUniversal Resource Locator（ＵＲＬ）を、メディアストリーム４７３を開始する命令とともに与え得る。いくつかのそのような例によると、ＣＨＡＳＭ４０１はまた、第１のオーディオセッションマネジメント制御信号を介して、メディアエンジン４４１に、メディアストリーム４７１をメディアエンジン４４２に与え、メディアストリーム４７２をメディアエンジン４４０に与える命令を与えていてもよい。
いくつかのそのような例において、ＣＨＡＳＭ４０１は、メディアエンジン４４１に、第１のオーディオセッションマネジメント制御信号を介して、オーディオ処理情報（レンダリング情報を含むが、それに限定されない）を、それにしたがってメディアストリーム４７３に対応するオーディオを処理する命令とともに与えていてもよい。例えば、ＣＨＡＳＭ４０１は、メディアエンジン４４１に、例えば、スマートオーディオデバイス４２０が左のチャネルに対応するスピーカフィード信号を受信することになること、スマートオーディオデバイス４２１がセンターチャネルに対応するスピーカフィード信号を再生することになること、および、スマートオーディオデバイス４２２が右のチャネルに対応するスピーカフィード信号を受信することになることの指示を与えていてもよい。
レンダリングの様々な他の例を本明細書において開示する。そのうちのいくつかは、異なるタイプのオーディオ処理情報をスマートオーディオデバイスに伝えるＣＨＡＳＭ４０１または別のオーディオセッションマネージャであり得る。例えば、いくつかの実装例において、オーディオ環境の１つ以上のデバイスは、Center of Mass Amplitude Panning（ＣＭＡＰ）および／またはFlexible Virtualization（ＦＶ）などのフレキシブルレンダ
リングを実装するように構成され得る。いくつかのそのような実装例において、フレキシブルレンダリングを実装するように構成されたデバイスは、１セットのオーディオデバイスの位置、推定された現在の聴取者の位置、および推定された現在の聴取者の向きが与えられ得る。フレキシブルレンダリングを実装するように構成されたデバイスは、環境内の１セットのオーディオデバイスに対して、その１セットのオーディオデバイスの位置、推定された現在の聴取者の位置、および推定された現在の聴取者の向きにしたがって、オー
ディオをレンダリングするように構成され得る。いくつかの詳細な例を以下に説明する。
図４を参照して説明した方法５００の上記の例において、オーディオセッションマネージャ以外のデバイスまたは第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成される。しかし、例えば、図２Ｃおよび２Ｄを参照して上述したように、いくつかの例において、第１のスマートオーディオデバイスは、第１のアプリケーションを実行するように構成され得る。
いくつかのそのような例によると、例えば、図２Ｃを参照して上述したように、第１のスマートオーディオデバイスは、特定の目的のオーディオセッションマネージャを含み得る。いくつかのそのような実装例において、オーディオセッションマネージャは、特定の目的のオーディオセッションマネージャと、第１のスマートオーディオデバイス通信リンクを介して通信し得る。いくつかの例において、オーディオセッションマネージャは、１つ以上の第１のメディアエンジン能力を特定の目的のオーディオセッションマネージャから取得し得る。いくつかのそのような例によると、オーディオセッションマネージャは、第１のメディアエンジンを制御するすべてのアプリケーションのためのゲートウェイとして機能し得るが、これは、アプリケーションが第１のスマートオーディオデバイス上で動作するか、または、他のデバイス上で動作するかにかかわらない。
上述したように、いくつかの例において、方法５００は、少なくとも、第１のオーディオソースに対応する第１のオーディオストリーム（例えば、図４のメディアストリーム４７３）を確立することを含み得る。いくつかの例において、第１のオーディオソースは、音楽ストリーミングサービス、テレビショーおよび／または映画ストリーミングサービスなどのクラウドベースのメディアストリーミングサービスを提供するように構成された１つ以上のサーバなどであり得る。第１のオーディオストリームは、第１のオーディオ信号を含み得る。いくつかのそのような実装例において、少なくとも第１のオーディオストリームを確立することは、第１のスマートオーディオデバイス通信リンクを介して第１のスマートオーディオデバイスに送信された第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、少なくとも第１のオーディオストリームを確立させることを含み得る。
いくつかの例において、方法５００は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにするレンダリング処理を含み得る。いくつかのそのような実装例において、レンダリング処理は、第１のオーディオセッションマネジメント制御信号に応答して、第１のスマートオーディオデバイスによって行われ得る。上記の例において、メディアエンジン４４１は、第１のオーディオセッションマネジメント制御信号に応答して、メディアストリーム４７３に対応するオーディオ信号をスピーカフィード信号にレンダリングし得る。
いくつかの例によると、方法５００は、第１のオーディオセッションマネジメント制御信号を介して、第１のスマートオーディオデバイスに、第１のスマートオーディオデバイスと、オーディオ環境の１つ以上の他のスマートオーディオデバイスのそれぞれとの間にスマートオーディオデバイス間通信リンクを確立させることを含み得る。図４を参照して上述した例において、メディアエンジン４４１は、メディアエンジン４４０および４４２との有線または無線スマートオーディオデバイス間通信リンクを確立し得る。図３Ｃを参照して上述した例において、メディアエンジン３０２は、メディアストリーム３１６をメディアエンジン３０１に与えるために、有線または無線スマートオーディオデバイス間通信リンクを確立し得る。
いくつかの例において、方法５００は、第１のスマートオーディオデバイスに、１つ以
上の生のマイクロフォン信号、処理されたマイクロフォン信号、レンダリングされたオーディオ信号またはレンダリングされていないオーディオ信号を１つ以上の他のスマートオーディオデバイスにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。図４を参照して上述した例において、スマートオーディオデバイス間通信リンクを使用して、レンダリングされたオーディオ信号またはレンダリングされていないオーディオ信号をメディアストリーム４７１およびメディアストリーム４７２を介して与え得る。いくつかのそのような例において、メディアストリーム４７１は、メディアエンジン４４２に対するスピーカフィード信号を含み得、メディアストリーム４７２は、メディアエンジン４４０に対するスピーカフィード信号を含み得る。図３Ｃを参照して上述した例において、メディアストリーム３１６を介して、メディアエンジン３０２は、生のマイクロフォン信号または処理されたマイクロフォン信号をメディアエンジン３０１に与え得る。
いくつかの例によると、方法５００は、オーディオセッションマネージャと、スマートオーディオ環境の少なくとも第２のオーディオデバイスとの間に第２のスマートオーディオデバイス通信リンクを確立することを含み得る。いくつかのそのような例において、第２のスマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスであり得る。いくつかの場合において、第２のスマートオーディオデバイスは、１つ以上のマイクロフォンを含み得る。いくつかのそのような方法は、オーディオセッションマネージャによって、第２のスマートオーディオデバイスの第２のメディアエンジンの１つ以上の第２のメディアエンジン能力を決定することを含み得る。第２のメディアエンジンは、例えば、マイクロフォンデータを１つ以上のマイクロフォンから受信し、マイクロフォンデータに対して第２のスマートオーディオデバイス信号処理を行うように構成され得る。
例えば、図３Ｃを参照すると、「第１のスマートオーディオデバイス」は、スマートオーディオデバイス１０１であり得る。いくつかのそのような例によると、「第２のスマートオーディオデバイス」は、スマートオーディオデバイス１０５であり得る。「第１のスマートオーディオデバイス通信リンク」を使用して、制御信号３１０を与え得、かつ、「第２のスマートオーディオデバイス通信リンク」を使用して制御信号３０９を与え得る。ＣＨＡＳＭ３０７は、デバイスプロパティディスクリプタ３１４ｃに少なくとも部分的に基づいて、メディアエンジン３０２の１つ以上のメディアエンジン能力を決定し得る。
いくつかのそのような方法は、第２のメディアエンジン能力にしたがって、オーディオセッションマネージャによって、第２のスマートオーディオデバイス通信リンクを介して第２のスマートオーディオデバイスに送信された第２のオーディオセッションマネージャ制御信号を介して、第２のスマートオーディオデバイスを制御することを含み得る。いくつかの場合において、第２のスマートオーディオデバイスを制御することは、第２のスマートオーディオデバイスに、第２のスマートオーディオデバイスと第１のスマートオーディオデバイスとの間のスマートオーディオデバイス間通信リンク（例えば、メディアストリーム３１６を提供するために使用されるスマートオーディオデバイス間通信リンク）を確立させることを含み得る。いくつかのそのような例は、第２のスマートオーディオデバイスに、処理されたまたは処理されていないマイクロフォンデータ（例えば、マイクロフォン３０５からの処理されたまたは処理されていないマイクロフォンデータ）のうちの少なくとも一方を第２のメディアエンジンから第１のメディアエンジンにスマートオーディオデバイス間通信リンクを介して送信させることを含み得る。
いくつかの例において、第２のスマートオーディオデバイスを制御することは、オーディオセッションマネージャによって、第１のアプリケーション通信リンクを介して、第１のアプリケーション制御信号を第１のアプリケーションから受信することを含み得る。図
３Ｃの例において、ＣＨＡＳＭ３０７は、この場合において電話アプリケーションであるアプリケーション３０８から制御信号３１１を受信する。いくつかのそのような例は、第２のオーディオセッションマネージャ制御信号を第１のアプリケーション制御信号にしたがって決定することを含み得る。例えば、図３Ｃを再度参照すると、ＣＨＡＳＭ３０７は、アプリケーション３０８からの制御信号３１１にしたがって与えられている電話会議に対する音声対エコー比（ＳＥＲ）を最適化するように構成され得る。ＣＨＡＳＭ３０７は、人物１０２の音声をキャプチャするためにマイクロフォン３０３の代わりにマイクロフォン３０５を使用することによってリモート会議に対するＳＥＲを改善できると決定し得る（図１Ｃを参照）。この決定は、いくつかの例において、人物１０２の位置の推定値に基づき得る。オーディオ環境内の人物の位置および／または向きを推定するいくつかの詳細な例を本明細書において開示する。
図６は、本開示の様々な態様を実装することができる装置のコンポーネントの例を図示するブロック図である。本明細書において提供した他の図と同様に、図６に図示された要素のタイプおよび数は、例示として与えられたに過ぎない。他の実装例は、より多くの、より少ないおよび／または異なるタイプおよび数の要素を含み得る。いくつかの例によると、装置６００は、本明細書において開示された方法のうちの少なくともいくつかを行うように構成されたスマートオーディオデバイスであってもよいし、それを含んでもよい。他の実装例において、装置６００は、ラップトップコンピュータ、携帯電話、タブレットデバイス、スマートホームハブなどの、本明細書において開示された方法のうちの少なくともいくつかを行うように構成された別のデバイスであってもよいし、それを含んでもよい。いくつかのそのような実装例において、装置６００は、サーバであってもよいし、それを含んでもよい。いくつかのそのような実装例において、装置６００は、本明細書においてＣＨＡＳＭと呼ばれ得るものを実装するように構成され得る。
この例において、装置６００は、インタフェースシステム６０５と、制御システム６１０とを含む。インタフェースシステム６０５は、いくつかの実装例において、ソフトウェアアプリケーション実行しているか、または、それを実行するように構成された１つ以上のデバイスと通信するように構成され得る。そのようなソフトウェアアプリケーションは、本明細書において「アプリケーション」または単に「アプリ」と呼ばれることもあり得る。インタフェースシステム６０５は、いくつかの実装例において、アプリケーションに関係する制御情報および関連のデータをやりとりするように構成され得る。インタフェースシステム６０５は、いくつかの実装例において、オーディオ環境の１つ以上の他のデバイスと通信するように構成され得る。オーディオ環境は、いくつかの例において、ホームオーディオ環境であり得る。インタフェースシステム６０５は、いくつかの実装例において、制御情報および関連のデータをオーディオ環境のオーディオデバイスとやりとりするように構成され得る。制御情報および関連のデータは、いくつかの例において、装置６００が通信するように構成される１つ以上のアプリケーションに関する。
インタフェースシステム６０５は、いくつかの実装例において、オーディオデータを受信するように構成され得る。オーディオデータは、オーディオ環境の少なくともいくつかのスピーカによって再生されるように予定されたオーディオ信号を含み得る。オーディオデータは、１つ以上のオーディオ信号および対応づけられた空間データを含み得る。空間データは、例えば、チャネルデータおよび／または空間メタデータを含み得る。インタフェースシステム６０５は、レンダリングされたオーディオ信号を環境の１セットのラウドスピーカのうちの少なくともいくつかのラウドスピーカに与えるように構成され得る。インタフェースシステム６０５は、いくつかの実装例において、環境内の１つ以上のマイクロフォンから入力を受信するように構成され得る。
インタフェースシステム６０５は、１つ以上のネットワークインタフェースおよび／ま
たは１つ以上の外部のデバイスインタフェース（１つ以上のユニバーサルシリアルバス（ＵＳＢ）インタフェースなど）を含み得る。いくつかの実装例によると、インタフェースシステム６０５は、１つ以上のワイヤレスインタフェースを含み得る。インタフェースシステム６０５は、１つ以上のマイクロフォン、１つ以上のスピーカ、ディスプレイシステム、タッチセンサシステムおよび／またはジェスチャーセンサシステムなどの、ユーザインタフェースを実装するための１つ以上のデバイスを含み得る。いくつかの例において、インタフェースシステム６０５は、制御システム６１０と、図６に図示されたオプションのメモリシステム６１５などのメモリシステムとの間の１つ以上のインタフェースを含み得る。しかし、制御システム６１０は、いくつかの場合において、メモリシステムを含み得る。
制御システム６１０は、例えば、汎用シングルもしくはマルチチッププロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）もしくは他のプログラマブルロジックデバイス、ディスクリートゲートもしくはトランジスタロジック、および／またはディスクリートハードウェアコンポーネントを含み得る。
いくつかの実装例において、制御システム６１０は、複数のデバイス内に存在し得る。例えば、制御システム６１０の一部は、本明細書に示された環境のうちの１つの内のデバイス内に存在し得、かつ、制御システム６１０の別の一部は、サーバ、移動型デバイス（例えば、スマートフォンまたはタブレットコンピュータ）などの環境の外側にあるデバイス内に存在し得る。他の例において、制御システム６１０の一部は、本明細書に示された環境のうちの１つの内のデバイス内に存在し得、かつ、制御システム６１０の別の一部は、環境の１つ以上の他のデバイス内に存在し得る。例えば、制御システム機能は、環境の複数のスマートオーディオデバイスにわたって分散され得るか、または、オーケストレートするデバイス（本明細書においてスマートホームハブと呼ばれ得るものなど）および環境の１つ以上の他のデバイスによって共有され得る。インタフェースシステム６０５はまた、いくつかのそのような例において、複数のデバイス内に存在し得る。
いくつかの実装例において、制御システム６１０は、少なくとも部分的に、本明細書において開示された方法を行うように構成され得る。いくつかの例によると、制御システム６１０は、オーディオセッションマネジメント方法を実装するように構成され得る。
本明細書に記載した方法のうちの一部またはすべては、１つ以上の非一時的な媒体に格納された命令（例えば、ソフトウェア）にしたがって、１つ以上のデバイスによって行われ得る。そのような非一時的な媒体は、本明細書に記載したようなメモリデバイスを含み得る。そのようなメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）デバイス、読み出し専用メモリ（ＲＯＭ）デバイスなどを含むが、これらに限定されない。１つ以上の非一時的な媒体は、例えば、図６に図示されたオプションのメモリシステム６１５および／または制御システム６１０内に存在し得る。したがって、本開示に記載の主題の様々な革新的な態様は、格納されたソフトウェアを有する１つ以上の非一時的な媒体内に実装できる。ソフトウェアは、例えば、オーディオセッションマネジメント方法を実装するために少なくとも１つのデバイスを制御するための命令を含み得る。ソフトウェアは、いくつかの例において、オーディオデータを取得、処理および／または提供するために１つ以上のオーディオ環境のオーディオデバイスを制御するための命令を含み得る。ソフトウェアは、例えば、図６の制御システム６１０などの制御システムの１つ以上のコンポーネントによって実行可能であり得る。
いくつかの例において、装置６００は、図６に図示されたオプションのマイクロフォンシステム６２０を含み得る。オプションのマイクロフォンシステム６２０は、１つ以上の
マイクロフォンを含み得る。いくつかの実装例において、マイクロフォンのうちの１つ以上は、スピーカシステムのスピーカ、スマートオーディオデバイスなどの別のデバイスの一部であるか、またはそれに連携し得る。いくつかの例において、装置６００は、マイクロフォンシステム６２０を含まなくてもよい。しかし、いくつかのそのような実装例において、装置６００は、インタフェースシステム６１０を介してオーディオ環境内の１つ以上のマイクロフォンに対するマイクロフォンデータを受信するように構成され得る。
いくつかの実装例によると、装置６００は、図６に図示されたオプションのラウドスピーカシステム６２５を含み得る。オプションのスピーカシステム６２５は、１つ以上のラウドスピーカを含み得る。ラウドスピーカは、本明細書において「スピーカ」と呼ばれることもあり得る。いくつかの例において、オプションのラウドスピーカシステム６２５のうちの少なくともいくつかのラウドスピーカは、任意に位置づけられ得る。例えば、オプションのラウドスピーカシステム６２５の少なくともいくつかのスピーカは、Ｄｏｌｂｙ５．１、Ｄｏｌｂｙ５．１．２、Ｄｏｌｂｙ７．１、Ｄｏｌｂｙ７．１．４、Ｄｏｌｂｙ９．１、Ｈａｍａｓａｋｉ２２．２などのいずれの標準の所定のスピーカレイアウトにも対応しない位置に配置され得る。いくつかのそのような例において、オプションのラウドスピーカシステム６２５の少なくともいくつかのスピーカは、空間（例えば、ラウドスピーカを収容する空間がある位置）に対して都合がよい位置に配置されてもよいが、いずれの標準の所定のスピーカレイアウトにも配置されなくてもよい。
いくつかの実装例において、装置６００は、図６に図示されたオプションのセンサシステム６３０を含み得る。オプションのセンサシステム６３０は、１つ以上のカメラ、タッチセンサ、ジェスチャーセンサ、動き検出器などを含み得る。いくつかの実装例によると、オプションのセンサシステム６３０は、１つ以上のカメラを含み得る。いくつかの実装例において、カメラは、自立型カメラであり得る。いくつかの例において、オプションのセンサシステム６３０の１つ以上のカメラは、単一目的オーディオデバイスまたはバーチャルアシスタントであり得るスマートオーディオデバイス内に存在し得る。いくつかのそのような例において、オプションのセンサシステム６３０の１つ以上のカメラは、ＴＶ、携帯電話またはスマートスピーカ内に存在し得る。いくつかの例において、装置６００は、センサシステム６３０を含まなくてもよい。しかし、いくつかのそのような実装例において、装置６００は、インタフェースシステム６１０を介して、オーディオ環境内の１つ以上のセンサに対するセンサデータを受信するように構成され得る。
いくつかの実装例において、装置６００は、図６に図示されたオプションのディスプレイシステム６３５を含み得る。オプションのディスプレイシステム６３５は、１つ以上の発光ダイオード（ＬＥＤ）ディスプレイなどの１つ以上のディスプレイを含み得る。いくつかの場合において、オプションのディスプレイシステム６３５は、１つ以上の有機発光ダイオード（ＯＬＥＤ）ディスプレイを含み得る。装置６００がディスプレイシステム６３５を含むいくつかの例において、センサシステム６３０は、ディスプレイシステム６３５の１つ以上のディスプレイに近いタッチセンサシステムおよび／またはジェスチャーセンサシステムを含み得る。いくつかのそのような実装例によると、制御システム６１０は、１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）を与えるようにディスプレイシステム６３５を制御するように構成され得る。
いくつかの例によると、装置６００は、スマートオーディオデバイスであってもよいし、それを含んでもよい。いくつかのそのような実装例において、装置６００は、（少なくとも部分的に）ウェイクワード検出器であってもよいし、それを実装してもよい。例えば、装置６００は、（少なくとも部分的に）バーチャルアシスタントであってもよいし、それを実装してもよい。
ここで図４を再度参照する。いくつかの例によると、図４のシステムは、ＣＨＡＳＭ４０１が抽象化をアプリケーション４１０、４１１および４１２に与え、アプリケーション４１０、４１１および４１２がオーケストレーションの言語でルートを生成することを介してプレゼンテーション（例えば、オーディオセッション）を達成できるように実装できる。この言語を使用して、アプリケーション４１０、４１１、および４１２は、制御リンク４３０、４３１、および４３２を介してＣＨＡＳＭ４０１を命令できる。
上記の図１Ａ、１Ｂ、および１Ｃを参照すると、アプリケーションおよびその結果の状況のオーケストレーションの言語における記述は、図１Ａの場合と図１Ｃの場合とで同じになり得ると考える。
シンタックスの例およびオーケストレーションの言語の例を説明するために、まず、図１Ａおよび１Ｃの状況を考えるいくつかの例を与える。
いくつかの例において、本明細書においてオーケストレーションの言語の「ルート」と呼ばれるものは、メディアソース（オーディオソースを含むが、それに限定されない）およびメディアデスティネーションの指示を含み得る。メディアソースおよびメディアデスティネーションは、例えば、アプリケーションによってＣＨＡＳＭに送信されるルート開始リクエストにおいて指定され得る。いくつかの実装例によると、メディアデスティネーションは、オーディオ環境デスティネーションであってもよいし、それを含んでもよい。オーディオ環境デスティネーションは、いくつかの場合において、少なくともある程度の時間、オーディオ環境内に存在する少なくとも１人の人物に、対応し得る。いくつかの場合において、オーディオ環境デスティネーションは、オーディオ環境の１つ以上のエリアまたはゾーンに対応し得る。オーディオ環境ゾーンのいくつかの例を本明細書において開示する。しかし、オーディオ環境デスティネーションは、一般に、ルートに関与することになる、オーディオ環境のいずれの特定のオーディオデバイスも含むことにはならない。オーケストレーションの言語（ルートを確立するためにアプリケーションから要求される詳細を含むが、それに限定されない）をより一般化することによって、ルート実装例のための詳細がＣＨＡＳＭによって決定され、必要に応じて更新され得る。
ルートは、いくつかの例において、オーディオセッション優先度、接続モード、１つ以上のオーディオセッション目標または判断基準などの他の情報を含み得る。いくつかの実装例において、ルートは、本明細書においてオーディオセッション識別子と呼ばれ得る、対応のコードまたは識別子を有することになる。いくつかの場合において、オーディオセッション識別子は、持続的でユニークなオーディオセッション識別子であり得る。
上記最初の例において、対応する「ルート」は、高優先度を有する同期モードにおける人物Ｘ（例えば、図１Ｃのユーザ１０２）からネットワーク（例えば、インターネット）へのルート、および高優先度を有する同期モードにおけるネットワークから人物Ｘへのルートを含み得る。そのような術語は、「電話コールを人物Ｘに接続する」したいと述べるときの自然言語に類似するが、以下を言うこととは全く異なる（デバイス１０１を含む図１Ａの状況を参照のこと）：
このデバイスＭｉｃ（すなわち、デバイス１０１のマイクロフォン）を処理（ノイズ／エコー除去）に接続、
処理出力（ノイズ／エコー）をネットワークに接続、
ネットワークを処理入力（ダイナミックス）に接続、
処理出力（ダイナミックス）をこのデバイススピーカに接続、
処理出力（ダイナミックス）を処理入力（レファレンス）に接続。
この時点において、デバイス１０５を導入すべき場合（つまり、電話アプリケーションの実行がデバイス１０５およびデバイス１０１を含む図１Ｃの状況で行われるべき場合）には、このようなコマンドのリストにしたがう電話アプリケーションを実行することは、デバイスの詳細を必要とし、必要な処理（エコーおよびノイズ除去）が完全に変更される必要があり得ることが分かるであろう。例えば、以下の通りである：
そのデバイスＭｉｃ（すなわち、デバイス１０５のマイクロフォン）をネットワークに接続、
ネットワークを入力処理（ノイズ／エコー除去）に接続、
処理出力（ノイズ／エコー）をネットワークに接続、
ネットワークを処理入力（ダイナミックス）に接続、
処理出力（ダイナミックス）をこのデバイススピーカ（すなわち、デバイス１０１のスピーカ）に接続、
処理出力（ダイナミックス）を処理入力（レファレンス）に接続。
どこで信号処理を行うのが最良であるか、どのように信号を接続するか、および一般に、何がユーザ（既知または既知でない位置に存在し得る）にとって最良の出力かの詳細は、いくつかの例においては、限られた数の使用事例について予め計算され得るが、多数のデバイスおよび／または多数の同期オーディオセッションに対しては管理できなくなり得るような最適化を含み得る。スマートオーディオデバイス（デバイスをオーケストレートまたはコーディネートすることによることを含む）のより良い接続性、能力、知識および制御を可能にし得る基礎のフレームワークを提供し、そして、デバイスを制御するための移植可能（ｐｏｒｔａｂｌｅ）で有効なシンタックスを生成する方が良いと、本発明者らは認識してきた。
いくつかの開示された実施形態は、設計上有効でありかつ非常に一般的である、アプローチおよび言語を使用する。オーディオデバイスを特定の終点のオーディオデバイスではなくルートの一部として考える場合（例えば、システムが本明細書に記載のＳＰＡＳＭではなく本明細書に記載のＣＨＡＳＭを含む実施形態において）に最も良く理解される言語の特定の態様がある。いくつかの実施形態の態様は、以下のルート指定シンタックス（ROUTE SPECIFICATION SYNTAX）、持続ユニークセッション識別子（PERSISTENT UNIQUE SESSION IDENTIFIER、および配信、承認および／または品質の連続概念（CONTINUOUS NOTION OF DELIVERY,ACKNOWLEDGEMENT, and/or QUALITY）のうちの１つ以上を含む。
ルート仕様シンタックス（どの生成されたルートについても要素を明示または暗示しておくという必要性に対処する）は、以下を含み得る：
〇ソース（人物／デバイス／自動決定）および、したがって、暗黙的権限、
〇この所望のオーディオルーティングがすでに進行中または後で到来し得る他のオーディオに対してどれくらい重要であるかについての優先度、
〇デスティネーション（理想的には、人物または１セットの人物、および場合により場所に一般化可能である）、
〇同期、トランザクションまたは予定の範囲の接続性のモード、
〇メッセージが承認されなければいけない程度、または、配信の確信度に関しての確実さの要求、および／または
〇何が、聞かれているコンテンツの最も重要な態様であるかの感覚（理解可能、品質、空間忠実、一貫性、またはおそらくは不可聴）。この最後の点は、聞くことおよび聞かれることへの関心だけでなく、聞こえないものおよび／または聞くことができないものを制御することへの関心という、ネガティブルートの概念を含み得る。いくつかのそのような例は、以下に詳細に説明する「乳児を起こさないで」実装例などの、オーディオ環境の１つ以上のエリアを比較的静かなままにしておくことを含む。他のそのような例は、例え
ば、１つ以上の近傍のラウドスピーカにおいて「ホワイトノイズ」を再生すること、１つ以上の近傍のラウドスピーカにおいて１つ以上の他のオーディオコンテンツの再生レベルを増大することなどによって、オーディオ環境内の他人に秘密の会話を盗み聞かれることを防止することを含み得る。
持続ユニークセッション識別子の態様は、以下を含み得る。いくつかの実施形態の重要な態様としては、いくつかの例において、ルートに対応するオーディオセッションは、完了するかまたは閉じられるまで、持続するということである。例えば、これにより、システムが進行中のオーディオセッションを監視し（例えば、ＣＨＡＳＭを介して）、どの個別セットの接続性が変更されなければいけないかを決定することをアプリケーションに要求するのではなく、ルーティングを変更するためにオーディオセッションを終了または解除することを可能にし得る。持続ユニークセッション識別子には、一旦生成されると、システムがメッセージまたはポーリング方式（poll-driven）管理を実装することを可能に
できるような、制御およびステータスの態様が関与し得る。例えば、オーディオセッションまたはルートの制御は、以下であり得るか、または、それらを含み得る：
－終了、
－デスティネーションを移動、および
－優先度を上げるか、または、下げる。
オーディオセッションまたはルートについて問い合せられ得る項目は、以下であり得るか、または、それらを含み得る：
－定位置にあるか、
－述べられた目標が競合する優先度の間でどれくらい良好に実装されているか、
－ユーザがオーディオを聞いた／承認した感覚または確信度はどれくらいか、
－品質はどれくらいか（例えば、忠実、空間、理解可能、情報、注意、一貫性または不可聴の異なる目標に対して）、
－所望の場合、どのオーディオデバイスが使用中であるかについて、実際のルート層へ下って問い合せする。
配信、承認および／または品質の連続概念の態様は、以下を含み得る。ネットワーキングソケットアプローチ（およびセッション層）の感覚がある程度存在し得るが、特に、同時にルーティングされるか、または、キューに入れられるなどされ得るオーディオアクティビティの数を考慮する場合、オーディオルーティングは、非常に異なり得る。また、デスティネーションが少なくとも１人の人物であり得るので、かつ、いくつかの場合において、ルーティングされる可能性のあり得るオーディオデバイスに対する人物の位置について不確実さがあり得るので、非常に連続な確信を有することは有用であり得る。ネットワーキングは、（到来するかも到来しないかもしれない）ＤＡＴＡＧＲＡＭＳ、そして（到来することが保証されている）ＳＴＲＥＡＭＳのいずれかである、リンクを含み得るか、またはそれらに関係し得る。オーディオの場合、物事が聞こえるあるいは聞こえないという感覚、および／または、我々が誰かを聞くことができるあるいはできないと思うという感覚があり得る。
これらの項目は、簡単なネットワーキングのいくつかの態様を有し得るオーケストレーション言語のいくつかの実施形態において導入されるものである。この上に（いくつかの実施形態において）は、プレゼンテーションおよびアプリケーション層（例えば、「電話コール」のアプリケーション例を実装する際に使用するため）がある。
オーケストレーション言語の実施形態は、セッション開始プロトコル（Session Initiation Protocol（ＳＩＰ））および／またはメディアサーバマークアップ言語（Media Server Markup Language（ＭＳＭＬ））（例えば、現在の１セットのオーディオセッション
に基づくデバイス中心、連続的かつ自律的適合ルーティング）に関係する態様を有し得る。ＳＩＰは、ボイス、ビデオおよび／またはメッセージングアプリケーションを含み得るセッションを開始、維持および終了するために使用される送信プロトコルである。いくつかの場合において、ＳＩＰは、例えば、ボイス通話、ビデオ通話、プライベートＩＰ電話システムのため、インターネットプロトコル（ＩＰ）ネットワークを介したインスタントメッセージングのため、携帯通話のためなどの、インターネット電話の通信セッションを送信および制御するために使用され得る。ＳＩＰは、メッセージのフォーマットおよび参加者の通信シーケンスを定義するテキストベースのプロトコルである。ＳＩＰは、ハイパーテキストトランスファープロトコル（Hypertext Transfer Protocol）（ＨＴＴＰ）お
よびシンプルメールトランスファープロトコル（Simple Mail Transfer Protocol）（Ｓ
ＭＴＰ）の要素を含む。ＳＩＰを用いて確立された通話は、いくつかの場合において、複数のメディアストリームを含み得るが、ＳＩＰメッセージのペイロードとしてデータをやりとりするアプリケーションに対して（例えば、テキストメッセージングアプリケーションに対して）は、分離したストリームは一切必要でない。
ＭＳＭＬは、Request for Comments（ＲＦＣ）５７０７に記載されている。ＭＳＭＬを使用して、ＩＰメディアサーバ上で様々なタイプのサービスが制御される。ＭＳＭＬによれば、メディアサーバは、リアルタイムトランスポートプロトコルメディアストリームなどのメディアストリームを制御および／または操作することに特化された機器である。ＭＳＭＬによると、アプリケーションサーバは、メディアサーバから分離されており、かつ、コール接続を確立および切断するように構成される。ＭＳＭＬによると、アプリケーションサーバは、ＳＩＰまたはＩＰを介して制御「トンネル」を確立するように構成される。アプリケーションサーバは、制御「トンネル」を使用して、ＭＳＭＬでコード化されたリクエストおよびレスポンスをメディアサーバに対してやり取りする。
ＭＳＭＬを使用して、どのようにマルチメディアセッションがメディアサーバとインタラクションするかを定義し、サービスを個々のユーザまたはユーザのグループに適用し得る。ＭＳＭＬを使用して、ビデオレイアウトおよびオーディオミキシングなどのメディアサーバ会議機能（features）など制御し、サイドバー会議（sidebar conference）またはパーソナルミックス（personal mix）を生成し、メディアストリームのプロパティの設定などを行い得る。
いくつかの実施形態は、特定のコマンドを出すことによってユーザが１集団のオーディオデバイスを制御することを可能にする必要がない。しかし、いくつかの実施形態は、デバイス自体を参照せずにアプリケーション層のすべての所望のプレゼンテーションを効果的に達成できることが考えられる。
図７は、一例に係るＣＨＡＳＭのブロックを図示するブロック図である。図７は、図４に示されたＣＨＡＳＭ４０１の例を図示する。図７は、オーケストレーションの言語を使用して複数のアプリからルートを受信し、ルートに関する情報をルーティングテーブル７０１に格納するＣＨＡＳＭ４０１を図示する。図７の要素は、以下を含む：
４０１：ＣＨＡＳＭ、
４３０：オーケストレーションの言語を使用する第１のアプリケーション（図４のアプリケーション４１０）からのコマンド、およびＣＨＡＳＭ４０１からのレスポンス、
４３１：オーケストレーションの言語を使用する第２のアプリケーション（図４のアプリケーション４１１）からのコマンド、およびＣＨＡＳＭ４０１からのレスポンス、
４３２：オーケストレーションの言語を使用する第３のアプリケーション（図４のアプリケーション４１２）からのコマンド、およびＣＨＡＳＭ４０１からのレスポンス、
７０３：オーケストレーションの言語を使用するさらなるアプリケーション（図４において図示せず）からのコマンド、およびＣＨＡＳＭ４０１からのレスポンス、
７０１：ＣＨＡＳＭ４０１によって維持されたルーティングテーブル、
７０２：本明細書においてオーディオセッションマネージャとも呼ばれる最適化器であって、現在のルーティング情報に基づいて複数のオーディオデバイスを連続的に制御する最適化器、
４３５：ＣＨＡＳＭ４０１から第１のオーディオデバイス（図４のオーディオデバイス４２０）へのコマンド、および第１のオーディオデバイスからのレスポンス、
４３４：ＣＨＡＳＭ４０１から第２のオーディオデバイス（図４のオーディオデバイス４２１）へのコマンド、および第２のオーディオデバイスからのレスポンス、
４３５：ＣＨＡＳＭ４０１から第３のオーディオデバイス（図４のオーディオデバイス４２２）へのコマンド、および第３のオーディオデバイスからのレスポンス。
図８は、一例に係る図７において示したルーティングテーブルの詳細を示す。図８の要素は、以下を含む：
７０１：ＣＨＡＳＭによって維持されるルートのテーブル。この例によると、各ルートは、以下のフィールドを有する、
●ＩＤまたは「持続ユニークセッション識別子」、
●どのアプリケーションがルートをリクエストしたかの記録、
●ソース、
●この例において、１人以上の人物または１つ以上の位置を含み得るが、オーディオデバイスを含まないデスティネーション、
●優先度、
●この例において、同期モード、予定されたモードおよびトランザクションモードを含むモードのリストから選択される接続モード、
●承認が要求されるかどうかの指示、
●本明細書においてオーディオセッション目標（単数または複数）と呼ばれる、優先すべきオーディオ品質態様（単数または複数）がどれであるか。いくつかの例において、オーディオセッションマネージャまたはプライオリタイザ（prioritizer）７０２は、オ
ーディオセッション目標（単数または複数）にしたがってオーディオセッションを最適化することになる、
８０１：アプリ４１０および割り当てられたＩＤ５０によってリクエストされた、ルーティングテーブル７０１におけるルート。このルートは、Ａｌｅｘ（デスティネーション）が優先度４を有するＳｐｏｔｉｆｙを聴きたいことを指定する。この例において、優先度は、整数値であり、最高の優先度は、１である。接続モードは、同期である。これは、この例において、進行中（ongoing）を意味する。この場合、Ａｌｅｘは、対応する音楽
がＡｌｅｘに与えられるかどうかを確認または承認することを要求されない。この例において、唯一指定されるオーディオセッション目標は、音楽品質である、
８０２：アプリ８１１および割り当てられたＩＤ５１によってリクエストされているルーティングテーブル７０１におけるルート。Ａｎｇｕｓは、優先度４を有するタイマーアラームを聞くことになっている。このオーディオセッションは、将来の時間に対して予定される。未来の時間は、ＣＨＡＳＭ４０１によって格納されているが、ルーティングテーブル７０１には示されていない。この例において、Ａｎｇｕｓは、アラームを聞いたことを承認することを要求される。この例において、Ａｎｇｕｓがアラームを聞く尤度を増大させるために唯一指定されたオーディオセッション目標は、可聴である、
８０３：アプリ４１０および割り当てられたＩＤ５２によってリクエストされているルーティングテーブル７０１におけるルート。デスティネーションは、「乳児」であるが、オーディオ環境内の乳児の近傍では基礎となるオーディオセッション目標は、不可聴であ
る。したがって、これは、「乳児を起こさないで！」の実装例であり、その詳細な例は、後述する。このオーディオセッションは、優先度が２である（ほぼどれよりも重要）。接続モードは、同期（進行中）である。起こされていない乳児からの承認は、要求されない。この例において、乳児の位置において唯一指定されるオーディオセッション目標は、音が聞こえないこと（不可聴）である。
８０４：アプリ４１１および割り当てられたＩＤ５３によってリクエストされているルーティングテーブル７０１におけるルート。この例において、アプリ４１１は、電話アプリである。この場合、Ｇｅｏｒｇｅは、電話中である。ここで、オーディオセッションの優先度は、３である。接続モードは、同期（進行中）である。Ｇｅｏｒｇｅがまだ通話中であることの承認は、要求されない。例えば、Ｇｅｏｒｇｅは、通話を終了する準備ができている場合に、バーチャルアシスタントに通話を終了させるように要求する意図を有し得る。この例において、唯一指定されるオーディオセッション目標は、音声が理解できること（理解可能性）である。
８０５：アプリ４１２および割り当てられたＩＤ５４によってリクエストされているルーティングテーブル７０１におけるルート。この例において、オーディオセッションの根底にある目的は、配管工が玄関にいて、Ｒｉｃｈａｒｄと話す必要があることをＲｉｃｈａｒｄに通知することである。接続モードは、トランザクションである。他のオーディオセッションの優先度の優先度を考慮して、可能な限り早くにＲｉｃｈａｒｄに対してメッセージを再生する。この例において、Ｒｉｃｈａｒｄは、ちょうど乳児をベッドに寝かしつけたところであり、Ｒｉｃｈａｒｄは、まだ乳児の部屋にいる。より高い優先度を有するルート８０３を考慮すると、ＣＨＡＳＭのオーディオセッションマネージャは、ルート８０５に対応するメッセージが配信されるまでＲｉｃｈａｒｄが乳児の部屋を離れるまで待機することになる。この例において、承認が要求される。この場合、Ｒｉｃｈａｒｄは、Ｒｉｃｈａｒｄがメッセージを聞いたこと、そして配管工に会いに行く途中であることを言葉で承認することが要求される。いくつかの例によると、Ｒｉｃｈａｒｄが指定の時間量内に承認しない場合、ＣＨＡＳＭのオーディオセッションマネージャは、Ｒｉｃｈａｒｄが応答するまで、オーディオ環境のすべてのオーディオデバイス（いくつかの例において、乳児の部屋内にオーディオデバイスがあればそれを除く）にこのメッセージを提供させ得る。この例において、唯一指定されるオーディオセッション目標は、音声が理解できること（理解可能性）であり、Ｒｉｃｈａｒｄは、メッセージを聞いて、理解する。
８０６：火災アラームシステムアプリ８１０および割り当てられたＩＤ５５によってリクエストされているルーティングテーブル７０１におけるルート。このルートの根底にある目的は、ある状況下で（例えば、煙検出センサからの応答にしたがって）家から退避させるために火災アラームを鳴らすことである。このルートは、取り得る最高の優先度を有する。乳児を起こすことも許容される。接続モードは、同期である。承認は、要求されない。この例において、唯一指定されるオーディオセッション目標は、可聴である。この例によると、ＣＨＡＳＭは、オーディオ環境内のすべての人物がアラームを聞き、退避させるために、オーディオ環境のすべてのオーディオデバイスがアラームを大音量で再生するように制御することになる。
いくつかの実装例において、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）は、各ルートに対応する情報を１つ以上のメモリ構造内に維持することになる。いくつかのそのような実装例によると、オーディオセッションマネージャは、オーディオ環境内の変化する状態（例えば、オーディオ環境内で人物が位置を変えること）および／またはオーディオセッションマネージャ７０２からの制御信号にしたがって、各ルートに対応する情報を更新するように構成され得る。例えば、ルート８０１を参照し、オーディオセッションマネージャは、以下の情報を含むか、または、それに対応する１つのメモリ構造を格
納および更新し得る。
表１に示す情報は、例示を提供することを目的として、人間が読み取ることが可能なフォーマットにされている。オーディオセッションマネージャがそのような情報（例えば、デスティネーションの位置およびデスティネーションの向き）を格納するために使用する実際のフォーマットは、特定の実装例に応じて、人間によって理解可能であってもよいし、そうでなくてもよい。
この例において、オーディオセッションマネージャは、Ａｌｅｘの位置および向き、ルート８０１についてのデスティネーションをモニタリングし、どのオーディオデバイスがルート８０１に対してオーディオコンテンツに与えることに関与することになるかを決定するように構成される。いくつかのそのような例によると、オーディオセッションマネージャは、ある方法（詳細は後述）にしたがって、オーディオデバイスの位置、人物の位置および人物の向きを決定するように構成され得る。表１における情報が変化すると、いくつかの実装例において、オーディオセッションマネージャは、対応するコマンド／制御信号を、ルート８０１に対してメディアストリームからのオーディオをレンダリングしているデバイスに送信し、表１を介して図示されるようなメモリ構造を更新することになる。
図９Ａは、オーケストレーションの言語におけるルート開始リクエストの文脈自由文法の例を表す。いくつかの例において、図９Ａは、アプリケーションからＣＨＡＳＭへのルートのリクエストの文法を表し得る。例えば、ルート開始リクエストは、例えば、携帯電話上でボイスコマンドを介してアプリケーションに対応するアイコンを選択するなど、ユーザがアプリケーションを選択し、それと対話したことにしたがって引き起こされ得る。
この例において、要素９０１は、要素９０２Ａ、９０２Ｂ、９０２Ｃおよび９０２Ｄと組み合わされて、ルートソースが定義されることを可能にする。要素９０２Ａ、９０２Ｂ、９０２Ｃおよび９０２Ｄによって図示されるように、この例において、ルートソースは、１人以上の人物、１つ以上のサービスおよびオーディオ環境位置であってもよいし、それらを含んでもよい。サービスは、例えば、クラウドベースのメディアストリーミングサービス、外部のドアベルまたはドアベルに関連するオーディオデバイスからのオーディオフィードを与えるホーム内サービスなどであり得る。いくつかの実装例において、サービスは、ＵＲＬ（例えば、ＳｐｏｔｉｆｙのＵＲＬ）、サービスの名称、自宅のドアベルのＩＰアドレスなどにしたがって指定され得る。オーディオ環境位置は、いくつかの実装例において、後述のオーディオ環境ゾーンに対応し得る。いくつかの例において、オーディオ環境位置ソースは、ゾーン内の１つ以上のマイクロフォンに対応する。要素９０２Ｄのコンマは、複数のソースが指定され得ることを示す。例えば、ルートリクエストは、「Ｒｏｇｅｒ、Ｍｉｃｈａｅｌからのルート」または「Ｓｐｏｔｉｆｙからのルート」または「キッチンからのルート」または「Ｒｏｇｅｒおよびキッチンからのルート」などを示し
得る。
この例において、要素９０３は、要素９０４Ａ、９０４Ｂ、９０４Ｃおよび９０４Ｄと組み合わされて、ルートデスティネーションが定義されることを可能にする。この実装例において、ルートデスティネーションは、１人以上の人物、１つ以上のサービスおよびオーディオ環境位置であってもよいし、それらを含んでもよい。例えば、ルートリクエストは、「Ｄａｖｉｄへのルート」または「キッチンへのルート」または「デッキへのルート」または「Ｒｏｇｅｒおよびキッチンへのルート」などを示し得る。
この例において、１ルートにつき１つの接続モードだけが選択され得る。この実装例によると、接続モードオプションは、同期、予定、またはトランザクションである。しかし、いくつかの実装例において、１ルートにつき複数の接続モードが選択され得る。例えば、いくつかのそのような実装例において、ルート開始リクエストは、ルートが予定およびトランザクションの両方であり得ることを示し得る。例えば、ルート開始リクエストは、メッセージが予定された時間にＤａｖｉｄに配信されるべきであり、Ｄａｖｉｄは、メッセージに対して返答すべきであることを示し得る。図９Ａに図示しないが、いくつかの実装例において、特定のメッセージ（例えば、予め記録されたメッセージ）がルート開始リクエストに含まれ得る。
この例において、オーディオセッション目標は、「特質（trait）」と呼ばれる。この
例によると、１つ以上のオーディオセッション目標は、ルート開始リクエストにおいて、品質９０７および１つ以上の特質９０８Ａの組み合わせを介して示され得る。コンマ９０８Ｂは、この例によると、１つ以上の特質が指定され得ることを示す。しかし、代替の実装例において、唯一のオーディオセッション目標がルート開始リクエストにおいて示され得る。
図９Ｂは、オーディオセッション目標の例を与える。この例によると、「特質」リスト９０８Ａは、１つ以上の重要な品質の指定を可能にする。いくつかの実装例において、ルート開始リクエストは、複数の特質を、例えば、降順に指定し得る。例えば、ルート開始リクエストは、（品質＝理解可能、空間忠実）を指定し得る。これは、理解可能が最も重要な特質であり、その次が空間忠実であることを意味する。ルート開始リクエストは、（品質＝可聴）を指定し得る。これは、人が、例えば、アラームを聞くことができることが唯一のオーディオセッション目標であることを意味する。
ルート開始リクエストは、（品質＝不可聴）を指定し得る。これは、ルートデスティネーションとして指定された人物（例えば、乳児）がオーディオ環境内で再生されるオーディオを聞かないことが唯一のオーディオセッション目標であることを意味する。これは、「乳児を起こさないで」実装例に対するルート開始リクエストの例である。
別の例において、ルート開始リクエストは、（品質＝可聴、プライバシー）を指定し得る。これは、例えば、主なオーディオセッション目標がルートデスティネーションとして指定された人物が配信されたオーディオを聞くことであるが、副次的なオーディオセッション目標が、例えば、秘密の電話会話中に、ルートにしたがって配信および／またはやりとりされるオーディオを他の人が聞くことができる程度を限定することであることを意味し得る。本明細書の他の箇所に説明するように、後者のオーディオセッション目標は、ルートデスティネーションと、オーディオ環境内の１人以上の他の人との間にホワイトノイズまたは他のマスキングノイズを再生すること、１人以上の他の人の近くで再生されている他のオーディオの音量を増大させることなどによって達成され得る。
ここで図９Ａを参照する。この例において、ルート開始リクエストは、要素９０９およ
び９１０を介して優先度を特定し得る。いくつかの例において、優先度は、有限個の整数（例えば、３、４、５、６、７、８、９、１０など）のうちの１つの整数を介して示され得る。いくつかの例において、１は、最高の優先度を示し得る。
この例によると、ルート開始リクエストは、必要に応じて、要素９１１を介して承認を指定し得る。例えば、ルート開始リクエストは、「Ｒｉｃｈａｒｄが夕食の準備ができたといったことをＭｉｃｈａｅｌに伝え、そして承認を得て」を意味し得る。これに応答して、いくつかの例において、オーディオセッションマネージャは、Ｍｉｃｈａｅｌの位置の決定を試み得る。例えば、ＣＨＡＳＭは、Ｍｉｃｈａｅｌのボイスが最後に検出された場所がガレージであるという理由で、Ｍｉｃｈａｅｌはガレージにいると推論し得る。したがって、オーディオセッションマネージャは、「夕食の準備ができました。このメッセージを聞いたことを確認してください」という告知がガレージ内の１つ以上のラウドスピーカを介して再生されるようにし得る。Ｍｉｃｈａｅｌが応答した場合、オーディオセッションマネージャは、その応答をＲｉｃｈａｒｄに報告または再生されるようにし得る。ガレージ告知に対するＭｉｃｈａｅｌの応答がなかった（例えば、１０秒後）場合、オーディオセッションマネージャは、Ｍｉｃｈａｅｌにとって２番目に可能性の高い位置、例えば、Ｍｉｃｈａｅｌが多くの時間を過ごす場所、前のガレージでの発声よりも前にＭｉｃｈａｅｌを聞いた最後の場所で告知がなされるようにし得る。その場所がＭｉｃｈａｅｌの寝室であるとする。Ｍｉｃｈａｅｌの寝室において告知に対するＭｉｃｈａｅｌの応答がない場合（例えば、１０秒後）、オーディオセッションマネージャは、環境の多くのラウドスピーカに告知を再生させ得るが、「乳児を起こさないで」などの他の拘束条件にはしたがう。
図１０は、一例に係るルートを変更するためのリクエストについてのフローを図示する。ルート変更リクエストは、例えば、アプリケーションによって送信され、オーディオセッションマネージャによって受信され得る。ルート変更リクエストは、例えば、ユーザがアプリケーションを選択し、それと対話したことにしたがって引き起こされてもよい。
この例において、ＩＤ１００２は、オーディオセッションマネージャがルート開始リクエストに応答してアプリに予め与えたであろう持続ユニークオーディオセッション番号またはコードを指す。この例によると、接続モードの変更は、要素１００３および要素１００４Ａ、１００４Ｂまたは１００４Ｃを介してなされ得る。あるいは、要素１００４Ａ、１００４Ｂおよび１００４Ｃは、接続モードの変更が所望されない場合に、迂回され得る。
この例によると、１つ以上のオーディオセッション目標は、要素１００５、１００６Ａおよび１００６Ｂを介して変更され得る。あるいは、要素１００５、１００６Ａおよび１００６Ｂは、オーディオセッション目標の変更が所望されない場合に、迂回され得る。
この例において、ルート優先度は、要素１００７および１００８を介して変更され得る。あるいは、要素１００７および１００８は、ルート優先度が所望されない場合に、迂回され得る。
この例によると、要素１００９または要素１０１１は、承認要求の変更を行うために使用され得る。例えば、要素１００９は、ルートに対して承認が以前において要求されなかった場合に、承認が追加され得ることを示す。反対に、要素１０１１は、ルートに対して承認が以前において要求された場合に、承認が解除され得ることを示す。要素１０１０のセミコロンは、ルートを変更するためのリクエストの終了を示す。
図１１Ａおよび１１Ｂは、ルートを変更するためのリクエストについてのフローのさら
なる例を図示する。図１１Ｃは、ルートを削除するためのフローの例を図示する。ルート変更または削除リクエストは、例えば、アプリケーションによって送信され、オーディオセッションマネージャによって受信され得る。ルート変更リクエストは、例えば、ユーザがアプリケーションを選択し、それと対話したことにしたがって引き起こされ得る。図１１Ａおよび１１Ｂにおいて、「シンク（ｓｉｎｋ）」は、ルートデスティネーションを指す。本明細書において開示された他のフロー図と同様に、図１１Ａ～１１Ｃに図示された動作は、必ずしも示された順序で行われない。例えば、いくつかの実装例において、ルートＩＤは、フローにおいてより早くに、例えば、フローの開始時に指定されてもよい。
図１１Ａは、ソースまたはデスティネーションを追加するためのフロー１１００Ａを図示する。いくつかの場合において、１つ以上のソースまたはデスティネーションが追加され得る。この例において、ルートソースは、要素１１０１および１１０２Ａを介して追加され得る。この例によると、ルートデスティネーションは、要素１１０１および１１０２Ｂを介して追加され得る。この例において、ルートソースまたはデスティネーションが追加されるルートは、要素１１０３および１１０４を介して示される。この例によると、人物は、ソースまたはデスティネーションとして要素１１０５Ａを介して追加され得る。この例において、サービスは、ソースまたはデスティネーションとして要素１１０５Ｂを介して追加され得る。この例によると、位置は、ソースまたはデスティネーションとして要素１１０５Ｃを介して追加され得る。要素１１０６は、１つ以上のソースまたはデスティネーションを追加するためのフローの終了を示す。
図１１Ｂは、ソースまたはデスティネーションを取り除くためのフロー１１００Ｂを図示する。いくつかの場合において、１つ以上のソースまたはデスティネーションが取り除かれ得る。この例において、ルートソースは、要素１１０７および１１０８Ａを介して取り除かれ得る。この例によると、ルートデスティネーションは、要素１１０７および１１０８Ｂ介して取り除かれ得る。この例において、ルートソースまたはデスティネーションが取り除かれるルートは、要素１１０９および１１１０を介して示される。この例によると、人物は、は、ソースまたはデスティネーションとして、要素１１１１Ａを介して取り除かれ得る。この例において、サービスは、ソースまたはデスティネーションとして、要素１１１１Ｂを介して取り除かれ得る。この例によると、位置は、ソースまたはデスティネーションとして、要素１１１１Ｃを介して取り除かれ得る。要素１１１２は、１つ以上のソースまたはデスティネーションを取り除くためのフローの終了を示す。
図１１Ｃは、ルートを削除するためのフローを図示する。ここで、要素１１１３は、削除を示す。要素１１１４を介して指定されたルートＩＤは、削除されるべきルートを示す。要素１１１５は、１つ以上のソースまたはデスティネーションを削除するためのフローの終了を示す。
図１２は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。この例によると、方法１２００は、複数のオーディオデバイスを有するオーディオ環境に対するオーディオセッションマネジメント方法である。方法１２００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１２００のブロックのうちの１つ以上が同時に行われ得る。さらに、方法１２００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法１２００のブロックは、１つ以上のデバイスによって行われ得る。それらのデバイスは、図６に図示された後述の制御システム６１０、または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）。
この例において、ブロック１２０５は、第１のアプリケーションを実装する第１のデバ
イスから、および、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）を実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信することを含む。この例によると、第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示す。ここで、第１のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第１の人物に対応する。しかし、この例において、第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかの例によると、第１のルート開始リクエストは、オーディオ環境の少なくとも第１のエリアを第１のルートソースまたは第１のルートデスティネーションとして示し得る。いくつかの場合において、第１のルート開始リクエストは、少なくとも第１のサービスを第１のオーディオソースとして示し得る。
この実装例において、ブロック１２１０は、オーディオセッションマネージャを実装するデバイスによって、第１のルート開始リクエストに対応する第１のルートを確立することを含む。この例において、第１のルートを確立することは、オーディオ環境内の少なくとも第１の人物の第１の位置を決定することと、第１のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第１のオーディオセッションを開始または予定することとを含む。
いくつかの例によると、第１のルート開始リクエストは、第１のオーディオセッション優先度を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１の接続モードを含み得る。第１の接続モードは、例えば、同期接続モード、トランザクション接続モードまたは予定接続モードであり得る。いくつかの例において、第１のルート開始リクエストは、複数の接続モードを示し得る。
いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１の人物から承認が要求されることになるかどうかの指示を含み得る。いくつかの例において、第１のルート開始リクエストは、第１のオーディオセッション目標を含み得る。第１のオーディオセッション目標は、例えば、理解可能、オーディオ品質、空間忠実および／または不可聴を含み得る。
本明細書の他の箇所に説明するように、いくつかの実装例においては、ルートは、対応づけられたオーディオセッション識別子を有し得る。対応づけられたオーディオセッション識別子は、いくつかの実装例において、持続ユニークオーディオセッション識別子であり得る。したがって、方法１２００のいくつかの実装例は、第１のルートに対して第１の持続ユニークオーディオセッション識別子を決定すること（例えば、オーディオセッションマネージャによって）と、第１の持続ユニークオーディオセッション識別子を第１のデバイス（第１のアプリケーションを実行しているデバイス）に送信することとを含み得る。
いくつかの実装例において、第１のルートを確立することは、環境内の少なくとも１つのデバイスに、少なくとも、第１のルートに対応する第１のメディアストリームを確立させることを含み得る、第１のメディアストリームは、第１のオーディオ信号を含む。方法１２００のいくつかの実装例は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。いくつかの例において、方法１２００は、オーディオ環境の別のデバイスに、第１のオーディオ信号を第１のレンダリングされたオーディオ信号にレンダリングさせるオーディオセッションマネージャを含み得る。しかし、いくつかの実装例において、オーディオセッションマネージャは、第１のオーディオ信号を受信し、第１のオーディオ信号を第１のレンダリングされたオーディ
オ信号にレンダリングするように構成され得る。
本明細書の他の箇所に説明するように、いくつかの実装例において、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）は、オーディオ環境内の１人以上の人物の位置および／または向き、オーディオ環境内のオーディオデバイスの位置などのオーディオ環境の状態をモニタリングし得る。例えば、「乳児を起こさないで」の使用事例について、オーディオセッションマネージャ（例えば、図７の最適化器７０２）は、どこに乳児がいるかを決定または少なくとも推定し得る。オーディオセッションマネージャは、関連するアプリケーションからの「オーケストレーションの言語」で送信されたユーザの表現文言（例えば、「乳児を起こさないで。乳児は、寝室１にいます」）によって、どこに乳児がいるかを知り得る。代替として、または、付加として、オーディオセッションマネージャは、以前の表現入力または乳児の泣き声を以前に検出したことに基づいて、どこに乳児がいるかを決定し得る（例えば、後述のように）。いくつかの例において、オーディオセッションマネージャは、この拘束条件（例えば、「不可聴」オーディオセッション目標を介して）受信し、例えば、乳児の位置における音圧力レベルが閾値デシベルレベル（例えば、５０ｄＢ）未満となるようにすることによって、拘束条件を実装し得る。
方法１２００のいくつかの例は、オーディオセッションの第１のステージに対して第１の人物の第１の向きを決定することを含み得る。いくつかのそのような例によると、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることは、第１の人物の第１の位置および第１の向きに対応する第１の基準空間モードを決定することと、第１の基準空間モードに対応するオーディオ環境内のラウドスピーカの第１の相対アクティベーションを決定することとを含み得る。いくつかの詳細な例を以下に説明する。
いくつかの場合において、オーディオセッションマネージャは、第１の人物が位置および／または向きを変更したと判定し得る。方法１２００のいくつかの例は、第１の人物の第２の位置または第２の向きのうちの少なくとも一方を決定することと、第２の位置または第２の向きのうちの少なくとも一方に対応する第２の基準空間モードを決定することと、第２の基準空間モードに対応するオーディオ環境内のラウドスピーカの第２の相対アクティベーションを決定することとを含み得る。
本開示の他の箇所に説明するように、オーディオマネージャは、いくつかの場合において、一度に複数のルートを確立および実装するタスクを課され得る。方法１２００のいくつかの例は、第２のアプリケーションを実装する第２のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第２のオーディオセッションに対して第２のルートを開始するための第２のルート開始リクエストを受信することを含み得る。第１のルート開始リクエストは、第２のオーディオソースおよび第２のオーディオ環境デスティネーションを示し得る。いくつかの例において、第２のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第２の人物に対応し得る。しかし、いくつかの場合において、第２のオーディオ環境デスティネーションは、第２のルートに対応づけられたいずれの特定のオーディオデバイスも示さなくてもよい。
方法１２００のいくつかのそのような例は、オーディオセッションマネージャを実装するデバイスによって、第２のルート開始リクエストに対応する第２のルートを確立すること含み得る。いくつかの場合において、第２のルートを確立することは、オーディオ環境内の少なくとも第２の人物の第１の位置を決定することと、第２のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第２のオーディオセッションを開始することとを含み得る。
いくつかの例によると、第２のルートを確立することは、少なくとも、第２のルートに対応する第２のメディアストリームを確立することを含み得る。第２のメディアストリームは、第２のオーディオ信号を含み得る。方法１２００のいくつかのそのような例は、第２のオーディオ信号が第２のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
方法１２００のいくつかの例は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含み得る。第１のオーディオ信号に対してレンダリング処理を変更することは、例えば、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープすることを含み得る。代替として、または、付加として、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。
図１３は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。この例によると、方法１３００は、複数のオーディオデバイスを有するオーディオ環境に対するオーディオセッションマネジメント方法である。方法１３００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１３００のブロックのうちの１つ以上が同時に行われ得る。さらに、方法１３００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法１３００のブロックは、図６に図示された後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。
この例において、ブロック１３０５は、第１のアプリケーションを実装する第１のデバイスから、および、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）を実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信することを含む。この例によると、第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示す。ここで、第１のオーディオ環境デスティネーションは、オーディオ環境の少なくとも第１のエリアに対応する。しかし、この例において、第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない。
いくつかの例によると、第１のルート開始リクエストは、オーディオ環境内の少なくとも第１の人物を第１のルートソースまたは第１のルートデスティネーションとして示し得る。いくつかの場合において、第１のルート開始リクエストは、少なくとも第１のサービスを第１のオーディオソースとして示し得る。
この実装例において、ブロック１３１０は、オーディオセッションマネージャを実装するデバイスによって、第１のルート開始リクエストに対応する第１のルートを確立することを含む。この例において、第１のルートを確立することは、第１のオーディオセッションの第１のステージに対して、オーディオ環境の第１のエリア内の少なくとも１つのオーディオデバイスを決定することと、第１のオーディオセッションを開始または予定することとを含む。
いくつかの例によると、第１のルート開始リクエストは、第１のオーディオセッション
優先度を含み得る。いくつかの場合において、第１のルート開始リクエストは、第１の接続モードを含み得る。第１の接続モードは、例えば、同期接続モード、トランザクション接続モードまたは予定接続モードであり得る。いくつかの例において、第１のルート開始リクエストは、複数の接続モードを示し得る。
いくつかの実装例において、第１のルート開始リクエストは、少なくとも第１の人物から承認が要求されることになるかどうかの指示を含み得る。いくつかの例において、第１のルート開始リクエストは、第１のオーディオセッション目標を含み得る。第１のオーディオセッション目標は、例えば、理解可能、オーディオ品質、空間忠実および／または不可聴を含み得る。
方法１３００のいくつかの実装例は、第１のルートに対して第１の持続ユニークオーディオセッション識別子を決定すること（例えば、オーディオセッションマネージャによって）と、第１の持続ユニークオーディオセッション識別子を第１のデバイス（第１のアプリケーションを実行しているデバイス）に送信することとを含み得る。
いくつかの実装例において、第１のルートを確立することは、環境内の少なくとも１つのデバイスに、少なくとも、第１のルートに対応する第１のメディアストリームを確立させることを含み得る、第１のメディアストリームは、第１のオーディオ信号を含む。方法１３００のいくつかの実装例は、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。いくつかの例において、方法１３００は、オーディオセッションマネージャがオーディオ環境の別のデバイスに第１のオーディオ信号を第１のレンダリングされたオーディオ信号にレンダリングさせることを含み得る。しかし、いくつかの実装例において、オーディオセッションマネージャは、第１のオーディオ信号を受信し、第１のオーディオ信号を第１のレンダリングされたオーディオ信号にレンダリングするように構成されてもよい。
本明細書の他の箇所に説明するように、いくつかの実装例において、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）は、オーディオ環境内の１つ以上のオーディオデバイスの位置などのオーディオ環境の状態をモニタリングし得る。
方法１３００のいくつかの例は、第１の時間においてオーディオ環境の第１のエリア内の複数のオーディオデバイスの各オーディオデバイスの第１の位置を自動的に決定する第１のラウドスピーカ自動位置（auto-location）処理を行うことを含み得る。いくつかの
そのような例において、レンダリング処理は、各オーディオデバイスの第１の位置に少なくとも部分的に基づき得る。いくつかのそのような例は、各オーディオデバイスの第１の位置を第１のルートに対応づけられたデータ構造内に格納することを含み得る。
いくつかの場合において、オーディオセッションマネージャは、第１のエリア内の少なくとも１つのオーディオデバイスが変更された位置を有すると判定し得る。いくつかのそのような例は、変更された位置を自動的に決定する第２のラウドスピーカ自動位置処理を行うことと、変更された位置に少なくとも部分的に基づいてレンダリング処理を更新することとを含み得る。いくつかのそのような実装例は、変更された位置を第１のルートに対応づけられたデータ構造に格納することを含み得る。
いくつかの場合において、オーディオセッションマネージャは、少なくとも１つのさらなるオーディオデバイスが第１のエリアに移動したと判定し得る。いくつかのそのような例は、さらなるオーディオデバイスのさらなるオーディオデバイス位置を自動的に決定する第２のラウドスピーカ自動位置処理を行うことと、さらなるオーディオデバイスの位置に少なくとも部分的に基づいて、レンダリング処理を更新することとを含み得る。いくつ
かのそのような実装例は、さらなるオーディオデバイスの位置を第１のルートに対応づけられたデータ構造に格納することを含み得る。
本明細書の他の箇所に説明するように、いくつかの例において、第１のルート開始リクエストは、少なくとも第１の人物を第１のルートソースまたは第１のルートデスティネーションとして示し得る。方法１３００のいくつかの例は、オーディオセッションの第１のステージに対して第１の人物の第１の向きを決定することを含み得る。いくつかのそのような例によると、第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにすることは、第１の人物の第１の位置および第１の向きに対応する第１の基準空間モードを決定することと、第１の基準空間モードに対応するオーディオ環境内のラウドスピーカの第１の相対アクティベーションを決定することとを含み得る。いくつかの詳細な例を以下に説明する。
いくつかの場合において、オーディオセッションマネージャは、第１の人物が位置および／または向きを変更したと判定し得る。方法１３００のいくつかの例は、第１の人物の第２の位置または第２の向きのうちの少なくとも一方を決定することと、第２の位置または第２の向きのうちの少なくとも一方に対応する第２の基準空間モードを決定することと、第２の基準空間モードに対応するオーディオ環境内のラウドスピーカの第２の相対アクティベーションを決定することとを含み得る。
本開示の他の箇所に説明するように、オーディオマネージャは、いくつかの場合において、一度に複数のルートを確立および実装するタスクを課され得る。方法１３００のいくつかの例は、第２のアプリケーションを実装する第２のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第２のオーディオセッションに対して第２のルートを開始するための第２のルート開始リクエストを受信することを含み得る。第１のルート開始リクエストは、第２のオーディオソースおよび第２のオーディオ環境デスティネーションを示し得る。いくつかの例において、第２のオーディオ環境デスティネーションは、オーディオ環境内の少なくとも第２の人物に対応し得る。しかし、いくつかの場合において、第２のオーディオ環境デスティネーションは、第２のルートに対応づけられたいずれの特定のオーディオデバイスも示さなくてもよい。
方法１３００のいくつかのそのような例は、オーディオセッションマネージャを実装するデバイスによって、第２のルート開始リクエストに対応する第２のルートを確立すること含み得る。いくつかの場合において、第２のルートを確立することは、オーディオ環境内の少なくとも第２の人物の第１の位置を決定することと、第２のオーディオセッションの第１のステージに対して少なくとも１つのオーディオデバイスを決定することと、第２のオーディオセッションを開始することとを含み得る。
いくつかの例によると、第２のルートを確立することは、少なくとも、第２のルートに対応する第２のメディアストリームを確立することを含み得る。第２のメディアストリームは、第２のオーディオ信号を含み得る。方法１３００のいくつかのそのような例は、第２のオーディオ信号が第２のレンダリングされたオーディオ信号にレンダリングされるようにすることを含み得る。
方法１３００のいくつかの例は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含み得る。第１のオーディオ信号に対してレンダリング処理を変更することは、例えば、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープす
ること含み得る。代替として、または、付加として、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。
図１４は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。この例によると、方法１４００は、複数のオーディオデバイスを有するオーディオ環境に対するオーディオセッションマネジメント方法である。方法１４００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１４００のブロックのうちの１つ以上が同時に行われ得る。さらに、方法１４００いくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法１４００のブロックは、図６に図示された後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。
この例において、ブロック１４０５において、図４のアプリケーション４１０は、オーケストレーションの言語を使用して、ＣＨＡＳＭ４０１を命令する。ブロック１４０５は、例えば、ＣＨＡＳＭ４０１にルート開始リクエストまたはルート変更リクエストを送信するアプリケーション４１０を含み得る。
この例によると、ＣＨＡＳＭ４０１は、アプリケーション４１０から受信された命令に応答し得る最適なメディアエンジン制御情報を決定する。この例において、最適なメディアエンジン制御情報は、アプリケーション４１０からの命令において示された、オーディオ環境内の聴取者の位置、オーディオ環境内のオーディオデバイス利用可能性、およびオーディオセッション優先度に少なくとも部分的に基づく。いくつかの場合において、最適なメディアエンジン制御情報は、例えば、関係するオーディオデバイス（単数または複数）によって共有されたデバイスプロパティディスクリプタを介して、ＣＨＡＳＭ４０１によって決定されたメディアエンジン能力に少なくとも部分的に基づき得る。いくつかの例によると、最適なメディアエンジン制御情報は、聴取者の向きに少なくとも部分的に基づき得る。
この場合、ブロック４１５は、制御情報を１つ以上のオーディオデバイスメディアエンジンに送信することを含む。制御情報は、図５を参照して上述したオーディオセッションマネジメント制御信号に対応し得る。
この例によると、ブロック１４２０は、ルート優先度における変化、オーディオデバイスの位置（単数または複数）における変化、聴取者の位置における変化などの任意の著しい変化があったかどうかを決定するために、オーディオ環境内の状態、およびこの特定のルートに関するアプリケーション４１０からの可能なさらなる通信をモニタリングするＣＨＡＳＭ４０１を表す。そうである場合、処理は、ブロック１４１０に戻り、そしてブロック１４１０の処理は、新たなパラメータ（単数または複数）にしたがって行われる。そうでない場合、ＣＨＡＳＭ４０１は、ブロック１４２０のモニタリング処理を継続する。
図１５は、いくつかの実装例に係る、オーディオ環境に新たに導入される１つ以上のオーディオデバイスに対する自動セットアップ処理のブロックを含むフロー図である。この例において、オーディオデバイスの一部またはすべては、新たなオーディオデバイスである。方法１５００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１５００のブロックのうちの１つ以上は、同時に行われ得る。さらに、方法１５００のいくつかの実装例は、図示および／または記
載されたものよりも多くのまたは少ないブロックを含み得る。方法１５００ブロックは、図６に図示された後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。
この例において、ブロック１５０５において、新たなオーディオデバイスが開梱され、電源投入される。ブロック１５１０の例において、新たなオーディオデバイスのそれぞれは、他のオーディオデバイスを探すために、かつ、特に、オーディオ環境のＣＨＡＳＭを探すために発見モードに入る。既存のＣＨＡＳＭが発見された場合、新たなオーディオデバイスは、各新たなオーディオデバイスの能力に関する情報をＣＨＡＳＭと共有することなどのために、ＣＨＡＳＭと通信するように構成され得る。
しかし、この例によると、既存のＣＨＡＳＭが発見されない。したがって、ブロック１５１０のこの例において、新たなオーディオデバイスのうちの１つは、自身をＣＨＡＳＭとして構成する。この例において、最も多くの利用可能な計算パワーおよび／または最も大きな接続性を有する新たなオーディオデバイスが、自身を新たなＣＨＡＳＭ４０１として構成することになる。
この例において、ブロック１５１５において、新たな非ＣＨＡＳＭオーディオデバイスのすべては、新たに指定されたＣＨＡＳＭ４０１である他の新たなオーディオデバイスと通信する。この例によると、新たなＣＨＡＳＭ４０１は、この例において図４のアプリケーション４１２である「セットアップ」アプリケーションを開始する。この場合、セットアップアプリケーション４１２は、セットアップ処理についてユーザをガイドするために、例えば、オーディオおよび／またはビジュアルプロンプトを介して、ユーザと対話するように構成され得る。
この例によると、ブロック１５２０において、セットアップアプリケーション４１２は、「すべての新たなデバイスをセットアップする」ことを示し、最高のレベルの優先度を有する命令をＣＨＡＳＭ４０１にオーケストレーションの言語で送信する。
この例において、ブロック１５２５において、ＣＨＡＳＭ４０１は、セットアップアプリケーション４１２からの命令を解釈し、そして、新たな音響マッピングキャリブレーションが要求されると判定する。この例によると、音響マッピング処理は、ブロック１５２５において開始され、ＣＨＡＳＭ４０１と新たな非ＣＨＡＳＭオーディオデバイスのメディアエンジン（この場合、図４のメディアエンジン４４０、４４１および４４２）との間の通信を介して、ブロック１５３０において完了する。本明細書において使用されるように、「音響マッピング」という用語は、オーディオ環境のすべての発見可能なラウドスピーカの位置の推定を含む。音響マッピング処理は、例えば、以下に詳細に記載されるようなラウドスピーカ自動位置処理を含み得る。いくつかの場合において、音響マッピング処理は、ラウドスピーカ能力情報および／または個別のラウドスピーカダイナミックス処理情報の発見の処理を含み得る。
この例によると、ブロック１５３５において、ＣＨＡＳＭ４０１は、セットアップ処理が完了したという確認をアプリケーション４１２に送信する。この例において、ブロック１５４０において、アプリケーション４１２は、セットアップ処理が完了したことをユーザに示す。
図１６は、いくつかの実装例に係る、バーチャルアシスタントアプリケーションをインストールするための処理のブロックを含むフロー図である。いくつかの場合において、方法１７００は、方法１５００のセットアップ処理の後に行われ得る。この例において、方
法１６００は、図４に図示されたオーディオ環境の状況においてバーチャルアシスタントアプリケーションをインストールすることを含む。方法１６００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１６００のブロックのうちの１つ以上は、同時に行われ得る。さらに、方法１６００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法１６００のブロックは、図６に図示された後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。
この例において、ブロック１６０５において、「バーチャル支援連絡（Ｖｉｒｔｕａｌ
Ａｓｓｉｓｔｉｎｇ Ｌｉａｉｓｏｎ）」またはＶＡＬと呼ばれる新たなアプリケーション４１１がユーザによってインストールされる。いくつかの例によると、ブロック１６０５は、１つ以上のサーバからインターネットを介して、アプリケーション４１１を携帯電話などのオーディオデバイスにダウンロードすることを含み得る。
この実装例によると、ブロック１６１０において、アプリケーション４１１は、ＣＨＡＳＭ４０１に対して、オーケストレーションの言語で、最高の優先度を有する、持続性オーディオセッションとしての新たなウェイクワード「やあＶａｌ」を連続的に聴き取るように命令する。この例において、ブロック１６１５において、ＣＨＡＳＭ４０１は、アプリケーション４１１からの命令を解釈し、そして、メディアエンジン４４０、４４１および４４２に対して、ウェイクワード「やあＶａｌ」を聴こうとし、ウェイクワード「やあＶａｌ」が検出された場合はいつでもコールバックをＣＨＡＳＭ４０１に出すようにウェイクワード検出器を構成するように命令する。この実装例において、ブロック１６２０において、メディアエンジン４４０、４４１および４４２は、ウェイクワードを聴こうとすることを継続する。
この例において、ブロック１６２５において、ＣＨＡＳＭ４０１は、ウェイクワード「やあＶａｌ」が検出されたことを示すコールバックをメディアエンジン４４０および４４１から受信する。これに応答して、ＣＨＡＳＭ４０１は、メディアエンジン４４０、４４１および４４２に対して、ウェイクワードが最初に検出された後の閾値期間（この例においては、５秒）のあいだコマンドを聴こうとし、コマンドが検出されたら、コマンドが検出されたエリア内のオーディオの音量を「下げる（ｄｕｃｋ）」または低減するように命令する。
この例によると、ブロック１６３０において、メディアエンジン４４０、４４１および４４２はすべて、コマンドを検出し、そして、ＣＨＡＳＭ４０１に、検出されたコマンドに対応する音声オーディオデータおよび確率を送信する。この例において、ブロック１６３０において、ＣＨＡＳＭ４０１は、アプリケーション４１１に、検出されたコマンドに対応する音声オーディオデータおよび確率を送る。
この実装例において、ブロック１６３５において、アプリケーション４１１は、検出されたコマンドに対応する音声オーディオデータおよび確率を受信し、そして、これらのデータを処理のためにクラウドベースの音声認識アプリケーションに送る。この例において、ブロック１６３５において、クラウドベースの音声認識アプリケーションは、音声認識処理の結果をアプリケーション４１１に送信する。音声認識処理の結果は、この例において、コマンドに対応する１つ以上のワードを含む。ここで、ブロック１６３５において、アプリケーション４１１は、ＣＨＡＳＭ４０１に対して、オーケストレーションの言語で、音声認識セッションを終了するように命令する。この例によると、ＣＨＡＳＭ４０１は、メディアエンジン４４０、４４１および４４２に対して、コマンドの聴取を停止するように命令する。
図１７は、いくつかの実装例に係るオーディオセッションマネジメント方法のブロックを含むフロー図である。この例によると、方法１７００は、音楽アプリケーションを図４のオーディオ環境内に実装するためのオーディオセッションマネジメント方法である。いくつかの場合において、方法１７００は、方法１５００のセットアップ処理の後に行われ得る。いくつかの例において、方法１７００は、図１６を参照して上述したバーチャルアシスタントアプリケーションをインストールするための処理の前または後に行われ得る。方法１７００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法１７００のブロックのうちの１つ以上は、同時に行われ得る。さらに、方法１７００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法１７００のブロックは、図６に図示された後述の制御システム６１０または他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。
この例において、ブロック１７０５において、ユーザは、オーディオ環境内のデバイス上で動作している音楽アプリケーションに入力を与える。この場合、音楽アプリケーションは、図４のアプリケーション４１０である。この例によると、アプリケーション４１０は、スマートフォン上で動作しており、入力は、タッチおよび／またはジェスチャーセンサシステムなどのスマートフォンのユーザインタフェースを介して与えられる。
この例によると、ブロック１７１０において、アプリケーション４１０は、ＣＨＡＳＭ４０１に対して、この例においてオーケストレーションの言語のルート開始リクエストを介して、クラウドベースの音楽サービスから、スマートフォンを介してアプリケーション４１０と対話しているユーザへのルートを開始するように命令する。この例において、ルート開始リクエストは、クラウドベースの音楽サービスのユーザの現在の好みのプレイリストを使用して、オーディオセッション目標が最高の音楽再生品質であり、承認がリクエストされず、優先度が４である同期モードを示す。
この例において、ブロック１７１５において、ＣＨＡＳＭ４０１は、ブロック１７１０において受信された命令にしたがって、オーディオ環境のどのオーディオデバイスがルートにおいて関与することになるかを決定する。決定は、オーディオデバイスが現在利用可能であるオーディオ環境の予め決定された音響マップ、利用可能なオーディオデバイスの能力、およびユーザの推定された現在の位置に少なくとも部分的に基づき得る。いくつかの例において、ブロック１７１５の決定は、ユーザの推定された現在の向きに少なくとも部分的に基づき得る。いくつかの実装例において、また、ブロック１７１５において、呼び（ｎｏｍｉｎａｌ）または初期聴取レベルが選択され得る。このレベルは、１つ以上のオーディオデバイスに対するユーザの推定された近傍度（ｐｒｏｘｉｍｉｔｙ）、ユーザのエリア内の周囲ノイズレベルなどに少なくとも部分的に基づき得る。
この例によると、ブロック１７２０において、ＣＨＡＳＭ４０１は、アプリケーション４１０によってリクエストされたルートに対応するメディアビットストリームを取得するために、制御情報を選択されたオーディオデバイスメディアエンジン（この例ではメディアエンジン４４１）に送信する。この例において、ＣＨＡＳＭ４０１は、メディアエンジン４４１に、クラウドベースの音楽プロバイダのＨＴＴＰアドレス、例えば、クラウドベースの音楽プロバイダによってホストされた特定のサーバのＨＴＴＰアドレスを与える。この実装例によると、ブロック１７２５において、メディアエンジン４４１は、メディアビットストリームを、クラウドベースの音楽プロバイダから、この例においては、１つ以上の割り当てられたサーバの位置から取得する。
この例において、ブロック１７３０は、ブロック１７２５において取得されたメディアストリームに対応する音楽を再生することを含む。この例によると、ＣＨＡＳＭ４０１は、少なくともラウドスピーカ４６１、およびいくつかの例においてはまた、ラウドスピーカ４６０および／またはラウドスピーカ４６２が音楽の再生に関与すると決定している。いくつかのそのような例において、ＣＨＡＳＭ４０１は、メディアエンジン４４１に対して、メディアストリームからのオーディオデータをレンダリングし、そして、レンダリングされたスピーカフィード信号をメディアエンジン４４０および／またはメディアエンジン４４２に与えるように命令する。
図１８Ａは、最小限バージョンの実施形態のブロック図である。Ｎ個のプログラムストリーム（
）が図示される。第１のプログラムストリームは、空間と明示的に標識される。Ｎ個のプログラムストリームの対応する１群のオーディオ信号は、対応するレンダラを介してフィードされる。レンダラはそれぞれ、それに対応するプログラムストリームを共通の１セットのＭ個の任意に間隔を開けられたラウドスピーカ（
）を介して再生するように個別に構成される。また、レンダラは、本明細書において、「レンダリングモジュール」と呼ばれ得る。レンダリングモジュールおよびミキサ１８３０ａは、ソフトウェア、ハードウェア、ファームウェアまたはそれらのある組み合わせを介して実装され得る。この例において、レンダリングモジュールおよびミキサ１８３０ａは、図６を参照して上述した制御システム６１０の一例である制御システム６１０ａによって実装される。いくつかの実装例によると、レンダリングモジュールおよびミキサ１８３０ａの機能は、本明細書においてオーディオセッションマネージャと呼ばれるものを実装しているデバイス（例えば、ＣＨＡＳＭ）からの命令にしたがって、少なくとも部分的に、実装され得る。いくつかのそのような例において、レンダリングモジュールおよびミキサ１８３０ａの機能は、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１からの命令にしたがって、少なくとも部分的に、実装され得る。代替の例において、また、オーディオセッションマネージャを実装しているデバイスは、レンダリングモジュールおよびミキサ１８３０ａの機能を実装してもよい。
図１８Ａに示される例において、Ｎ個のレンダラのそれぞれは、１セットのＭ個のラウドスピーカ上で同期再生するための、Ｎ個のレンダラのすべてにわたって合計されたＭ個のラウドスピーカフィードを出力する。この実装例によると、聴取環境内のＭ個のラウドスピーカのレイアウトについての情報がすべてのレンダラに与えられる。この情報は、ラウドスピーカブロックからフィードバックする破線によって示されている。これにより、レンダラは、スピーカを介して再生を行うように適切に構成され得る。このレイアウト情報は、特定の実装例に応じて、スピーカのうちの１つ以上のスピーカ自体から送信されてもよいし、そうでなくてもよい。いくつかの例によると、レイアウト情報は、聴取環境内のＭ個のラウドスピーカのそれぞれの相対的な位置を決定するように構成された１つ以上のスマートスピーカによって与えられ得る。いくつかのそのような自動位置方法は、は、到来方向方法または到着時間（ｔｉｍｅ ｏｆ ａｒｒｉｖａｌ（ＴＯＡ））方法に基づき得る。他の例において、このレイアウト情報は、別のデバイスによって決定され得るか、かつ／または、ユーザによって入力され得る。いくつかの例において、聴取環境内のＭ個のラウドスピーカのうちの少なくともいくつかの能力についてのラウドスピーカ仕様情報がすべてのレンダラに与えられ得る。そのようなラウドスピーカ仕様情報は、インピーダンス、周波数応答、感度、電力定格、個別のドライバの数および位置などを含み得る。この例によると、さらなるプログラムストリームのうちの１つ以上のプログラムストリームのレンダリングからの情報は、当該レンダリングが当該情報の関数としてダイナミック
に変更され得るように、主な空間ストリームのレンダラにフィードされる。この情報は、レンダラブロック２～Ｎからレンダラブロック１に戻る破線によって表される。
図１８Ｂは、さらなる特徴を有する別の（より能力の高い）実施形態を図示する。この例において、レンダリングモジュールおよびミキサ１８３０ｂは、図６を参照して上述した制御システム６１０の例である制御システム６１０を介して実装される。いくつかの実装例によると、レンダリングモジュールおよびミキサ１８３０ｂの機能は、本明細書においてオーディオセッションマネージャと呼ばれるものを実装しているデバイス（例えば、ＣＨＡＳＭ）からの命令にしたがって、少なくとも部分的に、実装され得る。いくつかのそのような例において、レンダリングモジュールおよびミキサ１８３０ｂの機能は、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１からの命令にしたがって、少なくとも部分的に、実装され得る。代替の例において、また、オーディオセッションマネージャを実装しているデバイスは、レンダリングモジュールおよびミキサ１８３０ｂの機能を実装し得る。
図１８Ｂにおいて、Ｎ個のレンダラのすべての間を上下に延びる破線は、Ｎ個のレンダラのうちの任意の１つが残りのＮ－１個のレンダラのうちのいずれかのダイナミック変更に寄与し得るという考えを表す。換言すると、Ｎ個のプログラムストリームのうちのいずれか１つをレンダリングすることは、残りのＮ－１個のプログラムストリームのいずれかのプログラムストリームの１つ以上のレンダリングの組み合わせの関数としてダイナミックに変更され得る。加えて、プログラムストリームのうちの任意の１つ以上は、空間ミックスであり得、かつ、任意のプログラムストリームのレンダリングは、そのプログラムストリームが空間であるかどうかにかかわらず、他のプログラムストリームのうちのいずれかのプログラムストリームの関数としてダイナミックに変更され得る。例えば、上述したように、Ｎ個のレンダラにラウドスピーカレイアウト情報が与えられ得る。いくつかの例において、Ｎ個のレンダラにラウドスピーカ仕様情報が与えられ得る。いくつかの実装例において、マイクロフォンシステム６２０ａは、聴取環境内に１セットのＫ個のマイクロフォン（
）を含み得る。いくつかの例において、マイクロフォン（単数または複数）は、ラウドスピーカのうちの１つ以上に取りつけられるか、または、連携し得る。これらのマイクロフォンは、実線で表された、それらによりキャプチャされたオーディオ信号、および、破線によって表された、さらなる構成情報（例えば、それらの位置）の両方を１セットのＮ個のレンダラにフィードバックし得る。次いで、Ｎ個のレンダラのいずれもが、このさらなるマイクロフォン入力の関数として、ダイナミックに変更され得る。本明細書において、様々な例が提供される。
マイクロフォン入力から得られ、その後、Ｎ個のレンダラのいずれかをダイナミックに変更するために使用される情報の例は、以下を含むが、それらに限定されない。
●システムのユーザによる特定のワードまたは用語の発声の検出。
●システムの１つ以上のユーザの位置の推定値。
●聴取空間内の特定の位置におけるＮ個のプログラムストリームの任意の組み合わせのラウドネスの推定値。
●聴取環境内の背景ノイズなどの他の環境音のラウドネスの推定値。
図１９は、図６、図１８Ａまたは図１８Ｂに図示されるような装置またはシステムによって提供され得る方法の一例の概要を示すフロー図である。方法１９００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。さらに、そのような方法は、図示および／または記載されたものよりも多くのまたは少ないブロックを
含み得る。方法１９００のブロックは、図６、１８Ａおよび１８Ｂに図示の上記制御システム６１０、制御システム６１０ａもしくは制御システム６１０ｂ、または、他の開示された制御システム例のうちの１つなどの制御システムであり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。いくつかの実装例によると、方法１９００のブロックは、本明細書においてオーディオセッションマネージャと呼ばれるものを実装しているデバイス（例えば、ＣＨＡＳＭ）からの命令にしたがって、少なくとも部分的に、行われ得る。いくつかのそのような例において、方法１９００のブロックは、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１からの命令にしたがって、少なくとも部分的に、行われ得る。代替の例において、また、オーディオセッションマネージャを実装しているデバイスは、方法１９００のブロックを実装し得る。
この実装例において、ブロック１９０５は、インタフェースシステムを介して、第１のオーディオプログラムストリームを受信することを含む。この例において、第１のオーディオプログラムストリームは、環境の少なくともいくつかのスピーカによって再生されるように予定された第１のオーディオ信号を含む。ここで、第１のオーディオプログラムストリームは、第１の空間データを含む。この例によると、第１の空間データは、チャネルデータおよび／または空間メタデータを含む。いくつかの例において、ブロック１９０５は、インタフェースシステムを介して、第１のオーディオプログラムストリームを受信する制御システムの第１のレンダリングモジュールを含む。
この例によると、ブロック１９１０は、環境のスピーカを介して再生するために第１のオーディオ信号をレンダリングして、第１のレンダリングされたオーディオ信号を生成することを含む。方法１９００のいくつかの例は、例えば、上述したように、ラウドスピーカレイアウト情報を受信することを含む。方法１９００のいくつかの例は、例えば、上述したように、ラウドスピーカ仕様情報を受信することを含む。いくつかの例において、第１のレンダリングモジュールは、ラウドスピーカレイアウト情報および／またはラウドスピーカ仕様情報に少なくとも部分的に基づいて、第１のレンダリングされたオーディオ信号を生成し得る。
この例において、ブロック１９１５は、インタフェースシステムを介して、第２のオーディオプログラムストリームを受信することを含む。この実装例において、第２のオーディオプログラムストリームは、環境の少なくともいくつかのスピーカによって再生されるように予定された第２のオーディオ信号を含む。この例によると、第２のオーディオプログラムストリームは、第２の空間データを含む。第２の空間データは、チャネルデータおよび／または空間メタデータを含む。いくつかの例において、ブロック１９１５は、インタフェースシステムを介して、第２のオーディオプログラムストリームを受信する制御システムの第２のレンダリングモジュールを含む。
この実装例によると、ブロック１９２０は、環境のスピーカを介して再生するために第２のオーディオ信号をレンダリングして、第２のレンダリングされたオーディオ信号を生成することを含む。いくつかの例において、第２のレンダリングモジュールは、受信されたラウドスピーカレイアウト情報および／または受信されたラウドスピーカ仕様情報に少なくとも部分的に基づいて、第２のレンダリングされたオーディオ信号を生成し得る。
いくつかの場合において、環境のいくつかまたはすべてのスピーカは、Ｄｏｌｂｙ５．１、Ｄｏｌｂｙ７．１、Ｈａｍａｓａｋｉ２２．２などのいずれの標準の所定のスピーカレイアウトにも対応しない位置に配置され得る。いくつかのそのような例において、環境のすくなくともいくつかのスピーカは、環境の家具、壁など（例えば、ラウドスピーカを収容すべき空間がある位置）に対して都合がよい位置に配置されてもよいが、いずれの標
準の所定のスピーカレイアウトにも配置されなくてもよい。
したがって、いくつかの実装例において、ブロック１９１０またはブロック１９２０は、任意の位置に配置されたスピーカに対してフレキシブルにレンダリングすることを含み得る。いくつかのそのような実装例は、質量中心振幅パニング（ＣＭＡＰ）、フレキシブル仮想化（ＦＶ）、またはその両方の組み合わせを含み得る。高いレベルから、これらの手法の両方は、１セットの２つ以上のスピーカ上で再生するために、それぞれが関連する所望の知覚された空間位置を有する１セットの１つ以上のオーディオ信号をレンダリングする。ここで、そのセットのスピーカの相対的なアクティベーションは、スピーカ上で再生される当該オーディオ信号の知覚された空間位置のモデル、および、スピーカの位置に対するオーディオ信号の所望の知覚された空間位置の近傍度の関数である。このモデルは、オーディオ信号がその意図された空間位置の近くで聴取者によって聞かれることを確実にし、近傍度項は、どのスピーカがこの空間印象を達成するために使用されるかを制御する。特に、近傍度項は、オーディオ信号の所望の知覚された空間位置の近くにあるスピーカのアクティベーションに対して有利に働く。ＣＭＡＰおよびＦＶの両方に対して、この関数的関係は、空間態様についての項および近傍度についての項の２つの項の合計として記述されるコスト関数から便宜的に得られる。
ここで、セット
は、１セットのＭ個のラウドスピーカの位置を表し、
は、オーディオ信号の所望の知覚された空間位置を表し、ｇは、スピーカアクティベーションのＭ次元ベクトルを表す。ＣＭＡＰに対して、ベクトルにおける各アクティベーションは、１スピーカごとのゲイン、他方、ＦＶに対して、各アクティベーションは、フィルタを表す（この第２の場合において、ｇは、特定の周波数における複素数のベクトルと等価的に考えることができ、フィルタを形成するために異なるｇが複数の周波数にわたって計算される）。アクティベーションの最適なベクトルは、アクティベーションにわたってコスト関数を最小化することによって見出される。
コスト関数の定義によっては、
の成分間の相対レベルが適切であっても、上記最小化から得られる最適なアクティベーションの絶対レベルを制御することは困難である。この問題に対処するために、アクティベーションの絶対レベルが制御されるように、後で
の正規化が行われ得る。例えば、単位長さを取得するようにベクトルを正規化することが望ましくあり得、これは、一般に使用される定パワーパニングルール（ｃｏｎｓｔａｎｔ
ｐｏｗｅｒ ｐａｎｎｉｎｇ ｒｕｌｅｓ）に沿う。
フレキシブルレンダリングアルゴリズムの正確なふるまいは、コスト関数の２つの項である
および
の特定の構築によって決定づけられる。ＣＭＡＰに対して、
は、１セットのラウドスピーカから再生されるオーディオ信号の知覚された空間位置を、関連するアクティベーティングゲイン
（ベクトルｇの成分）によって重みづけられたラウドスピーカの位置の質量中心に配置するモデルから得られる。
次いで、式３を操作して、所望のオーディオ位置と、アクティベートされたラウドスピーカによって生成されたオーディオ位置との間の二乗誤差を表す空間コストにする。
ＦＶの場合、コスト関数の空間項は、異なって定義される。ここで、目標は、聴取者の左右の耳におけるオーディオオブジェクト位置
に対応する両耳応答ｂを生成することである。概念的には、ｂは、フィルタ（各耳につき１つのフィルタ）の２×１ベクトルであるが、より便宜的には、特定の周波数における複合値の２×１ベクトルとして扱われる。特定の周波数におけるこの表現を用いて進めると、所望の両耳応答は、オブジェクト位置によってインデックスされた１セットのＨＲＴＦから取り出され得る。
同時に、ラウドスピーカによって聴取者の耳において生成された２×１両耳応答ｅは、
２×Ｍの音響伝播行列Ｈに複合スピーカアクティベーション値のＭ×１ベクトルｇを掛け合わせたものとしてモデル化される。
音響伝播行列Ｈは、聴取者の位置に対する１セットのラウドスピーカの位置
に基づいてモデル化される。最後に、コスト関数の空間成分は、所望の両耳応答（式５）と、ラウドスピーカによって生成された両耳応答（式６）との二乗誤差として定義される。
便宜的に、式４および７において定義されたＣＭＡＰおよびＦＶに対するコスト関数の空間項の両方は、スピーカアクティベーションｇの関数としての行列二次式に再配置できる。

ここで、Ａは、Ｍ×Ｍの正方行列であり、Ｂは、１×Ｍのベクトルであり、Ｃは、スカラーである。行列Ａは、ランク２であり、したがって、Ｍ＞２の場合、空間エラー項がゼロに等しいスピーカアクティベーションｇが有限個存在する。コスト関数の第２の項、
、を導入することは、不確定性を取り除き、他の可能な解と比較して、知覚的に有利なプロパティを有する特定の解を生じさせる。ＣＭＡＰおよびＦＶの両方に対して、
は、所望のオーディオ信号位置
と異なる位置
を有するスピーカのアクティベーションが、所望の位置に近い位置を有するスピーカのアクティベーションよりも大きなペナルティを受けるように構築される。この構築により、所望のオーディオ信号の位置の近傍にあるスピーカだけが顕著にアクティベートされるようなスパースな（ｓｐａｒｓｅ）最適な１セットのスピーカアクティベーションが生成され、当該セットのスピーカの周囲を聴取者が移動することに対して知覚的によりロバストであるオーディオ信号の空間再生が実際に得られる。
この目的のために、コスト関数の第２の項、
、は、スピーカアクティベーションの二乗された絶対値の、距離で重みづけられた合計として定義され得る。これは、以下のように行列形式で簡潔に表される。

ここで、Ｄは、所望のオーディオ位置と各スピーカとの間の距離ペナルティの対角行列である。
距離ペナルティ関数は、多くの形式をとることができるが、以下が有用なパラメータ化である。

ここで、
は、所望のオーディオ位置とスピーカの位置との間のユークリッド距離であり、
および
は、チューナブルパラメータである。パラメータ
は、ペナルティのグローバルな強さを示す。
は、距離ペナルティの空間程度であり（約
の距離またはそれよりも遠い距離のラウドスピーカがペナルティを受けることになる）、
は、距離
におけるペナルティの発生の突発性（ａｂｒｕｐｔｎｅｓｓ）に相当する。
式８および９ａにおいて定義されたコスト関数の２つの項を組み合わせると、総コスト関数が生成される。
ｇについてのこのコスト関数の微分をゼロに等しいと設定し、ｇについて解くと、最適なスピーカアクティベーション解が得られる。
一般に、式１１における最適な解は、負の値を有するスピーカアクティベーションを生成し得る。フレキシブルレンダラのＣＭＡＰ構築に対して、そのような負のアクティベーションは、所望されない場合があり、したがって、式（１１）は、すべてのアクティベーションが正のままとなるように最小化され得る。
フレキシブルレンダリング方法（いくつかの実施形態にしたがって実装される）を１セットのワイヤレススマートスピーカ（または他のスマートオーディオデバイス）と対にすることによって、極めて能力が高く、使用しやすい空間オーディオレンダリングシステムを生成できる。そのようなシステムとのインタラクションを考慮すると、システムの使用時に生じ得る他の目的に対して最適化するために、空間レンダリングをダイナミックに変更することが所望され得ることが明らかとなる。この目標を達成するために、１クラスの実施形態は、レンダリングされているオーディオ信号の１つ以上のプロパティ、１セットのスピーカ、および／または他の外部入力に依存する１つ以上のさらなるダイナミック構成可能機能を用いて、既存のフレキシブルレンダリングアルゴリズム（スピーカアクティベーションが上記の空間および近傍度項の関数である）を拡張する。いくつかの実施形態にしたがって、式１において与えられる既存のフレキシブルレンダリングのコスト関数は、以下に係るこれらの１つ以上のさらなる依存性を用いて拡張される。
式１２において、項
は、さらなるコスト項を表す。ここで、
は、レンダリングされているオーディオ信号（例えば、オブジェクトベースのオーディオプログラムのオーディオ信号）の１セットの１つ以上のプロパティを表し、
は、オーディオがレンダリングされているスピーカの１セットの１つ以上のプロパティを表し、
は、１つ以上のさらなる外部入力を表す。各項
は、セット
によって包括的に表されたオーディオ信号、スピーカ、および／または外部入力の１つ以上のプロパティの組み合わせに対して、コストをアクティベーションｇの関数として返す。セット
は、少なくとも、
、
、または
のいずれかからのただ１つの要素を含むことが理解されるべきである。

の例は、以下を含むが、それらに限定されない：
●オーディオ信号の所望の知覚された空間位置、
●オーディオ信号のレベル（おそらく時間変化する）、および／または
●オーディオ信号のスペクトル（おそらく時間変化する）。

の例は、以下を含むが、それらに限定されない：
●聴取空間内のラウドスピーカの位置、
●ラウドスピーカの周波数応答、
●ラウドスピーカの再生レベル限度、
●リミッタゲインなどの、スピーカ内のダイナミックス処理アルゴリズムのパラメータ、
●各スピーカから他のスピーカへの音響伝達の測定値または推定値、
●スピーカ上でのエコーキャンセラ能力の尺度、および／または
●スピーカの互いに対する相対的な同期化。

の例は、以下を含むが、それらに限定されない：
●１人以上の聴取者または話者の再生空間内の位置、
●各ラウドスピーカから聴取位置への音響伝達の測定値または推定値、
●話者から１セットのラウドスピーカへの音響伝達の測定値または推定値、
●再生空間内のある他のランドマークの位置、および／または
●各スピーカから再生空間内のある他のランドマークへの音響伝達の測定値または推定値。
式１２において定義された新たなコスト関数を用いると、ｇならびに式２ａおよび２ｂに上述した可能な事後正規化に対する最小化を介して最適なセットのアクティベーションが見つけられ得る。
式９ａおよび９ｂにおいて定義された近傍度コストと同様に、また、新たなコスト関数項
のそれぞれをスピーカアクティベーションの二乗された絶対値の重みづけ合計として表現することが都合よい。

ここで、
は、項ｊに対してアクティベーティングスピーカｉに関連するコストを記述する重み
の対角行列である。
式１３ａおよび１３ｂを、式１０において与えられるＣＭＡＰおよびＦＶコスト関数を行列二次式で表したものと組み合わせることによって、式１２において与えられる一般拡張コスト関数（いくつかの実施形態のもの）の、有利となり得る実装例が生成される。
新たなコスト関数項のこの定義を用いると、総コスト関数は、行列二次式のままであり、最適なセットのアクティベーション
は、式１４の微分を介して、以下のように見つけることができる。
重み項
のそれぞれ１つを、ラウドスピーカのそれぞれ１つに対する所与の連続ペナルティ値
の関数として考えることが有用である。一例示の実施形態において、このペナルティ値は、オブジェクト（レンダリング対象）から注目のラウドスピーカへの距離である。別の例示の実施形態において、このペナルティ値は、所与のラウドスピーカがある周波数を再生することができないことを表す。このペナルティ値に基づいて、重み項
、以下のようにパラメータ化できる。

ここで、
は、プレファクタ（ｐｒｅ－ｆａｃｔｏｒ）（重み項のグローバルな強度を考慮する）を表し、
は、ペナルティ閾値（その近傍またはそれ以上で重み項が有意になる）を表し、
は、単調増加関数を表す。例えば、
の場合、重み項は、以下の形態を有する。

ここで、
、
、
は、それぞれペナルティのグローバルな強さ、ペナルティの発生の突発性、およびペナルティの程度を示すチューナブルパラメータである。これらのチューナブル値を設定する際には、コスト項
の、任意の他のさらなるコスト項ならびに
および
に対する相対的な効果が所望の結果を達成することに適切となるように注意すべきである。例えば、経験則として、特定のペナルティが明らかに他のペナルティを支配することが望まれる場合は、その強度
をその次に最も大きなペナルティ強度よりもおよそ１０倍大きく設定することが適切であ
り得る。
すべてのラウドスピーカがペナルティを受けた場合、そのスピーカのうちの少なくとも１つがペナルティを受けないように、後処理において最小限のペナルティをすべての重み項から引算することが好都合であることが多い。
上述したように、本明細書に記載された新たなコスト関数項（および他の実施形態にしたがって使用される、類似の新たなコスト関数項）を使用して実現できる多くの可能な使用事例がある。次に、３つの例を用いてより具体的な詳細を説明する。すなわち、オーディオを聴取者または話者へ移動させること、オーディオを聴取者または話者から遠ざけるように移動させること、およびオーディオをランドマークから遠ざけるように移動させることである。
第１の例において、本明細書において「引力」と呼ばれるものを使用して、オーディオをある位置の方へ引く。この位置は、いくつかの例において、聴取者または話者の位置、ランドマークの位置、家具の位置などであり得る。この位置は、本明細書において、「引力位置」または「引力源位置」と呼ばれ得る。本明細書において使用されるように、「引力」は、引力位置により近傍である、相対的により高いラウドスピーカアクティベーションにとって有利な（ｆａｖｏｒ）ファクタである。この例によると、重み
は、式１７の形式をとる。式１７において、
は、固定された引力源位置
からのｉ番目のスピーカの距離によって与えられる連続ペナルティ値であり、
は、すべてのスピーカにわたるこれらの距離の最大値によって与えられる閾値である。
オーディオを聴取者または話者の方へ「引く」ことの使用事例を例示するために、具体的に、
＝２０、
＝３、および
を１８０度の聴取者／話者位置に対応するベクトルに設定する。
、
、および
のこれらの値は、例にすぎない。他の実装例において、
は、１～１００の範囲内、
は、１～２５の範囲内であり得る。
第２の例において、「反発力」を使用して、オーディオをある位置から遠ざけるように「押す」。この位置は、聴取者の位置、話者の位置、またはランドマークの位置、家具の位置など別の位置であり得る。この位置は、本明細書において、「反発力位置」または「反発位置」と呼ばれ得る。本明細書において使用されるように、「反発力」は、反発力位置に対してより近傍の相対的により低いラウドスピーカアクティベーションにとって有利なファクタである。この例によると、式１９における引力と同様に、固定された反発位置
に対して
および
を定義する。

および
オーディオを聴取者または話者から遠ざけるように押すことの使用事例を例示するために、具体的に、
＝５、
＝２、および
を１８０度の聴取者／話者位置に対応するベクトルに設定する。
、
、および
のこれらの値は、例にすぎない。
ここで図１９に戻る。この例において、ブロック１９２５は、変更された第１のレンダリングされたオーディオ信号を生成するために、第２のオーディオ信号、第２のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更することを含む。レンダリング処理を変更することの様々な例が本明細書において開示される。レンダリングされた信号の「特性」は、例えば、無音で、または、１つ以上のさらなるレンダリングされた信号の存在下でのいずれかでもよいが、意図された聴取位置において推定または測定されたラウドネスまたは可聴を含み得る。特性の他の例は、関連するプログラムストリームの構成信号の意図された空間位置、信号がレンダリングされるラウドスピーカの位置、構成信号の意図された空間位置の関数としてのラウドスピーカの相対アクティベーション、および当該レンダリングされた信号を生成するために利用されるレンダリングアルゴリズムに関連する任意の他のパラメータまたは状態などの当該信号のレンダリングに関連するパラメータを含む。いくつかの例において、ブロック１９２５は、第１のレンダリングモジュールによって行われ得る。
この例によると、ブロック１９３０は、変更された第２のレンダリングされたオーディオ信号を生成するために、第１のオーディオ信号、第１のレンダリングされたオーディオ信号またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、第２のオーディオ信号に対してレンダリング処理を変更することを含む。いくつかの例において、ブロック１９３０は、第２のレンダリングモジュールによって行われ得る。
いくつかの実装例において、第１のオーディオ信号に対してレンダリング処理を変更することは、第２のレンダリングされたオーディオ信号のレンダリング位置から離れるように第１のオーディオ信号のレンダリングをワープすること、および／または、第２のオーディオ信号または第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。代替として、または、付加として、第２のオーディオ信号に対してレンダリング処理を変更することは、第１のレンダリングされたオーディオ信号のレンダリング位置から遠ざかるように第２のオーディオ信号のレンダリングをワープすること、および／または第１のオーディオ信号または第１のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスに応答して、第２のレンダリングされたオーディオ信号のうちの１つ以上の信号のラウドネスを変更することを含み得る。以下に、図３以降の図を参照して、いくつかの例を与える。
しかし、他のタイプのレンダリング処理変更も本開示の範囲内にある。例えば、いくつかの場合において、第１のオーディオ信号または第２のオーディオ信号に対してレンダリング処理を変更することは、スペクトル変更、可聴に基づく変更、またはダイナミックレンジ変更を行うこと含み得る。これらの変更は、特定の例に応じて、ラウドネスに基づくレンダリングに関係してもよいし、そうでなくてもよい。例えば、主な空間ストリームがオープンプランのリビングエリアにおいてレンダリングされ、料理のコツからなる副次的なストリームが隣接のキッチンにおいてレンダリングされる上記の場合において、料理の
コツがキッチンにおいて可聴のままであることを確実にすることが望ましくてもよい。これは、干渉する第１の信号がない場合にキッチン内のレンダリングされた料理のコツのストリームに対してラウドネスがどれくらいであるかを推定し、次いで、キッチン内に第１の信号が存在する場合のラウドネスを推定し、最後に複数の周波数にわたって両方のストリームのラウドネスおよびダイナミックレンジをダイナミックに変更して、キッチンにおいて、第２の信号の可聴を確実にすることによって、達成される。
図１９に示される例において、ブロック１９３５は、少なくとも、変更された第１のレンダリングされたオーディオ信号および変更された第２のレンダリングされたオーディオ信号をミキシングして、ミキシングされたオーディオ信号を生成することを含む。ブロック１９３５は、例えば、図１８Ｂに図示されたミキサ１８３０ｂによって行われ得る。
この例によると、ブロック１９４０は、ミキシングされたオーディオ信号を環境の少なくともいくつかのスピーカに与えることを含む。方法１９００のいくつかの例は、ミキシングされたオーディオ信号をスピーカによって再生することを含み得る。
図１９に図示するように、いくつかの実装例は、２つより多くのレンダリングモジュールを提供し得る。いくつかのそのような実装例は、Ｎ個のレンダリングモジュールを提供し得る。ここで、Ｎは、２よりも大きな整数である。したがって、いくつかのそのような実装例は、１つ以上のさらなるレンダリングモジュールを含み得る。いくつかのそのような例において、１つ以上のさらなるレンダリングモジュールのそれぞれは、インタフェースシステムを介して、さらなるオーディオプログラムストリームを受信するように構成され得る。さらなるオーディオプログラムストリームは、環境の少なくとも１つのスピーカによって再生されるように予定されたさらなるオーディオ信号を含み得る。いくつかのそのような実装例は、環境の少なくとも１つのスピーカを介して再生するためのさらなるオーディオ信号をレンダリングして、さらなるレンダリングされたオーディオ信号を生成することと、変更されたさらなるレンダリングされたオーディオ信号を生成するために、第１のオーディオ信号、第１のレンダリングされたオーディオ信号、第２のオーディオ信号、第２のレンダリングされたオーディオ信号、またはその特性のうちの少なくとも１つに少なくとも部分的に基づいて、さらなるオーディオ信号に対してレンダリング処理を変更することとを含み得る。いくつかのそのような例によると、ミキシングモジュールは、変更されたさらなるレンダリングされたオーディオ信号を、少なくとも、変更された第１のレンダリングされたオーディオ信号および変更された第２のレンダリングされたオーディオ信号を用いてミキシングして、ミキシングされたオーディオ信号を生成するように構成され得る。
図６および１８Ｂを参照して上述したように、いくつかの実装例は、聴取環境内に１つ以上のマイクロフォンを含むマイクロフォンシステムを含み得る。いくつかのそのような例において、第１のレンダリングモジュールは、マイクロフォンシステムからの第１のマイクロフォン信号に少なくとも部分的に基づいて、第１のオーディオ信号に対してレンダリング処理を変更するように構成され得る。「第１のマイクロフォン信号」は、特定の実装例に応じて、単一のマイクロフォンまたは２つ以上のマイクロフォンから受信され得る。いくつかのそのような実装例において、第２のレンダリングモジュールは、第１のマイクロフォン信号に少なくとも部分的に基づいて、第２のオーディオ信号に対してレンダリング処理を変更するように構成され得る。
図１８Ｂを参照して上述したように、いくつかの場合において、１つ以上のマイクロフォンの位置は、制御システムに対して知られてもよいし、与えられてもよい。いくつかのそのような実装例によると、制御システムは、第１のマイクロフォン信号に基づいて、第１の音源位置を推定し、そして、第１の音源位置に少なくとも部分的に基づいて、第１の
オーディオ信号または第２のオーディオ信号のうちの少なくとも一方に対してレンダリング処理を変更するように構成され得る。第１の音源位置は、例えば、既知の位置を有する３つ以上のマイクロフォンのそれぞれ、またはマイクロフォン群のそれぞれに基づき、三角測量処理にしたがって推定され得る。代替として、または、付加として、第１の音源位置は、２つ以上のマイクロフォンから受信した信号の振幅にしたがって推定され得る。最も高い振幅信号を生成するマイクロフォンは、第１の音源位置に最も近いと推測され得る。いくつかのそのような例において、第１の音源位置は、最も近いマイクロフォンの位置に設定され得る。いくつかのそのような例において、第１の音源位置は、ゾーンの位置に対応づけられ得る。ここで、ゾーンは、処理信号によって、２つ以上のマイクロフォンから、ガウシアンミキサモデルなどの予め学習された分類器を介して選択される。
いくつかのそのような実装例において、制御システムは、第１のマイクロフォン信号が環境ノイズに対応するかどうかを決定するように構成され得る。いくつかのそのような実装例は、第１のマイクロフォン信号が環境ノイズに対応するかどうかに少なくとも部分的に基づいて、第１のオーディオ信号または第２のオーディオ信号のうちの少なくとも一方に対してレンダリング処理を変更することを含み得る。例えば、制御システムが第１のマイクロフォン信号が環境ノイズに対応すると決定した場合、第１のオーディオ信号または第２のオーディオ信号に対してレンダリング処理を変更することは、意図された聴取位置においてノイズの存在下に知覚された信号のラウドネスが、ノイズが存在しない状態で知覚された信号のラウドネスに実質的に等しくなるように、レンダリングされたオーディオ信号のレベルを増大させることを含み得る。
いくつかの例において、制御システムは、第１のマイクロフォン信号が人間のボイスに対応するかどうかを決定するように構成され得る。いくつかのそのような実装例は、第１のマイクロフォン信号が人間のボイスに対応するかどうかに少なくとも部分的に基づいて、第１のオーディオ信号または第２のオーディオ信号のうちの少なくとも一方に対してレンダリング処理を変更することを含み得る。例えば、制御システムが第１のマイクロフォン信号がウェイクワードなどの人間のボイスに対応すると決定した場合、第１のオーディオ信号または第２のオーディオ信号に対してレンダリング処理を変更することは、第１の音源位置からより遠いスピーカによって再生された、レンダリングされたオーディオ信号のラウドネスと比較して、第１の音源位置に近いスピーカによって再生された、レンダリングされたオーディオ信号のラウドネスを低減することを含み得る。第１のオーディオ信号または第２のオーディオ信号に対してレンダリング処理を変更することは、代替として、または、付加として、関連するプログラムストリームの構成信号の意図された位置を第１の音源位置から遠ざけるようにワープするため、および／または、第１の音源位置からより遠いスピーカと比較して、第１の音源位置に近いスピーカの使用にペナルティを与えるためにレンダリング処理を変更することを含み得る。
いくつかの実装例において、制御システムが第１のマイクロフォン信号が人間のボイスに対応すると決定した場合、制御システムは、第１の音源位置と異なる環境の位置に近い１つ以上のスピーカにおいて第１のマイクロフォン信号を再生するように構成され得る。いくつかのそのような例において、制御システムは、第１のマイクロフォン信号が子供の泣き声に対応するかどうかを決定するように構成され得る。いくつかのそのような実装例によると、制御システムは、親、親戚、保護者、チャイルドケアサービスプロバイダ、教師、看護師などの介護者の推定された位置に対応するする環境の位置の近くの１つ以上のスピーカにおいて第１のマイクロフォン信号を再生するように構成され得る。いくつかの例において、介護者の推定された位置を推定する処理は、「＜ウェイクワード＞、乳児を起こさないで」などのボイスコマンドによって引き起こされ得る。制御システムは、３つ以上のローカルなマイクロフォンによって与えられるＤＯＡ情報などに基づく三角測量によって、バーチャルアシスタントを実装する最も近いスマートオーディオデバイスの位置
にしたがって、スピーカ（介護者）の位置を推定できるであろう。いくつかの実装例によると、制御システムは、乳児部屋の位置（および／または、その中の聴取デバイス）を事前に知っており、次いで適切な処理を行うことができるであろう。
いくつかのそのような例によると、制御システムは、第１のマイクロフォン信号がコマンドに対応するかどうかを決定するように構成され得る。制御システムが第１のマイクロフォン信号がコマンドに対応すると決定した場合、いくつかの場合において、制御システムは、コマンドに対する返答を決定し、第１の音源位置に近い少なくとも１つのスピーカが返答を再生するように制御するように構成され得る。いくつかのそのような例において、制御システムは、第１の音源位置に近い少なくとも１つのスピーカが返答を再生するように制御した後に、第１のオーディオ信号または第２のオーディオ信号に対して、変更されていないレンダリング処理に戻すように構成され得る。
いくつかの実装例において、制御システムは、コマンドを実行するように構成され得る。例えば、制御システムは、オーディオデバイス、テレビ、家電製品などをコマンドにしたがって制御するように構成されたバーチャルアシスタントであってもよいし、それを含んでもよい。
図６、１８Ａおよび１８Ｂに図示された最小限かつより能力の高いマルチストリームレンダリングシステムのこの定義の場合、多くの有用なシナリオに対して、複数のプログラムストリームの同期再生のダイナミックマネジメントが達成され得る。以下に、図２０および２１を参照して数例を説明する。
まず、リビングルームにおける空間映画サウンドトラックおよびリビングルームに続くキッチンにおける料理のコツを同期再生することを含む上記の例を検討する。空間映画サウンドトラックは、上記に参照した「第１のオーディオプログラムストリーム」の例であり、料理のコツのオーディオは、上記に参照した「第２のオーディオプログラムストリーム」の例である。図２０および２１は、ひと続きのリビング空間の間取り図の例を図示する。この例において、リビング空間２０００は、左上のリビングルーム、中下のキッチン、および右下の寝室を含む。リビング空間全体に分散されたボックスおよび円２００５ａ～２００５ｈは、当該空間に都合のよい位置に設置された１セットの８個のラウドスピーカを表すが、いずれの標準の所定レイアウトにも固執しない（任意に配置される）。図２０において、空間映画サウンドトラックだけが再生され、リビングルーム２０１０およびキッチン２０１５におけるすべてのラウドスピーカは、ラウドスピーカの能力およびレイアウトを考慮して、テレビ２０３０に向かってソファ２０２５に座った聴取者の周囲に、最適化された空間再生を生成するように利用される。映画サウンドトラックのこの最適な再生は、アクティブなラウドスピーカの範囲内に位置するクラウド２０３５ａによって、視覚的に表される。
図２１において、第２の聴取者２０２０ｂに対し、キッチン２０１５内の単一のラウドスピーカ２００５ｇを介して、料理のコツが同時にレンダリングおよび再生される。この第２のプログラムストリームの再生は、ラウドスピーカ２００５ｇから出たクラウド２１４０によって視覚的に表される。図２０に図示するように、これらの料理のコツが映画サウンドトラックのレンダリングを変更することなく、同時に再生された場合、キッチン２０１５内またはその近傍においてスピーカから出された映画サウンドトラックからのオーディオは、第２の聴取者の料理のコツを理解する能力を邪魔するであろう。その代わりに、この例において、空間映画サウンドトラックのレンダリングは、料理のコツのレンダリングの関数としてダイナミックに変更される。具体的に、映画サウンドトラックのレンダリングは、料理のコツのレンダリングの位置の近くのスピーカから遠ざかるようにシフトされる（キッチン２０１５）。このシフトは、図２１において、キッチンの近くのスピー
カから遠ざかるように押されたより小さなクラウド２０３５ｂによって視覚的に表される。映画サウンドトラックがまだ再生している間に料理のコツの再生が停止した場合、いくつかの実装例において、映画サウンドトラックのレンダリングは、図２０において見られた元の最適な構成に戻るようにダイナミックにシフトされ得る。空間映画サウンドトラックのレンダリングにおけるそのようなダイナミックシフトは、多くの開示された方法を介して達成され得る。
多くの空間オーディオミックスは、聴取空間内の特定の位置において再生されるように設計された複数の構成オーディオ信号を含む。例えば、Ｄｏｌｂｙ５．１および７．１サラウンドサウンドミックスは、聴取者の周囲の所定の正準な位置におけるスピーカ上で再生されるように意図された、それぞれ６および８個の信号からなる。オブジェクトに基づくオーディオフォーマット、例えば、ＤｏｌｂｙＡｔｍｏｓは、オーディオがレンダリングされるように意図された聴取空間においておそらくは時間変化する３Ｄ位置を記述する関連のメタデータを有する構成オーディオ信号からなる。空間映画サウンドトラックのレンダラが任意のセットのラウドスピーカに対して任意の位置において個別のオーディオ信号をレンダリングできると仮定すると、図２０および２１に図示されたレンダリングへのダイナミックシフトは、空間ミックス内のオーディオ信号の意図された位置をワープすることによって達成され得る。例えば、オーディオ信号に対応づけられた２Ｄまたは３Ｄ座標は、キッチン内のスピーカの位置から遠ざかるように押され得るか、または代替として、リビングルームの左上の隅に向かって引かれ得る。そのようなワープの結果は、ここで、空間ミックスのオーディオ信号のワープされた位置がこの位置からより遠くなるので、キッチンに近いスピーカの使用がより少なくなることである。この方法は、第２のオーディオストリームを第２の聴取者にとってより理解できるものにするという目標を達成するが、第１の聴取者に対して映画サウンドトラックの意図された空間バランスを著しく改変するという犠牲を払って、それがなされている。
空間レンダリングに対してダイナミックシフトを達成するための第２の方法は、フレキシブルレンダリングシステムを使用して実現され得る。いくつかのそのような実装例において、フレキシブルレンダリングシステムは、上記のように、ＣＭＡＰ、ＦＶまたはその両方のハイブリッドであり得る。いくつかのそのようなフレキシブルレンダリングシステムは、意図された位置から来ると知覚されるすべての構成信号を用いて空間ミックスを再生しようとする。ミックスの各信号に対してそうしながら、いくつかの例において、その信号の所望の位置に近傍のラウドスピーカのアクティベーションを優先する。いくつかの実装例において、レンダリングの最適化にさらなる項がダイナミックに付加され得る。さらなる項は、他の判断基準に基づいて所定のラウドスピーカの使用にペナルティを与える。ここでの例に対して、「反発力」と呼ばれ得るものがキッチンの位置においてダイナミックに設置され、この位置の近くのラウドスピーカの使用に対して高いペナルティを与え、空間映画サウンドトラックのレンダリングを遠ざけるように効果的に押し得る。本明細書において使用されるように、「反発力」という用語は、聴取環境の特定の位置またはエリア内の相対的により低いスピーカアクティベーションに対応するファクタを指し得る。換言すると、「反発力」という用語は、「反発力」に対応する特定の位置またはエリアから相対的により遠いスピーカのアクティベーションにとって有利なファクタを指し得る。しかし、いくつかのそのような実装例によると、レンダラは、残りの、与えられたペナルティがより小さいスピーカを用いてミックスの意図された空間バランスを再生することをなおも試み得る。したがって、この手法は、ミックスの構成信号の意図された位置を単純にワープする方法と比較して、レンダリングのダイナミックシフトを達成するための優れた方法と考えられ得る。
空間映画サウンドトラックのレンダリングをキッチン内の料理のコツから遠ざかるようにシフトさせる上記のシナリオは、図１８Ａに図示されたマルチストリームレンダラの最
小限バージョンを用いて達成され得る。しかし、このシナリオは、図１８Ｂに図示された、より能力の高いシステムを使用して改善され得る。空間映画サウンドトラックのレンダリングをシフトさせることは、キッチン内の料理のコツの理解可能性を向上させるが、映画サウンドトラックは、キッチン内でなおも顕著に可聴であり得る。両ストリームの瞬間的な状態にしたがって、料理のコツは、映画サウンドトラックによってマスキングされ得る。例えば、映画サウンドトラック内のラウドモーメント（ｌｏｕｄ ｍｏｍｅｎｔ）が料理のコツ内のソフトモーメント（ｓｏｆｔ ｍｏｍｅｎｔ）をマスキングする。この問題に対処するために、空間映画サウンドトラックのレンダリングの関数としての料理のコツのレンダリングに対するダイナミック変更が加えられ得る。例えば、干渉する信号の存在下に知覚されたラウドネスを保存するために、周波数および時間にわたってダイナミックにオーディオ信号を改変するための方法が行われ得る。このシナリオにおいて、キッチンの位置におけるシフトされた映画サウンドトラックの知覚されたラウドネスの推定値が生成され、干渉する信号としてそのような処理にフィードされ得る。次いで、料理のコツの時間および周波数で変動するレベルは、この干渉を超えて知覚されるラウドネスを維持するために、ダイナミックに変更され得る。これにより、第２の聴取者に対して理解可能性がより良く維持される。キッチンにおいて映画サウンドトラックのラウドネスに要求される推定値は、サウンドトラックのレンダリングのスピーカフィード、キッチン内またはその近くのマイクロフォンからの信号、またはそれらの組み合わせから生成され得る。料理のコツの知覚されたラウドネスを維持するこの処理は、一般に、料理のコツのレベルを高くすることになり、いくつかの場合においては、総ラウドネスが好ましくないほど高くなり得る可能性がある。この問題に対処するために、さらに別のレンダリング変更が採用され得る。干渉する空間映画サウンドトラックは、キッチン内で過度に大きくなる、ラウドネスが変更された料理のコツの関数として、ダイナミックに低減され得る。最後に、ある外部ノイズ源が両プログラムストリームの可聴に同時に干渉し得る可能性がある。例えば、キッチン内で料理中にブレンダが使用され得る。リビングルームおよびキッチンの両方においてのこの環境ノイズ源のラウドネスの推定値は、レンダリングシステムに接続されたマイクロフォンから生成され得る。この推定値は、例えば、料理のコツのラウドネス変更に影響を与えるために、キッチン内でのサウンドトラックのラウドネスの推定値に加えられ得る。同時に、リビングルーム内でのサウンドトラックのレンダリングは、この環境ノイズの存在下にリビングルーム内でのサウンドトラックの知覚されたラウドネスを維持するために、リビングルーム内で環境ノイズの推定値の関数としてさらに変更され得る。これにより、リビングルーム内の聴取者に対して、可聴性がより良く維持される。
開示されたマルチストリームレンダラのこの使用事例は、同期再生を最適化するために、２つのプログラムストリームに対して、多くの相互に関連した変更を使用することが分かる。まとめると、ストリームに対するこれらの変更は、以下のようなものを挙げることができる。
●空間映画サウンドトラック
〇キッチン内でレンダリングされている料理のコツの関数としての、キッチンから遠ざかるようにシフトされる空間レンダリング
〇キッチン内でレンダリングされる料理のコツのラウドネスの関数としての、ラウドネスのダイナミックな低減
〇キッチンからの干渉するブレンダノイズのリビングルームにおけるラウドネスの推定値の関数としての、ラウドネスのダイナミックな増大
●料理のコツ
〇キッチンにおける映画サウンドトラックおよびブレンダノイズの両方のラウドネスの組み合わせ推定値の関数としての、ラウドネスのダイナミックな増大
開示されたマルチストリームレンダラの第２の使用事例は、ユーザによるある問い合せに対してスマートボイスアシスタントが応答した状態で、音楽などの空間プログラムストリームを同期再生することを含む。再生が一般に単一のデバイスを介したモノラルまたはステレオ再生に拘束されてきた既存のスマートスピーカでは、ボイスアシスタントとの対話は、典型的には、以下の段階からなる。
１）音楽の再生
２）ユーザがボイスアシスタントウェイクワードを発声する
３）スマートスピーカがウェイクワードを認識し、そして音楽を有意な量だけ低減する（下げる）
４）ユーザがコマンドをスマートアシスタントに発声する（すなわち、「次の曲を再生して」）
５）スマートスピーカがコマンドを認識し、音量を下げられた音楽の上にミキシングされた何らかのボイス応答（すなわち、「ＯＫ、次の曲を再生します」）をスピーカ介して再生することによって、これを肯定し、次いで、コマンドを実行する
６）スマートスピーカは、音楽を元の音量に戻す
図２２および２３は、空間音楽ミックスおよびボイスアシスタント応答の同時再生を与えるマルチストリームレンダラの例を図示する。多数のオーケストレートされたスマートスピーカを介して空間オーディオを再生する際、いくつかの実施形態は、上記一連のイベントを改善する。具体的に、空間ミックスは、ボイスアシスタントからの応答を中継するために適切に選択されたスピーカのうちの１つ以上から遠ざかるようにシフトされ得る。ボイスアシスタント応答に対してこの空間を生成することは、上記に列挙した出来事の既存の状態と比較して、空間ミックスの低減がより小さくてもよいか、または、おそらくは一切低減しなくてもよいことを意味する。図２２および２３は、このシナリオを図示する。この例において、変更された一連のイベントは、以下のように生じ得る。
１）図２２におけるユーザクラウド２０３５ｃに対して、多数のオーケストレートされたスマートスピーカを介して、空間音楽プログラムストリームが再生されている。
２）ユーザ２０２０ｃがボイスアシスタントウェイクワードを発声する。
３）１つ以上のスマートスピーカ（例えば、スピーカ２００５ｄおよび／またはスピーカ２００５ｆ）がウェイクワードを認識し、そして、ユーザ２０２０ｃの位置、または、ユーザ２０２０ｃがどのスピーカ（単数または複数）に一番近いかを、１つ以上のスマートスピーカと連携するマイクロフォンからの関連する記録を使用して決定する。
４）空間音楽ミックスのレンダリングが、ボイスアシスタント応答プログラムストリームが前のステップで決定された位置の近くでレンダリングされると見越して、その位置から遠ざかるようにシフトされる（図２３におけるクラウド２０３５ｄ）。
５）ユーザは、コマンドをスマートアシスタントに対して発声する（例えば、スマートアシスタント／ボイスアシスタントソフトウェアを動作させるスマートスピーカ）。
６）スマートスピーカがコマンドを認識し、対応する応答プログラムストリームを合成し、そして、ユーザの位置の近くで応答をレンダリングする（図２３におけるクラウド２３４０）。
７）ボイスアシスタント応答が完了したら、空間音楽プログラムストリームのレンダリングは、元の状態に戻るようにシフトする（図２２におけるクラウド２０３５ｃ）。
空間音楽ミックスおよびボイスアシスタント応答の同期再生を最適化することに加えて、空間音楽ミックスをシフトすることもまた、１セットのスピーカがステップ５において聴取者を理解する能力を向上させ得る。なぜなら、音楽が聴取者の近くのスピーカから離れるようにシフトされているので、連携するマイクロフォンのボイス対その他の比が向上するからである。
空間映画ミックスおよび料理のコツを用いた上記シナリオについて記載されたことと同
様に、このシナリオは、ボイスアシスタント応答の関数として空間ミックスのレンダリングをシフトすることによって与えられるものよりもさらに最適化され得る。空間ミックスをシフトすることは、それ自体だけでは、ボイスアシスタント応答をユーザに完全に理解させるのに十分でないことがある。簡単な解決策は、やはり、空間ミックスを一定量だけ低減することであるが、出来事の現在の状態を用いて要求されるものよりも小さい。あるいは、ボイスアシスタント応答プログラムストリームのラウドネスは、応答の可聴を維持するために、空間音楽ミックスプログラムストリームのラウドネスの関数としてダイナミックに増大され得る。拡張として、空間音楽ミックスのラウドネスはまた、応答ストリームに対するこの増大処理が過度に大きくなった場合に、ダイナミックに削減され得る。
図２４、２５および２６は、開示されたマルチストリームレンダラに対する第３の使用事例を例示する。この例は、乳児が隣接する部屋で眠ったままにさせつつも乳児が泣いているかどうかを聞くことができるように試みながら、同時に、空間音楽ミックスプログラムストリームおよびコンフォートノイズプログラムストリームの同期再生を管理することを含む。図２４は、パーティにおける多くの人物に対して、空間音楽ミックス（クラウド２０３５ｅによって表される）がリビングルーム２０１０およびキッチン２０１５内のすべてのスピーカ上で最適に再生している開始点を図示する。図２５において、乳児２５１０は、現在、右下に図示された隣接の寝室２５０５において眠ろうとしている。これを確実にすることを支援するために、空間音楽ミックスは、クラウド２０３５ｆによって図示されるように、寝室への漏れを最小化するために、寝室から遠ざかるようにダイナミックにシフトされるとともに、パーティにおける人物に対しては適度な体験をなおも維持する。同時に、緩和ホワイトノイズを含む第２のプログラムストリーム（クラウド２５４０によって表される）が乳児の部屋内のスピーカ２００５ｈから再生され、隣接する部屋の音楽からのいずれの残余の漏れもマスキングされる。完全なマスクキングを確実にするために、このホワイトノイズストリームのラウドネスは、いくつかの例において、乳児の部屋に漏れ入る空間音楽のラウドネスの推定値の関数としてダイナミックに変更され得る。この推定値は、空間音楽のレンダリングのスピーカフィード、乳児の部屋内のマイクロフォンからの信号、またはそれらの組み合わせから生成され得る。また、空間音楽ミックスのラウドネスは、過度に大きくなった場合に、ラウドネスが変更されたノイズの関数として弱められ得る。これは、第１のシナリオの空間映画ミックスと料理のコツとの間のラウドネス処理に類似する。最後に、乳児の部屋内のマイクロフォン（例えば、スピーカ２００５ｈと連携するマイクロフォンであって、いくつかの実装例において、スマートスピーカでもよい）は、乳児からのオーディオ（空間音楽およびホワイトノイズおよびホワイトノイズから取り上げられ得る相殺音）を記録するように構成され得る。次いで、これらの処理されたマイクロフォン信号の組み合わせは、泣き声を検出した場合に（機械学習によって、パターンマッチングアルゴリズムを介して、など）、リビングルーム２０１０において、聴取者２０２０ｄ（親または他の介護者であり得る）の近くで同時に再生され得る第３のプログラムストリームとして機能し得る。図２６は、クラウド２６５０を用いて、このさらなるストリームの再生を図示する。この場合、空間音楽ミックスは、さらに、乳児の泣き声を再生する親の近くのスピーカから遠ざかるようにシフトされ得る。これは、図２５のクラウド２０３５ｆの形状に対して変更されたクラウド２０３５ｇの形状によって図示される。乳児の泣き声のプログラムストリームは、乳児の泣き声が聴取者２０２０ｄに対して可聴のままであるように、空間音楽ストリームの関数として、ラウドネス変更され得る。この例において検討された３つのプログラムストリームの同期再生を最適化する、相互に関係する変更は、以下のようにまとめられ得る。
●リビングルーム内の空間音楽ミックス
〇乳児の部屋への伝達を低減するために、当該部屋から遠ざかるようにシフトされた空間レンダリング
〇乳児の部屋内でレンダリングされたホワイトノイズのラウドネスの関数としてのラ
ウドネスのダイナミックな低減
〇親の近くのスピーカ上でレンダリングされている乳児の泣き声の関数としての、親から遠ざかるようにシフトされた空間レンダリング
●ホワイトノイズ
〇乳児の部屋へ漏れ入る音楽ストリームのラウドネスの推定値の関数としての、ラウドネスのダイナミックな増大
●乳児の泣き声の記録
〇親または他の介護者の位置における音楽ミックスのラウドネスの推定値の関数としての、ラウドネスのダイナミックな増大
次に、上記実施形態のうちのいくつかがどのように実装され得るかについての例を説明する。
図１８Ａにおいて、レンダラブロック１．．．Ｎのそれぞれは、上記のＣＭＡＰ、ＦＶまたはハイブリッドレンダラなどの任意の単一ストリームレンダラの同一例として実装され得る。このようにマルチストリームレンダラを構築することは、いくつかの便利かつ有用なプロパティを有する。
まず、この階層的な配置においてレンダリングがなされ、単一ストリームレンダラ例のそれぞれが周波数／変換ドメインにおいて動作するように構成される場合（例えば、ＱＭＦ）、ストリームのミキシングもまた周波数／変換ドメインにおいて生じることが可能であり、Ｍチャネルに対して、逆変換は、一度行われる必要があるだけである。これは、Ｎ×Ｍ回の逆変換を行い、時間ドメインにおいてミキシングを行うことよりも著しく効率が向上する。
図２７は、図１８Ａに図示されたマルチストリームレンダラの周波数／変換ドメイン例を図示する。この例において、直交ミラー分析フィルタバンク（ＱＭＦ）がプログラムストリーム１～Ｎのそれぞれに適用された後、各プログラムストリームがレンダリングモジュール１～Ｎの対応する１つによって受信される。この例によると、レンダリングモジュール１～Ｎは、周波数ドメインにおいて動作する。ミキサ１８３０ａがレンダリングモジュール１～Ｎの出力をミキシングした後、逆合成フィルタバンク２７３５ａが当該ミックスを時間ドメインに変換し、そして、時間ドメイン内のミキシングされたスピーカフィード信号をラウドスピーカ１～Ｍに与える。この例において、直交ミラーフィルタバンク、レンダリングモジュール１～Ｎ、ミキサ１８３０ａおよび逆フィルタバンク２７３５ａは、制御システム６１０ｃのコンポーネントである。
図２８は、図１８Ｂに図示されたマルチストリームレンダラの周波数／変換ドメイン例を図示する。図２７と同様に、直交ミラーフィルタバンク（ＱＭＦ）がプログラムストリーム１～Ｎのそれぞれに適用された後、各プログラムストリームがレンダリングモジュール１～Ｎの対応する１つによって受信される。この例によると、レンダリングモジュール１～Ｎは、周波数ドメインにおいて動作する。この実装例において、マイクロフォンシステム６２０ｂからの時間ドメインマイクロフォン信号がまた直交ミラーフィルタバンクに与えられ、レンダリングモジュール１～Ｎが周波数ドメインにおいてマイクロフォン信号を受信する。ミキサ１８３０ｂがレンダリングモジュール１～Ｎの出力をミキシングした後、逆フィルタバンク２７３５ｂが当該ミックスを時間ドメインに変換し、時間ドメイン内のミキシングされたスピーカフィード信号をラウドスピーカ１～Ｍに与える。この例において、直交ミラーフィルタバンク、レンダリングモジュール１～Ｎ、ミキサ１８３０ｂおよび逆フィルタバンク２７３５ｂは、制御システム６１０ｄのコンポーネントである。
図２９を参照し、別の例示の実施形態を説明する。本明細書中に与えられた他の図と同様に、図２９に図示された要素のタイプおよび数は、例として与えられたにすぎない。他の実装例は、より多くの、より少ないおよび／または異なるタイプおよび数の要素を含み得る。図２９は、この例においてリビング空間である聴取環境の間取り図を図示する。この例によると、環境２０００は、左上のリビングルーム２０１０、中下のキッチン２０１５、および右下の寝室２５０５を含む。リビング空間全体に分散されたボックスおよび円は、当該空間に都合のよい位置に設置された、いくつかの実装例における１セットのラウドスピーカ２００５ａ～２００５ｈを表すが、そのうちの少なくともいくつかは、いくつかの実装例においてスマートスピーカであってもよく、いずれの標準の所定レイアウトにも固執しない（任意に配置される）。いくつかの例において、ラウドスピーカ２００５ａ～２００５ｈは、１つ以上の開示された実施形態を実装するようにコーディネートされ得る。例えば、いくつかの実施形態において、ラウドスピーカ２００５ａ～２００５ｈは、いくつかの例においてＣＨＡＳＭであり得るオーディオセッションマネージャを実装しているデバイスからのコマンドにしたがってコーディネートされ得る。いくつかのそのような例において、上記に開示されたオーディオ処理は、上記に開示されたフレキシブルレンダリング機能を含むがそれに限定されず、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述されたＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１からの命令にしたがって、少なくとも部分的に、実装され得る。この例において、環境２０００は、環境全体に分散されたカメラ２９１１ａ～２９１１ｅを含む。いくつかの実装例において、また、環境２０００内の１つ以上のスマートオーディオデバイスが１つ以上のカメラを含み得る。１つ以上のスマートオーディオデバイスは、単一目的オーディオデバイスまたはボイスアシスタントであり得る。いくつかのそのような例において、１つ以上のカメラ（図６のオプションのセンサシステム６３０のカメラであり得る）がテレビ２０３０内または上、携帯電話内、または１つ以上のラウドスピーカ２００５ｂ、２００５ｄ、２００５ｅまたは２００５ｈのうちの１つ以上などのスマートスピーカ内に存在し得る。本開示に提示された聴取環境のすべての図にカメラ２９１１ａ～２９１１ｅが図示されているわけではないが、環境２０００を含むがそれらに限定されない聴取環境のそれぞれは、いくつかの実装例において、１つ以上のカメラを含み得る。
図３０、３１、３２および３３は、図２９に図示されたリビング空間内の複数の異なる聴取位置および向きに対して、基準空間モードにおいて、空間オーディオをフレキシブルにレンダリングする例を図示する。図３０～３３は、４つの聴取位置例におけるこの能力を図示する。各例において、人物３０２０ａの方向を指す矢印３００５は、フロントサウンドステージ（人物３０２０ａが向いている）の位置を表す。各例において、矢印３０１０ａは、左サラウンドフィールドを表し、矢印３０１０ｂは、右サラウンドフィールドを表す。
図３０において、リビングルームのソファ２０２５に座っている人物３０２０ａに対して、基準空間モードは、（例えば、オーディオセッションマネージャを実装しているデバイスによって）決定されており、空間オーディオは、フレキシブルにレンダリングされている。図３０に示される例において、ラウドスピーカ能力およびレイアウトを考慮し、リビングルーム２０１０およびキッチン２０１５内のラウドスピーカのすべてを使用して、聴取者３０２０ａの周囲に、オーディオデータの最適化された空間再生を生成する。この最適な再生は、アクティブなラウドスピーカの範囲内に存在するクラウド３０３５によって視覚的に表される。
いくつかの実装例によると、オーディオセッションマネージャ（図６の制御システム６１０など）を実装するように構成された制御システムは、図６のインタフェースシステム６０５などのインタフェースシステムを介して受信された基準空間モードデータにしたが
って、基準空間モードの推測された聴取位置および／または推測された向きを決定するように構成され得る。いくつかの例が後述される。いくつかのそのような例において、基準空間モードデータは、マイクロフォンシステム（図６のマイクロフォンシステム１２０など）からのマイクロフォンデータを含み得る。
いくつかのそのような例において、基準空間モードデータは、「［ウェイクワード］、テレビをフロントサウンドステージにして」などのウェイクワードおよびボイスコマンドに対応するマイクロフォンデータを含み得る。代替として、または、付加として、マイクロフォンデータを使用し、例えば、到来方向（ＤＯＡ）データを介して、ユーザのボイスの音にしたがってユーザの位置を三角測量し得る。例えば、ラウドスピーカ２００５ａ～２００５ｅのうちの３つ以上がマイクロフォンデータを使用し、ＤＯＡデータを介して、人物３０２０ａのボイスの音にしたがって、リビングルームのソファ２０２５に座っている人物３０２０ａの位置を三角測量し得る。人物３０２０ａの位置にしたがって、人物３０２０ａの向きが推測され得る。人物３０２０ａが図３０に図示された位置にいる場合、人物３０２０ａは、テレビ２０３０の方を向いていると推測され得る。
代替として、または、付加として、人物３０２０ａの位置および向きは、カメラシステム（図６のセンサシステム１３０など）からの画像データにしたがって決定され得る。
いくつかの例において、人物３０２０ａの位置および向きは、グラフィカルユーザインタフェース（ＧＵＩ）を介して得られたユーザ入力にしたがって決定され得る。いくつかのそのような例によると、制御システムは、人物３０２０ａが人物３０２０ａの位置および向きを入力できるようにするＧＵＩを提示するようにディスプレイデバイス（例えば、携帯電話のディスプレイデバイス）を制御するように構成され得る。
図３１において、リビングルームの読書用椅子３１１５に座っている人物３０２０ａに対して、基準空間モードが決定されており、空間オーディオがフレキシブルにレンダリングされている。図３２において、キッチンカウンター３３０の隣に立っている人物３０２０ａに対して、基準空間モードが決定されており、空間オーディオがフレキシブルにレンダリングされている。図３３において、朝食用テーブル３４０に座っている人物３０２０に対して、基準空間モードが決定されており、空間オーディオがフレキシブルにレンダリングされている。矢印３００５によって示されるように、フロントサウンドステージの向きが必ずしも環境２０００内のいずれかの特定のラウドスピーカに対応するわけではないことが見て取れ得る。聴取者の位置および向きが変化すると、空間ミックスの様々な成分をレンダリングするスピーカの役割も変化する。
図３０～３３のいずれにおいても、人物３０２０ａは、図示の位置および向きのそれぞれに対して意図された空間ミックスを聞く。しかし、体験は、空間内のさらなる聴取者にとっては準最適であり得る。図３４は、２人の聴取者が聴取環境の異なる位置にいる場合の基準空間モードレンダリングの例を図示する。図３４は、ソファ上の人物３０２０ａおよびキッチンに立っている人物３０２０ｂに対する基準空間モードレンダリングを図示する。レンダリングは、人物３０２０ａに対しては最適であるが、人物３０２０ｂは、その人物の位置を考慮すると、主にサラウンドフィールドからの信号が聞こえるが、フロントサウンドステージの信号はほとんど聞こえないことになる。この場合、および複数の人物が空間内で予測できない動き回り方をするその他の場合（例えば、パーティ）、そのような分散した聴衆に対してより適切なレンダリングモードが必要である。そのような分散空間レンダリングモードの例が２０２０年６月２３日付け出願の米国仮特許出願第６２／７０５，３５１号（発明の名称：「ＡＤＡＰＴＡＢＬＥ ＳＰＡＴＩＡＬ ＡＵＤＩＯ ＰＬＡＹＢＡＣＫ」）の２７～４３頁の図４Ｂ～９を参照して記載されており、当該出願を本願に援用する。
図３５は、聴取者の位置および向きに関するユーザ入力を受け取るためのＧＵＩの例を図示する。この例によると、ユーザは、いくつかの可能な聴取位置および対応の向きを予め特定している。各位置および対応の向きに対応するラウドスピーカの位置は、既にセットアップ処理中に入力および格納されている。いくつかの例を本明細書において開示する。オーディオデバイス自動位置処理の詳細な例を以下に説明する。例えば、聴取環境レイアウトＧＵＩが提供されていてもよく、ユーザが可能な聴取位置およびスピーカの位置に対応する位置をタッチするように促されていてもよく、また、可能な聴取位置の名前を言うように促されていてもよい。この例において、図３５に図示された時間において、ユーザは、仮想ボタン「リビングルームのソファ」をタッチすることによって、ユーザの位置に関するＧＵＩ３５００に既にユーザ入力を与えていてもよい。Ｌ字形状のソファ２０２５を考慮すると、２つの可能な前向きの位置があるので、ユーザは、どちらの方向を向いているかを示すように促されている。
図３６は、ある環境内の３つのオーディオデバイス間の幾何学的関係の例を図示する。この例において、環境３６００は、テレビ３６０１、ソファ３６０３および５つのオーディオデバイス３６０５を含む部屋である。この例によると、オーディオデバイス３６０５は、環境３６００の位置１～５内にある。この実装例において、オーディオデバイス３６０５のそれぞれは、少なくとも３つのマイクロフォンを有するマイクロフォンシステム３６２０と、少なくとも１つのスピーカを含むスピーカシステム３６２５とを含む。いくつかの実装例において、各マイクロフォンシステム３６２０は、１配列のマイクロフォンを含む。いくつかの実装例によると、オーディオデバイス３６０５のそれぞれは、少なくとも３つのアンテナを含むアンテナシステムを含み得る。
本明細書において開示された他の例と同様に、図３６に図示された要素のタイプ、数および配置は、例にすぎない。他の実装例は、例えば、より多くのまたはより少ないオーディオデバイス３６０５、異なる位置におけるオーディオデバイス３６０５などの異なるタイプ、数および配置の要素を有し得る。
この例において、三角形３６１０ａは、位置１、２および３において頂点を有する。ここで、三角形３６１０ａは、辺１２、２３ａおよび１３ａを有する。この例によると、辺１２および２３間の角度は、
であり、辺１２および１３ａ間の角度は、
であり、辺２３ａおよび１３ａ間の角度は、
である。これらの角度は、さらなる詳細は後述するが、ＤＯＡデータにしたがって決定され得る。
いくつかの実装例において、三角形の辺の相対的な長さだけが決定され得る。代替の実装例において、三角形の辺の実際の長さが推定され得る。いくつかのそのような実装例によると、三角形の辺の実際の長さは、ＴＯＡデータにしたがって、例えば、ある三角形の頂点に位置するオーディオデバイスによって生成され、そして別の三角形の頂点に位置するオーディオデバイスによって検出された音の到着時間にしたがって推定され得る。代替として、または、付加として、三角形の辺の長さは、ある三角形の頂点に位置するオーディオデバイスによって生成され、そして別の三角形の頂点に位置するオーディオデバイスによって検出された電磁波にしたがって推定され得る。例えば、三角形の辺の長さは、ある三角形の頂点に位置するオーディオデバイスによって生成され、そして別の三角形の頂点に位置するオーディオデバイスによって検出された電磁波の信号強度にしたがって推定
され得る。いくつかの実装例において、三角形の辺の長さは、検出された電磁波の位相シフトにしたがって推定され得る。
図３７は、図３６に図示された環境内の３つのオーディオデバイス間の幾何学的関係の別の例を図示する。この例において、三角形３６１０ｂは、位置１、３および４において頂点を有する。ここで、三角形３６１０ｂは、辺１３ｂ、１４および３４ａを有する。この例によると、辺１３ｂおよび１４間の角度は、
であり、辺１３ｂおよび３４ａ間の角度は、
であり、辺３４ａおよび１４間の角度は、
である。
図３６および３７を比較することによって、三角形３６１０ａの辺１３ａの長さが三角形３６１０ｂの辺１３ｂの長さに等しくあるべきであることが見て取れ得る。いくつかの実装例において、ある三角形（例えば、三角形３６１０ａ）の辺の長さが正しいと仮定されてもよく、隣接する三角形によって共有される辺の長さがこの長さに拘束されることになる。
図３８は、図３６および３７に図示された三角形の両方を図示するが、対応するオーディオデバイスおよび環境のその他の備品を省略する。図３８は、三角形３６１０ａおよび３６１０ｂの辺の長さおよび角の向きの推定値を図示する。図３８に示される例において、三角形３６１０ｂの辺１３ｂの長さは、三角形３６１０ａの辺１３ａと同じ長さに拘束される。三角形３６１０ｂの他の辺の長さは、辺１３ｂの長さの得られた変化に比例して拡縮される。得られた三角形３６１０ｂ’を図３８に図示する。三角形３６１０ｂ’は、三角形３６１０ａに隣接する。
いくつかの実装例によると、三角形３６１０ａおよび３６１０ｂに隣接する他の三角形の辺の長さは、環境３６００内のオーディオデバイスの位置のすべてが決定されるまで、すべて同様に決定され得る。
オーディオデバイスの位置のいくつかの例は、以下のように進行し得る。各オーディオデバイスは、環境（例えば、部屋）内のすべての他のオーディオデバイスによって生成された音に基づいて、環境内のすべての他のオーディオデバイスのＤＯＡを報告し得る（例えば、ＣＨＡＳＭなどのオーディオセッションマネージャを実装しているデバイスからの命令にしたがって）。ｉ番目のオーディオデバイスのデカルト座標は、
として表現され得る。ここで、上付き添え字Ｔは、ベクトル転置を示す。環境内にＭ個のオーディオデバイスがあるとすると、
である。
図３９は、３つのオーディオデバイスによって形成される三角形の内角を推定する例を図示する。この例において、オーディオデバイスは、ｉ、ｊおよびｋである。デバイスｉから観測される、デバイスｊから出た音源のＤＯＡは、
として表現され得る。デバイスｉから観測される、デバイスｋから出た音源のＤＯＡは、
として表現され得る。図３９に示される例において、
および
は、軸３９０５ａから測定される。軸３９０５ａの向きは、任意であり、例えば、オーディオデバイスｉの向きに対応し得る。三角形３９１０の内角ａは、
として表現され得る。内角ａの計算が軸３９０５ａの向きに依存しないことが見て取れ得る。
図３９に示される例において、
および
は、軸３９０５ｂから測定される。軸３９０５ｂの向きは、任意であり、例えば、オーディオデバイスｊの向きに対応し得る。三角形３９１０の内角ｂは、
として表現され得る。同様に、この例において、
および
は、軸３９０５ｃから測定される。三角形３９１０の内角ｃは、
として表現され得る。
測定誤差が存在すると、
である。例えば、以下のように、各角度を他の２つの角度から予測し、そして平均することによって、ロバストネスを向上できる。
いくつかの実装例において、エッジの長さ
は、正弦法則を適用することによって、計算され得る（最大でスケーリングエラー）。いくつかの例において、あるエッジの長さに１などの任意の値が割り当てられ得る。例えば、
とし、そしてベクトル
を原点に置くことによって、残りの２つの頂点の位置は、以下のように計算され得る。
しかし、任意の回転が許容され得る。
いくつかの実装例によると、三角形パラメータ化の処理は、サイズ
のスーパーセット（ｓｕｐｅｒｓｅｔ）
において列挙される、環境内の３つのオーディオデバイスのすべての可能なサブセットに対して繰り返され得る。いくつかの例において、
は、ｌ番目の三角形を表し得る。実装例によるが、三角形は、特定の順序で列挙されなくてもよい。三角形は、ＤＯＡおよび／または辺の長さの推定値の可能な誤差によって、重なり合ってもよく、完全にアライメント（ａｌｉｇｎ）しなくてもよい。
図４０は、図６に図示されるような装置によって行われ得る方法の一例の概要を示すフロー図である。方法４０００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。さらに、そのような方法は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。この実装例において、方法４０００は、環境内のスピーカの位置を推定することを含む。方法４０００のブロックは、図６に図示された装置６００であり得る（または、それを含み得る）１つ以上のデバイスによって行われ得る。いくつかの実装例によると、方法４０００のブロックは、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）を実装するデバイスによって、および／または、オーディオセッションマネージャを実装するデバイスからの命令にしたがって、少なくとも部分的に、行われ得る。いくつかのそのような例において、方法４０００のブロックは、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１によって、少なくとも部分的に、行われ得る。いくつかの実装例によると、方法４０００のブロックは、図１５を参照して上述した方法１５００のセットアップ処理の一部として行われ得る。
この例において、ブロック４００５は、複数のオーディオデバイスの各オーディオデバイスに対して到来方向（ＤＯＡ）データを取得することを含む。いくつかの例において、複数のオーディオデバイスは、図３６に図示されたすべてのオーディオデバイス３６０５などの環境内のすべてのオーディオデバイスを含み得る。
しかし、いくつかの場合において、複数のオーディオデバイスは、環境内のすべてのオーディオデバイスのうちの１サブセットだけを含み得る。例えば、複数のオーディオデバイスは、環境内のすべてのスマートスピーカを含んでもよいが、環境内の他のオーディオデバイスのうちの１つ以上を含まなくてもよい。
ＤＯＡデータは、特定の実装例に応じて、様々な方法で取得され得る。いくつかの場合において、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの少なくとも１つのオーディオデバイスに対してＤＯＡデータを決定することを含み得る。例えば、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの単一のオーディオデバイスに対応する複数のオーディオデバイスマイクロフォンのうちの各マイクロフォンからマイクロフォンデータを受信し、そして単一のオーディオデバイスに対して、マイクロフォンデータに少なくとも部分的に基づいて、ＤＯＡデータを決定することを含み得る。代替として、または、付加として、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの単一のオーディオデバイスの１つ以上のアンテナからアンテナデータを受信して、そして単一のオーディオデバイスに対して、アンテナデータに少なくとも部分的に基づいて、ＤＯＡデータを決定することを含み得る。
いくつかのそのような例において、単一のオーディオデバイス自体は、ＤＯＡデータを決定し得る。いくつかのそのような実装例によると、複数のオーディオデバイスのうちの各オーディオデバイスが、自身のＤＯＡデータを決定し得る。しかし、他の実装例において、ローカルまたはリモートデバイスであり得る別のデバイスが環境内の１つ以上のオー
ディオデバイスに対してＤＯＡデータを決定し得る。いくつかの実装例によると、サーバが環境内の１つ以上のオーディオデバイスに対してＤＯＡデータを決定し得る。
この例によると、ブロック４０１０は、ＤＯＡデータに基づいて、複数の三角形のそれぞれに対して内角を決定することを含む。この例において、複数の三角形のうちの各三角形は、オーディオデバイスのうちの３つのオーディオデバイスの位置に対応する頂点を有する。いくつかのそのような例を上述した。
図４１は、ある環境内の各オーディオデバイスが複数の三角形の頂点である例を図示する。各三角形の辺は、オーディオデバイス３６０５のうちの２つの間の距離に対応する。
この実装例において、ブロック４０１５は、各三角形の各辺に対して辺の長さを決定することを含む（三角形の辺はまた、本明細書において「エッジ」とも呼ばれ得る）この例によると、辺の長さは、内角に少なくとも部分的に基づく。いくつかの場合において、辺の長さは、三角形の第１の辺の第１の長さを決定し、そして三角形の内角に基づいて三角形の第２の辺および第３の辺の長さを決定することによって計算され得る。いくつかのそのような例を上述した。
いくつかのそのような実装例によると、第１の長さを決定することは、第１の長さを所定の値に設定することを含み得る。しかし、第１の長さを決定することは、いくつかの例において、到着時間データおよび／または受信された信号強度データに基づき得る。到着時間データおよび／または受信された信号強度データは、いくつかの実装例において、環境内の第２のオーディオデバイスによって検出される環境内の第１のオーディオデバイスからの音波に対応し得る。代替として、または、付加として、到着時間データおよび／または受信された信号強度データは、境内の第２のオーディオデバイスによって検出される環境内の第１のオーディオデバイスからの電磁波（例えば、電波、赤外波など）に対応し得る。
この例によると、ブロック４０２０は、複数の三角形のうちのそれぞれを第１のシーケンスにアライメントするフォーワードアラインメント処理を行うことを含む。この例によると、フォーワードアラインメント処理は、フォーワードアラインメント行列を生成する。
いくつかのそのような例によると、三角形は、例えば、図３８に図示され、上述したように、エッジ
が近傍のエッジに等しくなるようにアラインメントすることが期待される。
をサイズ
であるすべてのエッジの集合とする。いくつかのそのような実装例において、ブロック４０２０は、
にわたりトラバース（ｔｒａｖｅｒｓｅ）し、エッジを前にアラインメントされたエッジに一致させることによって、三角形の共通のエッジを前向きの順序（ｆｏｒｗａｒｄ ｏｒｄｅｒ）でアラインメントさせることを含み得る。
図４２は、フォーワードアラインメント処理の一部の例を与える。図４２において太字で示された数字１～５は、図３６、３７および４１に図示されたオーディオデバイスの位
置に対応する。図４２に図示され、本明細書に記載されたフォーワードアラインメント処理のシーケンスは、例に過ぎない。
この例において、図３８に図示するように、三角形３６１０ｂの辺１３ｂの長さは、三角形３６１０ａの辺１３ａの長さに一致するようにされる。得られた三角形３６１０ｂ’を図４２に図示する。ここで、内角は、同じままである。この例によると、三角形３６１０ｃの辺１３ｃの長さはまた、三角形３６１０ａの辺１３ａの長さに一致するようにされる。得られた三角形３６１０ｃ’を図４２に図示する。ここで、内角は、同じままである。
次に、この例において、三角形３６１０ｄの辺３４ｂの長さは、三角形３６１０ｂ’の辺３４ａの長さに一致するようにされる。さらに、この例において、三角形３６１０ｄの辺２３ｂの長さは、三角形３６１０ａの辺２３ａの長さに一致するようにされる。得られた三角形３６１０ｄ’を図４２に図示する。ここで、内角は、同じままである。いくつかのそのような例によると、図４１に図示された残りの三角形も三角形３６１０ｂ、３６１０ｃおよび３６１０ｄと同じように処理され得る。
フォーワードアラインメント処理の結果は、データ構造内に格納され得る。いくつかのそのような例によると、フォーワードアラインメント処理の結果は、フォーワードアラインメント行列内に格納され得る。例えば、フォーワードアラインメント処理の結果は、行列
内に格納され得る。ここで、Ｎは、三角形の総数を示す。
ＤＯＡデータおよび／または初期の辺の長さの決定された値が誤差を含むと、オーディオデバイスの位置の推定値が複数生じることになる。誤差は、一般にフォーワードアラインメント処理中に増大することになる。
図４３は、フォーワードアラインメント処理中に生じたオーディオデバイスの位置の複数の推定値の例を図示する。この例において、フォーワードアラインメント処理は、７つのオーディオデバイスの位置を頂点として有する三角形に基づく。ここで、三角形は、ＤＯＡの推定値における加法誤差（ａｄｄｉｔｉｖｅ ｅｒｒｏｒ）によって、完全にはアラインメントしない。図４３に図示された数字１～７の位置は、フォーワードアラインメント処理によって生成された、オーディオデバイスの推定位置に対応する。この例において、「１」と標識されたオーディオデバイスの位置推定値は、一致するが、オーディオデバイス６および７に対するオーディオデバイスの位置推定値は、数字６および７が位置する相対的により大きなエリアによって示されるように、より大きな差を示す。
図４０に戻る。この例において、ブロック４０２５は、複数の三角形のうちのそれぞれを第１のシーケンスの反転である第２のシーケンスにアラインメントさせるリバースアラインメント処理を含む。いくつかの実装例によると、リバースアラインメント処理は、前と同様に、
にわたってトラバースするが、逆の順序で行うことを含み得る。代替の例において、リバースアラインメント処理は、フォーワードアラインメント処理の動作のシーケンスの正確な反転でなくてもよい。この例によると、リバースアラインメント処理は、本明細書において
と表され得るリバースアラインメント行列を生成する。
図４４は、リバースアラインメント処理の一部の例を与える。図４４において太字で示された数字１～５は、図３６、３７および４１に図示されたオーディオデバイスの位置に対応する。図４４に図示され、本明細書に記載されたリバースアラインメント処理のシーケンスは、例に過ぎない。
図４４に示される例において、三角形３６１０ｅは、オーディオデバイスの位置３、４および５に基づく。この実装例において、三角形３６１０ｅの辺の長さ（または「エッジ」）は、正しいと仮定され、隣接する三角形の辺の長さは、それらに一致するようにされる。この例によると、三角形３６１０ｆの辺４５ｂの長さは、三角形３６１０ｅの辺４５ａの長さに一致するようにされる。得られた三角形３６１０ｆ’を図４４に図示する。内角は、同じままである。この例において、三角形３６１０ｃの辺３５ｂの長さは、三角形３６１０ｅの辺３５ａの長さに一致するようにされる。得られた三角形３６１０ｃ’’を図４４に図示する。内角は、同じままである。いくつかのそのような例によると、図５に図示された残りの三角形は、リバースアラインメント処理がすべての残りの三角形を含むまで、三角形３６１０ｃおよび３６１０ｆと同じように処理され得る。
図４５は、リバースアラインメント処理中に生じたオーディオデバイスの位置の複数の推定値を図示する。この例において、リバースアラインメント処理は、図４３を参照して上述した頂点と同じ７つのオーディオデバイスの位置を有する三角形に基づく。図４５に図示された数字１～７の位置は、リバースアラインメント処理によって生成されたオーディオデバイスの推定位置に対応する。ここで、やはり、三角形は、ＤＯＡの推定値における加法誤差によって、完全にはアラインメントしない。この例において、６および７と標識されたオーディオデバイスの位置の推定値は、一致するが、オーディオデバイス１および２に対するオーディオデバイスの位置の推定値は、より大きな差を示す。
図４０に戻る。ブロック４０３０は、フォーワードアラインメント行列の値およびリバースアラインメント行列の値に少なくとも部分的に基づいて、各オーディオデバイスの位置の最終の推定値を生成することを含む。いくつかの例において、各オーディオデバイスの位置の最終の推定値を生成することは、フォーワードアラインメント行列を平行移動および拡大縮小して、平行移動および拡大縮小されたフォーワードアラインメント行列を生成することと、リバースアラインメント行列を平行移動および拡大縮小して、平行移動および拡大縮小されたリバースアラインメント行列を生成することとを含み得る。
例えば、平行移動および拡大縮小することは、重心を原点に移動させ、単位をフロベニウスノルムにすること、例えば、
および
、によって固定される。
いくつかのそのような例によると、各オーディオデバイスの位置の最終の推定値を生成することはまた、平行移動および拡大縮小されたフォーワードアラインメント行列ならびに平行移動および拡大縮小されたリバースアラインメント行列に基づいて回転行列を生成することを含み得る。回転行列は、各オーディオデバイスに対して、複数の推定されたオーディオデバイスの位置を含み得る。フォーワードおよびリバースアラインメント間の最適な回転は、例えば、特異値分解によって見出すことができる。いくつかのそのような例において、回転行列を生成することは、例えば以下のように、平行移動および拡大縮小されたフォーワードアラインメント行列ならびに平行移動および拡大縮小されたリバースア
ラインメント行列に対して特異値分解を行うことを含み得る。
上記の式において、ＵおよびＶは、それぞれ行列
の左特異ベクトルおよび右特異ベクトルを表す。
は、特異値の行列を表す。上記の式は、回転行列
を生成する。行列の積
は、
とアラインメントさせるように
が最適に回転されるような回転行列を生成する。
いくつかの例によると、回転行列
を決定した後、アラインメントは、例えば以下のように平均化され得る。
いくつかの実装例において、各オーディオデバイスの位置の最終の推定値を生成することはまた、各オーディオデバイスに対してオーディオデバイスの推定位置を平均化して、各オーディオデバイスの位置の最終の推定値を平均化することを含み得る。様々な開示された実装例は、ＤＯＡデータおよび／または他の計算が著しい誤差を含む場合でさえ、ロバストであることを実証している。例えば、
は、複数の三角形からの頂点が重複するので、同じノードの
個の推定値を含む。共通のノードにわたって平均化することで、最終の推定値
が生成される。
図４６は、オーディオデバイスの推定位置およびオーディオデバイスの実際の位置の比較を図示する。図４６に図示の例において、オーディオデバイスの位置は、図４３および４５を参照して上述したフォーワードおよびリバースアラインメント処理中に推定された位置に対応する。これらの例において、ＤＯＡの推定における誤差は、１５度の標準偏差を有した。しかしながら、各オーディオデバイスの位置の最終の推定値（それぞれは、図４６において「ｘ」によって表される）は、オーディオデバイスの実際の位置によく対応する（それぞれは、図４６において円によって表される）。
上記の記載のほとんどは、オーディオデバイス自動位置に関する。後述の議論は、上記に簡単に記載した、聴取者の位置および聴取者の角度向きを決定するいくつかの方法を拡張する。上記の記載において、「回転」という用語は、以下の記載において使用される「
向き」という用語と本質的に同じように使用される。例えば、上記に参照した「回転」は、最終のスピーカ幾何形状のグローバルな回転を指し得るが、図４０以降の図を参照して上述した処理中の個別の三角形の回転ではない。このグローバルな回転または向きは、聴取者の角度向きを参照して、例えば、聴取者が見ている方向によって、聴取者の鼻が指す方向によって、などで解かれ得る。
聴取者の位置を推定するための様々な満足のゆく方法を以下に説明する。しかし、聴取者の角度向きを推定することは、困難である可能性がある。いくつかの関連方法の詳細を以下に説明する。
聴取者の位置および聴取者の角度向きを決定することは、位置が特定されたオーディオデバイスの聴取者に対する方向を特定するなどのいくつかの所望の特徴を可能にできる。聴取者の位置および角度向きを知ることによって、例えば、聴取者に対して、環境内のどのスピーカが前にあり得るか、どれが後ろにあるか、どれが中心（それがあった場合）の近くにあるかなどを決定することが可能になる。
オーディオデバイスの位置と聴取者の位置および向きとの相関をとった後、いくつかの実装例は、オーディオデバイス位置データ、オーディオデバイス角度向きデータ、聴取者位置データおよび聴取者角度向きデータをオーディオレンダリングシステムに与えることを含み得る。代替として、または、付加として、いくつかの実装例は、オーディオデバイス位置データ、オーディオデバイス角度向きデータ、聴取者位置データおよび聴取者角度向きデータに少なくとも部分的に基づくオーディオデータレンダリング処理を含み得る。
図４７は、図６に図示されるような装置によって行われ得る方法の一例の概要を示すフロー図である。方法４７００のブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。さらに、そのような方法は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。この例において、方法４７００のブロックは、図６に図示された制御システム６１０であり得る（または、それを含み得る）制御システムによって行われる。上述したように、いくつかの実装例において、制御システム６１０は、単一のデバイス内に存在し得るが、他の実装例において、制御システム６１０は、２つ以上のデバイス内に存在し得る。いくつかの実装例によると、方法４７００のブロックは、オーディオセッションマネージャ（例えば、ＣＨＡＳＭ）を実装するデバイスによっておよび／またはオーディオセッションマネージャを実装するデバイスからの命令にしたがって、少なくとも部分的に、行われ得る。いくつかのそのような例において、方法４７００のブロックは、図２Ｃ、２Ｄ、３Ｃおよび４を参照して上述したＣＨＡＳＭ２０８Ｃ、ＣＨＡＳＭ２０８Ｄ、ＣＨＡＳＭ３０７および／またはＣＨＡＳＭ４０１によって、少なくとも部分的に、行われ得る。いくつかの実装例によると、方法４７００のブロックは、例えば、第１の人物の第１の位置および第１の向きを決定すること、第１の人物の第２の位置または第２の向きのうちの少なくとも一方を決定することなどの、図１２を参照して上述した方法１２００の処理の一部として行われ得る。
この例において、ブロック４７０５は、環境内の複数のオーディオデバイスの各オーディオデバイスについて到来方向（ＤＯＡ）データを取得することを含む。いくつかの例において、複数のオーディオデバイスは、図３６に図示されたすべてのオーディオデバイス３６０５などの環境内のすべてのオーディオデバイスを含み得る。
しかし、いくつかの場合において、複数のオーディオデバイスは、環境内のすべてのオーディオデバイスの１サブセットだけを含み得る。例えば、複数のオーディオデバイスは、環境内のすべてのスマートスピーカを含んでもよいが、環境内の他のオーディオデバイスのうちの１つ以上を含まなくてもよい。
ＤＯＡデータは、特定の実装例に応じて、様々な方法で取得され得る。いくつかの場合において、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの少なくとも１つのオーディオデバイスについてＤＯＡデータを決定することを含み得る。いくつかの例において、ＤＯＡデータは、環境内の複数のラウドスピーカのうちの各ラウドスピーカがテスト信号を再生するように制御することによって取得され得る。例えば、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの単一のオーディオデバイスに対応する複数のオーディオデバイスマイクロフォンのうちの各マイクロフォンからマイクロフォンデータを受信し、マイクロフォンデータに少なくとも部分的に基づいて、単一のオーディオデバイスについてＤＯＡデータを決定することを含み得る。代替として、または、付加として、ＤＯＡデータを決定することは、複数のオーディオデバイスのうちの単一のオーディオデバイスに対応する１つ以上のアンテナからのアンテナデータを受信し、アンテナデータに少なくとも部分的に基づいて、単一のオーディオデバイスについてＤＯＡデータを決定することを含み得る。
いくつかのそのような例において、単一のオーディオデバイス自体は、ＤＯＡデータを決定し得る。いくつかのそのような実装例によると、複数のオーディオデバイスのうちの各オーディオデバイスが、自身のＤＯＡデータを決定し得る。しかし、他の実装例において、ローカルまたはリモートデバイスであり得る別のデバイスが環境内の１つ以上のオーディオデバイスについてＤＯＡデータを決定し得る。いくつかの実装例によると、サーバが環境内の１つ以上のオーディオデバイスに対してＤＯＡデータを決定し得る。
図４７に図示の例によると、ブロック４７１０は、制御システムを介して、ＤＯＡデータに少なくとも部分的に基づいて、オーディオデバイス位置データを生成することを含む。この例において、オーディオデバイス位置データは、ブロック４７０５において参照される各オーディオデバイスに対するオーディオデバイスの位置の推定値を含む。
オーディオデバイス位置データは、例えば、デカルト座標系、球座標系または円筒座標系などの座標系の座標であり得る（または、それを含み得る）。座標系は、本明細書において、オーディオデバイス座標系と呼ばれ得る。いくつかのそのような例において、オーディオデバイス座標系は、環境内のオーディオデバイスのうちの１つを基準にして方向づけられ得る。他の例において、オーディオデバイス座標系は、環境内のオーディオデバイスの内の２つの間の線によって定義される軸を基準にして方向づけられ得る。しかし、他の例において、オーディオデバイス座標系は、テレビ、部屋の壁などの環境の別の部分を基準にして方向づけられ得る。
いくつかの例において、ブロック４７１０は、図４０を参照して上述した処理を含み得る。いくつかのそのような例によると、ブロック４７１０は、ＤＯＡデータに基づいて、複数の三角形のそれぞれに対して内角を決定することを含み得る。いくつかの場合において、複数の三角形のうちの各三角形は、オーディオデバイスのうちの３つのオーディオデバイスの位置に対応する頂点を有し得る。いくつかのそのような方法は、内角に少なくとも部分的に基づいて、各三角形の各辺に対して辺の長さを決定することを含み得る。
いくつかのそのような方法は、複数の三角形のうちのそれぞれを第１のシーケンスにアラインメントさせるフォーワードアラインメント処理を行って、フォーワードアラインメント行列を生成することを含み得る。いくつかのそのような方法は、複数の三角形のうちのそれぞれを第１のシーケンスの反転である第２のシーケンスにアラインメントさせるリバースアラインメント処理を行って、リバースアラインメント行列を生成することを含み得る。いくつかのそのような方法は、フォーワードアラインメント行列の値およびリバースアラインメント行列の値に少なくとも部分的に基づいて、各オーディオデバイスの位置
の最終の推定値を生成することを含み得る。しかし、方法４７００のいくつかの実装例において、ブロック４７１０は、図４０を参照して上述した方法以外の方法を適用することを含み得る。
この例において、ブロック４７１５は、制御システムを介して、環境内の聴取者の位置を示す聴取者位置データを決定することを含む。聴取者位置データは、例えば、オーディオデバイス座標系を基準とし得る。しかし、他の例において、座標系は、聴取者、またはテレビ、部屋の壁などの環境の一部を基準として方向づけられ得る。
いくつかの例において、ブロック４７１５は、聴取者に（例えば、環境内の１つ以上のラウドスピーカからのオーディオプロンプトを介して）１つ以上の発声を行うように促し、ＤＯＡデータにしたがって聴取者の位置を推定することを含み得る。ＤＯＡデータは、環境内の複数のマイクロフォンによって取得されたマイクロフォンデータに対応し得る。マイクロフォンデータは、マイクロフォンによる１つ以上の発声の検出に対応し得る。マイクロフォンのうちの少なくともいくつかは、ラウドスピーカと同じ位置に配置され得る。いくつかの例によると、ブロック４７１５は、三角測量処理を含み得る。例えば、ブロック４７１５は、例えば、図４８Ａを参照して上述したように、オーディオデバイスを通るＤＯＡベクトル間の交点を見つけることによって、ユーザのボイスを三角測量することを含み得る。いくつかの実装例によると、ブロック４７１５（または、方法４７００の別の動作）は、聴取者の位置が決定された後のオーディオデバイス座標系および聴取者座標系の原点を同じ位置に配置することを含み得る。オーディオデバイス座標系および聴取者座標系の原点を同じ位置に配置することは、オーディオデバイスの位置をオーディオデバイス座標系から聴取者座標系に変換することを含み得る。
この実装例によると、ブロック４７２０は、制御システムを介して、聴取者の角度向きを示す聴取者角度向きデータを決定することを含む。聴取者角度向きデータは、例えば、オーディオデバイス座標系などの、聴取者位置データを表すために使用される座標系を基準にして生成され得る。いくつかのそのような例において、聴取者角度向きデータは、オーディオデバイス座標系の原点および／または軸を基準にして生成され得る。
しかし、いくつかの実装例において、聴取者角度向きデータは、聴取者の位置、およびテレビ、オーディオデバイス、壁などの環境内の別の箇所によって定義された軸を基準にして生成され得る。いくつかのそのような実装例において、聴取者の位置は、聴取者座標系の原点を定義するために使用され得る。聴取者角度向きデータは、いくつかのそのような例において、聴取者座標系の軸を基準にして生成され得る。
ブロック４７２０を行うための様々な方法を本明細書において開示する。いくつかの例によると、聴取者の角度向きは、聴取者視方向に対応し得る。いくつかのそのような例において、聴取者視方向は、聴取者位置データを参照して、例えば、聴取者がテレビなどの特定のオブジェクトを視ていると推測することによって、推論され得る。いくつかのそのような実装例において、聴取者視方向は、聴取者の位置およびテレビの位置にしたがって決定され得る。代替として、または、付加として、聴取者視方向は、聴取者の位置およびテレビサウンドバーの位置にしたがって決定され得る。
しかし、いくつかの例において、聴取者視方向は、聴取者入力にしたがって決定され得る。いくつかのそのような例によると、聴取者入力は、聴取者によって保持されたデバイスから受信された慣性センサデータを含み得る。聴取者は、そのデバイスを使用して、環境内の位置、例えば、聴取者が向いている方向に対応する位置を指し示し得る。例えば、聴取者は、そのデバイスを使用して、音を出しているラウドスピーカ（音を再生しているラウドスピーカ）を指し示し得る。したがって、そのような例において、慣性センサデー
タは、音を出しているラウドスピーカに対応する慣性センサデータを含み得る。
いくつかのそのような例において、聴取者入力は、聴取者によって選択されたオーディオデバイスの指示を含み得る。オーディオデバイスの指示は、いくつかの例において、選択されたオーディオデバイスに対応する慣性センサデータを含み得る。
しかし、他の例において、オーディオデバイスの指示は、聴取者の１つ以上の発声（例えば、「今、テレビは、私の前にあります」、「今、スピーカ２は、私の前にあります」など）にしたがって生成され得る。聴取者の１つ以上の発声にしたがって聴取者角度向きデータを決定する他の例を以下に説明する。
図４７に図示の例によると、ブロック４７２５は、制御システムを介して、各オーディオデバイスについての聴取者の位置および聴取者の角度向きに対するオーディオデバイス角度向きを示すオーディオデバイス角度向きデータを決定することを含む。いくつかのそのような例によると、ブロック４７２５は、聴取者の位置によって定義された箇所の回りのオーディオデバイス座標の回転を含み得る。いくつかの実装例において、ブロック４７２５は、オーディオデバイス位置データのオーディオデバイス座標系から聴取者座標系への変換を含み得る。いくつかの例を以下に説明する。
図４８Ａは、図４７のいくつかのブロックの例を図示する。いくつかのそのような例によると、オーディオデバイス位置データは、オーディオデバイス１～５のそれぞれに対するオーディオデバイスの、オーディオデバイス座標系４８０７を基準にした位置の推定値を含む。この実装例において、オーディオデバイス座標系４８０７は、オーディオデバイス２のマイクロフォンの位置を原点として有するデカルト座標系である。ここで、オーディオデバイス座標系４８０７のｘ軸は、オーディオデバイス２のマイクロフォンの位置と、オーディオデバイス１のマイクロフォンの位置との間の直線４８０３に対応する。
この例において、この例、聴取者の位置は、１つ以上の発声４８２７を生成するように、ソファ３６０３に座っているように図示された聴取者４８０５を（例えば、環境内の１つ以上のラウドスピーカ４８００ａからのオーディオプロンプトを介して）促し、そして、到着時間（ＴＯＡ）データにしたがって聴取者の位置を推定することによって決定される。ＴＯＡデータは、環境内の複数のマイクロフォンによって取得されたマイクロフォンデータに対応する。この例において、マイクロフォンデータは、オーディオデバイス１～５のうちの少なくともいくつか（例えば、３つ、４つ、または５つすべて）のマイクロフォンによる１つ以上の発声４８２７の検出に対応する。
代替として、または、付加として、聴取者の位置は、オーディオデバイス１～５のうちの少なくともいくつか（例えば、３つ、４つ、または５つすべて）のマイクロフォンによって与えられたＤＯＡデータにしたがって。いくつかのそのような例によると、聴取者の位置は、ＤＯＡデータに対応する直線４８０９ａ、４８０９ｂなどの交点にしたがって決定され得る。
この例によると、聴取者の位置は、聴取者座標系４８２０の原点に対応する。この例において、聴取者角度向きデータは、聴取者の頭４８１０（および／または聴取者の鼻４８２５）とテレビ３６０１のサウンドバー４８３０との間の直線４８１３ａに対応する聴取者座標系４８２０のｙ’軸によって示される。図４８Ａに示された例において、直線４８１３ａは、ｙ’軸に平行である。したがって、角度θは、ｙ軸とｙ’軸との間の角度を表す。この例において、図２１のブロック２１２５は、オーディオデバイス座標を聴取者座標系４８２０の原点回りに角度θだけ回転させることを含み得る。したがって、オーディオデバイス座標系４８０７の原点は、オーディオデバイス２に対応するように図４８Ａに
図示されるが、いくつかの実装例は、オーディオデバイス座標を聴取者座標系４８２０の原点回りに角度θだけ回転させる前に、オーディオデバイス座標系４８０７の原点を聴取者座標系４８２０の原点と同じ位置に配置することを含む。この同じ位置に配置することは、オーディオデバイス座標系４８０７から聴取者座標系４８２０へ座標変換することによって行われ得る。
サウンドバー４８３０および／またはテレビ３６０１の位置は、いくつかの例において、サウンドバーに音を出射させ、そしてオーディオデバイス１～５のうちの少なくともいくつか（例えば、３つ、４つ、または５つすべて）のマイクロフォンの音の検出に対応し得るＤＯＡおよび／またはＴＯＡデータにしたがってサウンドバーの位置を推定することによって決定され得る。代替として、または、付加として、サウンドバー４８３０および／またはテレビ３６０１の位置は、ユーザに対して、ＴＶまで歩いて行くように促し、そしてオーディオデバイス１～５のうちの少なくともいくつか（例えば、３つ、４つ、または５つすべて）のマイクロフォンの音の検出に対応し得るＤＯＡおよび／またはＴＯＡデータによってユーザの音声の位置を特定することによって決定され得る。そのような方法は、三角測量を含み得る。そのような例は、サウンドバー４８３０および／またはテレビ３６０１が連携するマイクロフォンを有さない状況において利点を有し得る。
サウンドバー４８３０および／またはテレビ３６０１が連携するマイクロフォンを有さないいくつかの他の例において、サウンドバー４８３０および／またはテレビ３６０１の位置は、ＴＯＡ方法または本明細書において開示されたＤＯＡ方法などＤＯＡ方法にしたがって決定され得る。いくつかのそのような方法によると、マイクロフォンは、サウンドバー４８３０と同じ位置に配置され得る。
いくつかの実装例によると、サウンドバー４８３０および／またはテレビ３６０１は、連携するカメラ４８１１を有し得る。制御システムは、聴取者の頭４８１０（および／または聴取者の鼻４８２５）の画像をキャプチャするように構成され得る。いくつかのそのような例において、制御システムは、聴取者の頭４８１０（および／または聴取者の鼻４８２５）とカメラ４８１１との間の直線４８１３ａを決定するように構成され得る。聴取者角度向きデータは、直線４８１３ａに対応し得る。代替として、または、付加として、制御システムは、直線４８１３ａとオーディオデバイス座標系のｙ軸との間の角度θを決定するように構成され得る。
図４８Ｂは、聴取者角度向きデータを決定するさらなる例を図示する。この例によると、聴取者の位置は、図４７のブロック２１１５において既に決定されている。ここで、制御システムは、オーディオオブジェクト４８３５を環境４８００ｂ内の様々な位置にレンダリングするように環境のラウドスピーカ４８００ｂを制御している。いくつかのそのような例において、制御システムは、例えば、オーディオオブジェクト４８３５が聴取者座標系４８２０の原点の回りを回転するように思えるようにオーディオオブジェクト４８３５をレンダリングすることによって、オーディオオブジェクト４８３５が聴取者４８０５の回りを回転するように思えるように、ラウドスピーカにオーディオオブジェクト４８３５をレンダリングさせ得る。この例において、曲線矢印４８４０は、オーディオオブジェクト４８３５が聴取者４８０５の回りを回転したときの軌跡の一部を図示する。
いくつかのそのような例によると、聴取者４８０５は、オーディオオブジェクト４８３５が聴取者４８０５の向いている方向にあることを示すユーザ入力（例えば、「止めて」と言う）を与え得る。いくつかのそのような例において、制御システムは、聴取者の位置とオーディオオブジェクト４８３５の位置との間の直線４８１３ｂを決定するように構成され得る。この例において、直線４８１３ｂは、聴取者４８０５が向いている方向を示す聴取者座標系のｙ’軸に対応する。代替の実装例において、聴取者４８０５は、オーディ
オオブジェクト４８３５が環境の前、環境のＴＶ位置において、オーディオデバイスの位置において、などにあることを示すユーザ入力を与え得る。
図４８Ｃは、聴取者角度向きデータを決定するさらなる例を示す。この例によると、聴取者の位置は、図４７のブロック２１１５において既に決定されている。ここで、聴取者４８０５は、手持ちデバイス４８４５を使用しており、手持ちデバイス４８４５をテレビ３６０１またはサウンドバー４８３０の方向へ向けることによって、聴取者４８０５の視方向に関する入力を与える。手持ちデバイス４８４５および聴取者の腕の破線輪郭線は、聴取者４８０５が手持ちデバイス４８４５をテレビ３６０１またはサウンドバー４８３０の方向へ向けていた時間の前の時間に、この例において、聴取者４８０５が手持ちデバイス４８４５をオーディオデバイス２の方向へ向けていたことを示す。他の例において、聴取者４８０５は、手持ちデバイス４８４５を、オーディオデバイス１などの別のオーディオデバイスの方向へ向けていたかもしれない。この例によると、手持ちデバイス４８４５は、オーディオデバイス２と聴取者４８０５の視方向との間の角度を近似する、オーディオデバイス２とテレビ３６０１またはサウンドバー４８３０との角度αを決定するように構成される。
手持ちデバイス４８４５は、いくつかの例において、慣性センサシステムと、環境４８００ｃのオーディオデバイスを制御している制御システムと通信するように構成されたワイヤレスインタフェースとを含む携帯電話であり得る。いくつかの例において、手持ちデバイス４８４５は、例えば、ユーザプロンプト（例えば、グラフィカルユーザインタフェースを介して）を与えることによって、手持ちデバイス４８４５が所望の方向を指していることを示す入力を受信することによって、対応する慣性センサデータを保存し、かつ／または、対応する慣性センサデータを、環境４８００ｃのオーディオデバイスを制御している制御システムに送信することによって、手持ちデバイス４８４５を制御して必要な機能を行わせるように構成されたアプリケーション、すなわち、「アプリ」を動作させていてもよい。
この例によると、制御システム（手持ちデバイス４８４５の制御システム、または、環境４８００ｃのオーディオデバイスを制御している制御システムであり得る）は、慣性センサデータにしたがって、例えば、ジャイロスコープデータにしたがって、直線４８１３ｃおよび４８５０の向きを決定するように構成される。この例において、直線４８１３ｃは、軸ｙ’に対して平行であり、聴取者の角度向きを決定するために使用され得る。いくつかの例によると、制御システムは、オーディオデバイス２と聴取者４８０５の視方向との間の角度αにしたがって、オーディオデバイス座標に対して聴取者座標系４８２０の原点の回りの適切な回転を決定し得る。
図４８Ｄは、図４８Ｃを参照して説明した方法にしたがって、オーディオデバイス座標に対して適切な回転を決定する例を図示する。この例において、オーディオデバイス座標系４８０７の原点は、聴取者座標系４８２０の原点と同じ位置に配置される。オーディオデバイス座標系４８０７および聴取者座標系４８２０の原点を同じ位置に配置することは、聴取者の位置が決定される２１１５の処理の後で可能にされる。オーディオデバイス座標系４８０７および聴取者座標系４８２０の原点を同じ位置に配置することは、オーディオデバイスの位置をオーディオデバイス座標系４８０７から聴取者座標系４８２０へ変換することを含み得る。角度αは、図４８Ｃを参照して説明したように決定されている。したがって、角度αは、聴取者座標系４８２０におけるオーディオデバイス２の所望の向きに対応する。この例において、角度βは、オーディオデバイス座標系４８０７におけるオーディオデバイス２の向きに対応する。この例においてβ－αである角度θは、オーディオデバイス座標系４８０７のｙ軸を聴取者座標系４８２０のｙ’軸とアラインメントさせるために必要な回転を示す。
いくつかの実装例において、図４７の方法は、対応するオーディオデバイスの位置、対応するオーディオデバイスの角度向き、聴取者位置データおよび聴取者角度向きデータに少なくとも部分的に基づいて、環境内のオーディオデバイスのうちの少なくとも１つを制御することを含み得る。
例えば、いくつかの実装例は、オーディオデバイス位置データ、オーディオデバイス角度向きデータ、聴取者位置データおよび聴取者角度向きデータをオーディオレンダリングシステムに与えることを含み得る。いくつかの例において、オーディオレンダリングシステムは、図６の制御システム６１０などの制御システムによって実装され得る。いくつかの実装例は、オーディオデバイス位置データ、オーディオデバイス角度向きデータ、聴取者位置データおよび聴取者角度向きデータに少なくとも部分的に基づいて、オーディオデータレンダリング処理を制御することを含み得る。いくつかのそのような実装例は、ラウドスピーカ音響能力データをレンダリングシステムに与えることを含み得る。ラウドスピーカ音響能力データは、１つ以上の環境のラウドスピーカに対応し得る。ラウドスピーカ音響能力データは、１つ以上のドライバの向き、ドライバの数、または１つ以上のドライバのドライバ周波数応答を示し得る。いくつかの例において、ラウドスピーカ音響能力データは、メモリから取り出され、次いで、レンダリングシステムに与えられ得る。
あるクラスの実施形態は、複数のコーディネートされた（オーケストレートされた）スマートオーディオデバイスのうちの少なくとも１つ（例えば、すべてまたは一部）によって、再生のためにオーディオをレンダリングするか、および／または、オーディオを再生するための方法を含む。例えば、ユーザのホーム内にある１セットのスマートオーディオデバイス（システム内）は、スマートオーディオデバイスのうちのすべてまたは一部によって（すなわち、すべてまたは一部が有するスピーカ（単数または複数）によって）再生するためにオーディオをフレキシブルにレンダリングすることを含む様々な同期使用事例を取り扱うためにオーケストレートされ得る。レンダリングおよび／または再生に対するダイナミックな変更を要求する、システムとの多くのインタラクションが考えられる。そのような変更は、空間忠実に集中されてもよいが、必ずしもそうではない。
いくつかの実施形態は、コーディネートされた（オーケストレートされた）複数のスマートオーディオデバイスのスピーカ（単数または複数）によって、再生のためにレンダリングすること、および／または、再生することを実装する。他の実施形態は、別の１セットのスピーカのうちのスピーカ（単数または複数）によって、再生のためにレンダリングすること、および／または、再生することを実装する。
いくつかの実施形態（例えば、レンダリングシステムもしくはレンダラ、またはレンダリング方法、または再生システムもしくは方法）は、１セットのスピーカのうちの一部またはすべてのスピーカ（例えば、各アクティベートされたスピーカ）によって、再生のためにオーディオをレンダリングするため、および／または、再生するためのシステムおよび方法に関する。いくつかの実施形態において、スピーカは、スマートオーディオデバイスを含み得る、コーディネートされた（オーケストレートされた）１セットのオーディオデバイスのうちのスピーカである。
１セットのスマートオーディオデバイスのうちのスマートオーディオデバイスによる（または、別のセットのスピーカによる）再生ために空間オーディオミックスのレンダリング（または、レンダリングおよび再生）（例えば、オーディオの１ストリームまたはオーディオの複数のストリームのレンダリング）を行う状況において、スピーカ（例えば、スマートオーディオデバイス内、または、それに接続された）のタイプは、変化し得るので、スピーカの対応する音響学的能力は、非常に著しく変化し得る。例えば、図２９に図示
されたオーディオ環境２０００の一実装例において、ラウドスピーカ２００５ｄ、２００５ｆおよび２００５ｈは、単一の０．６インチのスピーカを有するスマートスピーカである。この例において、ラウドスピーカ２００５ｂ、２００５ｃ、２００５ｅおよび２００５ｆは、２．５インチのウーファおよび０．８インチのツイータを有するスマートスピーカである。この例によると、ラウドスピーカ２００５ｇは、５．２５インチのウーファ、３つの２インチのミッドレンジスピーカ、および１．０インチのツイータを有するスマートスピーカである。ここで、ラウドスピーカ２００５ａは、１６個の１．１インチのビームドライバおよび２つの４インチのウーファを有するサウンドバーである。したがって、スマートスピーカ２００５ｄおよび２００５ｆの低周波数能力は、環境２０００内の他のラウドスピーカ、特に４インチまたは５．２５インチのウーファを有するラウドスピーカよりも著しく低い。
図４９は、本開示の様々な態様を実装できるシステムのコンポーネントの例を図示するブロック図である。本明細書において提供された他の図と同様に、図４９に図示された要素のタイプおよび数は、例として提供されたに過ぎない。他の実装例は、より多くの、より少ないおよび／または異なるタイプおよび数の要素を含み得る。
この例によると、システム４９００は、スマートホームハブ４９０５と、ラウドスピーカ４９２５ａ～４９２５ｍとを含む。この例において、スマートホームハブ４９０５は、図６に図示の上記制御システム６１０の例を含む。いくつかの例において、システム４９００の機能は、図２ＣのＣＨＡＳＭ２０８Ｃ、図２ＤのＣＨＡＳＭ２０８Ｄ、図３ＣのＣＨＡＳＭ３０７、または図４のＣＨＡＳＭ４０１などのオーディオセッションマネージャからの命令にしたがって、少なくとも部分的に、与えられ得る。オーディオセッションマネージャは、いくつかの場合において、スマートホームハブ４９０５以外のデバイスによって実装され得る。しかし、いくつかの例において、オーディオセッションマネージャは、スマートホームハブ４９０５によって実装され得る。この実装例によると、制御システム６１０は、聴取環境ダイナミックス処理構成データモジュール４９１０、聴取環境ダイナミックス処理モジュール４９１５およびレンダリングモジュール４９２０を含む。聴取環境ダイナミックス処理構成データモジュール４９１０、聴取環境ダイナミックス処理モジュール４９１５およびレンダリングモジュール４９２０のいくつかの例を以下に説明する。いくつかの例において、レンダリングモジュール４９２０’は、レンダリングおよび聴取環境ダイナミックス処理の両方を行うように構成され得る。
スマートホームハブ４９０５とラウドスピーカ４９２５ａ～４９２５ｍとの間の矢印によって示唆されるように、スマートホームハブ４９０５はまた、図６に図示の上記インタフェースシステム６０５の例を含む。いくつかの例によると、スマートホームハブ４９０５は、図２に図示の環境２００の一部であり得る。いくつかの場合において、スマートホームハブ４９０５は、スマートスピーカ、スマートテレビ、携帯電話、ラップトップなどによって実装され得る。いくつかの実装例において、スマートホームハブ４９０５は、ソフトウェアによって、例えば、ダウンロード可能なソフトウェアアプリケーションまたは「アプリ」のソフトウェアを介して、実装され得る。いくつかの場合において、スマートホームハブ４９０５は、ラウドスピーカ４９２５ａ～ｍのそれぞれにおいて実装され得る。ラウドスピーカ４９２５ａ～ｍのすべては、モジュール４９２０から、同じである、処理されたオーディオ信号を生成するように並列に動作する。いくつかのそのような例によると、ラウドスピーカのそれぞれにおいて、レンダリングモジュール４９２０は、次いで、各ラウドスピーカまたは各グループのラウドスピーカに関係する１つ以上のスピーカフィードを生成し、これらのスピーカフィードを各スピーカダイナミックス処理モジュールに与え得る。
いくつかの場合において、ラウドスピーカ４９２５ａ～４９２５ｍは、図２９のラウド
スピーカ２００５ａ～２００５ｈを含み得、他方、他の例において、ラウドスピーカ４９２５ａ～４９２５ｍは、他のラウドスピーカであってもよいし、それらを含んでもよい。したがって、この例において、システム４９００は、Ｍ個のラウドスピーカを含む。ここで、Ｍは、２よりも大きな整数である。
スマートスピーカおよび多くの他のパワードスピーカは、典型的には、あるタイプの内部ダイナミックス処理を使用して、スピーカの歪みを防止する。そのようなダイナミックス処理には、信号リミット閾値（例えば、周波数にわたって可変なリミット閾値である）が対応づけられることが多い。信号リミット閾値より低い場合、信号レベルは、ダイナミックに保持される。例えば、Ｄｏｌｂｙ Ａｕｄｉｏ Ｐｒｏｃｅｓｓｉｎｇ （ＤＡＰ）のオーディオ後処理スイートにおけるいくつかのアルゴリズムのうちの１つであるＤｏｌｂｙのＡｕｄｉｏ Ｒｅｇｕｌａｔｏｒは、そのような処理を提供する。いくつかの場合において、スマートスピーカのダイナミックス処理モジュールを介するのは典型的ではないが、ダイナミックス処理はまた、１つ以上のコンプレッサ、ゲート、エクスパンダ（ｅｘｐａｎｄｅｒ）、ダッカ（ｄｕｃｋｅｒ）などを適用することを含み得る。
したがって、この例において、ラウドスピーカ４９２５ａ～４９２５ｍのそれぞれは、対応するスピーカダイナミックス処理（ＤＰ）モジュールＡ～Ｍを含む。スピーカダイナミックス処理モジュールは、聴取環境の各個別のラウドスピーカに対して個別のラウドスピーカダイナミックス処理構成データを適用するように構成される。スピーカＤＰモジュールＡは、例えば、ラウドスピーカ４９２５ａに対して適切な個別のラウドスピーカダイナミックス処理構成データを適用するように構成される。いくつかの例において、個別のラウドスピーカダイナミックス処理構成データは、特定の周波数範囲内かつ特定のレベルにおいて、はっきりとした歪みなく、オーディオデータを再生するラウドスピーカの能力などの、個別のラウドスピーカのより多くの能力のうちの１つに対応し得る。
それぞれが異なり得る再生リミットを有する１セットの異種のスピーカ（例えば、スマートオーディオデバイスの、または、それに接続されたスピーカ）にわたって空間オーディオがレンダリングされる場合、ダイナミックス処理を総ミックスに対して行う際に注意が必要である。簡単な解決策は、関係するスピーカのそれぞれに対して、空間ミックスをスピーカフィードにレンダリングし、次いで、各スピーカに関連するダイナミックス処理モジュールが対応するスピーカフィード上で当該スピーカのリミットにしたがって独立して動作できるようにする。
このアプローチは、各スピーカが歪むことを防止するが、知覚的に気を散らす（ｐｅｒｃｅｐｔｕａｌｌｙ ｄｉｓｔｒａｃｔｉｎｇ）ようなあり方で、ミックスの空間バランスをダイナミックにシフトさせ得る。例えば、図２９の戻り、テレビ番組がテレビ２０３０上に表示されており、対応するオーディオがオーディオ環境２０００のラウドスピーカによって再生されているとする。テレビ番組中に、静止オブジェクト（工場内の一台の重機など）に対応づけられたオーディオがオーディオ環境２０００の特定の位置にレンダリングされるように意図されるとする。さらに、低音範囲の音を再生する能力はラウドスピーカ４９２５ｂの方が実質的に大きいので、ラウドスピーカ４９２５ｄに関連するダイナミックス処理モジュールが低音範囲のオーディオに対してレベルを実質的にラウドスピーカ４９２５ｂに関連するダイナミックス処理モジュールよりも大きく低減するとする。静止オブジェクトに対応づけられた信号のボリュームが変動する場合、そのボリュームがより高いと、ラウドスピーカ４９２５ｄに関連するダイナミックス処理モジュールは、低音範囲のオーディオに対するレベルを、同じオーディオに対するレベルがラウドスピーカ４９２５ｂに関連するダイナミックス処理モジュールによって低減されるよりも実質的に大きく低減させることになる。このレベル差は、静止オブジェクトの見かけの位置を変化させることになる。したがって、改善された解決策が所望されるであろう。
本開示のいくつかの実施形態は、１セットのスマートオーディオデバイス（例えば、１セットのコーディネートされたスマートオーディオデバイス）のうちのスマートオーディオデバイスのうちの少なくとも１つ（例えば、すべてまたは一部）によって、および／または、別のセットのスピーカのうちのスピーカの少なくとも１つ（例えば、すべてまたは一部）によって、再生のために空間オーディオミックスをレンダリング（またはレンダリングおよび再生）（例えば、１つのオーディオストリームまたは複数のオーディオストリームのレンダリング）するためのシステムおよび方法である。いくつかの実施形態は、そのようなレンダリング（例えば、スピーカフィードの生成を含む）およびまたレンダリングされたオーディオの再生（例えば、生成されたスピーカフィードの再生）のための方法（またはシステム）である。そのような実施形態の例は、以下を含む。
オーディオ処理のためのシステムおよび方法は、少なくとも２つのスピーカ（例えば、１セットのスピーカのうちのスピーカのうちのすべてまたは一部）によって再生するために、オーディオをレンダリングすること（例えば、例えば１つのオーディオストリームまたは複数のオーディオストリームをレンダリングすることによって空間オーディオミックスをレンダリングすること）を含み得、以下によることを含み得る：
（ａ）個別のラウドスピーカの（リミット閾値（再生リミット閾値）などの個別のラウドスピーカダイナミックス処理構成データを組み合わせることによって、複数のラウドスピーカに対して、聴取環境ダイナミックス処理構成データを決定すること（組み合わされた閾値など）、
（ｂ）複数のラウドスピーカに対する聴取環境ダイナミックス処理構成データ（例えば、組み合わされた閾値）を使用して、ダイナミックス処理をオーディオ（例えば、空間オーディオミックスを示すオーディオストリーム（単数または複数））に対して行って、処理されたオーディオを生成すること、および
（ｃ）処理されたオーディオをスピーカフィードにレンダリングすること。
いくつかの実装例によると、処理（ａ）は、図４９に図示された聴取環境ダイナミックス処理構成データモジュール４９１０などモジュールによって行われ得る。スマートホームハブ４９０５は、インタフェースシステムを介して、Ｍ個のラウドスピーカのそれぞれに対して個別のラウドスピーカダイナミックス処理構成データを取得するように構成され得る。この実装例において、個別のラウドスピーカダイナミックス処理構成データは、複数のラウドスピーカのうちの各ラウドスピーカに対して設定された個別のラウドスピーカダイナミックス処理構成データを含む。いくつかの例によると、１つ以上のラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データは、１つ以上のラウドスピーカの１つ以上の能力に対応し得る。この例において、個別のラウドスピーカダイナミックス処理構成データセットのそれぞれは、少なくとも１つのタイプのダイナミックス処理構成データを含む。いくつかの例において、スマートホームハブ４９０５は、ラウドスピーカ４９２５ａ～４９２５ｍのそれぞれに問い合せることによって、個別のラウドスピーカダイナミックス処理構成データセットを取得するように構成され得る。他の実装例において、スマートホームハブ４９０５は、メモリ内に格納された、予め取得された個別のラウドスピーカダイナミックス処理構成データセットのデータ構造に問い合せることによって、個別のラウドスピーカダイナミックス処理構成データセットを取得するように構成され得る。
いくつかの例において、処理（ｂ）は、図４９の聴取環境ダイナミックス処理モジュール４９１５などのモジュールによって行われ得る。処理（ａ）および（ｂ）のいくつかの詳細な例を以下に説明する。
いくつかの例において、処理（ｃ）のレンダリングは、図４９のレンダリングモジュー
ル４９２０またはレンダリングモジュール４９２０’などのモジュールによって行われ得る。いくつかの実施形態において、オーディオ処理は、以下を含み得る。
（ｄ）各ラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データにしたがって、レンダリングされたオーディオ信号に対してダイナミックス処理を行うこと（例えば、対応するスピーカに対応づけられた再生リミット閾値にしたがってスピーカフィードを限定することによって、限定されたスピーカフィードを生成すること）。処理（ｄ）は、例えば、図４９に図示されたダイナミックス処理モジュールＡ～Ｍによって行われ得る。
スピーカは、１セットのスマートオーディオデバイスのうちのスマートオーディオデバイスのうちの少なくとも１つ（例えば、すべてまたは一部）の（または、それらに接続された）スピーカを含み得る。いくつかの実装例において、ステップ（ｄ）において限定されたスピーカフィードを生成するために、ステップ（ｃ）において生成されたスピーカフィードは、例えば、スピーカ上での最終の再生より前にスピーカフィードを生成するために、ダイナミックス処理の第２のステージによって（例えば、各スピーカの関連するダイナミックス処理システムによって）処理され得る。例えば、スピーカフィード（または、それらのサブセットまたは一部）は、スピーカのそれぞれ異なる１つのスピーカのダイナミックス処理システム（例えば、スマートオーディオデバイスのダイナミックス処理サブシステム。ここで、スマートオーディオデバイスは、スピーカのうちの関係する１つを含むか、またはそれに接続される）に与えられ、各当該ダイナミックス処理システムからの処理されたオーディオ出力を使用して、スピーカのうちの関係する１つに対してスピーカフィードを生成し得る。スピーカ特定ダイナミックス処理（換言すると、スピーカのそれぞれに対して、独立して行われるダイナミックス処理）に続いて、処理された（例えば、ダイナミックに限定された）スピーカフィードを使用して、音を再生するようにスピーカを駆動し得る。
ダイナミックス処理の第１のステージ（ステップ（ｂ）において）は、空間バランスにおいて知覚的に気を散らすシフトを低減するように設計され得る。そうしないと、ステップ（ａ）および（ｂ）が省略され、ステップ（ｄ）から生じるダイナミックス処理された（例えば、限定された）スピーカフィードが元のオーディオに応答して（ステップ（ｂ）において生成された、処理されたオーディオへの応答ではなく）生成された場合に、知覚的に気を散らすシフトが生じるであろう。これは、ミックスの空間バランスのおける望ましくないシフトを防止し得る。ステップ（ｃ）からのレンダリングされたスピーカフィード上で動作するダイナミックス処理の第２のステージは、いずれのスピーカも歪まないことを確実にするように設計され得る。なぜなら、ステップ（ｂ）のダイナミックス処理は、信号レベルがすべてのスピーカの閾値よりも下に低減されていることを必ずしも保証しないことがあり得るからである。個別のラウドスピーカダイナミックス処理構成データを組み合わせること（例えば、第１のステージ（ステップ（ａ）における閾値の組み合わせ）は、いくつかの例において、スピーカにわたって（例えば、スマートオーディオデバイスにわたって）個別のラウドスピーカダイナミックス処理構成データ（例えば、リミット閾値）を平均化するか、または、スピーカにわたって（例えば、スマートオーディオデバイスにわたって）個別のラウドスピーカダイナミックス処理構成データ（例えば、リミット閾値）の最小を取るステップに関係し得る（例えば、それを含み得る）。
いくつかの実装例において、ダイナミックス処理の第１のステージ（ステップ（ｂ）において）が空間ミックスを示すオーディオ（例えば、少なくとも１つのオブジェクトチャネルおよび必要に応じてまた少なくとも１つのスピーカチャネルを含むオブジェクトベースのオーディオプログラムのオーディオ）上で動作する場合、この第１のステージは、空間ゾーンの使用を介するオーディオオブジェクト処理のための手法にしたがって実装され
得る。そのような場合において、ゾーンのそれぞれに対応づけられた、組み合わされた個別のラウドスピーカダイナミックス処理構成データ（例えば、組み合わされたリミット閾値）は、個別のラウドスピーカダイナミックス処理構成データ（例えば、個別のスピーカリミット閾値）の重みづけ平均によって（または、それとして）得られ得、この重みづけは、ゾーンに対する各スピーカの空間近傍度および／またはゾーン内の位置によって、少なくとも部分的に、与えられ得るか、または、決定され得る。
例示の実施形態において、複数のＭ個のスピーカ（
）を仮定する。ここで、各スピーカは、変数ｉによってインデックスされる。各スピーカｉに、１セットの周波数変動再生リミット閾値
が対応づけられる。ここで、変数ｆは、閾値が指定される有限セットの周波数へのインデックスを表す。（なお、１セットの周波数のサイズが１である場合、対応する単一の閾値は、ブロードバンドと考えられ、全周波数範囲にわたって適用される）。これらの閾値は、スピーカの歪みの防止、または、スピーカがその近傍で不快と考えられるあるレベルを超えた再生を行うことの防止などの特定の目的のために、オーディオ信号を閾値
よりも低くなるように限定するために、各スピーカによって、自身の独立したダイナミックス処理関数において利用される。
図５０Ａ、５０Ｂおよび５０Ｃは、再生リミット閾値および対応する周波数の例を図示する。図示の周波数の範囲は、例えば、平均的な人間にとって可聴である周波数の範囲（例えば、２０Ｈｚから２０ｋＨｚ）にわたり得る。これらの例において、再生リミット閾値は、グラフ５０００ａ、５０００ｂおよび５０００ｃの縦軸によって示される。これらの例において、縦軸は、「レベル閾値」と標識される。再生リミット／レベル閾値は、縦軸上の矢印の方向に増大する。再生リミット／レベル閾値は、例えば、デシベル単位で表され得る。これらの例において、グラフ５０００ａ、５０００ｂおよび５０００ｃの横軸は、周波数を示す。周波数は、横軸上の矢印の方向に増大する。曲線５０００ａ、５０００ｂおよび５０００ｃによって示される再生リミット閾値は、例えば、個別のラウドスピーカのダイナミックス処理モジュールによって実装され得る。
図５０Ａのグラフ５０００ａは、再生リミット閾値の第１の例を周波数の関数として示す。曲線５００５ａは、各対応する周波数値に対する再生リミット閾値を示す。この例において、低音周波数ｆｂにおいて、入力レベルＴｉにおいて受信された入力オーディオは、ダイナミックス処理モジュールによって、出力レベルＴｏにおいて出力されることになる。低音周波数ｆｂは、例えば、６０～２５０Ｈｚの範囲内にあり得る。しかし、この例において、高音（ｔｒｅｂｌｅ）周波数ｆｔにおいて、入力レベルＴｉにおいて受信された入力オーディオは、ダイナミックス処理モジュールによって同じレベル、入力レベルＴｉ、で出力されることになる。高音周波数ｆｔは、例えば、１２８０Ｈｚより高い範囲内であり得る。したがって、この例において、曲線５００５ａは、低音周波数に対して、高音周波数に対するよりも著しく低い閾値を適用するダイナミックス処理モジュールに対応する。そのようなダイナミックス処理モジュールは、ウーファを有さないラウドスピーカ（例えば、図２９のラウドスピーカ２００５ｄ）に対して適切であり得る。
図５０Ｂのグラフ５０００ｂは、再生リミット閾値の第２の例を周波数の関数として示す。曲線５００５ｂは、図５０Ａに示された同じ低音周波数ｆｂにおいて、入力レベルＴｉにおいて受信された入力オーディオがダイナミックス処理モジュールによって、より高い出力レベルＴｏにおいて出力されることになることを示す。したがって、この例において、曲線５００５ｂは、低音周波数に対して曲線５００５ａと同程度に低い閾値を適用し
ないダイナミックス処理モジュールに対応する。そのようなダイナミックス処理モジュールは、少なくとも小さなウーファ（例えば、図２９のラウドスピーカ２００５ｂ）を有するラウドスピーカに対して適切であり得る。
図５０Ｃのグラフ５０００ｃは、再生リミット閾値の第２の例を周波数の関数として示す。曲線５００５ｃ（この例においては、直線である）は、図５０Ａに示された同じ低音周波数ｆｂにおいて、入力レベルＴｉにおいて受信された入力オーディオがダイナミックス処理モジュールによって同じレベルで出力されることになることを示す。したがって、この例において、曲線５００５ｃは、低音周波数を含む広い範囲の周波数を再生できるラウドスピーカに対して適切であり得るダイナミックス処理モジュールに対応する。便宜上、ダイナミックス処理モジュールは、示されたすべての周波数に対して同じ閾値を適用する曲線５００５ｄを実装することによって曲線５００５ｃを近似し得ることが見て取れるであろう。
空間オーディオミックスは、複数のスピーカに対して、質量中心振幅パニング（ＣＭＡＰ）、フレキシブルバーチャル化（ＦＶ）、または本明細書において開示されるようなＣＭＡＰおよびＦＶの組み合わせなどのレンダリングシステムを使用してレンダリングされ得る。空間オーディオミックスの構成成分から、レンダリングシステムは、複数のスピーカのそれぞれに対して１つのスピーカフィードを生成する。いくつかの上記の例において、次いで、スピーカフィードは、閾値
を有する、各スピーカの関連のダイナミックス処理関数によって独立に処理された。本開示の利点はないが、この記載のレンダリングシナリオは、レンダリングされた空間オーディオミックスの知覚された空間バランスにおいて気を散らすシフトを生じさせ得る。例えば、Ｍ個のスピーカのうちの１つ、例えば、聴取エリアの右手側のスピーカがその他のスピーカよりもはるかに能力が劣る（例えば、低音範囲のオーディオをレンダリングする能力）ことがあり得、したがって、当該スピーカに対する閾値
が、少なくとも特定の周波数範囲内で、他のスピーカよりも著しく低いことがあり得る。再生中に、このスピーカのダイナミックス処理モジュールは、右手側において空間ミックスの成分のレベルを左手側の成分よりも著しく大きく低下させていることになる。聴取者は、空間ミックスの左／右バランス間のそのようなダイナミックシフトに対して極めて敏感であり、非常に気を散らす結果を見出し得る。
この問題に対処するために、いくつかの例において、聴取環境の個別のスピーカの個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）は、組み合わされて、聴取環境のすべてのラウドスピーカに対する聴取環境ダイナミックス処理構成データが生成される。次いで、聴取環境ダイナミックス処理構成データは、スピーカフィードにレンダリングされる前に、全空間オーディオミックスの状況においてダイナミックス処理を先に行うために利用され得る。ちょうど１つの独立スピーカフィードとは反対に、ダイナミックス処理のこの第１のステージは、全空間ミックスにアクセスするので、処理は、ミックスの知覚された空間バランスに対して気を散らすシフトを与えないあり方で行われ得る。個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）は、個別のスピーカの独立したダイナミックス処理機能のいずれかによって行われるダイナミックス処理を排除またはその量を低減するように組み合わされ得る。
聴取環境ダイナミックス処理構成データを決定する一例において、個別のスピーカに対する個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）は、組み合わされて、単一のセットの聴取環境ダイナミックス処理構成データ（例えば、周波数変動再生リミット閾値
）になり得る。単一のセットの聴取環境ダイナミックス処理構成データは、ダイナミックス処理の第１のステージにおいて、空間ミックスのすべての成分に適用される。いくつかのそのような例によると、限定は、すべての成分に対して同じであるので、ミックスの空間バランスは、維持され得る。個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）を組み合わせる１つの方法は、すべてのスピーカｉにわたって、最小値を取ることである。
そのような組合せは、各スピーカの個別のダイナミックス処理の動作を本質的に排除する。なぜなら、空間ミックスは、最初に、どの周波数においても最も能力の低いスピーカの閾値よりも下に限定されるからである。しかし、そのような方策は、積極的過ぎることがあり得る。多くのスピーカは、その能力よりも低いレベルで再生しており、すべてのスピーカの組み合わされた再生レベルが不快な程度に低いことがあり得る。例えば、図５０Ａに示された低音範囲内の閾値が図５０Ｃに対する閾値に対応するラウドスピーカに適用されたならば、後者のスピーカの再生レベルは、低音範囲内において不必要に低いであろう。聴取環境ダイナミックス処理構成データを決定する代替の組合せは、聴取環境のすべてのスピーカにわたる個別のラウドスピーカダイナミックス処理構成データの平均を取ることである。例えば、再生リミット閾値に関して、平均は、以下のように決定され得る。
この組合せについて、ダイナミックス処理の第１のステージは、より高いレベルに限定するので、総再生レベルは、最小値を取ることと比較して増大し得る。これにより、より能力の高いスピーカがより大きく再生することを可能にする。個別のリミット閾値が平均よりも低いスピーカに対しては、それらの独立したダイナミックス処理機能が必要に応じて関連するスピーカフィードをやはり限定し得る。しかし、ある初期の限定が空間ミックスに対して行われているので、ダイナミックス処理の第１のステージは、おそらくこの限定の必要性を低減しているであろう。
聴取環境ダイナミックス処理構成データを決定するいくつかの例によると、個別のラウドスピーカダイナミックス処理構成データの最小値と平均との間を、チューニングパラメータαを介して、補間するチューナブル組合せを生成し得る。例えば、再生リミット閾値に関して、補間は、以下のように決定され得る。
個別のラウドスピーカダイナミックス処理構成データの他の組合せが可能であり、本開示は、すべてのそのような組合せを含むことが意図される。
図５１Ａおよび５１Ｂは、ダイナミックレンジ圧縮データの例を示すグラフである。グラフ５１００ａおよび５１００ｂにおいて、横軸上にデシベル単位の入力信号レベルが示され、縦軸上にデシベル単位の出力信号レベルが示される。他の開示された例と同様に、特定の閾値、比率および他の値は、例として示されたにすぎず、限定するものではない。
図５１Ａに図示の例において、出力信号レベルは、この例において－１０ｄＢである閾値よりも低い入力信号レベルに等しい。他の例は、異なる閾値、例えば、－２０ｄＢ、－１８ｄＢ、－１６ｄＢ、－１４ｄＢ、－１２ｄＢ、－８ｄＢ、－６ｄＢ、－４ｄＢ、－２ｄＢ、０ｄＢ、２ｄＢ、４ｄＢ、６ｄＢなどを含み得る。閾値より高い場合の、圧縮比の様々な例を示す。Ｎ：１比は、閾値より高い場合に、入力信号においてＮｄＢだけ増大するごとに、出力信号レベルが１ｄＢだけ増大することになることを意味する。例えば、１０：１の圧縮比（直線５１０５ｅ）は、閾値より高い場合、入力信号において１０ｄＢだけ増大するごとに、出力信号レベルが１ｄＢだけ増大することになることを意味する。１：１の圧縮比（直線５１０５ａ）は、閾値より高くても、出力信号レベルがなおも入力信号レベルに等しいことを意味する。直線５１０５ｂ、５１０５ｃ、および５１０５ｄは、３：２、２：１および５：１の圧縮比に対応する。他の実装例は、２．５：１、３：１、３．５：１、４：３、４：１などの異なる圧縮比を与え得る。
図５１Ｂは、この例において０ｄＢである閾値においてまたはその近くにおいて圧縮比がどのように変化するかを制御する「ニー（ｋｎｅｅ）」の例を図示する。この例によると、「ハード（ｈａｒｄ）」ニーを有する圧縮曲線は、２つの直線区間から構成される。閾値までの直線区間５１１０ａ、および閾値より上の直線区間５１１０ｂである。ハード・ニーは、より簡単に実装できるが、アーチファクトを生じ得る。
図５１Ｂにおいて、「ソフト」ニーの一例も図示する。この例において、ソフト・ニーは、１０ｄＢにわたる。この実装例によると、１０ｄＢ区間（ｓｐａｎ）よりも上およびより下において、ソフト・ニーを有する圧縮曲線の圧縮比は、ハード・ニーを有する圧縮曲線と同じである。他の実装例は、「ソフト」ニーの様々な他の形状を提供し得る。「ソフト」ニーは、より多くのまたは少ないデシベルにわたってもよいし、その区間より上で異なる圧縮比を示してもよいなどである。
他のタイプのダイナミックレンジ圧縮データは、「アタック」データおよび「リリース」データを含み得る。アタックは、圧縮比によって決定されたゲインに達するために、例えば、入力において増大したレベルに応答して、コンプレッサがゲインを低減している期間である。コンプレッサに対するアタック時間は、一般に２５ミリ秒～５００ミリ秒の範囲であるが、他のアタック時間も可能である。リリースは、圧縮比によって決定されたゲインに達するために（または、入力レベルが閾値よりも下に落ちている場合は、入力レベルに）、例えば、入力において低減したレベルに応答して、コンプレッサがゲインを増大している期間である。リリース時間は、例えば、２５ミリ秒～２秒の範囲であり得る。
したがって、いくつかの例において、個別のラウドスピーカダイナミックス処理構成データは、複数のラウドスピーカのうちの各ラウドスピーカに対して、ダイナミックレンジ圧縮データセットを含み得る。ダイナミックレンジ圧縮データセットは、閾値データ、入力／出力比データ、アタックデータ、リリースデータおよび／またはニーデータを含み得る。１つ以上のこれらのタイプの個別のラウドスピーカダイナミックス処理構成データは、聴取環境ダイナミックス処理構成データを決定するために組み合わせされ得る。再生リミット閾値を組み合わせることを参照して上述したように、ダイナミックレンジ圧縮データは、いくつかの例において、聴取環境ダイナミックス処理構成データを決定するために平均化され得る。いくつかの場合において、ダイナミックレンジ圧縮データの最小値または最大値を使用して、聴取環境ダイナミックス処理構成データ（例えば、最大圧縮比）を
決定し得る。他の実装例において、例えば、式（２２）を参照して上述したようなチューニングパラメータを介して、個別のラウドスピーカダイナミックス処理に対するダイナミックレンジ圧縮データの最小値および平均値間を補間するチューナブル組合せを生成し得る。
上記のいくつかの例において、ダイナミックス処理の第１のステージにおいて、単一のセットの聴取環境ダイナミックス処理構成データ（例えば、単一のセットの組み合わされた閾値
）が空間ミックスのすべての成分に適用される。そのような実装例は、ミックスの空間バランスを維持できるが、他の不要なアーチファクトを与え得る。例えば、隔離された空間内の空間ミックスの非常に音の大きな部分によって全ミックスの音が下げられた場合、「空間ダッキング（ｄｕｃｋｉｎｇ）」が生じ得る。このラウド成分から空間的に離れたミックスの他のよりソフトな成分は、不自然にソフトとなるように知覚され得る。例えば、ソフトな背景音楽は、空間ミックスのサラウンドフィールド内で、組み合わされた閾値
よりも低いレベルで再生されていてもよく、したがって、ダイナミックス処理の第１のステージによる空間ミックスの限定は、行われない。次いで、空間ミックスの前で（例えば、映画サウンドトラックに対するスクリーン上で）大きな音の発砲が瞬間的に導入され得、ミックスの総レベルが組み合わされた閾値よりも高くに増大する。この時、ダイナミックス処理の第１のステージは、全ミックスのレベルを閾値
よりも下へ低下させる。音楽は、発砲から空間的に離れているので、これは、音楽の連続ストリームにおける不自然なダッキングとして知覚され得る。
そのような問題に対処するために、いくつかの実装例は、空間ミックスの異なる「空間ゾーン」に対して、独立した、または、部分的に独立したダイナミックス処理を可能にする。空間ゾーンは、全空間ミックスがレンダリングされる１サブセットの空間領域と考えられ得る。以下の記載の大半は、再生リミット閾値に基づくダイナミックス処理の例を提供するが、その概念は、他のタイプの個別のラウドスピーカダイナミックス処理構成データおよび聴取環境ダイナミックス処理構成データに等しく適用される。
図５２は、聴取環境の空間ゾーンの例を示す。図５２は、空間ミックスの領域の例（正方形全体によって表される）を図示する。空間ミックスの領域は、フロント、センター、およびサラウンドの３つの空間ゾーンに細分される。
図５２における空間ゾーンは、はっきりとした境界を有するように図示されるが、実際には、ある空間ゾーンから別の空間ゾーンへの移行は連続であるように扱うことが有利である。例えば、正方形の左エッジの中央に位置する空間ミックスの成分は、フロントゾーンに割り当てられたレベルの半分およびサラウンドゾーンに割り当てられたレベルの半分を有し得る。空間ミックスの各成分からの信号レベルは、このように連続的に空間ゾーンのそれぞれに割り当ておよび累積され得る。次いで、各空間ゾーンに対して、独立して、ミックスから当該空間ゾーンに割り当てられた総信号レベルにダイナミックス処理関数が働き得る。次いで、空間ミックスの各成分に対して、各空間ゾーンからのダイナミックス処理の結果（例えば、周波数あたりの時変ゲイン）が組み合わされ、そして成分に適用され得る。いくつかの例において、空間ゾーン結果のこの組合せは、各成分に対して異なり、当該特定の成分の各ゾーンへの割り当ての関数である。最後の結果は、類似の空間ゾーン割り当てを有する空間ミックスの成分が類似のダイナミックス処理を受けるが、空間ゾーン間の独立が許されることである。空間ゾーンは、ある空間的に独立した処理をなおも可能にしつつ（例えば、上記空間ダッキングなどの他のアーチファクトを低減するため）
、左／右のアンバランスなどの不快な空間シフトを防止するために選択されることが有利であり得る。
本開示のダイナミックス処理の第１のステージにおいて、空間ミックスを空間ゾーンごとに処理するための手法を使用することが有利であり得る。例えば、スピーカｉにわたる個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）の異なる組合せが各空間ゾーンに対して計算され得る。１セットの組み合わされたゾーン閾値は、
によって表され得る。ここで、添え字ｊは、複数の空間ゾーンのうちの１つを指す。上記の手法にしたがって、対応づけられた閾値
を有する各空間ゾーン上で独立にダイナミックス処理モジュールが動作し得、その結果が空間ミックスの構成成分に戻って適用され得る。
全部でＫ個の個別の構成信号
からなるようにレンダリングされている空間信号を考える。各個別の構成信号は、対応づけられた所望の空間位置（おそらくは、時間変化する）を有する。ゾーン処理を実装するための１つの特定の方法は、各オーディオ信号
がゾーンｊにどれだけ寄与するかを記述する時変パニング（ｐａｎｎｉｎｇ）ゲイン
を、ゾーンの位置に対するオーディオ信号の所望の空間位置の関数として計算することを含む。これらのパニングゲインは、ゲインの二乗の合計が１（ｕｎｉｔｙ）に等しいことを要求するパワー保存パニング則にしたがうように設計されることが有利であり得る。これらのパニングゲインから、ゾーン信号
は、当該ゾーンについて、パニングゲインによって重みづけられた構成信号の合計として計算され得る。
次いで、各ゾーン信号
は、独立して、ゾーン閾値
によってパラメータ化されたダイナミックス処理関数ＤＰによって処理され、周波数および時間とともに変化するゾーン変更ゲインＧｊを生成し得る。
次いで、周波数および時間とともに変化する変更ゲインは、各個別の構成信号
に対して、当該信号のゾーンに対するパニングゲインに比例するゾーン変更ゲインを組み合わせることによって計算され得る。
次いで、これらの信号変更ゲインＧｋは、例えばフィルタバンクを使用して、各構成信号に適用されて、ダイナミックス処理された構成信号
を生成し得る。次いで、その後、ダイナミックス処理された構成信号は、スピーカ信号にレンダリングされ得る。
各空間ゾーンに対する個別のラウドスピーカダイナミックス処理構成データ（スピーカ再生リミット閾値など）を組み合わせることは、様々な方法で行われ得る。一例として、空間ゾーン再生リミット閾値
は、空間ゾーンおよびスピーカに依存した重みづけ
を使用して、スピーカ再生リミット閾値
の重みづけ合計として計算され得る。
類似の重みづけ関数を他のタイプの個別のラウドスピーカダイナミックス処理構成データに適用し得る。有利には、空間ゾーンの組み合わされた個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）は、当該空間ゾーンに対応づけられた空間ミックスの成分を再生することに対して最も大きな役割を有するスピーカの個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）の方へバイアスされ得る。そのようなバイアスは、いくつかの例において、重み
を、周波数ｆに対して当該ゾーンに関連する空間ミックスの成分をレンダリングする各スピーカの役割の関数として設定することによって達成され得る。
図５３は、図５２の空間ゾーン内のラウドスピーカの例を図示する。図５３は、図５２と同じゾーンを図示するが、重ね合わされる空間ミックスをレンダリングする役割を有する５つのラウドスピーカ例（スピーカ１、２、３、４、および５）の位置も図示する。この例において、ラウドスピーカ１、２、３、４、および５は、菱形によって表される。この特定の例において、スピーカ１は、主にセンターゾーンをレンダリングする役割を有し、スピーカ２および５は、主にフロントゾーンをレンダリングする役割を有し、スピーカ３および４は、主にサラウンドゾーンをレンダリングする役割を有する。スピーカの空間ゾーンへのこの概念的な１対１マッピングに基づいて、重み
を生成し得るが、空間ゾーンに基づく空間ミックスの処理と同様に、より連続的なマッピ
ングが好適であり得る。例えば、スピーカ４がフロントゾーンに非常に近く、スピーカ４および５（概念的なフロントゾーン内にあるが）間に位置するオーディオミックスの成分が主にスピーカ４および５の組合せによっておそらく再生されることになる。したがって、スピーカ４の個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）がフロントゾーンおよびサラウンドゾーンの組み合わされた個別のラウドスピーカダイナミックス処理構成データ（例えば、再生リミット閾値）に寄与することは意味のあることである。
この連続的なマッピングを達成する１つの方法は、空間ゾーンｊに対応づけられた成分のレンダリングにおける各スピーカｉの相対的な寄与を記述するスピーカ参加値に等しい重み
を設定することである。そのような値は、スピーカ（例えば、上記ステップ（ｃ）から）および各空間ゾーンに対応づけられた１セットの１つ以上の呼び空間位置に対するレンダリングの役割を有するレンダリングシステムから直接に得られ得る。このセットの呼び空間位置は、各空間ゾーン内に１セットの位置を含み得る。
図５４は、図５３の空間ゾーンおよびスピーカに重ね合わされた呼び空間位置の例を図示する。呼び位置は、番号づけられた円によって示される。フロントゾーンには、正方形の上の隅に位置する２つの位置が対応づけられ、センターゾーンには、正方形の上の中央に単一の位置が対応づけられ、サラウンドゾーンには、正方形の下の隅に２つの位置が対応づけられる。
空間ゾーンに対してスピーカ参加値を計算するために、当該ゾーンに対応づけられた呼び位置のそれぞれは、レンダラを介してレンダリングされて、当該位置に対応づけられたスピーカアクティベーションを生成する。これらのアクティベーションは、例えば、ＣＭＡＰの場合は各スピーカに対するゲインであり、ＦＶの場合は各スピーカに対する所与の周波数における複合値であり得る。次に、各スピーカおよびゾーンに対して、これらのアクティベーションは、空間ゾーンに対応づけられた呼び位置のそれぞれにわたって累積され、値
を生成し得る。この値は、空間ゾーンｊに対応づけられた呼び位置の全セットをレンダリングするためのスピーカｉの総アクティベーションを表す。最後に、空間ゾーンにおけるスピーカ参加値は、スピーカにわたって累積されたこれらのアクティベーションのすべての合計によって正規化された累積アクティベーション
として計算され得る。次いで、重みは、このスピーカ参加値に設定され得る。
上記正規化は、すべてのスピーカｉにわたる
の合計が１に等しくなることを確実にする。これは、式８における重みに対して所望なプロパティである。
いくつかの実装例によると、スピーカ参加値を計算し、閾値をこれらの値の関数として組み合わせるための上記処理は、静的（ｓｔａｔｉｃ）処理として行われ得る。ここで、
得られる組み合わせ閾値は、環境内のスピーカのレイアウトおよび能力を決定するセットアップ手続き中に一度計算される。そのようなシステムにおいて、一旦セットアップされると、個別のラウドスピーカのダイナミックス処理構成データ、および、レンダリングアルゴリズムがラウドスピーカを所望のオーディオ信号位置の関数としてアクティベートする様態の両方は、静的のままであることが仮定され得る。あるシステムにおいて、しかし、これらの態様の両方は、例えば、再生環境内の状態の変化に応答して、経時的に変化し得、したがって、そのような変化を考慮するために、組み合わされた閾値を上記処理にしたがって更新することが望ましい。この更新は、連続的な方法で行ってもよいし、イベントをきっかけとする方法で行ってもよい。
ＣＭＡＰおよびＦＶレンダリングアルゴリズムの両方は、聴取環境内の変化に応答可能な１つ以上のダイナミックに構成可能な機能に適合するように拡張され得る。例えば、図５３を参照して、スピーカ３の近くに位置する人物は、スピーカに関連するスマートアシスタントのウェイクワードを発声することにより、システムを当該人物からの後のコマンドを聞くように待機する状態に設定し得る。ウェイクワードが発声されると、システムは、ラウドスピーカと連携するマイクロフォンを使用して人物の位置を決定し得る。次いで、この情報を用いて、システムは、スピーカ３上のマイクロフォンが人物をより良く聞き得るように、スピーカ３から再生されているオーディオのエネルギーを他のスピーカへ転用するように選択し得る。そのようなシナリオにおいて、図５３におけるスピーカ２は、ある期間、スピーカ３の役割に本質的に「とって代わり」、これにより、サラウンドゾーンに対するスピーカ参加値は、著しく変化する。スピーカ３の参加値は、低減し、スピーカ２の参加値は、増大する。次いで、ゾーン閾値は、変化したスピーカ参加値に依存するので、再計算され得る。あるいは、またはレンダリングアルゴリズムに対するこれらの変更に加えて、スピーカ３のリミット閾値は、スピーカが歪むことを防止するために設定された呼び値よりも低くされ得る。これにより、スピーカ３から再生される残りのオーディオは一切、人物を聴取するマイクロフォンを邪魔すると決定されるある閾値を超えないことが確実になり得る。ゾーン閾値はまた、個別のスピーカ閾値の関数であるので、この場合も更新され得る。
図５５は、本明細書において開示されるような装置またはシステムによって行われ得る方法の一例の概要を示すフロー図である。方法５５００ブロックは、本明細書に記載の他の方法と同様に、必ずしも示された順序で行われない。ある実装例において、方法５５００のブロックのうちの１つ以上が同時に行われ得る。さらに、方法５５００のいくつかの実装例は、図示および／または記載されたものよりも多くのまたは少ないブロックを含み得る。方法５５００のブロックは、１つ以上のデバイスによって行われ得る。これらのデバイスは、図６に図示の上記制御システム６１０などの制御システム、または他の開示された制御システム例のうちの１つであり得る（または、それを含み得る）。いくつかの例において、方法５５００は、図２ＣのＣＨＡＳＭ２０８Ｃ、図２ＤのＣＨＡＳＭ２０８Ｄ、図３ＣのＣＨＡＳＭ３０７、または、図４のＣＨＡＳＭ４０１などのオーディオセッションマネージャなどからの命令にしたがって、少なくとも部分的に、行われ得る。
この例によると、ブロック５５０５は、制御システムによって、インタフェースシステムを介して、聴取環境の複数のラウドスピーカのそれぞれに対して、個別のラウドスピーカダイナミックス処理構成データを取得することを含む。この実装例において、個別のラウドスピーカダイナミックス処理構成データは、複数のラウドスピーカのうちの各ラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データセットを含む。いくつかの例によると、１つ以上のラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データは、１つ以上のラウドスピーカの１つ以上の能力に対応し得る。この例において、個別のラウドスピーカダイナミックス処理構成データセットのそれぞれは、少なくとも１つのタイプのダイナミックス処理構成データを含む。
いくつかの場合において、ブロック５５０５は、個別のラウドスピーカダイナミックス処理構成データセットを聴取環境の複数のラウドスピーカのそれぞれから取得することを含み得る。他の例において、ブロック５５０５は、個別のラウドスピーカダイナミックス処理構成データセットをメモリ内に格納されたデータ構造から得ることを含み得る。例えば、個別のラウドスピーカダイナミックス処理構成データセットは、例えば、ラウドスピーカのそれぞれに対するセットアップ手続きの一部として、予め得られ、データ構造内に格納されていてもよい。
いくつかの例によると、個別のラウドスピーカダイナミックス処理構成データセットは、所有権下にあり得る。いくつかのそのような例において、個別のラウドスピーカダイナミックス処理構成データセットは、類似の特性を有するスピーカに対する個別のラウドスピーカダイナミックス処理構成データに基づいて予め推定されていてもよい。例えば、ブロック５５０５は、複数のスピーカおよび複数のスピーカのうちのそれぞれに対する対応の個別のラウドスピーカダイナミックス処理構成データセットを示すデータ構造から最も類似のスピーカを決定するスピーカマッチング処理を含み得る。スピーカマッチング処理は、例えば、１つ以上のウーファ、ツイータおよび／またはミッドレンジスピーカのサイズの比較に基づき得る。
この例において、ブロック５５１０は、制御システムによって、複数のラウドスピーカに対して聴取環境ダイナミックス処理構成データを決定することを含む。この実装例によると、聴取環境ダイナミックス処理構成データを決定することは、複数のラウドスピーカのうちの各ラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データセットに基づく。聴取環境ダイナミックス処理構成データを決定することは、例えば、１つ以上のタイプの個別のラウドスピーカダイナミックス処理構成データの平均を取ることによって、ダイナミックス処理構成データセットの個別のラウドスピーカダイナミックス処理構成データを組み合わせることを含み得る。いくつかの場合において、聴取環境ダイナミックス処理構成データを決定することは、１つ以上のタイプの個別のラウドスピーカダイナミックス処理構成データの最小値または最大値を決定することを含み得る。いくつかのそのような実装例によると、聴取環境ダイナミックス処理構成データを決定することは、１つ以上のタイプの個別のラウドスピーカダイナミックス処理構成データの最小値または最大値と平均との間を補間することを含み得る。
この実装例において、ブロック５５１５は、制御システムによって、インタフェースシステムを介して、１つ以上のオーディオ信号および対応づけられた空間データを含むオーディオデータ受信することを含む。例えば、空間データは、オーディオ信号に対応する、意図され、知覚された空間位置を示し得る。この例において、空間データは、チャネルデータおよび／または空間メタデータを含む。
この例において、ブロック５５２０は、ダイナミックス処理を、制御システムによって、聴取環境ダイナミックス処理構成データに基づいて、オーディオデータに対して行って、処理されたオーディオデータを生成することを含む。ブロック５５２０のダイナミックス処理は、本明細書において開示されたダイナミックス処理方法のいずれかを含み得る。その方法は、１つ以上の再生リミット閾値、圧縮データなどを適用することを含むが、それに限定されない。
ここで、ブロック５５２５は、制御システムによって、複数のラウドスピーカのうちの少なくともいくつかを含む１セットのラウドスピーカを介した再生のために、処理されたオーディオデータをレンダリングして、レンダリングされたオーディオ信号を生成することを含む。いくつかの例において、ブロック５５２５は、ＣＭＡＰレンダリング処理、Ｆ
Ｖレンダリング処理、またはその２つの組合せを適用することを含み得る。この例において、ブロック５５２０は、ブロック５５２５より前に行われる。しかし、上述したように、ブロック５５２０および／またはブロック５５１０は、ブロック５５２５のレンダリング処理に少なくとも部分的に基づき得る。ブロック５５２０および５５２５は、図４９の聴取環境ダイナミックス処理モジュールおよびレンダリングモジュール４９２０を参照して上述した処理などの処理を行うことを含み得る。
この例によると、ブロック９３０は、インタフェースシステムを介して、レンダリングされたオーディオ信号を１セットのラウドスピーカに与えることを含む。一例において、ブロック９３０は、スマートホームハブ４９０５によって、そのインタフェースシステムを介して、レンダリングされたオーディオ信号をラウドスピーカ４９２５ａ～４９２５ｍに与えることを含み得る。
いくつかの例において、方法５５００は、レンダリングされたオーディオ信号が与えられる１セットのラウドスピーカのうちの各ラウドスピーカに対する個別のラウドスピーカダイナミックス処理構成データにしたがって、レンダリングされたオーディオ信号に対してダイナミックス処理を行うことを含み得る。例えば、図４９を再度参照すると、ダイナミックス処理モジュールＡ～Ｍは、ラウドスピーカ４９２５ａ～４９２５ｍに対する個別のラウドスピーカダイナミックス処理構成データにしたがって、レンダリングされたオーディオ信号に対してダイナミックス処理を行い得る。
いくつかの実装例において、個別のラウドスピーカダイナミックス処理構成データは、複数のラウドスピーカのうちの各ラウドスピーカに対する再生リミット閾値データセットを含み得る。いくつかのそのような例において、再生リミット閾値データセットは、複数の周波数のそれぞれに対する再生リミット閾値を含み得る。
聴取環境ダイナミックス処理構成データを決定することは、いくつかの場合において、複数のラウドスピーカにわたって最小再生リミット閾値を決定することを含み得る。いくつかの例において、聴取環境ダイナミックス処理構成データを決定することは、再生リミット閾値の平均を取り、複数のラウドスピーカにわたって平均化された再生リミット閾値を得ることを含み得る。いくつかのそのような例において、聴取環境ダイナミックス処理構成データを決定することは、複数のラウドスピーカにわたって最小再生リミット閾値を決定し、最小再生リミット閾値と平均化された再生リミット閾値との間を補間することを含み得る。
いくつかの実装例によると、再生リミット閾値の平均を取ることは、再生リミット閾値の重みづけ平均を決定することを含み得る。いくつかのそのような例において、重みづけ平均は、制御システムによって実装されたレンダリング処理の特性、例えば、ブロック５５２５のレンダリング処理の特性に少なくとも部分的に基づき得る。
いくつかの実装例において、オーディオデータに対してダイナミックス処理を行うことは、空間ゾーンに基づき得る。空間ゾーンのそれぞれは、聴取環境の１サブセットに対応し得る。
いくつかのそのような実装例によると、ダイナミックス処理は、空間ゾーンのそれぞれに対して別個に行われ得る。例えば、聴取環境ダイナミックス処理構成データを決定することは、空間ゾーンのそれぞれに対して別個に行われ得る。例えば、複数のラウドスピーカにわたってダイナミックス処理構成データセットを組み合わせることは、１つ以上の空間ゾーンのそれぞれに対して別個に行われ得る。いくつかの例において、１つ以上の空間ゾーンのそれぞれに対して別個に、複数のラウドスピーカにわたってダイナミックス処理
構成データセットを組み合わせることは、１つ以上の空間ゾーンにわたる所望のオーディオ信号位置の関数としてのレンダリング処理によるラウドスピーカのアクティベーションに少なくとも部分的に基づき得る。
いくつかの例において、１つ以上の空間ゾーンのそれぞれに対して別個に、複数のラウドスピーカにわたってダイナミックス処理構成データセットを組み合わせることは、１つ以上の空間ゾーンのそれぞれにおける各ラウドスピーカに対するラウドスピーカ参加値に少なくとも部分的に基づき得る。各ラウドスピーカ参加値は、１つ以上の空間ゾーンのそれぞれの内の１つ以上の呼び空間位置に少なくとも部分的に基づき得る。呼び空間位置は、いくつかの例において、Ｄｏｌｂｙ５．１、Ｄｏｌｂｙ５．１．２、Ｄｏｌｂｙ７．１、Ｄｏｌｂｙ７．１．４またはＤｏｌｂｙ９．１サラウンド音ミックスにおけるチャネルの正準な位置に対応し得る。いくつかのそのような実装例において、各ラウドスピーカ参加値は、１つ以上の空間ゾーンのそれぞれの内の１つ以上の呼び空間位置のそれぞれにおけるオーディオデータのレンダリングに対応する各ラウドスピーカのアクティベーションに少なくとも部分的に基づく。
いくつかのそのような例によると、再生リミット閾値の重みづけ平均は、空間ゾーンに対するオーディオ信号近傍度の関数としてのレンダリング処理によるラウドスピーカのアクティベーションに少なくとも部分的に基づき得る。いくつかの場合において、重みづけ平均は、空間ゾーンのそれぞれの内の各ラウドスピーカに対するラウドスピーカ参加値に少なくとも部分的に基づき得る。いくつかのそのような例において、各ラウドスピーカ参加値は、空間ゾーンのそれぞれの内の１つ以上の呼び空間位置に少なくとも部分的に基づき得る。例えば、呼び空間位置は、Ｄｏｌｂｙ５．１、Ｄｏｌｂｙ５．１．２、Ｄｏｌｂｙ７．１、Ｄｏｌｂｙ７．１．４またはＤｏｌｂｙ９．１サラウンド音ミックスにおけるチャネルの正準な位置に対応し得る。いくつかの実装例において、各ラウドスピーカ参加値は、空間ゾーンのそれぞれの内の１つ以上の呼び空間位置のそれぞれにおけるオーディオデータのレンダリングに対応する各ラウドスピーカのアクティベーションに少なくとも部分的に基づき得る。
図５６Ａおよび５６Ｂは、いくつかの実施形態にしたがって実装され得るシステムの例を図示する。図５６Ｂは、図５６Ａにおけるユーザの位置５６０１が図５６Ｂにおけるユーザの位置１１３と異なる点で、図５６Ａと異なる。
図５６Ａおよび図５６Ｂにおいて、標識された要素は、以下の通りである：
５６０７：ゾーン１、
５６１２：ゾーン２、
５６０１：ゾーン１内のユーザ（話者）位置、
５６０２：直接的でローカルなボイス（ユーザによって発声された）、
５６０３：ゾーン１内に位置するスマートオーディオデバイス（例えば、ボイスアシスタントデバイス）内の複数のラウドスピーカ、
５６０４：ゾーン１内に位置するスマートオーディオデバイス（例えば、ボイスアシスタントデバイス）内の複数のマイクロフォン、
５６０５：ゾーン１内に位置する家電製品、例えばランプ、
５６０６：ゾーン１内に位置する家電製品内の複数のマイクロフォン、
５６１３：ゾーン２内のユーザ（話者）位置、
５６０８：ゾーン２内に位置するスマートオーディオデバイス（例えば、ボイスアシスタントデバイス）内の複数のラウドスピーカ、
５６０９：ゾーン２内に位置するスマートオーディオデバイス（例えば、ボイスアシスタントデバイス内の複数のマイクロフォン、
５６１０：ゾーン２内に位置する家電製品（例えば、冷蔵庫）、および
５６１１：ゾーン２内に位置する家電製品内の複数のマイクロフォン。
図５７は、実施形態にしたがって、ある環境（例えば、ホーム）において実装されたシステムのブロック図である。システムは、ユーザ位置を追跡する「フォローミー」機構を実装する。図５７において、標識された要素は、以下の通りである：
５７０１：決定されたアクティビティ（例えば、入力５７０６Ａによって示される）に対する使用に最良のマイクロフォンおよびラウドスピーカについて、入力を受け取り、決定を行う（当該入力に応答して）ように構成されたサブシステム（モジュールまたは「フォローミー」モジュールと呼ばれることもある）、
５７０１Ａ：決定されたアクティビティに対する使用に最良のシステムのラウドスピーカ（単数または複数）、および／または、ユーザ（例えば、話者）が現在位置するゾーン（すなわち、ゾーンマップ５７０３によって示されるゾーンのうちの１つ）に関する決定（モジュール５７０１において決定される）を示すデータ、
５７０１Ｂ：決定されたアクティビティに対する使用に最良のシステムのマイクロフォン（単数または複数）、および／または、ユーザが現在位置するゾーン（すなわち、ゾーンマップ５７０３によって示されるゾーンのうちの１つ）に関する決定（モジュール５７０１において決定される）を示すデータ、
５７０２：例えば、環境のゾーン内の、ユーザ（例えば、話者、例えば、図５６Ａまたは５６Ｂのユーザ）の位置を決定するように構成されたユーザ位置サブシステム（モジュール）。いくつかの実施形態において、サブシステム５７０２は、ユーザのゾーンを推定する（例えば、マイクロフォン５７０５のうちの少なくともいくつかから得られた複数の音響特徴にしたがって）ように構成される。いくつかのそのような実施形態において、目標は、ユーザの正確な幾何的位置を推定することではなく、ユーザが位置する別々のゾーンのロバストな推定を形成することである（例えば、大きなノイズおよび残留エコーの存在下に）、
５７０２Ａ：モジュール５７０２によって決定され、モジュール５７０１にアサートされるユーザ（話者）の現在の位置を示す情報（データ）、
５７０３：システムの環境のゾーン（例えば、システムが図５６Ａおよび５６Ｂの環境内にある場合の図５６Ａおよび５６Ｂのゾーン）、およびゾーン内の位置によってグループ化されたシステムのすべてのマイクロフォンおよびラウドスピーカのリストを示すゾーンマップ与えるゾーンマップサブシステム。いくつかの実装例において、サブシステム５７０３は、ゾーンマップを示すデータを格納するメモリであるか、または、それを含む。いくつかの例によると、サブシステム５７０１、５７０２および／または５７０３の機能は、本明細書において、ＳＰＡＳＭ（例えば、図２ＣのＳＰＡＳＭ２０７Ｃを参照）と呼ばれるものによって与えられ得る、
５７０３Ａ：少なくとも１つのゾーン（ゾーンマップの）およびゾーンマップの各そのようなゾーン（例えば、ゾーンの少なくとも１サブセットのそれぞれ）に含まれた複数のマイクロフォンおよびラウドスピーカについての情報（データ）であって、モジュール５７０１および／またはモジュール５７０２にアサートされる情報（データ）（システムのいくつかの実装例において）、
５７０４：マイクロフォン５７０５の出力の前処理を行うように接続および構成された前処理サブシステム。サブシステム５７０４は、１つ以上のマイクロフォン前処理サブシ
ステム（例えば、エコーマネジメントサブシステム、ウェイクワード検出器、および／または音声認識サブシステムなど）を実装し得る。したがって、サブシステム５７０４は、本明細書において「メディアエンジン」と呼ばれ得るもののコンポーネントの例である（例えば、図４のメディアエンジン４４０、４４１および４４２を参照）、
５７０４Ａ：サブシステム５７０４によって生成され、そこから出力される、前処理されたマイクロフォン信号（単数または複数）、
５７０５：複数のマイクロフォン（例えば、図５６Ａおよび５６Ｂのマイクロフォン５６０４、５６０６、５６０９、および５６１１を含む）、
５７０６：少なくとも１つの現在のオーディオアクティビティを実装するように接続および構成されたサブシステム（例えば、複数の現在進行中のオーディオアクティビティ）。各そのようなオーディオアクティビティ（便宜上、本明細書において「アクティビティ」と呼ばれることもある）は、音を検出すること（少なくとも１つのマイクロフォンを使用して）および／または音を生成すること（少なくとも１つのラウドスピーカから音を出射することによって）を含む。そのようなオーディオアクティビティの例は、音楽再生（例えば、サブシステム５７０７によるレンダリングのためのオーディオを与えるステップを含む）、ポッドキャスト（例えば、サブシステム５７０７によるレンダリングのためのオーディオを与えるステップを含む）、および／または通話（例えば、サブシステム５７０７によるレンダリングのためのリモート会議オーディオを与えること、ならびにサブシステム５７０４に与えられる各マイクロフォン信号を処理および／または送信することを含む）を含むが、それらに限定されない。したがって、サブシステム５７０６は、本明細書において、「ソフトウェアアプリケーション」、「アプリケーション」、「アプリ」、または、ソフトウェアアプリケーション、アプリケーションもしくはアプリを実行するように構成されたデバイスと呼ばれ得るものの例である（例えば、図４のアプリケーション４１０、４１１および４１２を参照）、
５７０６Ａ：サブシステム５７０６によって実装された現在進行中のアクティビティについての情報（データ）であって、サブシステム５７０６によって生成され、サブシステム５７０６からモジュール５７０１にアサートされる情報（データ）、
５７０７：システムの少なくとも１つの現在のアクティビティの実行中に生成されるか、または、そうでなければ与えられるオーディオをレンダリングする（例えば、スピーカ５７０８を駆動するためのスピーカフィードを生成することによって）ように接続および構成されたマルチチャネルラウドスピーカレンダラサブシステム。例えば、サブシステム５７０７は、データ５７０１Ａにしたがって、ユーザの現在の位置（例えば、ゾーン）において、関係するラウドスピーカによって出射された音がユーザによって知覚可能である（例えば、はっきりと、または最良もしくは所望の様態で）ように、１サブセットのスピーカ５７０８（異なるスマートオーディオデバイス内に実装され得るか、または、それに接続され得る）による再生のためにオーディオをレンダリングするように実装され得る。したがって、サブシステム５７０７は、本明細書において「メディアエンジン」と呼ばれ得るもののコンポーネントの例である（例えば、図４のメディアエンジン４４０、４４１および４４２を参照）、
５７０８：複数のラウドスピーカ（例えば、図５６Ａおよび５６Ｂの５６０３および５６０８を含む）、および
５７０９：ユーザ（例えば、話者、例えば、図５６Ａまたは５６Ｂのユーザ）からのボイスコマンドであって、システムの典型的な実施例において、サブシステム５７０４から
出力され、モジュール５７０１に与えられるボイスコマンド（単数または複数）。
要素５７０１、５７０２、および５７０３（または、要素５７０２および５７０３）は、図５７のシステムのユーザ位置およびアクティビティ制御サブシステムと総呼ばれ得る。
図５７のシステム（およびいくつかの他の実施形態）の要素は、スマートオーディオデバイス内に実装され得るか、または、それに接続され得る。例えば、ラウドスピーカ５７０８のすべてもしくは一部、および／または、マイクロフォン５７０５のすべてもしくは一部は、１つ以上のスマートオーディオデバイス内に実装され得るか、または、それに接続され得、あるいは、マイクロフォンおよびラウドスピーカのうちの少なくともいくつかは、Ｂｌｕｅｔｏｏｔｈ送信器／受信器（例えば、スマートフォン）に接続されたＢｌｕｅｔｏｏｔｈデバイス内に実装され得る。また、例えば、図５７のシステムの１つ以上の他の要素（例えば、要素５７０１、５７０２、５７０３、５７０４、および５７０６のすべてまたは一部）（および／または、後述の図６０システムの要素５７０１、５７０２、５７０３、５７０４、５７０６、および６０１１のすべてまたは一部）は、スマートオーディオデバイス内に実装され得るか、または、それらに接続され得る。そのような例示の実施形態において、「フォローミー」モジュール５７０１は、システムの少なくとも１つのマイクロフォンよって検出された音（ユーザによって発せられた）に応答してユーザ位置をトラッキングすることによって、スマートオーディオデバイスをコーディネート（オーケストレート）するように動作する（および、他のシステム要素が動作する）。例えば、そのようなコーディネーションは、システムの要素（単数または複数）によって出射されるべき音のレンダリングおよび／もしくはシステムのマイクロフォン（単数または複数）の出力（単数または複数）の処理、ならびに／または、システムによって（例えば、システムの要素５７０６によって、例えば、図６０のアクティビティマネージャ６０１１またはシステムの別のアクティビティマネージャを制御することによって）実装された少なくとも１つのアクティビティのコーディネーションを含む。
典型的には、サブシステム５７０２および５７０３は、しっかりと統合されている。サブシステム５７０２は、マイクロフォン５７０５（例えば、非同期マイクロフォンとして実装される）のすべてまたは一部（例えば、２つ以上）の出力を受信し得る。サブシステム５７０２は、分類器を実装し得る。分類器は、いくつかの例において、システムのスマートオーディオデバイス内に実装される。他の例において、分類器は、マイクロフォンと通信するように接続および構成された、システムの別のタイプのデバイス（例えば、オーディオを与えるようには構成されていないスマートデバイス）によって実装され得る。例えば、マイクロフォン５７０５の少なくともいくつかは、いずれのスマートオーディオデバイスにも含まれないが、分類器としてサブシステム５７０２を実装するデバイスと通信するように構成された別々のマイクロフォン（例えば、家電製品内の）であり得る。分類器は、各マイクロフォンの出力信号から得られた複数の音響特徴にしたがってユーザのゾーンを推定するように構成され得る。いくつかのそのような実施形態において、目標は、ユーザの正確な幾何的位置を推定することでなく、別々のゾーンのロバストな推定値を形成すること（例えば、大きなノイズおよび残留エコーの存在下に）である。
本明細書において、環境内の、オブジェクト、またはユーザ、または話者の「幾何的位置」という表現（上記および下記の記載において呼ばれる）は、システム環境全体を基準とした（例えば、環境内のどこかを原点に有するデカルトまたは極座標系にしたがう）、または、環境内の特定のデバイス（例えば、スマートオーディオデバイス）を基準にした（例えば、デバイスを原点として有するデカルトまたは極座標系にしたがう）座標系（例えば、ＧＰＳ座標を基準とする座標系）に基づく位置を指す。いくつかの実装例において、サブシステム５７０２は、マイクロフォン５７０５の幾何的位置を参照せずに、環境内
のユーザの位置の推定値を決定するように構成される。
「フォローミー」モジュール５７０１は、複数の入力（１つ以上の５７０２Ａ、５７０３Ａ、５７０６Ａ、および５７０９）に応答して動作し、出力５７０１Ａおよび５７０１Ｂの一方または両方を生成するように接続および構成される。次に、入力の例の詳細を説明する。
入力５７０３Ａは、ゾーンマップの各ゾーン（音響ゾーンと呼ばれることもある）に関する情報を示し得る。入力５７０３Ａは、各ゾーン内に位置するシステムのデバイス（例えば、スマートデバイス、マイクロフォン、ラウドスピーカなど）のリスト、各ゾーンの寸法（単数または複数）（例えば、同じ座標系において、幾何的位置単位として）、環境に対する、および／もしくは、他のゾーンに対する各ゾーン（例えば、キッチン、リビングルーム、寝室など）の幾何的位置、システムの各デバイスの幾何的位置（例えば、それぞれのゾーンに対して、および／または、デバイスのうちの他のデバイスに対して）、ならびに／またはゾーンの名称のうちの１つ以上を含むが、それらに限定されない。
入力５７０２Ａは、ユーザ（話者）が位置する音響ゾーン、そのようなゾーン内の話者の幾何的位置、および話者がそのようなゾーン内にどれくらい長くいたかのうちのすべてまたは一部に関するリアルタイム情報（データ）であり得るか、または、それを含み得る。入力５７０２Ａはまた、前回のセンテンスに記述された情報のいずれかの正確性または正しさに関するユーザ位置モジュール５７０２による確信度、および／または、話者の移動の履歴（例えば、過去Ｎ時間内、ここで、パラメータＮは、変更可能（ｃｏｎｆｉｇｕｒａｂｌｅ）である）を含み得る。
入力５７０９は、ユーザ（話者）によって発せられた１つのボイスコマンド、または２つ以上のボイスコマンドであり得る。各ボイスコマンドは、前処理サブシステム５７０４によって検出されている（例えば、「フォローミー」モジュール５７０１の機能に関するか、または、関しないコマンド）。
モジュール５７０１の出力５７０１Ａは、レンダリングサブシステム（レンダラ）５７０７に、話者の現在の（例えば、最後に決定された）音響ゾーンにしたがって処理を適合化させるための命令である。モジュール５７０１の出力５７０１Ｂは、前処理サブシステム５７０４に、話者の現在の（例えば、最後に決定された）音響ゾーンにしたがって処理を適合化させるための命令である。
出力５７０１Ａは、例えば、レンダラ５７０７に、システムによって実装されている、関係するアクティビティに対して可能な最良の方法でレンダリングを行わせるために、話者の現在の音響ゾーンに対する話者の幾何的位置、ならびに話者に対するラウドスピーカ５７０８のそれぞれの幾何的位置および距離を示し得る。可能な最良の方法は、アクティビティおよびゾーン、ならびに必要に応じてまた、話者の予め決定された（例えば、記録された）好みに依存し得る。例えば、アクティビティが映画であり、話者がリビングルームにいる場合、出力５７０１Ａは、映画館のような体験のために、レンダラ５７０７に可能な限り多くのラウドスピーカを使用して映画のオーディオを再生するように命令し得る。アクティビティが音楽またはポッドキャストであり、かつ、話者がキッチンまたは寝室にいる場合、出力５７０１Ａは、より個人的な（ｉｎｔｉｍａｔｅ）体験のために、レンダラ５７０７に、最も近いラウドスピーカだけを用いて音楽をレンダリングするように命令し得る。
出力５７０１Ｂは、サブシステム５７０４による使用のためのマイクロフォン５７０５の一部またはすべての、ソートされたリストを示し得る（すなわち、出力（単数または複
数）が無視されるべきでないマイクロフォン（単数または複数）であって、代わりに、サブシステム５７０４によって使用（すなわち、処理）されるべきであるマイクロフォン）、およびユーザ（話者）に対する各そのようなマイクロフォンの幾何的位置を示し得る。いくつかの実施形態において、サブシステム５７０４は、マイクロフォン５７０５のうちの一部またはすべての出力を、以下のうちの１つ以上によって決定された方法で処理され得る。話者（出力５７０１Ｂによって示される）からの各マイクロフォンの距離、利用可能ならば、各マイクロフォンに対するウェイクワードスコア（すなわち、ユーザによって発声されたウェイクワードをマイクロフォンが聞いた尤度）、各マイクロフォンの信号対ノイズ比（すなわち、話者によって発せられた音声がマイクロフォンからキャプチャされた環境ノイズおよび／またはオーディオ再生に対してどれだけ大きいか）、または、上記のうちの２つ以上の組合せである。ウェイクワードスコアおよび信号対ノイズ比は、前処理サブシステム５７０４によって計算され得る。通話などのいくつかのアプリケーションにおいて、サブシステム５７０４は、マイクロフォン５７０５（上記リストに示す）のうちの最良のマイクロフォンの出力を使用するだけであり得るか、または、当該リストからの複数のマイクロフォンからの信号を用いてビームフォーミングを実装し得る。分散型音声認識器または分散型ウェイクワード検出器などのいくつかのアプリケーションを実装するために、サブシステム５７０４は、マイクロフォン５７０５の出力を使用し得る（例えば、出力５７０１Ｂによって示された、ソートされたリストから決定され、ここで、ソートは、例えば、ユーザに対する近傍度の順であり得る）。
いくつかのアプリケーション例において、サブシステム５７０４（モジュール５７０１および５７０２を有する）は、出力５７０１Ｂを使用して（すなわち、少なくとも部分的に応答して）、ユーザのゾーンからの音をより効果的に取り上げようとする（例えば、ウェイクワードに続くコマンドをより良く認識するために）マイクロフォン選択または適応ビームフォーミング方式を実装する。そのようなシナリオにおいて、モジュール５７０２は、以下を含む（それらに限定しない）様々な方法のいずれかで、ユーザゾーン決定を向上させるために、サブシステム５７０４の出力５７０４Ａを、ユーザゾーン予測の品質に関するフィードバックとして使用し得る：
ウェイクワードに続くボイスコマンドの誤認識を生じる予測にペナルティを科すこと。例えば、コマンドに対するボイスアシスタントの応答をユーザが中断させることになる（例えば、「Ａｍａｎｄａ、ストップ！」のような取消コマンド様のものを発することにより）ようなユーザゾーン予測に、ペナルティが科され得る、
音声認識器（サブシステム５７０４によって実装される）がコマンドを正しく認識した低確信度をもたらす予測にペナルティを科すこと、
セカンドパス（ｓｅｃｏｎｄ－ｐａｓｓ）ウェイクワード検出器（サブシステム５７０４によって実装される）が高確信度でウェイクワードを遡及的に検出することに失敗する結果となる予測にペナルティを科すこと、および／または
ウェイクワードの確信度の高い認識および／またはユーザボイスコマンドの正確な認識を生じる予測を強化すること。
図５８は、図５７のモジュール５７０１の例示の実施形態の要素のブロック図である。図５８において、標識された要素は、以下の通りである：
図５７のシステムの要素（図２および３と同じ標識）、
５８０４：少なくとも１つの特定のタイプのボイスコマンド５７０９を認識し、モジュール５８０３に対して（ボイスコマンド５７０９が特定の認識されたタイプであることを認識したことに応答して）指示をアサートするように接続および構成されたモジュール、
５８０３：出力信号５７０１Ａおよび５７０１Ｂ（または、いくつかの実装例において、信号５７０１Ａまたは信号５７０１Ｂのうちの一方だけ）を生成するように接続および構成されたモジュール、および
５７０９：話者からのボイスコマンド（単数または複数）。
図５８の実施形態において、「フォローミー」モジュール５７０１は、以下のように動作するように構成される。話者からのボイスコマンド５７０９（例えば、サブシステム５７０６が通話を実装している間に発声された、「Ａｍａｎｄａ、通話をこちらに移動して」）に応答して、それにしたがって使用されるべきレンダラ５７０７および／またはサブシステム５７０４に対して、ラウドスピーカ（出力５７０１Ａによって示される）および／またはマイクロフォン（出力５７０１Ｂによって示される）の変更されたセットを決定すること。
モジュール５７０１が図５８と同様に実装された状態で、ユーザ位置モジュール５７０２またはサブシステム５７０４（図５７において両方が図示される）は、話者の直接のローカルなボイス（すなわち、サブシステム５７０４からモジュール５７０２に与えられるマイクロフォン信号５７０４Ａ（単数または複数）は、そのようなローカルなボイスを示し、または、コマンド５７０９がモジュール５７０２およびモジュール５７０１に与えられる）からのコマンドを認識する簡単なコマンド・制御モジュールであり得るか、または、それを含み得る。例えば、図５７の前処理サブシステム５７０４は、ボイスコマンド（マイクロフォン５７０５のうちの１つ以上のマイクロフォンの出力（単数または複数）によって示される）を認識し、出力５７０９（そのようなコマンドを示す）をモジュール５７０２およびモジュール５７０１に与えるように接続および構成された簡単なコマンド・制御モジュールを含み得る。
モジュール５７０１の図５８実装例の例において、モジュール５７０１は、以下などによって、話者からのボイスコマンド５７０９（例えば、「通話をここに移動して」）に応答するように構成される。
ゾーンマッピングにより話者の位置（入力５７０２Ａによって示される）を知り、現在の話者音響ゾーン情報（出力５７０１Ａによって示される）にしたがってレンダラ５７０７を命令し、話者の現在の音響ゾーンに対して最良のラウドスピーカ（単数または複数）を使用するために当該レンダラが自身のレンダリング構成を変更できるようにする、および／または
ゾーンマッピングにより話者の位置（入力５７０２Ａによって示される）を知り、前処理モジュール５７０４に対して、現在の話者音響ゾーン情報（出力５７０１Ｂによって示される）にしたがって最良のマイクロフォン（単数または複数）のみの出力を使用するように命令すること。
モジュール５７０１の図５８の実装例において、モジュール５７０１は、以下のように動作するように構成される：
１．ボイスコマンド（５７０９）を待つ、
２．ボイスコマンド５７０９を受信したら、受信されたコマンド５７０９が所定の特定のタイプのものであるかどうか、（例えば、「［アクティビティ］をここに移動して」または「フォローミー」のうちの一方であるかどうかを決定する（モジュール５８０４において）、ここで、「［アクティビティ］」は、システムによって（例えば、サブシステム５７０６によって）現在において実装されているアクティビティのいずれかを示す、
３．ボイスコマンドが特定のタイプのものでなければ、ボイスコマンドを無視する（その結果、無視されているボイスコマンドが受信されなかったかのように出力信号５７０１Ａおよび／または出力信号５７０１Ｂが生成される）、および
４．ボイスコマンドが特定のタイプのものであるならば、システムの他の要素に対して、現在の音響ゾーンにしたがって処理を変更するように命令するために、出力信号５７０１Ａおよび／または出力信号５７０１Ｂを生成する（モジュール５８０３において）（ユーザ位置モジュール５７０２によって検出され、入力５７０２Ａによって示されるように。
図５９は、図５７のモジュール５７０１の別の例示の実施形態（図５９において５９００と標識される）およびその動作のブロック図である。図５９において、標識された要素は、以下の通りである：
５９００：「フォローミー」モジュール、
図５７のシステムの要素（図２および４と同一に標識される）、
モジュール５９００の要素５８０３および５８０４（図５８のモジュール５７０１の対応する要素と同様に標識される）、
５８０１：話者の（例えば、ユーザの）過去の体験から学習された好みを示すデータのデータベース。データベース５８０１は、非一時的にデータを格納するメモリとして実装され得る、
５８０１Ａ：話者の過去の体験から学習された好みに関するデータベース５８０１からの情報（データ）、
５８０２：入力５７０９および／もしくは５７０６Ａのうちの１つ以上、ならびに／または、出力５７０１Ａおよび５７０１Ｂ（モジュール５８０３によって生成される）のうちの１つもしくは両方に応答してデータベース５８０１を更新するように接続および構成された学習モジュール、
５８０２Ａ：話者の好みについての更新された情報（データ）（モジュール５８０２によって生成され、格納のためにデータベース５８０１に与えられる）、
５８０６：決定された話者の位置についての確信度を評価するように接続および構成されたモジュール、
５８０７：決定された話者の位置が新たな位置であるかどうかを評価するように接続および構成されたモジュール、および
５８０８：ユーザ確認（例えば、ユーザの位置の確認）をリクエストするように接続および構成されたモジュール。
図５９のフォローミーモジュール５９００は、図５８のフォローミーモジュール５７０１の例示の実施形態の拡張を実装する。モジュール５９００は、使用すべき最良のラウドスピーカ（単数または複数）およびマイクロフォン（単数または複数）について、話者の過去の体験に基づいて自動的に決定するように構成される。
図５７のモジュール５７０１が図５９のモジュール５９００として実装された状態で、図５７の前処理サブシステム５７０４は、ボイスコマンド（マイクロフォン５７０５のうちの１つ以上のマイクロフォンの出力（単数または複数）によって示される）を認識し、出力５７０９（認識されたコマンドを示す）をモジュール５７０２およびモジュール５９００の両方に与えるように接続および構成された簡単なコマンド・制御モジュールを含み得る。より一般には、ユーザ位置モジュール５７０２またはサブシステム５７０４（図５７において両方を図示する）は、話者の直接のローカルなボイス（例えば、サブシステム５７０４からモジュール５７０２に与えられるマイクロフォン信号５７０４Ａ（単数または複数）は、そのようなローカルなボイスを示し、認識されたボイスコマンド５７０９は、サブシステム５７０４からモジュール５７０２およびモジュール５９００に与えられる）からのコマンドを認識するように構成されたコマンド・制御モジュールであり得るか、または、それを実装し得る。モジュール５７０２は、認識されたコマンドを使用して、話者の位置を自動的に検出するように構成される。
図５９の実施形態において、モジュール５７０２は、ゾーンマップ５７０３とともに、音響ゾーンマッピング器（ｍａｐｐｅｒ）を実装し得る（モジュール５７０２は、ゾーンマップ５７０３とともに動作するように接続および構成され得るか、または、ゾーンマップ５７０３と一体化され得る）。いくつかの実装例において、ゾーンマッピング器は、Ｂｌｕｅｔｏｏｔｈデバイスまたは他の無線周波数ビーコンの出力を使用して、ゾーン内の
話者の位置を決定し得る。いくつかの実装例において、ゾーンマッピング器は、自身のシステム内に履歴情報を保持し、出力５７０２Ａを生成し得る（図５９のモジュール５９００、または図５７のモジュール５７０１の別の実施形態に与えるため）。出力５７０２Ａは、話者の位置についての確率的な確信度を示す。話者の位置が正しく決定された確率は、ラウドスピーカレンダラの鋭敏さ（ａｃｕｉｔｙ）に影響を与えるためにモジュール５８０６（モジュール５９００の）によって使用され得る（例えば、例えば、モジュール５９００が当該位置からの話者の発話の、データ５８０１Ａによって示される他のインスタンス（ｉｎｓｔａｎｃｅ）を見たという理由で、モジュール５８０６が話者の位置について著しく確信している場合、出力５７０１Ａによって、次いでレンダラ５７０７に、より集中して関係するオーディオをレンダリングさせる）。反対に、話者が前に特定の位置にいたことモジュール５９００が認識せず、モジュール５８０６が話者の位置についての確信度が不十分である（例えば、所定の閾値よりも低い確信度）場合、およびモジュール５８０６は、より広い（ｇｅｎｅｒａｌ）近傍において知覚されるべき関係するオーディオをレンダラ５７０７にレンダリングさせるように、出力５７０１Ａが生成されるようにし得る。
図５９の実装例において、例えば、図５８の例示の実施形態と同様に、話者からのコマンド５７０９は、モジュール５９００に、新たなセットの現在のラウドスピーカおよび／またはマイクロフォンを示すための出力５７０１Ａおよび／または出力５７０１Ｂを生成させ、したがって、使用中の現在のラウドスピーカおよび／またはマイクロフォンを停止するようにさせ得る。音響ゾーン内の話者の位置（例えば、入力５７０２Ａによって示される）、話者が実際に決定されたゾーン内にいる確信度（モジュール５８０６によって決定される）、現在進行中のアクティビティ（すなわち、図５７のサブシステム５７０６によって実装されているアクティビティ、例えば、入力５７０６Ａによって示されたアクティビティ）、および過去に学習された体験（例えば、データ５８０１Ａによって示される）に応じて、モジュール５９００は、決定された進行中のアクティビティに対して、現在使用中のラウドスピーカおよび／またはマイクロフォンを変更することを自動的に決定するように構成される。いくつかの実装例において、そのような自動的な決定ついてシステムに十分な確信がない（例えば、モジュール５８０６が有する決定された話者の位置についての確信度が所定の閾値を超えない）場合、システムは、話者からの位置を確認するためのリクエストを発する（例えば、モジュール５８０６は、モジュール５８０８に、リクエストの発出を出力５７０１Ａにさせるようさせ得る）。このリクエストは、話者に最も近いラウドスピーカからのボイスプロンプトの形態であり得る（例えば、「あなたがキッチンに移動したことを検出しました。ここで音楽を再生したいですか？」というプロンプト）。
図５９のモジュール５９００は、音響ゾーン内における話者の移動、および必要に応じて、過去の体験（データベース５８０１内のデータによって示される）に基づいて、レンダラ５７０７の構成およびどのマイクロフォン（単数または複数）をサブシステム５７０４が使用すべきかについて自動的に決定するように構成される。そうするために、モジュール５９００は、上記コマンド・制御モジュール（前処理サブシステム５７０４またはモジュール５７０２によって実装される）からの入力（例えば、コマンド５７０９（単数または複数））を考慮し得る。この入力は、話者の直接のローカルなボイス、および話者の位置を示す情報（例えば、モジュール５７０２によって生成された入力５７０２Ａ）によって示されたコマンドを示す。
モジュール５９００によって決定がなされた（すなわち、予め決定された１セットのラウドスピーカおよび／またはマイクロフォンにおいて変化を生じさせるために出力５７０１Ａおよび／または出力５７０１Ｂを生成する）後、学習モジュール５８０２がデータ５８０２Ａをデータベース５８０１に格納し得る。データベース５８０１において、データ
５８０２Ａは、将来において自動的に決定された結果がより良くなることを確実にしようとして、決定が満足されたか（例えば、話者が手動で決定を止めなかった）または満足されてないか（例えば、話者がボイスコマンドを発出することによって手動で決定を止めた）を示し得る。
より一般には、出力５７０１Ａおよび／または出力５７０１Ｂの生成（例えば、更新）は、進行中のオーディオアクティビティの時間に、少なくとも１つの前のアクティビティ（出力５７０１Ａおよび／または５７０１Ｂの生成の前、例えば、進行中のオーディオアクティビティの前に生じたアクティビティ）から学習モジュール５８０２（および／または実施形態の別の学習モジュール）によって決定された、学習された体験（例えば、ユーザの学習された好み）を示すデータ（例えば、データベース５８０１から）に応答して、行われ得る。例えば、学習された体験は、現在進行中のオーディオアクティビティ中に存在する条件と同じまたは類似の条件下にアサートされた前のユーザコマンドから決定され得、かつ、出力５７０１Ａおよび／または出力５７０１Ｂは、そのような学習された体験を示すデータ（例えば、データベース５８０１から）に基づく確率的な確信度にしたがって更新され得る（例えば、モジュール５９００が学習された体験に基づいてユーザの好みについて十分に確信がある場合、更新された出力５７０１Ａが、レンダラ５７０７に、関係するオーディオをより集中してレンダリングするようにさせるという意味で、ラウドスピーカレンダラ５７０７の鋭敏さに影響を与える）。
学習モジュール５８０２は、各１セットの同じ入力（モジュール５９００に与えられる）および／または特徴に応答してなされた（および／または有する）最後の正しい決定の簡単なデータベースを実装し得る。このデータベースへの入力は、同じ状況における前の決定が正しかったかどうかに関して、現在のシステムアクティビティ（例えば、入力５７０６Ａによって示される）、現在の話者の音響ゾーン（入力５７０２Ａによって示される）、前の話者の音響ゾーン（また入力５７０２Ａによって示される）、および指示（例えば、ボイスコマンド５７０９によって示される）であり得るか、または、それらを含み得る。あるいは、モジュール５８０２は、話者がシステムの状態を自動的に変更したい確率を有する状態マップを実装できる。ここで、各過去の決定は、正確であるか、正確でないかにかかわらず、そのような確率マップに付加される。あるいは、モジュール５８０２は、モジュール５９００の入力のすべてまたは一部に基づいて学習するニューラルネットワークとして実装され得る。ここで、その出力は、出力５７０１Ａおよび５７０１Ｂを生成するために使用される（例えば、ゾーン変更が要求されるかどうかにかかわらず、レンダラ５７０７および前処理モジュール５７０４を命令するために）。
図５７のシステム（図５９のモジュール５９００として実装されるモジュール５７０１を有する）によって行われる処理のフロー例を以下に説明する：
１．話者が音響ゾーン１（例えば、図５６Ａの要素５６０７）内にいて、Ａｎｔｈｏｎｙとの通話を開始する、
２．ユーザ位置モジュール５７０２およびフォローミーモジュール５９００は、話者がゾーン１内にいることを知り、モジュール５９００は、前処理モジュール５７０４に当該ゾーンに対して最良のマイクロフォンを使用させるために、出力５７０１Ａおよび５７０１Ｂを生成し、レンダラ５７０７に当該ゾーンに対して最良のラウドスピーカ構成を使用させる、
３．話者は、音響ゾーン２（例えば、図５６Ｂの要素５６１２）に移動する、
４．ユーザ位置モジュール５７０２は、話者の音響ゾーンにおける変更を検出し、当該
変更を示すように入力５７０２Ａをモジュール５９００にアサートする、
５．モジュール５９００は、話者が現在の状況のような状況において移動した時に、話者が通話を新たな音響ゾーンに移動させることを要求したことを過去の体験（すなわち、データベース５８０１内のデータが示す）から思い出す。短時間の後、通話を移動させるべきである確信度がある設定の閾値（モジュール５８０６によって決定される）よりも高くなり、モジュール５９００は、前処理サブシステム５７０４に、マイクロフォン構成を新たな音響ゾーンに変更するように命令し、また、レンダラ５７０７に、新たな音響ゾーンに対して最良の体験を与えるように自身のラウドスピーカ構成を調整するように命令する、および
６．話者は、ボイスコマンド５７０９を発声することによって自動決定を停止することをせず（モジュール５８０４がそのような停止を学習モジュール５８０２およびモジュール５８０３に示さないようにするため）、かつ、学習モジュール５８０２は、モジュール５９００がこの場合に正しい決定を行ったことを示すために、データ５８０２Ａがデータベース５８０１内に格納されるようにし、類似の将来の場合に対してそのような決定を強化する。
図６０は、別の例示の実施形態のブロック図である。図６０において、標識された要素は、以下の通りである：
図５７のシステムの要素（図５７および６０と同一に標識される）、
６０１１：サブシステム５７０６およびモジュール５７０１に接続され、かつ、システムが実装される環境（例えば、ホーム）内における、および、それを越えた話者のアクティビティを知るアクティビティマネージャ。アクティビティマネージャ６０１１は、本明細書においオーディオセッションマネージャと呼ばれるものの例である。アクティビティマネージャのいくつかの例は、本明細書においてＣＨＡＳＭと呼ばれる（例えば、図２ＣのＣＨＡＳＭ２０８Ｃ、図２ＤのＣＨＡＳＭ２０８Ｄ、図３ＣのＣＨＡＳＭ３０７および図４のＣＨＡＳＭ４０１を参照、
６０１２：アクティビティマネージャ６０１１に接続されたスマートフォン（本明細書において話者と呼ばれることもあるシステムのユーザ）、およびスマートフォンに接続されたＢｌｕｅｔｏｏｔｈヘッドセット、および
５７０６Ｂ：サブシステム５７０６によって実装された現在進行中のアクティビティ（および／または、システムが実装されている環境を越えた話者のアクティビティ）についての情報（データ）であって、アクティビティマネージャ６０１１および／またはサブシステム５７０６によって生成され、モジュール５７０１への入力として与えられるシステム。
図６０のシステムにおいて、「フォローミー」モジュール５７０１の出力５７０１Ａおよび５７０１Ｂは、アクティビティマネージャ６０１１ならびにレンダラ５７０７および前処理サブシステム５７０４への命令である。命令により、これらのそれぞれは、話者の現在の音響ゾーン（例えば、話者が位置すると決定された新たな音響ゾーン）にしたがって処理を適合化し得る。
図６０のシステムにおいて、モジュール５７０１は、入力５７０６Ｂ（およびモジュール５７０１に与えられた他の入力）に応答して、出力５７０１Ａおよび／または出力５７０１Ｂを生成するように構成される。モジュール５７０１の出力５７０１Ａは、レンダラ５７０７（および／またはアクティビティマネージャ６０１１）に対して、話者の現在の（例えば、新たに決定された）音響ゾーンにしたがって処理を適合化するように命令する。モジュール５７０１の出力５７０１Ｂは、前処理サブシステム５７０４（および／またはアクティビティマネージャ６０１１）に対して、話者の現在の（例えば、新たに決定さ
れた）音響ゾーンにしたがって処理を適合化するように命令する。
図６０のシステムによって実装された処理のフロー例は、システムが家の中に実装されるが、要素６０１２は、家の中で動作してもよいし、家の外で動作してもよいこと、かつ、モジュール５７０１は、図５９のモジュール５９００と同様に実装されることを仮定する。フロー例は、以下の通りである：
１．話者は、散歩のために家の外にいて、スマートフォン要素６０１２上でＡｎｔｈｏｎｙからの電話コールを受ける、
２．話者は、家の中に入り、音響ゾーン１（例えば、図５６Ａの要素５６０７）に入り、通話中となり、そして、要素６０１２のＢｌｕｅｔｏｏｔｈヘッドセットをオフにする、
３．ユーザ位置モジュール５７０２およびモジュール５７０１は、話者が音響ゾーン１に入ったことを検出し、モジュール５７０１は、話者が通話中（サブシステム５７０６によって実装されている）であり、要素６０１２のＢｌｕｅｔｏｏｔｈヘッドセットがオフにされたことを知る（入力５７０６Ｂから）、
４．モジュール５７０１は、過去の体験から、現在の状況と類似の状況において話者が通話を新たな音響ゾーンに移動させることを要求したことを思い出す。短時間後、通話が移動されるべきである確信度が上昇して閾値を超え、モジュール５７０１は、アクティビティマネージャ６０１１に対して（適切な出力５７０１Ａおよび／または５７０１Ｂをアサートすることによって）、通話がスマートフォン要素６０１２から、ホーム内に実装されている図６０のシステムのデバイスに移動されるべきであることを命令する。モジュール５７０１は、前処理サブシステム５７０４に対して（適切な出力５７０１Ｂ（単数または複数）をアサートすることによって）、マイクロフォン構成を新たな音響ゾーンに変更することを命令する。モジュール５７０１はまた、新たな音響ゾーンに対して最良の体験を与えるようにラウドスピーカ構成を調整するように、レンダラ５７０７に対して（適切な出力５７０１Ａをアサートすることによって）命令する、および
５．話者は、ボイスコマンドを発声することによって自動決定（モジュール５７０１によってなされる）を停止することをせず、モジュール５７０１の学習モジュール（５８０２）は、類似の将来の場合に対してそのような決定を強化する際に使用するために、モジュール５７０１がこの場合に正しい決定を行ったことを示すデータを格納する。
他の実施形態は、以下を含み得る：
環境内に複数のスマートオーディオデバイスを含むシステムを制御する方法であって、システムは、１セットの１つ以上のマイクロフォン（例えば、マイクロフォンのそれぞれは、環境内のスマートオーディオデバイスのうちの少なくとも１つと通信するために含まれるか、または、構成される）と、１セットの１つ以上のラウドスピーカとを含み、かつ、環境は、複数のユーザゾーンを含み、この方法は、少なくとも部分的にマイクロフォンの出力信号から、環境内のユーザの位置の推定値を決定するステップを含む。ここで、推定値は、ユーザゾーンのうちのどのユーザゾーン内にユーザが位置するかを示す、方法、
複数のスマートオーディオデバイスにわたってオーディオセッションを管理する方法であって、ユーザのリクエストまたはユーザが発した他の音に応答して、進行中のオーディオアクティビティに対して、１セットの現在使用されているマイクロフォンおよびラウドスピーカを変更するステップを含む方法、および
複数のスマートオーディオデバイスにわたってオーディオセッションを管理する方法であって、少なくとも１つの前の体験に基づいて（例えば、少なくとも１つの、ユーザの過
去の体験から学習された好みに基づいて）、進行中のオーディオアクティビティに対して、１セットの現在使用されているマイクロフォンおよびラウドスピーカを変更するステップを含む方法。
いくつかの実施形態の態様は、以下に続く列挙実施形態例（ｅｎｕｍｅｒａｔｅｄ ｅｘａｍｐｌｅ ｅｍｂｏｄｉｍｅｎｔｓ）（ＥＥＥ）を含む。
ＥＥＥ１．オーディオ信号ルーティングのためにより低いレベル制御を発出できる単一の階層的なシステムを介して集合的に動作する複数のオーディオデバイス（例えば、スマートオーディオデバイス）を備えるデバイスの集合的なシステム（集団）においてオーディオを制御する方法であって、
ａ．制御できる前記デバイス集団に対するアプリケーションのための１つのインタフェースポイントが存在し、
ｂ．この単一のコンタクトポイントとのインタラクションは、前記デバイスについての具体的な詳細に関係せず、
ｃ．前記インタラクションは、
ｉ．ソース、
ｉｉ．デスティネーション、および
ｉｉｉ．優先度
を含む複数の明示的または暗黙的なパラメータを含み、
ｄ．前記システムは、これらのルート（例えば、ＣＨＡＳＭへのリクエスト）のそれぞれに対してユニーク持続識別子を監視し、必要に応じて、また、前記ユニーク持続識別子から複数のプロパティを問い合せることができ（例えば、本質的に連続的なプロパティ）、および
ｅ．前記システムは、オーディオデバイスの制御を実行するために利用可能な（例えば、少なくともいくつか、または任意の、またはすべての利用可能な現在のおよび履歴の）情報を連続的に利用する、方法。
ＥＥＥ２．前記複数のパラメータはまた、モード（例えば、ｓｙｎｃ）を含む、請求項ＥＥＥ１に記載の方法。
ＥＥＥ３．前記複数のパラメータはまた、品質（例えば、オーディオを配信する目標、例えば、理解可能）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ４．前記複数のパラメータはまた、要求（ｉｎｓｉｓｔａｎｃｅ）（例えば、確認されていることをあなたは、どれくらい知りたいか）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ５．前記複数のプロパティは、どれくらいよく（例えば、確信度）聞こえているか（例えば、オーディオが）（例えば、進行中）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ６．前記複数のプロパティは、インタラクション（承認）があった程度を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ７．前記複数のパラメータは、可聴を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ８．前記複数のパラメータは、可聴の欠如を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ９．前記複数のパラメータは、理解可能を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ１０．前記複数のパラメータは、理解可能性の欠如（例えば、マスクキング、「コーン・オブ・サイレンス（ｃｏｎｅ ｏｆ ｓｉｌｅｎｃｅ）」）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ１１．前記複数のパラメータは、空間忠実（例えば、ローカライゼーション能力）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ１２．前記複数のパラメータは、一貫性を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ１３．前記複数のパラメータは、忠実（例えば、符号化の歪みの欠如）を含む、先行する請求項のいずれかに記載の方法。
ＥＥＥ１４．ルートは、単一のデスティネーションを有することだけができる（ユニキャスト）、先行する請求項のいずれかに記載の方法を実装するように構成されたシステム。
ＥＥＥ１５．ルートは、複数のデスティネーションを有してもよい（マルチキャスト）、ＥＥＥ１～ＥＥＥ１３のいずれかに記載の方法を実装するように構成されたシステム。
ＥＥＥ１６．複数のオーディオデバイスを有するオーディオ環境に対するオーディオセッションマネジメント方法であって、前記オーディオセッションマネジメント方法は、
第１のアプリケーションを実装する第１のデバイスから、および、オーディオセッションマネージャを実装するデバイスによって、第１のオーディオセッションに対して第１のルートを開始するための第１のルート開始リクエストを受信するステップであって、前記第１のルート開始リクエストは、第１のオーディオソースおよび第１のオーディオ環境デスティネーションを示し、前記第１のオーディオ環境デスティネーションは、前記オーディオ環境の少なくとも第１のエリアに対応し、前記第１のオーディオ環境デスティネーションは、オーディオデバイスを示さない、ステップと、
前記オーディオセッションマネージャを実装する前記デバイスによって、前記第１のルート開始リクエストに対応する前記第１のルートを確立するステップであって、前記第１のルートを確立するステップは、
前記第１のオーディオセッションの第１のステージに対して、前記オーディオ環境の前記第１のエリア内の少なくとも１つのオーディオデバイスを決定するステップと、
前記第１のオーディオセッションを開始または予定するステップと、
を含む、ステップと、
を含む、オーディオセッションマネジメント方法。
ＥＥＥ１７．前記第１のルート開始リクエストは、第１のオーディオセッション優先度を含む、ＥＥＥ１６に記載のオーディオセッションマネジメント方法。
ＥＥＥ１８．前記第１のルート開始リクエストは、第１の接続モードを含む、ＥＥＥ１６またはＥＥＥ１７に記載のオーディオセッションマネジメント方法。
ＥＥＥ１９．前記第１の接続モードは、同期接続モード、トランザクション接続モードまたは予定接続モードである、ＥＥＥ１８に記載のオーディオセッションマネジメント方法。
ＥＥＥ２０．前記第１のルート開始リクエストは、第１の人物を示し、少なくとも前記第１の人物から承認が要求されることになるかどうかの指示を含む、ＥＥＥ１６～ＥＥＥ１９のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ２１．前記第１のルート開始リクエストは、第１のオーディオセッション目標を含む、ＥＥＥ１６～ＥＥＥ２０のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ２２．前記第１のオーディオセッション目標は、理解可能、オーディオ品質、空間忠実または不可聴のうちの１つ以上を含む、ＥＥＥ２１に記載のオーディオセッションマネジメント方法。
ＥＥＥ２３．前記第１のルートに対して第１の持続ユニークオーディオセッション識別子を決定し、前記第１の持続ユニークオーディオセッション識別子を前記第１のデバイスに送信するステップをさらに含む、ＥＥＥ１６～ＥＥＥ２２のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ２４．前記第１のルートを確立するステップは、前記環境内の少なくとも１つのデバイスに、少なくとも、前記第１のルートに対応する第１のメディアストリームを確立させるステップを含み、前記第１のメディアストリームは、第１のオーディオ信号を含む、ＥＥＥ１６～ＥＥＥ２３のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ２５．前記第１のオーディオ信号が第１のレンダリングされたオーディオ信号にレンダリングされるようにするレンダリング処理をさらに含む、ＥＥＥ２４に記載のオーディオセッションマネジメント方法。
ＥＥＥ２６．第１の時点において前記オーディオ環境の前記第１のエリア内の複数のオーディオデバイスの各オーディオデバイスの第１の位置を自動的に決定する第１のラウドスピーカ自動位置処理を行うステップであって、前記レンダリング処理は、各オーディオデバイスの前記第１の位置に少なくとも部分的に基づく、ステップと、
各オーディオデバイスの前記第１の位置を前記第１のルートに対応づけられたデータ構造に格納するステップと、
をさらに含む、ＥＥＥ２５に記載のオーディオセッションマネジメント方法。
ＥＥＥ２７．前記第１のエリア内の少なくとも１つのオーディオデバイスが変更された位置を有すると判定するステップと、
前記変更された位置を自動的に決定する第２のラウドスピーカ自動位置処理を行うステップと、
前記変更された位置に少なくとも部分的に基づいて、前記レンダリング処理を更新するステップと、
前記変更された位置を前記第１のルートに対応づけられた前記データ構造に格納するステップと、
をさらに含む、ＥＥＥ２５に記載のオーディオセッションマネジメント方法。
ＥＥＥ２８．少なくとも１つのさらなるオーディオデバイスが前記第１のエリアに移動したと判定するステップと、
前記さらなるオーディオデバイスのさらなるオーディオデバイス位置を自動的に決定する第２のラウドスピーカ自動位置処理を行うステップと、
前記さらなるオーディオデバイス位置に少なくとも部分的に基づいて、レンダリング処理を更新するステップと、
前記さらなるオーディオデバイス位置を前記第１のルートに対応づけられた前記データ構造に格納するステップと、
をさらに含む、ＥＥＥ２５に記載のオーディオセッションマネジメント方法。
ＥＥＥ２９．前記第１のルート開始リクエストは、少なくとも第１の人物を第１のルートソースまたは第１のルートデスティネーションとして示す、ＥＥＥ１６～ＥＥＥ２８のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ３０．前記第１のルート開始リクエストは、少なくとも第１のサービスを前記第１のオーディオソースとして示す、ＥＥＥ１６～ＥＥＥ２９のいずれか１項に記載のオーディオセッションマネジメント方法。
ＥＥＥ３１．ＥＥＥ１６～ＥＥＥ３０のいずれか１項に記載の方法を行うように構成された装置。
ＥＥＥ３２．ＥＥＥ１６～ＥＥＥ３０のいずれか１項に記載の方法を行うように構成されたシステム。
ＥＥＥ３３．符号化されたソフトウェアを有する１つ以上の非一時的な媒体であって、前記ソフトウェアは、ＥＥＥ１６～ＥＥＥ３０のいずれか１項に記載の方法を行うように１つ以上のデバイスを制御するための命令を含む、媒体。
いくつかの開示された実装例は、開示された方法の一部またはすべてを行うように構成された（例えば、プログラムされた）システムまたはデバイス、および開示された方法またはそのステップの一部またはすべてを実装するためのコードを格納する有体のコンピュータ読み取り可能な媒体（例えば、ディスク）を含む。いくつかの開示されたシステムは、開示された方法またはそのステップの一部またはすべての実装例を含む、データに対して様々な動作のうちのいずれかを行うように、ソフトウェアまたはファームウェアを用いてプログラムされた、および／またはそうでなければ、構成されたプログラマブル汎用プロセッサ、デジタル信号プロセッサ、またはマイクロプロセッサであること、または、それを含むことが可能である。そのような汎用プロセッサは、入力デバイスと、メモリと、アサートされたデータに応答して、開示された方法（またはそのステップ）の一部またはすべてを行うようにプログラムされた（および／またはそうでなければ、構成された）処理サブシステムとを含むコンピュータシステムであってもよいし、それを含んでもよい。
いくつかの実施形態は、開示された方法の一部またはすべてを実行することを含む、オーディオ信号（単数または複数）に対して必要な処理を行うように構成された（例えば、プログラムされた、およびそうでなければ、構成された）構成可能な（例えば、プログラム可能な）デジタル信号プロセッサ（ＤＳＰ）として実装され得る。代替として、または、付加として、いくつかの実施形態（または、それらの要素）は、開示された方法の一部またはすべてを含む様々な動作のいずれかを行うように、ソフトウェアまたはファームウェアを用いてプログラムされた、および／またはそうでなければ、構成された汎用プロセッサ（例えば、入力デバイスおよびメモリを含み得るパソコン（ＰＣ）または他のコンピュータシステムまたはマイクロプロセッサ）として実装され得る。代替として、または、付加として、いくつかの実施形態の要素は、開示された方法の一部またはすべてを行うように構成された（例えば、プログラムされた）汎用プロセッサまたはＤＳＰとして実装され得、システムはまた、他の要素（例えば、１つ以上のラウドスピーカおよび／または１つ以上のマイクロフォン）を含み得る。開示された方法の一部またはすべてを行うように
構成された汎用プロセッサは、いくつかの例において、入力デバイス（例えば、マウスおよび／またはキーボード）、メモリ、およびディスプレイデバイスに接続され得る。
本開示のいくつかの実装例は、開示された方法またはそのステップの一部またはすべてを行うためのコードを格納するコンピュータ読み取り可能な媒体（例えば、ディスクまたは他の有体のストレージ媒体）（例えば、それを行うことを実行可能なコーダ（ｃｏｄｅｒ））であってもよいし、それを含んでもよい。
特定の実施形態およびアプリケーションを本明細書に記載したが、本明細書に図示、記載および請求した内容の範囲を逸脱せずに、本明細書に記載された実施形態およびアプリケーションに対して多くの変更が可能であることが当業者に明らかとなるであろう。ある実装例が図示および記載されたが、本開示が記載および図示の特定の実施形態ならびに記載の特定の方法に限定されないことが理解されるべきである。

Claims (1)

  1. オーディオ環境のオーディオシステムのためのオーディオセッションマネジメント方法であって、
    前記オーディオシステムの、オーディオセッションマネージャと複数のスマートオーディオデバイスとの間に複数のスマートオーディオデバイス通信リンクを確立するステップであって、前記複数のスマートオーディオデバイスのうちの各スマートオーディオデバイスは、単一目的オーディオデバイスまたは多目的オーディオデバイスのいずれかを含み、各スマートオーディオデバイスは、１つ以上のラウドスピーカと、メディアエンジンとを含む、ステップと、
    前記オーディオセッションマネージャと複数のアプリケーションデバイスとの間に複数のアプリケーション通信リンクを確立するステップであって、前記複数のアプリケーションデバイスのうちの各アプリケーションデバイスは、複数のアプリケーションのうちのアプリケーションを実行し、前記複数のアプリケーション通信リンクは、前記複数のアプリケーションデバイスからの複数のルート開始リクエストに応答して確立され、前記アプリケーションは、前記スマートオーディオデバイスおよび前記スマートオーディオデバイスの前記１つ以上のラウドスピーカを選択せず、前記アプリケーションは、どのスマートオーディオデバイスが前記アプリケーションによって与えられるコマンドの実装に関与するかを認識しない、ステップと、
    前記オーディオセッションマネージャによって、各スマートオーディオデバイスの各メディアエンジンの１つ以上の第１のメディアエンジン能力を決定するステップであって、各メディアエンジンは、それぞれのスマートオーディオデバイスによって受信された１つ以上のオーディオメディアストリームを管理し、前記メディアエンジンのメディアエンジンサンプルクロックにしたがって前記１つ以上のオーディオメディアストリームに対してスマートオーディオデバイス信号処理を行うように構成される、ステップと、
    前記オーディオセッションマネージャによって、前記複数のアプリケーション通信リンクを介して、各アプリケーションからアプリケーション制御信号を受信するステップと、
    前記オーディオセッションマネージャによって、前記アプリケーション制御信号を用いて各スマートオーディオデバイスにそれぞれのスマートオーディオデバイス通信リンクを介して送信されたオーディオセッションマネジメント制御信号を介して、それぞれのメディアエンジンの前記メディアエンジン能力にしたがって前記複数のスマートオーディオデバイスを制御するステップであって、前記オーディオセッションマネージャは、前記オーディオセッションマネジメント制御信号を各スマートオーディオデバイスに、前記それぞれのメディアエンジンの前記メディアエンジンサンプルクロックを参照せずに送信し、前記オーディオセッションマネージャは、それぞれのメディアエンジンを制御するすべてのアプリケーションに対して、前記アプリケーションがスマートオーディオデバイス上で動作するか、他のデバイス上で動作するかにかかわらず、ゲートウェイとして機能する、ステップと、
    を含むオーディオセッションマネジメント方法。
JP2023076015A 2019-07-30 2023-05-02 オーディオデバイスのコーディネーション Pending JP2023120182A (ja)

Applications Claiming Priority (32)

Application Number Priority Date Filing Date Title
US201962880121P 2019-07-30 2019-07-30
US201962880118P 2019-07-30 2019-07-30
US201962880115P 2019-07-30 2019-07-30
US201962880114P 2019-07-30 2019-07-30
ES201930702 2019-07-30
US62/880,114 2019-07-30
US62/880,121 2019-07-30
US62/880,118 2019-07-30
US62/880,115 2019-07-30
ESP201930702 2019-07-30
US201962949998P 2019-12-18 2019-12-18
US62/949,998 2019-12-18
EP19217580.0 2019-12-18
EP19217580 2019-12-18
US202062971421P 2020-02-07 2020-02-07
US62/971,421 2020-02-07
US202062992068P 2020-03-19 2020-03-19
US62/992,068 2020-03-19
US202062705143P 2020-06-12 2020-06-12
US62/705,143 2020-06-12
US202062705351P 2020-06-23 2020-06-23
US62/705,351 2020-06-23
US202062705410P 2020-06-25 2020-06-25
US62/705,410 2020-06-25
US16/929,215 US11659332B2 (en) 2019-07-30 2020-07-15 Estimating user location in a system including smart audio devices
US16/929,215 2020-07-15
US202062705883P 2020-07-20 2020-07-20
US202062705884P 2020-07-20 2020-07-20
US62/705,883 2020-07-20
US62/705,884 2020-07-20
JP2022506121A JP7275375B2 (ja) 2019-07-30 2020-07-28 オーディオデバイスのコーディネーション
PCT/US2020/043795 WO2021021766A1 (en) 2019-07-30 2020-07-28 Coordination of audio devices

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2022506121A Division JP7275375B2 (ja) 2019-07-30 2020-07-28 オーディオデバイスのコーディネーション

Publications (1)

Publication Number Publication Date
JP2023120182A true JP2023120182A (ja) 2023-08-29

Family

ID=71944433

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2022506086A Pending JP2022542388A (ja) 2019-07-30 2020-07-27 オーディオ装置の協調
JP2022506121A Active JP7275375B2 (ja) 2019-07-30 2020-07-28 オーディオデバイスのコーディネーション
JP2023076015A Pending JP2023120182A (ja) 2019-07-30 2023-05-02 オーディオデバイスのコーディネーション

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2022506086A Pending JP2022542388A (ja) 2019-07-30 2020-07-27 オーディオ装置の協調
JP2022506121A Active JP7275375B2 (ja) 2019-07-30 2020-07-28 オーディオデバイスのコーディネーション

Country Status (6)

Country Link
US (2) US20220345820A1 (ja)
EP (2) EP4005247A1 (ja)
JP (3) JP2022542388A (ja)
KR (1) KR102550030B1 (ja)
CN (2) CN114514756A (ja)
WO (2) WO2021021752A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111312239B (zh) * 2020-01-20 2023-09-26 北京小米松果电子有限公司 响应方法、装置、电子设备及存储介质
US20220148575A1 (en) * 2020-11-12 2022-05-12 Samsung Electronics Co., Ltd. Electronic apparatus and controlling method thereof
WO2023131399A1 (en) * 2022-01-04 2023-07-13 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for multi device audio object rendering
US11769506B1 (en) * 2022-05-09 2023-09-26 Amazon Technologies, Inc. Response orchestrator for natural language interface
CN116028005B (zh) * 2022-05-16 2023-10-20 荣耀终端有限公司 音频会话获取方法、装置、设备和存储介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6329908B1 (en) * 2000-06-23 2001-12-11 Armstrong World Industries, Inc. Addressable speaker system
US7492913B2 (en) * 2003-12-16 2009-02-17 Intel Corporation Location aware directed audio
US7668939B2 (en) * 2003-12-19 2010-02-23 Microsoft Corporation Routing of resource information in a network
US8214447B2 (en) * 2004-06-08 2012-07-03 Bose Corporation Managing an audio network
WO2009086602A1 (en) * 2008-01-07 2009-07-16 Avega Systems Pty Ltd Systems and methods for providing media playback in a networked environment
US8929807B2 (en) * 2011-08-30 2015-01-06 International Business Machines Corporation Transmission of broadcasts based on recipient location
US9727321B2 (en) * 2012-10-11 2017-08-08 Netflix, Inc. System and method for managing playback of streaming digital content
DE102013217367A1 (de) * 2013-05-31 2014-12-04 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung und verfahren zur raumselektiven audiowiedergabe
US10002499B2 (en) * 2014-11-27 2018-06-19 Abb Schweiz Ag Distribution of audible notifications in a control room
IL243513B2 (en) * 2016-01-07 2023-11-01 Noveto Systems Ltd A system and method for voice communication
US10743101B2 (en) * 2016-02-22 2020-08-11 Sonos, Inc. Content mixing
US9749583B1 (en) * 2016-03-31 2017-08-29 Amazon Technologies, Inc. Location based device grouping with voice control
BR112018077408A2 (pt) * 2016-07-05 2019-07-16 Sony Corp aparelho e método de formação do campo de som, e, programa.
CN107026943B (zh) * 2017-03-30 2020-04-24 联想(北京)有限公司 语音交互方法及系统
CN107948838A (zh) * 2017-12-25 2018-04-20 广州市尊浪电器有限公司 一种音箱的控制方法及音箱设备
US10511930B2 (en) * 2018-03-05 2019-12-17 Centrak, Inc. Real-time location smart speaker notification system

Also Published As

Publication number Publication date
EP4005231A1 (en) 2022-06-01
CN114208207A (zh) 2022-03-18
KR20220028091A (ko) 2022-03-08
US20240163340A1 (en) 2024-05-16
KR102550030B1 (ko) 2023-07-03
US20220345820A1 (en) 2022-10-27
JP7275375B2 (ja) 2023-05-17
WO2021021766A1 (en) 2021-02-04
CN114514756A (zh) 2022-05-17
WO2021021752A1 (en) 2021-02-04
JP2022542963A (ja) 2022-10-07
EP4005247A1 (en) 2022-06-01
JP2022542388A (ja) 2022-10-03

Similar Documents

Publication Publication Date Title
JP7275375B2 (ja) オーディオデバイスのコーディネーション
US11089402B2 (en) Conversation assistance audio device control
US11809775B2 (en) Conversation assistance audio device personalization
JP2019518985A (ja) 分散したマイクロホンからの音声の処理
US20220272454A1 (en) Managing playback of multiple streams of audio over multiple speakers
US10854216B2 (en) Adaptive beamforming microphone metadata transmission to coordinate acoustic echo cancellation in an audio conferencing system
US10978085B2 (en) Doppler microphone processing for conference calls
US11997448B2 (en) Multi-modal audio processing for voice-controlled devices
US20200174735A1 (en) Wearable audio device capability demonstration
US11968268B2 (en) Coordination of audio devices
JP2022514325A (ja) 聴覚デバイスにおけるソース分離及び関連する方法
WO2018198790A1 (ja) コミュニケーション装置、コミュニケーション方法、プログラム、およびテレプレゼンスシステム
RU2818982C2 (ru) Управление акустической эхокомпенсацией для распределенных аудиоустройств
WO2024027315A1 (zh) 音频处理方法、装置、电子设备、存储介质和程序产品
US20220337969A1 (en) Adaptable spatial audio playback
CN116806431A (zh) 通过相互设备可听性在用户位置处的可听性
CN117133296A (zh) 显示设备及多路语音信号的混音处理方法
CN116547751A (zh) 针对遍布式聆听插入强制间隙
CN116783900A (zh) 基于子带域声学回声消除器的声学状态估计器

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230623

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230623