(57)【要約】【課題】複数のメディア処理を並行して行なう場合に、リソースを最適に配分することができるメディア処理装置及びメディア処理方法を提供する。【解決手段】メディア処理装置は、第１のアプリケーション１１及び第２のアプリケーション１２を有するアプリケーション処理プロセッサ１と、解析部２１、メディアモジュール情報処理部２２、音楽再生モジュール２３、音声通話モジュール２４、及びチップ内メモリ２５を有するメディア処理プロセッサ２とを備えている。各モジュールは複数の動作モードを有し、解析部２１がユーザーからの処理要求に応じて最適な動作モードに切り替える。これにより、動作時にリソースを最適に配分することができるので、複数のメディア処理を並行して行なうことが可能となる。【選択図】        図１
2005004581.tif 000002
【特許請求の範囲】
【請求項１】
メディア毎にメディア処理機能を実現する複数のメディアモジュールを有するメディア処理プロセッサと、
上記複数のメディアモジュールを用いてメディア処理を行うアプリケーションを有するアプリケーション処理プロセッサと
を備えたメディア処理装置であって、
上記複数のメディアモジュールのうち少なくとも１つは複数の動作モードを有しており、
上記メディア処理プロセッサは、
上記複数のメディアモジュールの各動作モードにおける使用リソース情報と、処理データ情報に応じた必要リソース情報とを保持するメディアモジュール情報保持部と、
動作時に、上記アプリケーションから上記処理データ情報を取得し、上記メディアモジュール情報保持部から、上記使用リソース情報と上記必要リソース情報とを取得し、さらに、リソースの空き情報を調査して取得した情報に基づきメディアモジュールの動作モードを選択し、選択された動作モードへの切り替えを指示する解析部と
を備えている、メディア処理装置。
【請求項２】
請求項１に記載のメディア処理装置において、
上記処理データ情報は、ストリームデータのフォーマットおよびビットレートを含んでいる、メディア処理装置。
【請求項３】
請求項１または２に記載のメディア処理装置において、
上記メディア処理プロセッサは、メディア処理を行うための作業領域であるチップ内メモリをさらに備えており、
上記使用リソース情報及び必要リソース情報には、上記チップ内メモリの容量についての情報が含まれている、メディア処理装置。
【請求項４】
請求項１〜３のうちいずれか１つに記載のメディア処理装置において、
上記使用リソース情報及び必要リソース情報には、上記メディア処理プロセッサの負荷情報を含まれている、メディア処理装置。
【請求項５】
請求項１〜４のうちいずれか１つに記載のメディア処理装置において、
上記解析部は、メディアモジュールごとにモード切り替え時の優先度情報を有しており、上記優先度情報に応じて動作モードの切り替えの優先順位を決定する、メディア処理装置。
【請求項６】
請求項１〜５のうちいずれか１つに記載のメディア処理装置において、
上記解析部は、
上記アプリケーションから上記処理データ情報を取得するための処理データ取得部と、
上記メディアモジュール情報保持部から、使用リソース情報と必要リソース情報とを取得するためのリソース情報取得部と、
メディアモジュールの動作モードを選択し、選択された動作モードへの切り替えを指示する指示部と
を有している、メディア処理装置。
【請求項７】
メディア毎にメディア処理機能を実現する複数のメディアモジュールと、上記複数のメディアモジュールの各動作モードにおける使用リソース情報並びに処理データ情報に応じた必要リソース情報を保持するメディアモジュール情報保持部と、解析部とを有するメディア処理プロセッサと、
上記複数のメディアモジュールを用いてメディア処理を行うアプリケーションを有するアプリケーション処理プロセッサと
を備えたメディア処理装置を用いたメディア処理方法であって、
上記解析部が上記処理データ情報を取得するステップ（ａ）と、
上記解析部が上記使用リソース情報と上記必要リソース情報とを取得するステップ（ｂ）と、
上記解析部が、リソースの空きを調査して取得した情報に基づいて上記メディアモジュールのうちから動作モードの切替え候補を選択するステップ（ｃ）と、
上記解析部が、上記切替え候補のうちから動作モードを選択し、選択された動作モードへの切替えを指示するステップ（ｄ）と
を含んでいるメディア処理方法。
【請求項８】
請求項７に記載のメディア処理方法において、
１つのメディアモジュールごとに上記ステップ（ａ）、上記ステップ（ｂ）、上記ステップ（ｃ）、及び上記ステップ（ｄ）を繰り返す、メディア処理方法。
【請求項９】
請求項７に記載のメディア処理方法において、
上記複数のメディアモジュールの全てについて上記ステップ（ａ）、上記ステップ（ｂ）、及び上記ステップ（ｃ）を行った後に、上記ステップ（ｄ）を行なう、メディア処理方法。
【請求項１０】
請求項７または８に記載のメディア処理方法において、
上記解析部は、上記複数のメディアモジュールのそれぞれについてのモード切り替え時の優先度情報を有しており、上記優先度情報に応じて動作モードの切り替えの優先順位を決定する、メディア処理方法。
【請求項１１】
請求項７〜１０のうちいずれか１つに記載のメディア処理方法において、
上記メディア処理装置はプログラムを保持する記憶装置をさらに有しており、
上記プログラムは、コンピュータを用いて上記ステップ（ａ）、上記ステップ（ｂ）、上記ステップ（ｃ）、及び上記ステップ（ｄ）を実現する、メディア処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、メディア信号処理を行うメディア処理装置及びメディア処理方法に関し、特に、複数のメディア処理動を並行して行なう場合のリソース管理の最適化制御に関するものである。
【０００２】
【従来の技術】
近年、メディア処理装置が多機能化し、複数のメディア処理が並列して行われることが増えてきた。
【０００３】
単独のメディア信号処理を行う従来のメディア処理方法では、例えばＤＳＰ（Ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）が実行する一連の処理を、一定周期でサンプルされて入力するサンプル入力毎に実行する軽い処理と、サンプル入力の周期に比し充分に大きな複数倍の周期毎に実行する重い処理とに分離することが行われる。そして、メディア処理装置を、当該サンプル入力の複数倍の周期で実行する重い処理を時間的に複数に分割して分散的に実行するように構成することにより、ＤＳＰの単一ハードウェア当たりの処理能力の向上を実現していた（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開平９−８１５４２号公報（図１）
【０００５】
【発明が解決しようとする課題】
しかしながら、メディア処理装置で処理するメディアの種類が増え、上述のように一つの処理装置で複数のメディア処理を同時に行う場合が増えている。このため、メディア処理に使用する処理装置内のリソースを最適に利用することにより並列度を向上させる必要性がより一層高まってきた。
【０００６】
先に示した従来の技術では、メディア処理ごとに常に一定量のリソースを確保する。従って、この方法で複数のメディア処理を同時に行う場合には、各メディアモジュールが必要とするリソースの最大量を足し合わせたリソース量を常に確保する必要がある。しかし、実際に複数のメディア処理を並行して行なう場合でも、すべての機能を並行して実行していることは少なく、従来の方法では確保されたリソースが有効に使われていなかった。このため、ハードウェアの処理能力が十分に生かされていなかった。
【０００７】
本発明は、上記課題を解決するためになされたものであり、複数のメディア処理を並行して行なう場合に、リソースを最適に配分することができるメディア処理装置及びメディア処理方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明のメディア処理装置は、メディア毎にメディア処理機能を実現する複数のメディアモジュールを有するメディア処理プロセッサと、上記複数のメディアモジュールを用いてメディア処理を行うアプリケーションを有するアプリケーション処理プロセッサとを備えたメディア処理装置であって、上記複数のメディアモジュールのうち少なくとも１つは複数の動作モードを有しており、上記メディア処理プロセッサは、上記複数のメディアモジュールの各動作モードにおける使用リソース情報と、処理データ情報に応じた必要リソース情報とを保持するメディアモジュール情報保持部と、動作時に、上記アプリケーションから上記処理データ情報を取得し、上記メディアモジュール情報保持部から、上記使用リソース情報と上記必要リソース情報とを取得し、さらに、リソースの空き情報を調査して取得した情報に基づきメディアモジュールの動作モードを選択し、選択された動作モードへの切り替えを指示する解析部とを備えている。
【０００９】
これにより、ユーザーの処理要求などに応じて各メディアモジュールの動作モードの組み合わせを切替えることができるので、リソース配分を最適化することができ、複数のメディア処理を遅滞なく並行処理できるようになる。
【００１０】
上記メディア処理プロセッサは、メディア処理を行うための作業領域であるチップ内メモリをさらに備えており、上記使用リソース情報及び必要リソース情報には、上記チップ内メモリの容量についての情報が含まれていてもよい。
【００１１】
上記使用リソース情報及び必要リソース情報には、上記メディア処理プロセッサの負荷情報を含まれていてもよい。また、使用リソース情報及び必要リソース情報には、外付けメモリについてのリソース情報が含まれていてもよい。
【００１２】
上記解析部は、メディアモジュールごとにモード切り替え時の優先度情報を有しており、上記優先度情報に応じて動作モードの切り替えの優先順位を決定することにより、処理能力の低下を防ぐことができる。例えば、動作モード切替え時のオーバーヘッドが少ないメディアモジュールの優先度を高く設定しておけば、動作モードの切替え時に処理のオーバーヘッドを生じにくくすることができるので、処理能力の低下を効果的に防げる。
【００１３】
本発明のメディア処理方法は、メディア毎にメディア処理機能を実現する複数のメディアモジュールと、上記複数のメディアモジュールの各動作モードにおける使用リソース情報並びに処理データ情報に応じた必要リソース情報を保持するメディアモジュール情報保持部と、解析部とを有するメディア処理プロセッサと、上記複数のメディアモジュールを用いてメディア処理を行うアプリケーションを有するアプリケーション処理プロセッサとを備えたメディア処理装置を用いたメディア処理方法であって、上記解析部が上記処理データ情報を取得するステップ（ａ）と、上記解析部が上記使用リソース情報と上記必要リソース情報とを取得するステップ（ｂ）と、上記解析部が、リソースの空きを調査して取得した情報に基づいて上記メディアモジュールのうちから動作モードの切替え候補を選択するステップ（ｃ）と、上記解析部が、上記切替え候補のうちから動作モードを選択し、選択された動作モードへの切替えを指示するステップ（ｄ）とを含んでいる。
【００１４】
この方法により、動作時に動作モードが適宜切替えられるので、状況に応じてリソース配分が行われるので、リソースの有効利用が可能となる。その結果、複数のメディア処理を並行して行えるようになる。また、リソース配分を最適化すると共に、消費電力の低減を図ることもできる。
【００１５】
１つのメディアモジュールごとに上記ステップ（ａ）、上記ステップ（ｂ）、上記ステップ（ｃ）、及び上記ステップ（ｄ）を繰り返すことにより、全てのメディアモジュールについてステップ（ａ）〜（ｃ）を繰り返す場合に比べ、より短時間で処理を行なうことができる。
【００１６】
上記複数のメディアモジュールの全てについて上記ステップ（ａ）、上記ステップ（ｂ）、及び上記ステップ（ｃ）を行った後に、上記ステップ（ｄ）を行なうことにより、先に全ての動作モードの組み合わせを候補に挙げることができるので、最適な動作モードの組み合わせを選択することができる。
【００１７】
上記解析部は、上記複数のメディアモジュールのそれぞれについてのモード切り替え時の優先度情報を有しており、上記優先度情報に応じて動作モードの切り替えの優先順位を決定することにより、例えば切替え時にオーバーヘッドを起こしにくいメディアモジュールの優先度を高めておくことにより、処理能力の低下を防ぐことが可能となる。
【００１８】
上記メディア処理装置はプログラムを保持する記憶装置をさらに有しており、
上記プログラムは、コンピュータを用いて上記ステップ（ａ）、上記ステップ（ｂ）、上記ステップ（ｃ）、及び上記ステップ（ｄ）を実現してもよい。
【００１９】
【発明の実施の形態】
本発明の各実施形態を、図を用いながら以下に説明する。ここでは、メディア処理として音楽の再生、録音、および無線を利用した他の装置との音声通話を例として挙げるが、録画再生やＣＧ処理など、メディア処理はこれらに限定されるものではない。
【００２０】
（第１の実施形態）
図１は、本発明の第１の実施形態に係るメディア処理装置を示すブロック図である。ここに示すメディア処理装置の例としては、携帯電話などが挙げられる。
【００２１】
図１に示すように、本実施形態のメディア処理装置は、入力されるストリームデータを処理するためのアプリケーション処理プロセッサ１と、アプリケーションプロセッサからの指令に基づいてメディア処理を行なうメディア処理プロセッサ２と、不揮発性メモリである記録メディア３と、例えば通信や通話に関する処理を行なうためのベースバンドプロセッサ４と、スピーカー５と、マイク６と、外付けメモリ７とを備えている。
【００２２】
アプリケーション処理プロセッサ１は、ひとつ以上のアプリケーションを有し、ユーザからの処理要求を受けて、記録メディア３、ベースバンドプロセッサ４との間でデータ送受信を行い、また、メディア処理プロセッサ２の制御を行っている。なお、図１に示す例において、アプリケーション処理プロセッサ１には、第１のアプリケーション１１と第２のアプリケーション１２とが含まれている。第１のアプリケーション１１及び第２のアプリケーション１２は、メディア処理プロセッサ２内の音楽再生モジュール２３及び音声通話モジュール２４をそれぞれ制御し、メディア処理を実現する。
【００２３】
また、メディア処理プロセッサ２は、解析部２１と、メディアモジュール情報保持部２２と、チップ内メモリ２５と、複数のメディアモジュールとを有し、メディア処理のための演算を行い、ハードウェアデバイスを制御するプロセッサである。図１に示す例において、メディア処理プロセッサ２には、音楽再生モジュール２３と音声通話モジュール２４とが含まれている。
【００２４】
記録メディア３は、メディア処理に必要なストリームデータなどを保存するための不揮発性メモリである。
【００２５】
ベースバンドプロセッサ４は、無線を利用して他の装置との通信を行うためのプロセッサである。
【００２６】
スピーカー５は、メディア処理プロセッサ２から受け取った音声データの出力を行う。
【００２７】
マイク６は、取得した音声データをメディア処理プロセッサ２に出力する。
【００２８】
外付けメモリ７は、メディアモジュールが利用するワークメモリである。
【００２９】
そして、メディアモジュール情報保持部２２は、以下に示す２種類の情報を保持している。
【００３０】
メディアモジュール情報保持部２２は、各メディアモジュールが動作時に使用するリソースの情報を、その動作モードごとに図２に示すような形式で保持している。各メディアモジュールは、自らの使用リソースの組み合わせを複数組用意しており、それぞれを動作モードと呼ぶ。
【００３１】
また、メディアモジュール情報保持部２２は、各メディアモジュールが動作時に必要となる演算量の情報を、メディアモジュールで処理するストリームデータのデータフォーマットの種類およびビットレートごとに図３に示すような形式で保持している。この情報を、本明細書では処理データ情報と呼ぶ。
【００３２】
ここで、図２は、音楽再生モジュール及び音声通話モジュールについてのリソース情報を示す図であり、図３は、ストリーム情報のフォーマットの種類やビットレートの情報を示す図である。図２には、各モードについて、チップ内メモリ及び外付けメモリの必要量、マイク及びスピーカーの使用の有無、演算可能量（使用するＣＰＵリソース量）、消費電力などの情報を示している。また、図３には、フォーマットの種類とビットレート情報の他に必要演算量を示している。
【００３３】
解析部２１は、第１のアプリケーション１１、第２のアプリケーション及びメディアモジュール情報保持部２２から、それぞれ、データフォーマットの種類とビットレートの情報、使用リソース情報、必要リソース情報を受け取り、その情報から動作中のメディアモジュールに最適な動作モードを決定し、音楽再生モジュール２３及び音声通話モジュール２４に対してモードの変更を指示する。解析部２１での動作モードを決定する処理の流れについての詳細は後述する。
【００３４】
メディア処理プロセッサ２内には、複数のメディアモジュールが存在し、状況に応じ並列に動作することができる。本実施形態のメディア処理プロセッサ２は、記録メディア３に保存されている音楽データをスピーカー５で再生するための音楽再生モジュール２３と、ベースバンドプロセッサ４、スピーカー５及びマイク６を利用して、無線を通じて他の装置と音声通話を行うための音声通話モジュール２４とを有している。
【００３５】
各メディアモジュールは、アプリケーション処理プロセッサ１内の各アプリケーションから制御され、メディア処理の演算を行う。
【００３６】
また、各メディアモジュールは、必要であればスピーカー５、マイク６の各種ハードウェアデバイスと接続され、これらのハードウェアデバイスを使用することができる。本実施形態のメディア処理装置では、音楽再生モジュール２３がスピーカー５に接続され、音声通話モジュール２４がスピーカー５及びマイク６に接続される。
【００３７】
アプリケーション処理プロセッサ１内の第１のアプリケーション１１は、外部からの処理要求を受け、記録メディア３から音楽ストリームデータを取り出し、ストリームデータおよび制御命令を音楽再生モジュール２３と送受信することで音楽再生モジュール２３を制御するとともに、スピーカー５で音楽の再生を行わせる。
【００３８】
また、第２のアプリケーション１２は、外部からの処理要求を受け、音声通話モジュール２４を制御し、ベースバンドプロセッサ４からの音声ストリームデータを処理してスピーカー５で再生させ、また、マイク６からの音声データを処理してベースバンドプロセッサ４に送る。
【００３９】
次に、解析部２１において、動作モードを決定する処理の流れを図４、図５、図６に示すフローチャートを用いて説明する。
【００４０】
図４は、本実施形態のメディア処理方法を示すフローチャート図であり、図５は、メディア処理方法におけるリソース情報収集手順を示すフローチャート図である。また、図６は、メディア処理方法における切替え候補からの動作モード選択手順を示すフローチャート図である。
【００４１】
この動作モードの決定は、動作中の各メディアモジュールに対して、アプリケーションから得られるストリーム情報の変化、あるいは、メディアモジュールの起動や停止などの状況変化によって繰り返し行われる。また、ステップＳ１１〜ステップＳ２２までの手順は状況に応じて繰り返され（繰り返しＡ）、ステップＳ１４〜ステップＳ１８も必要に応じて繰り返される（ステップＢ）。
【００４２】
まず、図４に示すステップＳ１１では、ストリーム情報の変化やメディアモジュールの状況変化を受けて、動作モードの切替えを開始する。ステップＳ１１からステップＳ２２までの処理は、メディアモジュールごとに行なう。
【００４３】
続いて、ステップＳ１２では、解析部２１がリソース情報の収集を行なう。このリソース情報の収集ステップは、図５に示す複数のステップで構成されている。
【００４４】
まず、ステップＳ１２２では、解析部２１は、アプリケーションからストリームデータのデータフォーマットの種類およびビットレートの情報を取得する。
【００４５】
次に、ステップＳ１２３では、解析部２１が、取得したデータフォーマットの種類とビットレートの情報を用いて、メディアモジュール情報保持部２２から、動作時に必要となる演算量の情報を取得する。
【００４６】
次いで、ステップＳ１２４で、解析部２１は、チップ内メモリ２５及び外付けメモリ７を調査し、それぞれの空き容量についての情報を取得する。以上の手順によりリソース情報の収集が行われる。
【００４７】
次に、図４に示すステップＳ１３では、対象のメディアモジュールに対する全動作モードを一旦切り替え候補とする。
【００４８】
続くステップＳ１４では、以下の処理を動作モードごとに行う。
【００４９】
すなわち、ステップＳ１５で、解析部２１は、メディアモジュール情報保持部２２から、メディアモジュールの動作モードごとの使用リソース情報を取得する。
【００５０】
次に、ステップＳ１６では、演算量、チップ内メモリ、外付けメモリの各リソースの中に、この動作モードを選択することによりリソース不足となる項目があるかどうかを解析部２１が判断する。ここで、リソース不足となる項目があればステップＳ１７へ、なければステップＳ１８へ進む。
【００５１】
そして、ステップＳ１７では、ステップＳ１６でリソース不足が検出された動作モードを切替え候補からはずす。そして、ステップＳ１８に進む。
【００５２】
次に、ステップＳ１８では、再度ステップＳ１４に戻り、別の動作モードについての検討を行う。このステップＳ１４からステップＳ１８までの手順は、全ての動作モードを検討するまで繰り返される。
【００５３】
次に、ステップＳ１９では、選択されたメディアモジュール内の全ての動作モードについてステップＳ１４からＳ１８までの処理が終わった後、切替え候補の中から切替え対象となる動作モードを選択する。このステップはステップＳ１９１〜ステップＳ１９６までのステップを含んでいる。
【００５４】
まず、図６に示すステップＳ１９１で、切替え候補の動作モードが存在するかどうかを判定する。切替え候補が存在すればステップＳ１９２へ進み、存在しなければステップＳ１９４へ進む。
【００５５】
次に、ステップＳ１９２では、リソース不足により動作不可と判断されたメディアモジュールがあるか否かを解析部２１が判定する。ここで、動作不可とされたメディアモジュールが存在すれば、ステップＳ１９６へ進み、存在しなければステップＳ１９３へと進む。
【００５６】
次いで、ステップＳ１９３では、残った切替え候補のうち最も消費電力が少ないものを最適の動作モードとして選択する。なお、本実施形態では、消費電力の低減を優先しているが、これ以外の事項、例えば音質を優先するように動作モードを選択するようにしても構わない。
【００５７】
また、ステップＳ１９６で、以前にリソース不足によって動作不可と判断されたメディアモジュールがあった場合は、動作不可の原因となったリソース項目の消費量が少ない動作モードを選択する。
【００５８】
一方、ステップＳ１９４で、本手順で検討されたメディアモジュールは動作不可であると解析部２１が判断する。
【００５９】
続いて、ステップＳ１９５では、ステップＳ１９４で動作不可であると判断された原因のリソース項目を解析部２１が記憶する。
【００６０】
以上のステップの後、図４に示すステップＳ２０へ進む。
【００６１】
ステップＳ２０では、ステップＳ１９で選択された動作モードが現在動作中の動作モードと異なるか否かを解析部２１が判断する。選択された動作モードが動作中の動作モードと同一である場合にはステップＳ２２へと進み、異なる場合にはステップＳ２１へと進む。
【００６２】
そして、ステップＳ２１で、解析部２１は、選択された動作モードへの切替えをメディアモジュールに対して指示する。その後、ステップＳ２２に進む。
【００６３】
次に、ステップＳ２２では、再度ステップＳ１１に進み、以上のステップＳ１１からステップＳ２１を別のメディアモジュールについて繰り返す。
【００６４】
以上の方法により、リソースの再配分を適切に行なうことができるので、複数のメディア処理を並行して行なうことが可能となる。
【００６５】
次に、動作モードが切り替えられる際の動作の具体例を、図７、図８を用いて順を追って説明する。
【００６６】
図７は、音楽再生モジュール及び音声通話モジュールにおける動作モードの切替えを示す図であり、図８は、本具体例における処理を示すフローチャート図である。これらの図を参照しながら以下に本具体例について説明する。ここで、スピーカー５（図１参照）は複数のメディアモジュールからの同時使用を認めるものとし、チップ内メモリの合計は６４ＫＢ、外付けメモリの合計は５１２ＫＢであったとする。
【００６７】
まず、最初に時刻ｔ０において、外部からの処理要求によって、第２のアプリケーション１２が音声通話モジュール２４を起動したとする。
【００６８】
このとき、解析部２１は、前述の動作モードを決定する処理の流れに沿って最適な動作モードの解析を行うが、ほかにメディアモジュールが動作しておらず、メモリなどのリソースは十分にあるため、ステップＳ１９３において、より消費電力の少ない、図２に示す「動作モード２」を選択することになる。「動作モード２」で動作を開始した音声通話モジュール２４により、チップ内メモリは３０ＫＢが消費され、スピーカー５、マイク６が使用中の状態になる。
【００６９】
次に、時刻ｔ１において、音声通話モジュール２４が動作した状態のまま、外部からの処理要求によって、第１のアプリケーション１１が図３に示すＦＯＲＭＡＴ−Ｂの１２８ｋｂｐｓの音楽データを再生するために、音楽再生モジュール２３を起動しようとしたとする。
【００７０】
このとき、解析部２１は、ステップＳ１２３において、メディアモジュール情報保持部２２の持つ演算量情報（図３）から必要演算量が３０ＭＩＰＳであることを読みとるので、ステップＳ１６において、図２に示す「動作モード１」以外は演算可能量が不足しており、切り替え候補からはずれる。
【００７１】
ところが、音声通話モジュール２４は動作モード２で動作中で、チップ内メモリ３０ＫＢを使用しているためにチップ内メモリの空き容量は３４ＫＢであり、音楽再生モジュール２３の動作モード１で使用する３５ＫＢを確保することができず動作モード１も切り替え候補からはずれてしまう。
【００７２】
このため、音声通話モジュールは一旦、ステップＳ１９４において動作不可能と判断され、ステップＳ１９５においてチップ内メモリが足りなかったことが記憶される。
【００７３】
しかし、この後時刻ｔ２において、解析部２１は、すでに動作中である音声通話モジュール２４の動作モードを切り替えようと試み、ステップＳ１９２、Ｓ１９６において、先に動作不可能と判断されたメディアモジュールがあり、その原因がチップ内メモリの空きサイズ不足であったことから、チップ内メモリの使用量が少ない「動作モード１」を選択し、モード切り替えを指示する。すなわち、時刻ｔ２において、解析部２１からの指示により、音声通話モジュール２４は、「動作モード２」から「動作モード１」に切り替えられる。
【００７４】
「動作モード１」で動作を開始した音声通話モジュール２４により、外付けメモリの消費量は２５ＫＢに増加するが、チップ内メモリの消費量は３０ＫＢから１０ＫＢに減少し、スピーカー５、マイク６が使用中の状態に変化はない。これによりチップ内メモリの空きサイズが３４ＫＢから５４ＫＢに増加する。
【００７５】
次に、時刻ｔ３において、解析部２１はもう一度、音楽再生モジュール２３の動作モード選択を行い、チップ内メモリの空きサイズが増加しているために、今度は「動作モード１」が切り替え候補として残り、「動作モード１」が選択されて、音楽再生モジュール２３は動作を開始する。
【００７６】
「動作モード１」で動作中の音声通話モジュール２４と、「動作モード１」で動作を開始した音楽再生モジュール２３により、チップ内メモリは４５ＫＢ、外付けメモリは２５ＫＢが消費され、スピーカー５が２つのメディアモジュールの共用状態、マイク６が使用中の状態になる。
【００７７】
このように、メディアモジュールの動作モードを動的に切り替えることによって、リソースの動的な再配分が行われ、複数のメディアモジュールを並行して動作させることができる。
【００７８】
なお、以上の説明では、解析部２１が最適な動作モードの選択のために利用するリソース情報として、演算量、メモリ容量を用いていたが、これらに加えて、メディア処理プロセッサの負荷率の情報を用いても、同様の手法でリソースの最適な再配分を可能とするような動作モードの動的変更が可能である。
【００７９】
また、本実施形態のメディア処理装置として、図１に示すようなハード構成を有する例を示したが、各アプリケーション、解析部、メディアモジュールの動作をプログラムされたソフトウェアを用いて本実施形態のメディア処理装置と同様の処理をプロセッサに行わせることも可能である。このようなプログラムは、例えば装置外部のＲＯＭなどに記録しておけばよい。
【００８０】
また、本実施形態のメディア処理装置では、解析部２１が処理データを取得し、メディアモジュールの動作モードを選択し、選択された動作モードへの切替えを指示していたが、これらの動作を別個の部分で行ってもよい。
【００８１】
（第２の実施形態）
図９は、本発明の第２の実施形態に係るメディア処理装置の構成を示すブロック図である。
【００８２】
同図に示すように、本実施形態のメディア処理装置は、アプリケーション処理プロセッサ１、メディア処理プロセッサ２、不揮発性メモリである記録メディア３、ベースバンドプロセッサ４、スピーカー５、マイク６及び外付けメモリ７を備えている点は第１の実施形態と同様だが、メディア処理プロセッサ２内に、解析部２１の代わりに解析部１２１を追加している。ここでは、第１の実施形態のメディア処理装置と異なる点のみ説明する。
【００８３】
まず、解析部１２１は、メディアモジュールごとに動作モード切り替えに対する優先度を保持している。
【００８４】
解析部１２１での動作モードの決定手法を図１０および、図５、図６に示すフローチャートを用いて説明する。
【００８５】
ここで、図１０は、本実施形態のメディア処理方法を示すフローチャート図である。
【００８６】
解析部１２１は、以下の処理を動作中の全メディアモジュールについてステップＳ３１からステップＳ４２までの処理を繰り返す。ここで、繰り返す際の順序は動作モード切り替えに対する優先度が高いメディアモジュールの順とする
まず、ステップＳ３１では、ストリーム情報の変化やメディアモジュールの状況変化を受けて、動作モードの切替えを開始する。
【００８７】
次に、解析部１２１は、解析部２１と同様に、メディアモジュール情報保持部２２からリソース情報を取得する。このステップは図５に示す第１の実施形態のリソース処理方法と同様である。
【００８８】
次に、ステップＳ３３及びステップＳ３４で、対象のメディアモジュールに対する全動作モードを一旦切り替え候補として、以下の処理を動作モードごとに行う。
【００８９】
そして、ステップＳ３５で、解析部１２１は、メディアモジュール情報保持部２２から、メディアモジュールの動作モードごとのリソース情報を取得する。
【００９０】
次いで、ステップＳ３６では、演算量、チップ内メモリ、外付けメモリの各リソースの中に、この動作モードを選択することによりリソース不足となる項目があるかどうかを解析部１２１が検討する。ここで、リソース不足となる項目があればステップＳ３７へ進み、無ければステップＳ３８に進む。
【００９１】
次に、ステップＳ３７では、ステップＳ３６でリソース不足が検出された動作モードを切替え候補からはずす。そして、ステップＳ３８へ進む。
【００９２】
次に、ステップＳ３８では、再度ステップＳ３４に戻り、別の動作モードについての検討を行う。このステップＳ３４からステップＳ３８までの手順は、全ての動作モードを検討するまで繰り返される。
【００９３】
次に、ステップＳ３９では、全ての動作モードについてステップＳ３４からステップＳ３８までの処理が終わった後、切替え候補の中から最適な動作モードを選択する。
【００９４】
次いで、ステップＳ４０で、解析部１２１は、ステップＳ３９で選択された動作モードが現在のモードと異なるか否かを判断する。選択された動作モードが動作中の動作モードと同一である場合にはステップＳ４２へと進み、異なる場合にはステップＳ４１へと進む。
【００９５】
次に、ステップＳ４１では、解析部１２１が選択された動作モードへの切り替えをメディアモジュールに対して指示し、このメディアモジュールより動作モード切り替えの優先度が低いメディアモジュールに対する処理を中断して、あらためて優先度の高いメディアモジュールから処理を再開する。ステップＳ４０で動作モードの切替えが発生した場合に、以上のようにして繰り返しを抜け出すことにより、動作モード切替えの優先度が高いメディアモジュールの動作モードの切り替え頻度を優先度が低いものに比べて高くできる。
【００９６】
優先度の決定方法については特に規定しないが、例えば、動作モード切り替え時のオーバーヘッドが少ないメディアモジュールの優先度を高く設定する方法がある。この方法によれば、動作モードの切替えのオーバーヘッドが大きいメディアモジュールに対するモード切替え指示の頻度が低くなり、処理能力の低下を防ぐことができる。
【００９７】
（第３の実施形態）
本発明の第３の実施形態として、第１の実施形態に係るメディア処理装置を用い、第１の実施形態とは異なる処理を行なうメディア処理方法について説明する。
【００９８】
図１１は、第３の実施形態に係るメディア処理方法を示すフローチャート図であり、図１２は、本実施形態のメディア処理方法におけるリソース情報収集手順を示すフローチャート図である。また、図１３は、本実施形態のメディア処理方法における切替え候補からの動作モード選択手順を示すフローチャート図である。
【００９９】
まず、図１１に示すステップＳ５１では、ストリーム情報の変化やメディアモジュールの状況変化を受けて、動作モードの切替えを開始する。
【０１００】
続いて、ステップＳ５２では、選択されたメディアモジュールの全動作モードを切替え候補として以下の処理を行なう。
【０１０１】
次に、ステップＳ５３では、解析部２１がリソース情報の収集を行なう。このリソース情報の収集ステップは、図１２に示す複数のステップで構成されている。
【０１０２】
まず、ステップＳ５３１で、解析部２１は、アプリケーションからストリームデータのデータフォーマットの種類およびビットレートの情報を取得する。
【０１０３】
次に、ステップＳ５３２では、解析部２１が、取得したデータフォーマットの種類とビットレートの情報を用いて、メディアモジュール情報保持部２２から、動作時に必要となる演算量の情報を取得する。なお、本実施形態のメディア処理方法は、全ての動作中、あるいは動作しようとしているメディアモジュールの、全ての動作モードの組み合わせを一度に調査して最適な組み合わせを求めるものであるので、この時点でメモリの空き容量を調べる必要はない。
【０１０４】
次いで、ステップＳ５４では、以下の処理を動作モードごとに行なう。
【０１０５】
すなわち、ステップＳ５５で、解析部２１は、メディアモジュール情報保持部２２から、メディアモジュールの動作モードごとの使用リソース情報を取得する。
【０１０６】
次に、ステップＳ５６では、この動作モードでの演算可能量が必要演算量を満たしているか否かを解析部２１が判断する。ここで、演算可能量が必要演算量を満たしていればステップＳ５８へ、満たしていなければステップＳ５７へ進む。
【０１０７】
そして、ステップＳ５７では、ステップＳ５６で必要演算量を満たさなかった動作モードを切替え候補からはずす。そして、ステップＳ５８へ進む。
【０１０８】
次に、ステップＳ５８では、再度ステップＳ５４に戻り、別の動作モードについての検討を行う。このステップＳ５４からステップＳ５８までの手順は、全ての動作モードを検討するまで繰り返される。
【０１０９】
次いで、ステップＳ５９では、再度ステップＳ５１に進み、別のメディアモジュールの動作モードについてステップＳ５１からステップＳ５８までの処理を繰り返す。ここが第１の実施形態と本実施形態の処理方法の異なる点である。すなわち、第１の実施形態においては、メディアモジュールごとに最適な動作モードを選択し、その後に異なるメディアモジュールについての検討を行っていたが、本実施形態の方法では、先に全てのメディアモジュールの動作モードについて検討し、その後に全ての動作モードの中から最適な動作モードを選択する。
【０１１０】
次に、ステップＳ６０では、全てのメディアモジュール内の全ての動作モードについてステップＳ５１からステップＳ５９までの処理が終わった後、切替え候補の中から切替え対象となる動作モードを選択する。本ステップでは、それぞれの動作中、あるいは動作しようとしているメディアモジュールに対する動作モードの最適な組み合わせが一つだけ決められる。
【０１１１】
このステップＳ６０は、図１３に示すステップＳ６０１〜ステップＳ６１０までのステップを含んでいる。
【０１１２】
まず、ステップＳ６０１で、最適動作モードの組み合わせ候補を「該当なし」とする。
【０１１３】
次いで、ステップＳ６０２で、解析部２１がシステムでの最大消費電力ｗを算出する。ここで、最大消費電力ｗは、それまで調べた中で最も消費電力が少ない組み合わせの消費電力を格納する変数である。
【０１１４】
続いて、ステップＳ６０３では、ステップＳ５７で選択対象外とならなかった動作モードの全組み合わせを検討する。
【０１１５】
そして、ステップＳ６０４では、当該組み合わせでの合計リソース使用量をリソースの種類ごとに解析部２１が計算する。
【０１１６】
続くステップＳ６０５では、計算の結果、リソース不足となる項目があるか否かを解析部２１が判断する。そして、リソース不足となる項目があればステップＳ６０９へ進み、なければステップＳ６０６へ進む。
【０１１７】
次に、ステップＳ６０６では、動作モードの当該組み合わせでの消費電力が最大消費電力ｗより少ないかどうかを判定する。消費電力が最大消費電力ｗより少ない場合はステップＳ６０７へ進み、最大消費電力ｗと同等である場合にはステップＳ６０９へ進む。
【０１１８】
そして、ステップＳ６０７では、解析部２１が動作モードの当該組み合わせでの消費電力ｗを算出する。
【０１１９】
続いて、ステップＳ６０８では、動作モードの当該組み合わせを最適動作モードの組み合わせ候補とする。その後、ステップＳ６０９に処理を進める。
【０１２０】
次に、ステップＳ６０９では、ステップＳ６０３に再び処理を進め、異なる動作モードの組み合わせについてステップＳ６０４からステップＳ６０８までの処理を繰り返す。この際に、最大消費電力ｗは、ステップＳ６０４からステップＳ６０８までの繰り返しの中でさらに消費電力の少ない組み合わせが見つかった場合、随時更新される。
【０１２１】
次いで、ステップＳ６１０では、ステップＳ５６で選択された全ての動作モードの組み合わせを検討後、最後に選択された最適動作モードの組み合わせ候補を最適動作モード組み合わせとする。本実施形態では、最後に選択された動作モードの組み合わせが、消費電力が最小となる組み合わせになっている。以上の処理後、ステップＳ６１に処理を進める。
【０１２２】
次に、ステップＳ６１では、動作中または動作しようとしている各メディアモジュールについて以下の処理を行なう。
【０１２３】
すなわち、ステップＳ６２では、先のステップＳ６１までで選択された動作モードが現在の動作モードと異なっているかどうかを判別する。そして、選択された動作モードが動作中の動作モードと異なる場合にはステップＳ６３へ進み、動作中の動作モードと同じ場合にはステップＳ６４へ進む。
【０１２４】
次に、ステップＳ６４では、再びステップＳ６１に進み、処理を繰り返す。ここで、ステップＳ６１〜Ｓ６４の繰り返しは、動作中または動作しようとしているメディアモジュールの数だけ行われる。
【０１２５】
以上のように、本実施形態のメディア処理方法では、全てのメディアモジュールに含まれる動作モードを選択対象とした後で最適な動作モードの組み合わせを求めるので、第１のメディア処理方法に比べて最適な動作モードの組み合わせを確実に求めることができる。本実施形態ではステップＳ６０６での動作モードの選択基準を消費電力としているので、より消費電力の小さい動作モードを必要に応じて実行させることが可能になる。
【０１２６】
なお、必要に応じて消費電力以外の選択基準を採用しても構わない。
【０１２７】
【発明の効果】
本発明のメディア処理装置によれば、メディア処理ごとに使用リソースの異なる動作モードを持ち、状況に応じた最適なリソース配分を行い、メディア処理に使用する処理装置内のリソースを最適に利用することにより、複数のメディア処理を並行して行なうことができる。また、状況に応じた最適なリソース配分の結果、消費電力の削減も可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るメディア処理装置を示すブロック図である。
【図２】音楽再生モジュール及び音声通話モジュールについてのリソース情報を示す図である。
【図３】ストリーム情報のフォーマットの種類やビットレートの情報を示す図である。
【図４】本発明のメディア処理方法を示すフローチャート図である。
【図５】第１の実施形態及び第２の実施形態に係るメディア処理方法におけるリソース情報収集手順を示すフローチャート図である。
【図６】第１の実施形態及び第２の実施形態に係るメディア処理方法における切替え候補からの動作モード選択手順を示すフローチャート図である。
【図７】第１の実施形態に係るメディア処理方法において、音楽再生モジュール及び音声通話モジュールにおける動作モードの切替えを示す図である。
【図８】第１の実施形態の具体例に係るメディア処理方法を示すフローチャート図である。
【図９】本発明の第２の実施形態に係るメディア処理装置の構成を示すブロック図である。
【図１０】第２の実施形態に係るメディア処理方法を示すフローチャート図である。
【図１１】第３の実施形態に係るメディア処理方法を示すフローチャート図である。
【図１２】第３の実施形態のメディア処理方法におけるリソース情報収集手順を示すフローチャート図である。
【図１３】第３の実施形態のメディア処理方法における切替え候補からの動作モード選択手順を示すフローチャート図である。
【符号の説明】
１          アプリケーション処理プロセッサ
２          メディア処理プロセッサ
３          記録メディア
４          ベースバンドプロセッサ
５          スピーカー
６          マイク
７          外付けメモリ
１１        第１のアプリケーション
１２        第２のアプリケーション
２１        解析部
２２        メディアモジュール情報保持部
２３        音楽再生モジュール
２４        音声通話モジュール
２５        チップ内メモリ
１２１      解析部
【図１】
2005004581.tif 000003
【図２】
2005004581.tif 000004
【図３】
2005004581.tif 000005
【図４】
2005004581.tif 000006
【図５】
2005004581.tif 000007
【図６】
2005004581.tif 000008
【図７】
2005004581.tif 000009
【図８】
2005004581.tif 000010
【図９】
2005004581.tif 000011
【図１０】
2005004581.tif 000012
【図１１】
2005004581.tif 000013
【図１２】
2005004581.tif 000014
【図１３】
2005004581.tif 000015