JP2009536752A - オーディオプラットフォームに適応したオーディオ・デコーディングのためのオーディオ・ストリームの優先順位付け - Google Patents

Abstract

本開示は、モバイル装置で実行するビデオゲームのような、ソフトウェア・アプリケーションのオーディオ・ストリームの優先順位付けスキームを実行するオーディオコーディング技術について記述される。オーディオ・ストリームの優先度は、アプリケーションのコンテンツ製作者により定義される。さらに、（オーディオ警報のような）アプリケーションと関係しない追加的なオーディオ・ストリームの優先度も同様に定義される。モバイル装置は、アプリケーションを実行するプロセッサと、モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信し、アプリケーションとは関係のない追加的な優先順位付オーディオ・ストリームを受信し、そして、共通オーディオ・ストリームを形成する優先度に従い、アプリケーションと関係する優先順位付オーディオ・ストリームのサブセットと追加的な優先順位付オーディオ・ストリームを結合する、オーディオ・デコーディング装置を含む。

Description

本出願は、オーディオコーディング技術に関し、そして、特に、種々のプラットフォームで実行され得るアプリケーションのオーディオ・ストリームのためのオーディオ・デコーディング技術に関する。

オーディオコーディングは、衛星ラジオ、デジタルラジオ、インターネットストリーミング（ウェブラジオ）、デジタル音楽プレーヤー、無線モバイル装置、そして、各種のモバイルマルチメディアアプリケーションのような多くのアプリケーションや環境で使用される。動画像専門家グループ（ＭＰＥＧ）、ウィンドウズ（登録商標）・メディア・オーディオ（ＷＭＡ）による標準、ドルビー・ラボラトリー社による標準のようなオーディオコーディング標準は多数存在する。ＭＰ３標準と、アップルコンピュータにより販売される“アイポッド（iPod）”装置に使用されるアドバンス・オーディオコーディング（ＡＡＣ）のようなＭＰ３標準の後継を含む、多くのオーディオコーディング標準が出現し続けている。オーディオコーディング標準は、圧縮を使用する低ビットレートの高品質オーディオコーディングの実現を追求することが一般的である。いくつかのオーディオコーディングでは“ロスレス(loss-less)”、つまり、コーディングがオーディオ信号を劣化させはしないが、オーディオコーディングによっては、追加的な圧縮を行うために、いくらかのロスを招いてしまう可能性がある。

多くのアプリケーションでは、オーディオコーディングは、ビデオ電話通信（ＶＴ）あるいはストリーミングビデオのようなアプリケーションに対してマルチメディアコンテンツを供給するために、ビデオコーディングと一緒に使用される。オーディオコーディングもまた、ビデオゲーム等のようなマルティメディアアプリケーションをサポートするモバイル装置で一般的に使用される。実際に、モバイル装置は、使用者にオーディオ出力を提供し、それゆえに、オーディオコーディング技術を使用する幅広い種類の機能性とコンテンツをますます組み入れ、オーディオとビデオの情報は、オーディオとビデオデータのブロックを含むフレームに分割される可能性がある。オーディオ出力のストリームは、フレームのデコーディングの後のオーディオフレームにより定義することができる。
不運にも、異なるモバイル装置が、幅広い種類の機器構成を前提としている。特に、異なるモバイル装置は、異なるプラットホームを使用する可能性がある。たとえば、いくつかのモバイル装置は、他のモバイル装置より多くのメモリを含む可能性がある。さらに、異なるモバイル装置における処理パワーは、劇的に変化し得る。モバイル装置プラットホームにおけるこうした変形のために、そのようなモバイル装置に対するコンテンツ提供者は、異なる装置に対する異なるソフトウェアアプリケーションの設計を余儀なくされることが多い。たとえば、同じビデオゲームコンセプトが、異なるプラットフォームを持つ装置に対して、異なる設計を要する可能性がある。より低品質の携帯電話が、より高品質の携帯電話に対して設計される所与のマルチメディアビデオゲームのオーディオ情報を、確実にリアルタイムでデコードするためには、不十分なメモリや処理パワーを有する可能性がある。このケースでは、ゲームがより低品質の携帯電話で機能するために、コンテンツ提供者は、ビデオゲームのオーディオ複雑性を減少するよう、ビデオゲームを再設計する必要があるかもしれない。

一般に、本開示は、モバイル装置で実行するビデオゲームのようなアプリケーションに対して定義されるオーディオ・ストリームの優先順位スキーム（prioritization scheme）を実行するオーディオコーディング技術を説明する。モバイル装置プラットフォームは、異なる装置において変化することが可能であるため、所与のプラットフォームによりサポートされるオーディオデコーディング量は、モバイル装置で稼動するそのようなアプリケーションを設計するコンテンツ製作者にとって未知であり得る。本開示に従って、コンテンツ製作者は、自分たちが作り出すアプリケーションの種々のオーディオ・ストリームの優先度（priority）を定義することが可能となる。そして、モバイル装置における実行に際して、優先順位が付けられたオーディオ・ストリームのサブセットは、アプリケーションに対するオーディオ出力を定義する共通オーディオ・ストリームを形成する優先度に従い結合されることが可能である。

本開示に従って、アプリケーションは、よりプラットフォーム独立となることが可能であり、複数のモバイル装置のプラットフォームに対してより互換性を持つ可能性がある。低品質のプラットフォームは、共通オーディオ・ストリームの生成において、より少ないオーディオ・ストリームを使用する可能性があるが、アプリケーションがなお機能的であることを確実にするために、一般に、最高優先度のストリームを使用する。高品質のプラットフォームは、対照的に、拡張されたオーディオ体験を使用者に提供するために、共通オーディオ・ストリームの生成において、オーディオ・ストリームのより多くを使用することが可能である。同じアプリケーションは、異なるプラットフォームで実行されるが、異なるプラットフォームは、異なるメモリ量と処理パワーを持つ可能性があるため、オーディオ出力が異なる可能性がある。コンテンツ製作者は、最重要のオーディオ・ストリームがあらゆるプラットフォームにおけるアプリケーションの実行に含まれることを確実にするために、アプリケーションの異なるオーディオ・ストリームのオーディオ優先順位（audio prioritization）を定義することが可能であるが、その一方で、一つ以上の重要性の低いオーディオ・ストリームは、低品質のプラットフォームにおけるアプリケーションの実行では除外される可能性がある。

さらに、本開示に従い、アプリケーションと関係ない一つ以上の追加的なオーディオ・ストリームが同様に優先順位付けされる。たとえば、（入来する電話呼出の警報通知のような）オーディオ警報は、典型的には、装置の製造者によって、スキームで優先順位付けされることが可能である。共通オーディオ・ストリームの生成は、優先度に従って、アプリケーションと関係する優先順位が付けられたオーディオ・ストリームのサブセットと追加的な優先順位が付けられたオーディオ・ストリームの結合を含む可能性がある。各オーディオ・ストリームは、独自の優先度を有する可能性があり、典型的にオーディオ警報は、スキームにおいて最高の優先度を与えられる。しかし、本開示は、この点に必ずしも限定されるわけではない。

一つの具体例において、本開示は、モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信することと、アプリケーションと関係ない追加的な優先順位付オーディオ・ストリームを受信することと、共通オーディオ・ストリームを形成する優先度に従い、アプリケーションと関係する優先順位付オーディオ・ストリームのサブセットと追加的な優先順位付オーディオ・ストリームを結合することとを含む方法を提供する。

他の具体例では、本開示は、アプリケーションを実行するプロセッサと、モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信し、アプリケーションと関係ない追加的な優先順位付オーディオ・ストリームを受信し、共通オーディオ・ストリームを形成する優先度に従い、アプリケーションと関係する優先順位付オーディオ・ストリームのサブセットと追加的な優先順位付オーディオ・ストリームを結合する、オーディオ・デコーディング装置を含む装置を提供する。

いくつかのケースにおいては、本開示の技術は、コンピュータ可読媒体に格納されるソフトウェアで実行され得る。このように、他の具体例では、本開示は、モバイル装置において実行時に、モバイル装置に、モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信させ、アプリケーションと関係ない追加的な優先順位付オーディオ・ストリームを受信させ、共通オーディオ・ストリームを形成する優先度に従い、アプリケーションと関係する優先順位付オーディオ・ストリームのサブセットと追加的な優先順位付オーディオ・ストリームを結合させることを引き起こす実行可能命令を含むコンピュータ可読媒体を提供する。

他の具体例において、本開示は、コンテンツ製作者と装置製造者により実行される方法を提供する。この場合には、方法は、アプリケーションのオーディオ・ストリームの優先度を定義すること、アプリケーションと関係ないオーディオ警報の優先度を定義すること、アプリケーションと警報の結合オーディオ出力を定義するために第１のモバイル装置がアプリケーションのオーディオ・ストリームの第１のサブセットを使用するように、第１のプラットフォームを定義する第１のモバイル装置へアプリケーションを提供すること、第１のサブセットが第２のサブセットとは異なるように、第２のモバイル装置がアプリケーションと警報の結合オーディオ出力を定義するためにアプリケーションのオーディオ・ストリームの第２のサブセットを使用するように、第２のプラットフォームを定義する第２のモバイル装置へアプリケーションを提供すること、を含む。アプリケーションのオーディオ・ストリームの優先度は、典型的に、コンテンツ製作者により定義されるが、その一方で、アプリケーションと関係ない追加的なオーディオ・ストリームの優先度は、装置製造者により割り当てられる可能性がある。

各種の具体例の追加的な詳細は、下記に添付された図と説明で明らかにされる。他の特徴、目的、有利な点は、説明と図、そして、請求項から明らかになるだろう。

詳細な説明

本開示は、アプリケーションのコンテンツ製作者により定義され得るソフトウェア・アプリケーションのオーディオ・ストリームに対する優先順位付スキームを実行するオーディオコーディング技術について記述する。特に、（モバイル装置で実行するビデオゲームのような）アプリケーションのコンテンツ製作者は、ビデオゲームにおける異なるオーディオストリームの優先度を定義することが可能である。さらに、本開示に従い、アプリケーションと関係のない一つ以上の追加的なオーディオストリームは、典型的には装置製造業者により、同様に優先順位付される。たとえば、（入来する電話呼出の警報通知のような）オーディオ警報は、そのスキームにおいて優先順位付されることが可能である。そして、共通オーディオストリームは、優先度に従い、アプリケーションと関係する優先順位付オーディオストリームのサブセットと追加的な優先順位付オーディオストリームを結合することにより生成され得る。各オーディオ・ストリームは、独自の優先度を持つ可能性があり、オーディオ警報はそのスキームにおいて最高の優先度を与えられることが典型的である。しかしながら、本開示は必ずしもこの点に限定されるわけではない。

モバイル装置のプラットフォームは、種々の装置において変化することが可能であるため、所与のプラットフォームによりサポートされるオーディオ・デコーディング量は、モバイル装置上で稼動させるようなアプリケーションを設計するコンテンツ製作者には不明である可能性がある。従って、コンテンツ製作者に、彼らの作り出すアプリケーションの種々のオーディオ・ストリームの優先度を定義可能にすることにより、オーディオ出力は、そのようなアプリケーションを実行する種々のプラットフォームに対して適応性があるようになり得る。

より低品質のプラットフォームは、共通オーディオ・ストリームの生成に際して、より少ないオーディオ・ストリームを利用する可能性があるが、アプリケーションがなおも機能的であるように、最高優先度のストリームを使用することが一般的である。より高品質のプラットフォームは、対照的に、拡張されたオーディオ体験を使用者に提供するために、共通オーディオ・ストリームの生成に際して、より多くのオーディオ・ストリームを使用することが可能である。異なるプラットフォームは異なるメモリ量と処理パワーを有する可能性があるので、同じアプリケーションは異なるプラットフォームで実行するが、オーディオ出力は異なる可能性がある。コンテンツ製作者は、最重要オーディオ・ストリームがすべてのプラットフォームにおいてアプリケーション実行に関する出力に含まれることを確実にするために、アプリケーションの異なるオーディオ・ストリームに優先順位を付けることが可能であるが、一方では、より低い重要度ストリームは、より低品質プラットフォームにおいてアプリケーション実行の出力から除外される可能性がある。さらに、（警報のような）アプリケーションと関係ないオーディオ・ストリームは、典型的には装置製造者により、スキームにおいて優先順位付けが可能である。本開示に従い、アプリケーションのオーディオは、プラットフォーム適応であるが、一方では、たとえば、入来する電話呼出や使用者に対して警報を要する他の事象のケースでは、アプリケーションのそれの上に、追加的なオーディオを端挟む（interject）能力をさらにサポートする。

図１は、本開示の技術を実行し得る典型的なモバイル装置のブロック図である。モバイル装置１０は、オーディオ・デコーディング能力を含む幅広い種類のモバイル装置すべてを含むことが可能である。例では、（アップルコンピュータから商業的に利用可能な）アイポッド（ｉＰｏｄ）装置のようなデジタル音楽プレーヤー、類似のデジタル音楽装置、モバイルデジタルテレビ装置、無線通信装置、個人用携帯情報機器（ＰＤＡ）、ラップトップコンピュータ、ハンドヘルドコンピュータ、デジタルカメラ、デジタル録音装置、携帯あるいは衛星ラジオ電話、（時には「ウォーキートーキー」と呼ばれる）直接ツーウェイ通信装置、（任天堂アメリカから商業的に入手可能な）ゲームボーイ装置のようなハンドヘルドビデオゲーム装置、類似のゲーム装置などを含む。

典型的なモバイル装置１０は、メモリ１４、（キーボード、マウス、トラックボール、ジョイステックなどのような）ユーザーインターフェース１３、ディスプレイ１７に結合されたプロセッサ１２を含む。装置１０は、情報の無線通信を促進するために、アンテナとモデムのような図１で示されていない他の部品を含む可能性がある。プロセッサ１２は、デジタル信号プロセッサ（ＤＳＰ）として実装され得るオーディオ・デコーディング装置１６に結合される。オーディオ・デコーディング装置１６もまた、メモリ１４に結合され、オーディオ・デコーディング処理の態様（aspect）を加速するためにハードウェア１８にアクセスする可能性がある。いくつかのケースでは、プロセッサ１２もまた、ハードウェア１８に結合される可能性がある。さらに、プロセッサ１２は駆動回路１５に連結されるが、駆動回路１５はプロセッサからオーディオ制御信号を受信し、スピーカー１９Ａと１９Ｂを駆動するために駆動信号を生成し、それによって可聴（audible）サウンドを生成する。たとえば、ハードウェア１８は、デジタルアナログ変換器（ＤＡＣ）を含む可能性があるが、デジタルアナログ変換器は、スピーカー１９Ａと１９Ｂを駆動するように増幅可能なアナログ信号を配信するために、駆動回路１５に直接連結される可能性がある。

プロセッサ１２はマイクロプロセッサを含む可能性があり、汎用プロセッサである可能性や、あるいはモバイル装置に対して特別に設計された特殊プロセッサである可能性もある。いずれの場合でも、本開示に従い、プロセッサ１２は一般にソフトウェア・アプリケーションを実行する。使用者は、ユーザーインターフェース１３を通じて、ソフトウェア・アプリケーションと相互に作用する（ｉｎｔｅｒａｃｔ）ことができる。そして、マルチメディア出力は、ディスプレイ１７とスピーカー１９Ａと１９Ｂを通じて、使用者に配信されることが可能である。オーディオ・デコーディング装置１６は、コード化されたオーディオ・ストリームのデコード／伸長（decompression）のような、集中的なオーディオデコーディングタスクを取り扱うために、プロセッサ１２により呼び出される。

本開示に従い、プロセッサ１２で実行するアプリケーションは、優先順位付オーディオ・ストリームを定義する。そして、その優先度はアプリケーションの製作者により定義される。たとえば、アプリケーションは、使用者が娯楽目的のためにモバイル装置１０で実行可能なビデオゲームを含む可能性がある。そのようなビデオゲームのアプリケーションは、一つ以上のタイプのＢＧＭのようないくつかのオーディオ・ストリームと、（爆発や砲撃のような）多くの対話型のリアルタイムサウンド効果を典型的に含む。オーディオ・ストリームは、ゲームの種々のオーディオチャンネルに対応する可能性がある。いくつかのビデオゲームでは、たとえば、ジャンプ、走行、スライディング、運転、回転、方向変換など、ビデオゲームキャラクターのリアルタイムアクションに関係する多数のサウンド効果を供給する可能性がある。同様に、サウンドは、背景キャラクターとも関係する可能性があり、つまり、そのようなキャラクターの出現または滅亡とも関係する可能性がある。実際に、ビデオゲームにおけるサウンド効果チャンネルの数は、一般に制限がなく、典型的には（アプリケーションのコンテンツ提供者とも一般に言われる）ゲーム設計者により定義される。

ビデオゲームのいくつかのサウンドは、使用者がビデオゲームのアクションを理解し、そして一般にゲームをナビゲートするために必要である。いくつかのゲームでは、たとえば、オーディオの指示は、ビデオゲームキャラクターによるアクションに反応して、ゲームから使用者に対して配信される可能性がある。そのような指示は、使用者がゲームを理解するために必要とされる可能性がある。しかしながら、他のサウンドは、砲撃や爆発のように重要度が低い可能性があり、使用者体験を高めるが、使用者がゲームを理解するには不必要な可能性がある。さらに、他のサウンドは、ＢＧＭや他のサウンドのように、重要度が低い可能性さえある。

本開示に従い、オーディオ・ストリームは、プロセッサ１２で実行するアプリケーションにおいて別々に符号化される（encoded）。さらに、符号化されたオーディオ・ストリームは、アプリケーションのコンテンツ製作者により優先順位が付けられる。プロセッサ１２のアプリケーションの実行に関しては、コンテンツ製作者により割り当てられた優先度に従い、オーディオ・ストリームは、装置１２によりデコードされる。さらに、（警報のような）アプリケーションとは関係のない一つ以上のオーディオ・ストリームは、同様に優先順位付けが可能である。アプリケーションと関係する優先順位付オーディオストリームのサブセットと追加的な優先順位付オーディオストリームは、共通オーディオストリームを形成する優先度に従い結合が可能である。

オーディオ・デコーディング装置１６は、一般に、共通オーディオ・ストリームを供給するために、オーディオ・ストリームをデコードし、結合する。次に、共通オーディオ・ストリームは、スピーカー１９Ａと１９Ｂに対する駆動信号を生成するために、駆動回路１５へ配信されることが可能である。しかしながら、共通オーディオ・ストリームが形成される間に、符号化されたオーディオ・ストリームのいくつかは、不十分なメモリ、オーディオ・デコーディング装置１６の不十分な処理パワー、あるいは装置１０の他のプラットフォーム制限によって、排除される可能性がある。この場合には、“より高い優先度”のオーディオ・ストリームは、共通オーディオ・ストリームの形成に使用されるが、その一方で、一つ以上の“より低い優先度” のオーディオ・ストリームは、装置１０の制限により共通オーディオ・ストリームから除外される。

このように、モバイル装置１０は、アプリケーションを実行することが可能であり、低優先度のオーディオ・ストリームが高優先度のオーディオ・ストリームを超える優先順位（precedence）を決して与えられることがないことを保証するように、オーディオ出力を生成することが可能である。言い換えれば、高優先度のオーディオ・ストリームは、より低い優先度のオーディオ・ストリームのために、出力から除外されることは決してない。さらに、（装置１０に類似した）２つの装置が同じアプリケーションの実行に利用され、その装置の一方が、より容量の大きなメモリ１４、および／または、より速いデコーディング装置１６を持つ場合には、より高品質の装置がより低品質の装置に関係した拡張オーディオを生成する可能性がある。この場合には、両方の装置が同じアプリケーションを実行することになる。しかしながら、装置の一方は、より有能な計算プラットフォームを持つために、より高品質の装置は、使用者の体験を高めるために、オーディオ出力の生成において、“より低い優先度（lower priority）”のオーディオ・ストリームをより多く使用する可能性がある。それ故に、同じアプリケーションを実行する異なる装置の異なるプラットフォームのために、同じアプリケーションが異なる装置において異なるオーディオ出力レベルを結果的に生じる可能性がある。コンテンツ提供者は、優先順位付オーディオ・ストリームを備えた、あるアプリケーションを設計することが可能であり、アプリケーションを実行するプラットフォームに依存して、その同じアプリケーションは異なるオーディオ出力量を結果として生じることが可能である。

オーディオ・ストリームがコンテンツ提供者により優先順位付けされるため、アプリケーションが低品質のプラットフォームで実行される場合でさえ、（コンテンツ提供者と装置製造者により定義されるような）最も重要なオーディオは常に出力に含まれる。また、このことが意味することは、コンテンツ提供者は、プラットフォームの質に応じて、異なる品質レベルで実行可能な単一のアプリケーションを生成することができるということである。さらに、コンテンツ提供者は、最小主義者（minimalist）レベルにおけるアプリケーションを実行するために定義された最も低い品質のプラットフォームでさえ、使用者がビデオゲームのようなアプリケーションの効果的な使用をなおも可能にすることを確実にするように、ビデオゲームのオーディオ優先度を定義することができる。同じアプリケーションが、より高い品質のプラットフォームで実行される場合には、同じアプリケーションがより低い品質のプラットフォームで実行されるのに比べて、向上した（enhanced）オーディオを生成することができる。

プロセッサ１２は、優先順位付オーディオを含むアプリケーションを実行する可能性があるが、他のアプリケーションを実行する可能性もある。これらの他のアプリケーションは、いくつかのケースでは、アプリケーションの任意のオーディオに取って代わる（supersede）ことが可能なオーディオ・ストリームを生成することもできる。例としては、優先順位付オーディオを持つアプリケーションは、ビデオゲームを含む可能性があり、アプリケーションと関係ない一つ以上のオーディオ・ストリームは、（モバイル装置１０が携帯電話である場合に、携帯電話の鳴り響く音のような）ビデオゲームと関係のないオーディオ警報を含む可能性がある。この場合には、ビデオゲームと関係ないオーディオ警報は、優先順位（precedence）または優先度（priority）を与えられ、共通オーディオ・ストリームに含まれ、あるいは、ゲームのすべてのオーディオに取って代わる可能性がある。プロセッサ１２は、割り込み駆動（interrupt driven）される可能性があり、そのケースでは、入来する電話呼は、可聴警報がビデオゲームのすべてのオーディオに取って代わる原因となる割り込みを生成することが可能であり、あるいは、ビデオゲームの最高優先度のオーディオと結合され、オーディオ出力に含まれることが可能である。警報はアプリケーションとは関係がないにも関わらず、アプリケーションの異なるオーディオストリームとちょうど同様の優先度を与えられる可能性がある。各オーディオ・ストリームは、独自の優先度を有する可能性があり、典型的にはオーディオ警報がそのスキームにおいて最高の優先度を与えられる。しかしながら、本開示は必ずしもこの点に限定されるものではない。コンテンツ提供者により割り当てられるアプリケーションのオーディオとは違い、アプリケーションと関係ないオーディオ・ストリームは、装置製造者により定義される可能性がある。いずれのケースでも、各オーディオストリームは、独自の優先度を与えられる。

図２は、図１の装置、あるいは他の類似の装置により実行され得る技術を示す流れ図である。図２に示されるように、オーディオデコーディング装置１６は、たとえばプロセッサ１２において、装置１０で実行するアプリケーションと関係する優先順位付オーディオストリームを受信する（２１）。さらに、オーディオ・デコーディング装置１６は、アプリケーションと関係のない追加的な優先順位付オーディオ・ストリームを受信する（２２）。オーディオ・デコーディング装置１６は、共通オーディオ・ストリームを形成する優先度に従い、アプリケーションのオーディオ・ストリームのサブセットと追加的なオーディオ・ストリームを結合する（２３）。オーディオ・デコーディング装置１６は、それから出力信号を生成することが可能になり（２４）、その出力信号は、スピーカー１９Ａと１９Ｂを通じて可聴信号を生成するために駆動回路１５により使用される可能性がある。また、オーディオ・ストリームの優先順位付けと、優先順位付オーディオ・ストリームのサブセットと追加のオーディオ・ストリームからの共通オーディオ・ストリームの形成は、アプリケーションが、異なるプラットフォーム上で、異なってはいるが効率的に動作することを可能にする。

図３は、オーディオ・デコーディング装置１６（図１）により実現され得る技術を示すブロック図である。一般に、複数のオーディオ・ストリームは、オーディオ・ストリームの優先度に基づいて処理され、次に結合される。図３に示されるように、オーディオ・ストリーム３１Ａ−３１Ｅ（まとめてオーディオストリーム３１）は処理が行われ、処理されたオーディオ・ストリーム３２Ａ−３２Ｅ（まとめて処理されたオーディオ・ストリーム３２）として定義される。オーディオ・ストリーム３１の処理には、伸長（decompression）が含まれる可能性があり、その場合、オーディオ・ストリーム３２は、別々にオーディオ・ストリーム３１の伸長バージョンになる可能性がある。もし望まれれば、追加的な処理もオーディオ・ストリーム３１に対して行なわれる可能性がある。

制御論理３５は、共通オーディオ・ストリーム３６を生成するために、処理されたオーディオ・ストリーム３２のサブセットを結合する。図３では、図に示される処理されたオーディオストリーム３２Ａ−３２Ｅのすべては、共通オーディオストリーム３６を生成するために、論理３５により結合されている。しかしながら、アプリケーションが実行されるプラットホームとオーディオストリーム数に依存して、共通オーディオストリーム３６に含まれるオーディオストリーム数は増減し得る。いくつかの場合では、たとえば、一つ以上のより低い優先度のオーディオ・ストリームは、共通オーディオ・ストリーム３６から除外される可能性がある。論理３５は、処理されたオーディオ・ストリーム３２のどれが共通オーディオ・ストリーム３６に含まれるかを制御することができる。論理３５は、優先度とオーディオ信号生成に利用可能な計算資源に基づき、そのような決定を行う。論理３５はハードウェアで実装が可能であるが、その場合には、論理３５は使用されてきた計算資源の測定基準（metric）と利用可能な資源を維持する可能性がある。あるいは、論理３５の機能は、下記でより詳細に議論されるように、ソフトウェアやファームウェア・ルーチン（routine）のイベント駆動型タスク（event driven task）により実現され得る。その場合には、それぞれのタスクは、計算資源がそのような実行を許可する場合に限って、実行され得る。図３の例では、処理されたオーディオ・ストリーム０（３２Ａ）は、最高の優先度を有する可能性があり、処理されたオーディオ・ストリーム１（３２Ｂ）、次にストリーム２（３２Ｃ）、次にストリーム３（３２Ｄ）、次にストリーム４（３２Ｅ）等が後に続く可能性がある。

共通オーディオ・ストリーム３６が一度作り出されると、処理された共通オーディオ・ストリーム３８を生成するために、後処理（post processing）が行われる可能性がある。たとえば、後処理は、信号の強度（intensity）（ボリューム（volume））を調整する可能性があり、あるいは、共通オーディオ・ストリーム３６のオーディオ・エンハンスメントを含む可能性がある。しかしながら、本開示によれば、後処理は、特に処理パワーが制限されている場合には、いくつかの場合には除外される可能性がある。

図４は、本開示の技術を実現することが可能な典型的な装置の別のブロック図である。図４の装置は、プロセッサ４２、オーディオデコーディング装置４６、ハードウェア４８を含む。図４に示される、これらそれぞれの構成要素は、モバイル装置１０の要素１２、１６、１８（図１）に対応しており、あるいは、図１のものとは異なるアーキテクチャを持つ他の装置において実現し得る。

プロセッサ４２は、ここにおいて説明されるように、優先順位付オーディオ・ストリームを含むアプリケーションを実行する。さらにまた、アプリケーションのコンテンツ提供者は、アプリケーションのオーディオ・ストリームの優先度を選択する。多数のオーディオ・ストリームを含む各種の他のアプリケーションについて、その技術は働き得るけれども、一つの例では、アプリケーションはビデオゲームを含む。ビデオゲームの例では、オーディオ・ストリームは、（爆発や砲撃のような）ＢＧＭ、対話型リアルタイムサウンド効果、そして、たとえば、ジャンプ、走行、スライディング、運転、回転、方向変換などのゲームアクションに関係する幅広い種類のサウンド効果を含む可能性がある。同様に、サウンドは、背景キャラクターとも関係する可能性があり、つまり、そのようなキャラクターの出現や滅亡とも関係する可能性がある。異なるオーディオ・ストリームは、ビデオゲームの異なるオーディオチャンネルに対応する可能性があり、チャンネル数は、一般に、制限がなく、ゲーム自身により定義される。

図４の例では、オーディオタスク４１Ａ−４１Ｅは、一般に、それぞれの優先順位付オーディオ・ストリームで実行されるタスクを示す。つまり、オーディオタスク４１Ａ−４１Ｅは、プロセッサ４２で実行するアプリケーションのオーディオ・ストリームと、（警報のように）アプリケーションと関係ない少なくとも一つの追加的なオーディオ・ストリームで実行されるタスクを示す。プロセッサ４２は、それぞれのオーディオ・ストリームの処理（たとえば、デコード）のために、各々のオーディオ・ストリームをオーディオ・デコーディング装置４６へ送る。オーディオタスク４１Ａ−４１Ｅは、より多くのデータが必要とされると、プロセッサ４２に要求信号を送るオーディオタスク４１Ａ−４１Ｅにおいて、イベント駆動型タスクになる可能性がある。オーディオ・ストリームは、データブロックを含むオーディオフレームにおいて、プロセッサ４２からそれぞれのオーディオストリームタスク４１Ａ−４１Ｅへ送られることが可能である。オーディオタスク４１Ａ−４１Ｅにより多くのオーディオフレームが必要とされるときには、制御信号はプロセッサ４２へ送られ、そして、プロセッサ４２は、追加のデータを要求するそれぞれのオーディオタスクによる処理のために追加のデータを送る。

オーディオタスク０（４１Ａ）は、最高の優先度を持つストリームと関係する可能性があり、オーディオタスク１（４１Ｂ）、次にオーディオタスク２（４１Ｃ）、次にオーディオタスク３（４１Ｄ）、次にオーディオタスク４（４１Ｅ）などが続く。オーディオタスク４１Ａ−４１Ｅは、それぞれのオーディオ・ストリームで実行されるオーディオ・デコーディング、あるいは、伸長タスクを含む可能性がある。図５に示されるように、オーディオタスク４１Ａ−４１Ｅは、（図１のメモリ１４に対応する）メモリ４４から圧縮オーディオストリームを受信する可能性がある。そして、次のデコードは、伸長したオーディオ・ストリームをメモリ４４に戻して格納することが可能である。オーディオタスク４１Ａ−４１Ｅは、いくつかのデコーディングタスクが同時に実行するように、平行あるいはオーバーラップする方式で実行され得る。しかしながら、伸長されたオーディオ・ストリームがオーディオタスクにより受信される場合には、伸長は必要とされず、受信された同じ情報が、伸長されたオーディオ・ストリームとして、メモリ４４に戻され格納される。この場合、そのようなデータが圧縮されているか、伸長されているが不明であるかもしれないため、オーディオタスクにさらにデータが送られる。

図４に戻って参照すると、後処理（post processing）（ＰＰ）タスク４３は、一般に、共通オーディオ・ストリームを形成するために、優先順位付オーディオ・ストリームと伸長されたオーディオ・ストリームのサブセットを結合するデコーディングタスク表す。ＰＰタスク４３は、また、結合オーディオ・ストリームに対して（ボリューム調整やオーディオ・エンハンスメントのような）任意の後処理を実行する。ＰＰタスク４３は、また、データが必要とされると、オーディオタスク４１Ａ−４１Ｅへ制御信号を送るイベント駆動型タスクになる可能性がある。データは、メモリにおけるアドレス位置（address location）により転送されるか、あるいは、識別されることが可能である。ＰＰタスク４３は、オーディオタスク４１Ａに関係する任意のデータが最高の優先度を与えられ、次にオーディオタスク４１Ｂからのデータ、次にオーディオタスク４１Ｃからのデータ、次にオーディオタスク４１Ｄからのデータ、次にオーディオタスク４１Ｅからのデータなどが続くことを確実にする優先順位付け方式（prioritized manner）で処理の実行が可能である。

図５に示されるように、同じメモリ４４は、オーディオタスク４１Ａ−４１Ｅと関係する圧縮データと伸長データを格納するために使用され得る、そして、オーディオＰＰタスク４３と関係する結合され、そして後処理されたオーディオ・ストリームを格納するためにも使用され得る。たとえば、共有メモリ４４の使用は、結合されたオーディオ・ストリームの後処理以前に、そのようなデータを個々に再ロード（ｒｅｌｏａｄ）する必要なしに、ＰＰタスクが、オーディオタスク４１Ａ−４１Ｅの伸長オーディオ・ストリームへ直接アクセスすることができるので、効率性の促進が可能となる。オーディオストリームは、オーディオデータの連続するブロックを含むオーディオフレームに分割され得る。いずれの場合でも、オーディオ・デコーディング装置４６は、共有メモリ４４の使用を促進し、不要なデータ再ロードに対する必要性を回避するように、メモリ４４のアドレスレコードを維持することが可能である。従って、オーディオＰＰタスク４３は、オーディオタスク４１Ａ−４１Ｅのデコード結果にアクセスし、結合オーディオ・ストリームを生成する。そして、その結合オーディオストリームは、さらに処理することが可能であり、つまりは、後処理が行われることになる。明快な説明のために、図５の典型的なメモリレイアウトが示される。しかしながら、他の状況下では、一つ以上のタスクオーディオタスクに対するメモリ領域がメモリにおいてオーバーラップする可能性があるかもしれない。

重要なことには、オーディオＰＰタスク４３が、優先度に基づいてオーディオタスク４１Ａ−４１Ｅの伸長オーディオ・ストリームを選択する。この目的のために、一つ以上のより低い優先度のオーディオ・ストリームは、（制限されたメモリ４４あるいはデコーディング装置４６の制限された処理パワーのような）プラットフォームの制約（constraint）が存在する場合には、オーディオＰＰタスク４３により生成される結合オーディオ・ストリームから除外される可能性がある。一般に、オーディオＰＰタスク４３は、伸長されたオーディオ・ストリームのサブセットから結合されたオーディオ・ストリームを生成し、この結合を優先度に基づいて行なう。より高い優先度のオーディオ・ストリームを含んだ後に、十分なメモリと処理パワーが利用可能である場合にのみ、各それぞれのオーディオ・ストリームは含まれることになる。

システムは、イベント駆動型方式で動作する可能性があり、オーディオ・ストリームは、オーディオフレームに分割される可能性がある。この場合には、システムの処理速度とメモリは、適応性のある方式（adaptive fashion）で利用することができる。所与の“高優先度”のオーディオ・ストリームと関係するオーディオデータ量が増加する場合、このことは、所与の“低い優先度”のオーディオ・ストリームが、所与の段階（instance）において共通オーディオ・ストリームから除外されるかどうかに影響し得る。さらに、所与の“高い優先度”のオーディオ・ストリームと関係するオーディオデータ量が減少する場合、このことは、システム資源を解放し、より多くの“低い優先度”のオーディオデータが共通オーディオ・ストリームに含まれることを可能にするかもしれない。つまり、イベント駆動タスクとフレームに分割されたオーディオ・ストリームを利用することによって、優先順位が付けられたオーディオ・ストリームのサブセットからの共通オーディオ・ストリームの形成は、プラットフォームのシステム資源をより完全に利用するために、時間にわたって適応が可能となる。実際に、共通オーディオ・ストリームに含まれる優先順位が付けられたオーディオ・ストリームの数は、アプリケーションがリアルタイムにプロセッサ４２上で実行するにつれて、変化する可能性がある。

図５の例では、結合され、そして後処理されたオーディオ・ストリームは、オーディオタスク４１Ａ−４１Ｄと関係する伸長オーディオ・ストリームを含むが、オーディオタスク４（４１Ｅ）と関係するオーディオ・ストリームを除外する。言い換えれば、図５に示されるように、最低の優先度のオーディオタスク、つまり、オーディオタスク４（４１Ｅ）と関係する伸長オーディオ・ストリームは、オーディオＰＰタスク４３によりアクセスされず、それ故に、結合されたオーディオ・ストリームには含まれない。さらに他の例では、デコーディングタスクは、結合されたオーディオ・ストリームから除外される可能性のある任意のオーディオ・ストリームに対して避けられる可能性がある。一般に、オーディオ・ストリームの圧縮サイズと伸長サイズは、“アプリオリ（a priori）”に知られる可能性がある。優先度は２つの方式で使用される可能性がある。第１に、オーディオ・ストリームが始まると、それぞれのタスクは、そのオーディオ・ストリームを取り扱うのに十分なメモリが存在するかどうかを決定する可能性がある。そうでない場合には、ストリームは除外される可能性がある。第２に、ランタイムの間に、処理速度が所与のオーディオ・ストリームを取り扱うのに不十分である場合、たとえ十分なメモリが存在しようとも、それぞれのオーディオタスクは、不十分な処理能力のために呼び出されない可能性がある。

図４を再び参照すると、一旦、ＰＰタスク４３が結合オーディオ・ストリームを生成し、結合オーディオ・ストリームに対して任意の後処理を実行すると、オーディオフロントエンド（ＡＦＥ）タスク４５は、信号を生成し出力するために、結合され、そして後処理されたオーディオ・ストリームを使用する可能性がある。ハードウェア４８は、結合オーディオ・ストリームのサンプルからアナログ信号を生成するために、デジタルアナログ変換器（ＤＡＣ）４９を含む可能性がある。この場合、アナログ出力を生成するために、ＡＦＥ４５は、ＤＡＣ４９にアクセスすることができる。そのアナログ出力は、次に駆動回路に配信され、増幅され、オーディオ出力を使用者に提供するためにスピーカーの駆動に使用されることが可能である。

図６は、図４の装置、あるいは他の類似の装置により実行され得る技術を示す流れ図である。図６に示されるように、オーディオ・デコーディング装置４６は、プロセッサ４２で実行するアプリケーションと関係する優先順位が付けられたオーディオ・ストリームを受信する（５１）。さらに、オーディオ・デコーディング装置４６は、アプリケーションとは関係ない追加的な優先順位が付けられたオーディオ・ストリームを受信する（５２）。オーディオタスク４１Ａ−４１Ｅは、（アプリケーションと関係のないものを含む）優先度オーディオ・ストリームをデコードし、メモリ４４（図５）でデコードされたオーディオ・ストリームを格納する（５３）。ＰＰタスク４３は、次に、共通オーディオ・ストリームを形成するために、そのストリームの割り当てられた優先度に従い、アプリケーションのデコードされたオーディオ・ストリームのサブセットと追加的なオーディオ・ストリームを結合する（５４）。また、このことは、典型的には、共通オーディオ・ストリームから一つ以上の低い優先度のストリームを除外し、そして、一つ以上の高い優先度のストリームを包含することを含んでいる。ＰＰタスク４３は、また、共通オーディオ・ストリームへのオーディオ・エンハンスメントやボリューム調整のように、共通オーディオ・ストリームでさらに処理を行なう可能性もある（５５）。ＡＦＥタスク４５は、処理され、そして共通のオーディオ・ストリームに基づいて出力を生成し（５６）、この出力は、次にスピーカーの駆動に利用される可能性がある。たとえば、ＡＦＥタスク４５は、共通オーディオストリームのサンプルからアナログオーディオ信号を生成するために、ＤＡＣ４９にアクセスする可能性がある。

オーディオ・デコーディング装置４６は、デジタル信号プロセッサ（ＤＳＰ）として実装され得るが、その場合、オーディオタスク４１Ａ−４１Ｅ、ＰＰタスク４３、ＡＦＥタスク４５は、ＤＳＰ上で実行するソフトウェアモデュールであり得る。しかしながら、より一般的には、ここにおいて説明された技術は、ハードウェア、ソフトウェア、ファームウェア、あるいは、それらの任意の組み合わせで実現される可能性がある。ソフトウェアで実現される場合、本開示は、オーディオ・ストリームをデコードする装置において実行する際に、ここに説明された一つ以上のオーディオデコード技術を遂行する命令を含むコンピュータ可読媒体に向けられる可能性がある。その場合には、コンピュータ可読媒体は、同期式ダイナミック・ランダム・アクセス・メモリ（ＳＤＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、不揮発性ランダム・アクセス・メモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル・読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリなどのようなランダム・アクセス・メモリ（ＲＡＭ）を含む可能性がある。

命令は、コンピュータ可読の命令であるかもしれない、そして、ＤＳＰは、一つ以上のオーディオ・デコーディング技術を実行するために、メモリに格納された命令を実行することができる。いくつかの場合に、その技術は、各種のハードウェア構成要素にコーディング処理の加速を引き起こさせるＤＳＰによって実行される可能性がある。他の場合には、ここにおいて説明されるユニットやモジュールは、マイクロプロセッサ、一つ以上の特定用途向けIC（application specific integrated circuit）（ＡＳＩＣ）、一つ以上のフィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、あるいは、いくつかの他のハードウェアとソフトウェアの組み合わせとして実現される可能性がある。

図７は、コンテンツ製作者の視点から本開示の態様を示す流れ図である。特に、図７の技術は、アプリケーションおよびアプリケーションと関係のないオーディオのオーディオ優先度をそれぞれ定義するために、アプリケーションのコンテンツ製作者と装置製造者により実行される可能性がある。次に、アプリケーションは種々のプラットフォームに分配されることが可能である。示されるように、（ビデオゲーム設計者のような）コンテンツ製作者は、モバイル装置で操作するために、（ビデオゲームのような）アプリケーションのオーディオストリームの優先度を定義する（６１）。さらに、装置製造者は、アプリケーションと関係しないオーディオ警報の優先度を定義する（６２）。コンテンツ製作者は、第１のモバイル装置にアプリケーションを供給し、その第１のモバイルは、アプリケーションと警報に対する結合オーディオ出力を定義するために、アプリケーションのオーディオ・ストリームの第１のサブセットを使用する（６３）。次に、コンテンツ製作者は、第２のモバイル装置へアプリケーションを供給するが、第２のモバイル装置は、第１のモバイル装置とは異なるプラットフォームを有する（６４）。第２のモバイル装置は、アプリケーションと警報に対する結合オーディオ・ストリームを定義するために、アプリケーションのオーディオ・ストリームの第２のサブセットを使用する。第２のサブセットは、第１の装置と第２の装置が異なるプラットフォームを有するという事実のために、第１のサブセットとは異なる可能性がある。たとえば、第１のサブセットは、第１のモバイル装置と関係するメモリが第２のモバイル装置に関係するメモリより小さいという事実のために、第２のサブセットより小さい可能性がある。この場合には、コンテンツ製作者は、両方の装置に同一のアプリケーションを分配することが可能であり、アプリケーションがそれぞれの装置で実行する際に、アプリケーションのオーディオ出力信号においてオーディオ・ストリームが含まれる範囲（およびオーディオ・ストリームが除外される範囲）を、それぞれの装置に決定させることが可能である。

コンテンツ製作者は、アプリケーションに含まれるオーディオ・ストリームの優先度スキームにわたって制御を行うので、コンテンツ製作者は、使用者がゲームを効果的にプレイするため（あるいは、そうでなければ所与のアプリケーションをナビゲートするため）に必要な任意のサウンドが最高の優先度を与えられることを確実にすることが可能である。言い換えれば、より高い優先度のオーディオ・ストリームは、使用者がビデオゲームを効果的にプレイするために必要とされるオーディオ・ストリームを含むことが可能であるが、その一方で、より低い優先度のオーディオ・ストリームは、使用者がビデオゲームを効果的にプレイするために必要とされないオーディオ・ストリームを含む可能性がある。この場合には、低品質のプラットフォームは、ゲームが機能的であるために必要とされる高い優先度のオーディオ・ストリームを含むことを確実にするために、十分なメモリとプロセッサ速度を有する可能性がある。同時に、高品質のプラットフォームは、ゲームが機能的であるために必要とされるより高い優先度のオーディオ・ストリームを含むことと、ゲームのオーディオ出力を拡張するより低い優先度のオーディオ・ストリームを含むこととの両方を許容する追加的なメモリとプロセッサ速度（低品質のプラットフォームに比較して）を有する可能性がある。

さらに、ここにおいて説明される技術は、アプリケーションと関係ないオーディオ・ストリームの扱いを許容する。たとえば、モバイル携帯電話の場合では、入来する電話呼出が受信された場合には、ビデオゲーム・アプリケーション上でオーディオ警報を許容することが望ましいかもしれない。この場合には、装置は、共通オーディオ・ストリームを形成するために、アプリケーションと関係のないオーディオストリーム（たとえば、警報）をアプリケーションの優先順位付オーディオ・ストリームのサブセットと結合させる可能性がある。言い換えれば、装置は、ビデオゲームの優先順位付けされたオーディオだけでなく、ビデオゲームと関係ない警報も結合することにより、ゲームのオーディオ出力の部分として、ビデオゲームと関係ないオーディオ警報を含む可能性がある。アプリケーションのオーディオ・ストリームのように、警報は、優先度により定義されるが、その優先度は、アプリケーションのオーディオ・ストリームのすべてに対して独自性を持つ可能性がある。入来する電話呼出は可能な限り最高の優先度を割り当てられ、ビデオゲームのアクションに取って代わる可能性があり、たとえば、入来する電話呼出は、使用者に入来する呼出を知らせるために、ビデオゲームの任意のオーディオに取って代わる警報を引き起こす可能性がある。

さらに他の場合には、オーディオストリーム（および警報）の優先度は、アプリケーションにおける調整可能な変数によって定義されることが可能である。この場合には、コンテンツ製作者は、アプリケーションで定義される種々のオーディオ・ストリームの優先度の調整や再設計を容易に行うことができる。各オーディオ・ストリームは、変数を介して優先度を割り当てられる可能性があるが、その変数はコンテンツ製作者により調整が可能である。特定のプラットフォームをより良く提供するために、非常に簡単にオーディオを再優先順位付けすることを、設計者や装置製造者に認めることが可能であるので、そのような柔軟性は望ましいかもしれない。

追加された例として、アプリケーションと関係ないオーディオ・ストリームは、アプリケーションのものに関連して優先順位付けされているが、警報よりむしろ他のものになる可能性がある。たとえば、デジタル写真が装置により撮られていると同時に、ビデオゲームがその装置でプレイされている場合には、画像キャプチャと関係する“シャッター音”は、ゲームコンテンツのすべてより高い優先度を与えられることが可能である。この場合には、共通オーディオ・ストリームは、シャッター音を含むであろう、そのシャッター音は、オーディオやゲームの部分やすべてと結合するであろう。本開示に従って、アプリケーションと関係ない他のタイプのオーディオ・ストリームは、アプリケーションのものに関連して優先順位付けされることも可能であろう。

コンテンツ提供者が、アプリケーションのコンテンツに優先度を割り当てない場合には、アプリケーションは、ストリームのタイミングに基づいて優先度を定義することにより、装置でさらに機能する可能性があるだろう。この場合には、オーディオ・ストリームの優先度は、ファーストイン方式（first-in basis）で単純に割り当てられる可能性があるだろう。ファーストイン・オーディオは、最高の優先度または最低の優先度を与えられ得るだろう。これらの代案は可能なオーディオ出力の最良な結果とは限らないかもしれないが、オーディオ・ストリームの優先順位付けがゲーム設計者により定義されない場合において、ゲームはある程度はなおも機能しうるであり得るだろう。優先度が割り当てられていないオーディオ・ストリームを取り扱う他の方法は、コンテンツタイプに基づいて優先度をダイナミックに割り当てることを含む可能性がある。これらの方法では、オーディオサウンドの割り当て優先度を有するように設計されたアプリケーションは、そのような優先度が割り当てされない状態であっても、さらに機能する可能性がある。

ここにおいて説明される技術は、アービトレーション（arbitration）中に適用される可能性もある。言い換えれば、処理パワーやメモリに制限が生じない場合、あるいは、処理パワーやメモリに制限が生じるまでは、オーディオストリームの選択や除外は避けられる可能性がある。そのような制限に遭遇した場合には、本開示の技術は、処理あるいはメモリ束縛を所与として、必要な程度まで、高い優先度のオーディオを含み、低い優先度のオーディオを除外するアービトレーションとして適用され得る。

前述の議論では、本開示は、ビデオゲームのアプリケーションの文脈で詳細を提供してきた。しかしながら、本開示の技術は、他のタイプの幅広い種類のアプリケーションで使用されることも可能であろう。同様に、技術は、アプリケーションとは関係ないオーディオ警報のサポートとして説明されてきたが、他の優先順位が付けられたオーディオ・ストリームもまた、アプリケーションのものと結合されることが可能であろうし、本開示の教示と矛盾しないであろう。技術は、モバイル装置で実行するようにソフトウェア会社によりしばしば設計されるコンテンツベースのアプリケーションについて最も有効であり得る。ビデオゲームはそのようなコンテンツベースのアプリケーションの一例であるが、他の幅広い種類のアプリケーションもまた、そのアプリケーションにおいて優先順位付オーディオ・ストリームを可能にするので、本開示の教示から利益を得ることが可能である。類似の技術あるいはアプリケーションは、非モバイル装置についても望ましいであろう。これらと他の具体例は、次の請求項の範囲内である。

本開示の技術を実現することが可能な典型的なモバイル装置のブロック図である。 図１の装置、あるいは他の類似装置により実行され得る技術を示す流れ図である。 複数のオーディオ・ストリームが処理され、次にオーディオ・ストリームの優先度に基づいて結合される技術を示すブロック図である。 本開示の技術を実現することが可能な典型的な装置の他のブロック図である。 共有されるメモリロケーション内の各種オーディオ情報の格納を示すブロック図である。 図４の装置あるいは他の類似装置により実行され得る技術を示す流れ図である。 アプリケーション内でオーディオ優先度を定義し、それからアプリケーションを種々のプラットフォームに分配するために、アプリケーションのコンテンツ製作者により実行され得る技術を示す流れ図である。

Claims (33)

1. モバイル装置において実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信することと、
   前記アプリケーションとは関係のない追加的な優先順位付オーディオ・ストリームを受信することと、
   共通オーディオ・ストリームを形成するために優先度に従って、前記アプリケーションと関係する優先順位付オーディオ・ストリームのサブセットと前記追加的な優先順位付オーディオ・ストリームを結合すること、
   を含む方法。
2. 前記共通オーディオ・ストリームに基づいてオーディオ出力を生成することを、さらに含む、請求項１の方法。
3. 優先度に従って、前記アプリケーションと関係する前記優先順位付オーディオストリームのサブセットと前記追加的な優先順位付オーディオストリームを結合することは、
   前記共通オーディオ・ストリームに前記アプリケーションの一つ以上のより高い優先度のオーディオ・ストリームを含めることと、
   前記共通オーディオ・ストリームから前記アプリケーションの一つ以上のより低い優先度のオーディオ・ストリームを除外すること、
   を含む請求項１の方法。
4. 前記アプリケーションは、ビデオゲームを含み、前記アプリケーションの前記オーディオ・ストリームは、前記ビデオゲームの種々のオーディオチャンネルに対応し、ならびに、
   前記より高い優先度のオーディオ・ストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされるオーディオ・ストリームを含み、
   前記より低い優先度のオーディオ・ストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされないオーディオ・ストリームを含む、
   請求項３の方法。
5. 前記共通オーディオ・ストリームを形成する以前に、前記優先順位付オーディオ・ストリームの前記サブセットをデコードすることをさらに含む、請求項１の方法。
6. 前記共通オーディオ・ストリームを形成する以前に、前記優先順位付オーディオ・ストリームをデコードすることをさらに含む、請求項１の方法。
7. 前記共通オーディオストリームを処理することをさらに含む、請求項１の方法。
8. 前記共通オーディオ・ストリームの前記処理に続いて、前記共通オーディオ・ストリームに基づいてオーディオ出力を生成することをさらに含む、請求項７の方法。
9. 前記アプリケーションは、ビデオゲームを含み、前記アプリケーションと関係ない前記オーディオ・ストリームは、前記ビデオゲームと関係のないオーディオ警報を含む、請求項９の方法。
10. 前記アプリケーションの前記複数の優先順位付オーディオ・ストリームの各々と前記追加的な優先順位付オーディオ・ストリームは、独自の優先度を定義する、請求項１の方法。
11. アプリケーションのオーディオ・ストリームの優先度を定義することと、
    前記アプリケーションと関係のないオーディオ警報の優先度を定義することと、
    前記アプリケーションと前記警報の結合オーディオ出力を定義するために、第１のモバイル装置が前記アプリケーションの前記オーディオ・ストリームの第１のサブセットを使用するように、第１のプラットフォームを定義する第１のモバイル装置へ前記アプリケーションを供給することと、
    第１のサブセットは第２のサブセットとは異なり、前記アプリケーションと前記警報の結合オーディオ出力を定義するために、第２のモバイル装置が前記アプリケーションの前記オーディオ・ストリームの第２のサブセットを使用するように、第２のプラットフォームを定義する第２のモバイル装置へ前記アプリケーションを供給すること、
    を含む方法。
12. 前記第１のプラットフォームは、前記第２のプラットフォームより少ないメモリを定義し、前記より少ないメモリのために、前記第１のサブセットは、前記第２のサブセットより小さい、請求項１１の方法。
13. モバイル装置において実行する際に、
    前記モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信することと、
    前記アプリケーションと関係のない追加的な優先順位付オーディオ・ストリームを受信することと、
    共通オーディオ・ストリームを形成するために優先度に従って、前記アプリケーションと関係する前記優先順位付オーディオ・ストリームのサブセットと前記追加的な優先順位付オーディオ・ストリームを結合すること、
    を、前記モバイル装置に引き起こす実行可能命令を含む、コンピュータ可読媒体。
14. 前記命令は、前記モバイル装置に、前記共通オーディオ・ストリームに基づいてオーディオ出力を生成させることを引き起こす、請求項１３のコンピュータ可読媒体。
15. 前記共通オーディオ・ストリーム内に前記アプリケーションの一つ以上のより高い優先度のオーディオ・ストリームを含めることと、
    前記共通オーディオ・ストリームから前記アプリケーションの一つ以上のより低い優先度のオーディオ・ストリームを除外すること、
    による優先度に従い、前記命令は、前記モバイル装置に、前記アプリケーションと関係する前記優先順位付オーディオ・ストリームの前記サブセットと前記追加的な優先順位付オーディオ・ストリームを結合させることを引き起こす、請求項１３のコンピュータ可読媒体。
16. 前記アプリケーションは、ビデオゲームを含み、前記オーディオ・ストリームは、前記ビデオゲームの種々のオーディオチャンネルに対応する、そして、
    前記より高い優先度のオーディオ・ストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされるオーディオ・ストリームを含み、ならびに、
    前記より低い優先度のオーディオ・ストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされないオーディオ・ストリームを含む、
    請求項１５のコンピュータ可読媒体。
17. 前記命令は、前記共通オーディオ・ストリームを形成する以前に、前記モバイル装置に、前記優先順位付オーディオ・ストリームの前記サブセットをデコードさせることを引き起こす、請求項１３のコンピュータ可読媒体。
18. 前記命令は、前記共通オーディオ・ストリームを形成する以前に、前記モバイル装置に、前記優先順位付オーディオ・ストリームをデコードさせることを引き起こす、請求項１３のコンピュータ可読媒体。
19. 前記命令は、前記共通オーディオ・ストリームを前記モバイル装置に処理させることを引き起こす、請求項１３のコンピュータ可読媒体。
20. 前記命令は、前記モバイル装置に、前記共通オーディオ・ストリームの前記処理に続いて、前記共通オーディオ・ストリームに基づいてオーディオ出力を生成させることを引き起こす、請求項１９のコンピュータ可読媒体。
21. 前記アプリケーションは、ビデオゲームを含み、前記アプリケーションと関係ない前記オーディオ・ストリームは、前記ビデオゲームと関係ないオーディオ警報を含む、請求項１３のコンピュータ可読媒体。
22. 前記アプリケーションの前記複数の優先順位付オーディオ・ストリームの各々と前記追加的な優先順位付オーディオ・ストリームは、独自の優先度を定義する、請求項１３のコンピュータ可読媒体。
23. アプリケーションを実行するプロセッサと、
    モバイル装置で実行するアプリケーションの複数の優先順位付オーディオ・ストリームを受信し、前記アプリケーションと関係ない追加的な優先順位付オーディオ・ストリームを受信し、共通オーディオ・ストリームを形成する優先度に従い、前記アプリケーションと関係する前記優先順位付オーディオ・ストリームのサブセットと前記追加的な優先順位付オーディオ・ストリームを結合するオーディオ・デコーディング装置、
    を備える装置。
24. 前記オーディオ・デコーディング装置は、前記共通オーディオ・ストリームに基づいてオーディオ出力を生成する、請求項２３の装置。
25. 前記共通オーディオ・ストリームに前記アプリケーションの一つ以上のより高い優先度のオーディオ・ストリームを含めることと、
    前記共通オーディオ・ストリームから前記アプリケーションの一つ以上のより低い優先度のオーディオ・ストリームを除外すること、
    による優先度に従い、前記オーディオデコーディング装置は、前記アプリケーションと関係する前記優先順位付オーディオストリームの前記サブセットと前記追加的な優先順位付オーディオストリームを結合する、請求項２３の装置。
26. 前記アプリケーションは、ビデオゲームを含み、前記オーディオ・ストリームは、前記ビデオゲームの種々のオーディオチャンネルに対応する、そして、
    前記より高い優先度のオーディオ・ストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされるオーディオ・ストリームを含み、ならびに、
    前記より低い優先度オーディオストリームは、使用者が前記ビデオゲームを効果的にプレイするために必要とされないオーディオストリームを含む、
    請求項２３の装置。
27. 前記オーディオ・デコーディング装置は、前記共通オーディオ・ストリームを形成する以前に、前記優先順位付オーディオ・ストリームの前記サブセットをデコードする、請求項２３の装置。
28. 前記オーディオ・デコーディング装置は、前記共通オーディオ・ストリームを形成する以前に、前記優先順位付オーディオ・ストリームをデコードする、請求項２３の装置。
29. 前記オーディオ・デコーディング装置は、前記共通オーディオストリームを処理する、請求項２３の装置。
30. 前記オーディオ・デコーディング装置は、前記共通オーディオ・ストリームの前記処理に続いて、前記共通オーディオ・ストリームに基づいてオーディオ出力を生成する、請求項２９の装置。
31. 前記アプリケーションは、ビデオゲームを含み、前記アプリケーションと関係のない前記オーディオ・ストリームは、前記ビデオゲームと関係ないオーディオ警報を含む、請求項２３の装置。
32. 前記装置は、ビデオゲーム・アプリケーションを実行することが可能なモバイル無線通信装置を含む、請求項２３の装置。
33. 前記アプリケーションの前記複数の優先順位付オーディオ・ストリームの各々と前記追加的な優先順位付オーディオ・ストリームは、独自の優先度を定義する、請求項２３の装置。

Images