JP2006243016A - オーディオデコード装置 - Google Patents

Abstract

【課題】 本発明の課題は、動作中であっても、ＣＰＵが処理する仕事がない状態を適切に検出してスリープ状態に移行することによって、消費電流の削減を可能とするオーディオデコード装置を提供することを目的とする。
【解決手段】 上記課題は、圧縮されたストリームの復号に係る主要タスクが実行されたか否かを判断する主要タスク実行判断手段と、前記主要タスクが実行されなかったと判断すると、スリープカウントをインクリメントするスリープカウント手段と、前記主要タスクが実行されたと判断すると、前記スリープカウントをゼロクリアするスリープカウント初期化手段と、動作中であって、かつ、前記スリープカウントがスリープ遷移閾値を越えているか否かを判断するスリープ判断手段と、前記スリープカウントがスリープ遷移閾値を越えている場合、スリープ状態に遷移するスリープ状態遷移手段とを有するオーディオデコード装置によって達成される。
【選択図】 図５

Description

本発明は、圧縮されたストリームを復号するオーディオデコード装置に関し、特に、動作中の場合でもＣＰＵが処理する仕事がない状態を適切に検出してスリープ状態に移行することによって、消費電流の削減を可能とするオーディオデコード装置に関する。

ＣＰＵによって制御されるコンピュータ装置の普及により、電力消費を削減する試みがなされてきている。

例えば、マイクロプロセッサに配置されるカウンタの計数に基づいて、マイクロプロセッサの使用度を予測し、その予測された使用度と閾値とを比較することによって、マイクロプロセッサの電力消費を選択的に調整することが提案されている（例えば、特許文献１）。

また、ＤＭＡ転送要求信号が所定時間以上出力されない場合、ＣＰＵをスリープモード、或いは、電源停止モードへ遷移するように制御する印刷装置が提案されている（例えば、特許文献２）。

更に、マルチタスクＯＳによるソフトウェア制御システム環境において、時間制約があり且つ付加変動のある複数のタスクを実行させる際に、プロセッサの消費電力を効果的に節減することが提案されている（例えば、特許文献３）。
特開平１１−１６１３８３号公報 特開２００３−３３７７１３号公報 特開２００１−１８００８３号公報

しかしながら、オーディオデコード装置では、従来、非動作時になったときにのみスリープモードになっていた。その結果、動作中であるにも関わらずＣＰＵが処理する仕事がない場合でもメインループを延々と回っているだけで電流を消費していた。

本発明は、上述の問題点に鑑みてなされたものであって、動作中であっても、ＣＰＵが処理する仕事がない状態を適切に検出してスリープ状態に移行することによって、消費電流の削減を可能とするオーディオデコード装置を提供することを目的とする。

上記課題を解決するため、本発明は、圧縮されたストリームの復号に係る主要タスクが実行されたか否かを判断する主要タスク実行判断手段と、前記主要タスクが実行されなかったと判断されると、スリープカウントをインクリメントするスリープカウント手段と、前記主要タスクが実行されたと判断されると、前記スリープカウントをゼロクリアするスリープカウント初期化手段と、ステートが動作中であって、かつ、前記スリープカウントがスリープ遷移閾値を越えているか否かを判断するスリープ判断手段と、前記スリープカウントがスリープ遷移閾値を越えている場合、スリープ状態に遷移するスリープ状態遷移手段とを有するように構成される。

このようなオーディオデコード装置では、連続して主要タスクが何も実行されない回数が閾値を超えると、ＣＰＵのスリープ動作に遷移するように制御可能となる。したがって、低消費電流化を実現することができる。

本発明は、連続して主要タスクが実行されない回数をカウントして、その値が閾値を超えると、ＣＰＵのスリープ動作に遷移することで、低消費電流のオーディオデコード装置を構成することが可能である。更に、以前に連続して主要タスクが実行された回数をカウントして、この情報に基づいて適応的にスリープ遷移閾値を動的に決定することができる。したがって、効率的にスリープ動作に遷移可能となる。

以下、本発明の実施の形態を図面に基づいて説明する。

図１は、本発明に係るオーディオ装置の原理を説明するためのブロック図である。図１において、オーディオ装置１００は、ＣＰＵ（Central Processing Unit）及びメインメモリ１１０と、ＤＭＡ転送回路１２０と、ＳＤＲＡＭ１３０と、ＤＭＡ転送回路及びＰＣＭ出力回路１４０とで構成される。ハードウェア構成としては、ＤＭＡ転送回路１２０とＤＭＡ転送回路及びＰＣＭ出力回路１４０とは一つである。また、図１では、ＣＰＵのファームウェアで処理する部分をタスクとして示している。

ストリーム及びデータの処理は次のようになる。

まず、上位ＣＰＵからストリームバッファ１３２へＡｕｄｉｏ（オーディオ）の圧縮されたストリームが順次格納される。ストリームが溜まり、かつ、バンクバッファとして構成されるＰＥＳ（Packetized Elementary Stream）バッファ１１２に１面以上の空きがあると、ＰＥＳ転送タスクＴＳＫ１が実行される。これは、アクセス時間の遅いＳＤＲＡＭ１３０からＣＰＵが高速に処理できるメインメモリへストリームを転送する処理である。

このＰＥＳ転送タスクＴＳＫ１によって、２５６バイト単位でＰＥＳバッファ１１２へデータが転送される。このタスクはＤＭＡ転送回路１２０への起動処理であって、実際の転送はＤＭＡ転送（ＤＭＡ＿ＤＳ）で行われる。

１面以上のＰＥＳバッファ１１２があり、かつ１面以上のリングバッファとして構成されるＥＳ（Elementary Stream）バッファ１１４の空きがあると、ＥＳ抽出タスクＴＳＫ２が実行される。ＥＳ抽出タスクＴＳＫ２は、ＰＥＳストリームからＡｕｄｉｏのＥＳデータを抽出する処理である。

ＥＳバッファ１１４は、１ＥＳ以上溜まり、かつ、ＰＣＭバッファ１３４に１面以上の空きがあると、デコード処理タスクＴＳＫ３が実行される。デコード処理タスクＴＳＫ３は、符号化されたストリームを復号する本体の処理である。復号されたデータは、単一バッファとして構成される一時バッファ１１６へ一旦格納され、ＰＣＭ転送タスクＴＳＫ４が連動して実行される。ＰＣＭ転送タスクＴＳＫ４は、ＤＭＡ転送回路１２０への起動処理で実際の転送は、ＤＭＡ転送（ＤＭＡ＿ＥＴＣ）で行われる。

ＰＣＭバッファ１３４に１面以上存在すると、ＰＣＭ出力タスクＴＳＫ５が実行される。ＰＣＭ出力タスク５は、デコードしたデータを一定レートでシリアルで外部端子へ転送する。ＰＣＭ出力タスク５は、ＤＭＡ転送回路１２０への起動処理で実際の転送は、ＤＭＡ転送（ＤＭＡ＿ＤＰ）で行われる。

一旦、ＰＣＭ出力タスクＴＳＫ５が実行され、ＰＣＭが出力され始め動作中になると、ＰＣＭバッファ１３４が枯渇しないように継続的に、上記処理を滞りなく処理していく必要がある。ＰＣＭバッファ１３４が枯渇すると音切れなどの状態になり望ましくない。ＰＣＭバッファ１３４は、ＳＤＲＡＭ１３０に１１面確保されて、ストリームが供給され続けると、これが一杯になるまでデコード処理が行われる。このＰＣＭバッファ１３４を十分に蓄えておくことで、一時的に処理が重くなってもＰＣＭ出力が途切れることなく出力できる。

このように、一定時間にデコード処理を行う必要性から、一定処理単位をタスクとして処理を分割し、その前後で並列に処理ができるようにバッファリングする構成になっている。そして、各タスクの実行条件は、入力側と出力側のバッファの状態によって決定される。

これらのバッファの状態は、通常状態ではある程度一定で、これに伴いタスクの動作も予期できるが、ストリームバッファの供給状態、ＥＳストリームの内容、ストリームにエラーが存在した場合、Ｖｉｄｅｏ（ビデオ）とリップシンクのためにサンプル単位でスキップ又はリピートなどが発生した場合など、あらゆる影響によって、各バッファ状態が変化し、各タスクが動作するタイミングが刻々と変化する。

図２は、本発明に係るＣＰＵによって実行される処理を説明するためのフローチャート図である。図２において、ＣＰＵによって実行される処理を、メイン処理と割り込み処理とに大きく分けて説明する。

メイン処理では、初期化処理（ステップＳ１０１）を行ったあと、シーケンス管理タスク（ステップＳ１０２）、スリープ動作検出タスク（ステップＳ１０３）、ＰＥＳ転送タスクＴＳＫ１（ステップＳ１０４）、ＥＳ抽出タスクＴＳＫ２（ステップＳ１０５）、デコード処理タスクＴＳＫ３（ステップＳ１０６）、ＰＣＭ転送タスクＴＳＫ４（ステップＳ１０７）、ＰＣＭ出力タスクＴＳＫ５（ステップＳ１０８）が、各タスクが評価され実行条件が満足していれば、そのタスクを実行する。

前述の説明のとおり、タスクＴＳＫ１から４までは、バッファ状態によって実行判断が決定される。ＰＣＭ出力タスクＴＳＫ５は、最初の１回だけメイン処理から実行され、２回目以降は、割り込み処理から実行される。この理由は、ＰＣＭ出力を行うＤＭＡ転送（ＤＭＡ＿ＤＰ）の終了が、次のＤＭＡ転送（ＤＭＡ＿ＤＰ）の起動トリガに使用されるためである。つまり、ＰＣＭ出力を途切れることなく割り込みから起動処理する。

シーケンス管理タスク（ステップＳ１０２）は、上位ＣＰＵからのデコードの開始又は指示コマンドを判断して状態遷移の判断を行う。上位ＣＰＵからのこれらのコマンド取得又は解析は、割り込み処理で行われるが、実際の処理は、このタスクで実行される。割り込みには、他にＤＭＡ転送（ＤＭＡ＿ＤＳ）の完了後の処理を行うＰＥＳ転送後処理タスクがある。

スリープ動作検出タスク（ステップＳ１０３）は、タスクの処理状況を判断して、ＣＰＵが処理する仕事がなくスリープモードへ移行できるか判断を行い、条件があればスリープ状態となる。通常ならば、図２に示すメイン処理のループを定期的に繰り返し実行しているが、スリープ状態になるとＣＰＵの命令が停止するので、スリープ動作検出タスク内部で完全に停止状態となる。これによって、低消費電流での待機状態となる。このスリープ状態からの復帰は、割り込み信号がアサートされた場合であり、次の条件から復帰できる。上位ＣＰＵからストリーム供給コマンドの通知、ＤＭＡ転送（ＤＭＡ＿ＤＳ）転送完了割り込み、ＤＭＡ転送（ＤＭＡ＿ＤＰ）転送完了割り込みがある。これは、割り込み処理でのコマンド取得又は解析タスク（ステップＳ２０１）、ＰＥＳ転送後処理タスク（ステップＳ２０２）、ＰＣＭ出力ＴＳＫ５（ステップＳ２０３）にそれぞれ対応する。それ以外にもＶｉｄｅｏのＶＳＹＮＣ１６．６ｍｓ間隔で通知される上位ＣＰＵからのデコードの開始又は停止指示コマンドがある。

図３は、１フレームデコードに着目した処理時間の内訳を示す図である。図３において、通常は、タスクＴＳＫ１から４の順に処理が行われる。ＥＳ抽出タスクＴＳＫ２は、ストリームによっては、１フレームデコードの際に複数回数呼び出される可能性がある。ＰＣＭ出力タスクＴＳＫ５において、ファームウェアでの処理はハードウェアへの起動処理だけで、かつ、ＰＣＭバッファ１３４の内容をハードウェアで外部へＤＭＡ転送するだけなので、１フレームデコード処理になんら影響を及ぼさない。したがって、ＣＰＵの処理としては無視できるので、内訳には記載していない。また、同時にメイン処理でのシーケンス処理タスク（ステップＳ１０２）、スリープ動作検出タスク（ステップＳ１０３）および割り込み処理でのコマンド取得又は解析タスク（ステップＳ２０１）、ＰＥＳ転送後処理タスク（ステップＳ２０２）は、他の処理に比較して十分処理量が少なく無視できるので詳細説明を省略する。

この例は、２ｃｈのＡｕｄｉｏデコードをする場合の処理時間内訳例であるが、もし、４ｃｈのＡｕｄｉｏデコードを行う場合は、１１ｍｓ×２＝２２ｍｓ必要となる。これらの処理が１１ｍｓ必要とすると、１フレーム時間は２４ｍｓ必要なので、１３ｍｓが残りのマージンとなる。つまり、この時間はＣＰＵの空き時間でスリープ対象となる期間である。

図４は、複数フレームの処理時間タイミングを示す図である。図４において、デコード開始直後は、ストリームバッファに潤沢にストリームが供給され続けたと仮定するとタスクＴＳＫ１から４まで（１１ｍｓ）が連続して処理され、ＣＰＵに処理の無駄時間（空き）が発生せずＰＣＭバッファ１３４が一杯になるまで処理が継続される。１１フレームがデコードされ、ＰＣＭバッファ１３４が一杯になると、無駄時間（空き）が発生してくる。

また、ストリームの供給が一旦滞る状態によっては、ＰＣＭバッファ１３４が一杯にならない場合でも、ストリーム供給待ちでＣＰＵは待機待ち状態となりえる。

このように、マージン（空き時間）はバッファ状態を含め各要因で変化する。

本発明では、特定のバッファ状態だけを監視するのではなく、連続して主要タスクが何も実行されない回数をカウントし、それが閾値を越えるとＣＰＵのスリープ動作にする。

図２に示すメイン処理のうち、タスクＴＳＫ１から３の主要タスクがそのタスクを実行したか否かのフラグを一つの共通の変数で用意する。ここで、ＰＣＭ転送タスクＴＳＫ４は、デコード処理タスクＴＳＫ３から派生するものであるから、デコード処理タスクＴＳＫ３と併用する。

このタスク動作判定フラグは、最初の初期化処理とＰＥＳ転送タスクＴＳＫ１の直前でゼロクリアされる。そして各タスクによって、もし実行されるとこのフラグに１がセットされる。実行されなければなにもしない。結果的に、タスクＴＳＫ１から３の主要タスクのどれかが実行されれば１となり、全く実行されなければ０となる。このタスク動作判定フラグをスリープ動作検出タスク（ステップＳ１０３）が参照する。

図５は、スリープ動作検出タスクによる処理の一例を説明するためのフローチャート図である。まず、現在のステートを確認する（ステップＳ１３１）。動作中でなければ、ステップＳ１３５へと進む。一方、動作中であれば、タスク動作判定フラグを確認して主要タスクが実行されたか否かを確認する（ステップＳ１３２）。主要タスクが実行されていれば、主要タスク連続未実行回数sleep_cntをゼロクリアし（ステップＳ１３３）、実行されなければ＋１される（ステップＳ１３４）。したがって、主要タスク連続未実行回数sleep_cntには、主要タスクが連続して実行されなかった回数がカウントされる。

次に、現在のステートが停止中か否かを確認し（ステップＳ１３５）、停止中である場合、無条件に、ＣＰＵのスリープ命令を実行してスリープ状態になり（ステップＳ１３７）、スリープ状態からの復帰直後に主要タスク連続未実行回数sleep_cntをゼロクリアして（ステップＳ１３８）、ＣＰＵは、スリープ動作検出タスクによる処理から復帰する。

また、現在のステートが動作中で、かつ、主要タスク連続未実行回数sleep_cntが閾値１０を超えた場合、同様に、ＣＰＵのスリープ命令を実行してスリープ状態になり（ステップＳ１３７）、スリープ状態からの復帰直後に主要タスク連続未実行回数sleep_cntをゼロクリアして（ステップＳ１３８）、ＣＰＵは、スリープ動作検出タスクによる処理から復帰する。一方、主要タスク連続未実行回数sleep_cntが閾値１０を超えていない場合、ＣＰＵは、そのままスリープ動作検出タスクによる処理から復帰する。

スリープ状態へ遷移するための閾値は、ＥＳ抽出タスクＴＳＫ２がストリームによっては１フレームデコードの際に複数回呼び出される可能性があるのでこれを考慮して設定される。この理由は、ＰＥＳバッファ１１２のサイズが片面２５６バイトであり、一方、ＥＳバッファ１１４のサイズが同様に片面２０４８バイトになっており、単純には複数面のＰＥＳバッファ１１２の内容が、ＥＳバッファ１１４の１面に相当する。大きくはビットレートに依存するが、ＥＳ抽出の境界条件によって一概にはＥＳバッファ１１４の１面分がＰＥＳバッファ１１２の何面に相当するかは言えない。

したがって、この閾値は小さい値にすると、ＥＳ抽出タスクＴＳＫ２が完全に実行されずにスリープ状態に陥る可能性がある一方、大きくとればスリープ状態への遷移が遅れることになる。

このような問題を解決するために、スリープ動作検出タスクに、以前に連続してタスクが実行された場合をカウントして、この情報を元に新たな閾値を算出し、常にフィードバックをかけることで最適な状態でスリープモードに遷移する仕組みを持たせるようにする。このように、閾値を動的に変更する仕組みについて図６で説明する。

図６は、スリープ動作検出タスクによる処理の他の例を説明するためのフローチャート図である。図６において、図５に示す処理と同様に、主要タスク連続未実行回数sleep_cntには、連続して実行されなかった回数がカウントされる。新たに、連続してタスクが実行された値をカウントする主要タスク連続実行回数task_cntを設ける。

まず、現在のステートを確認する（ステップＳ１５１）。動作中でなければ、ステップＳ１５７へと進む。一方、動作中であれば、タスク動作判定フラグを確認して主要タスクが実行されたか否かを確認する（ステップＳ１５２）。主要タスクが実行されていれば、主要タスク連続未実行回数sleep_cntをゼロクリアし、主要タスク連続実行回数task_cntを１インクリメントして（ステップＳ１５３）、ステップＳ１５７へと進む。

主要タスクが実行されていなければ、主要タスク連続未実行回数sleep_cntを１インクリメントして（ステップＳ１５４）、主要タスク連続実行回数task_cntを今までの最大カウントを示す主要タスク最大実行回数max_task_cnt と比較する（ステップＳ１５５）。主要タスク連続実行回数task_cntが主要タスク最大実行回数max_task_cnt以下である場合、ステップＳ１５７へと進む。一方、主要タスク連続実行回数task_cntが主要タスク最大実行回数max_task_cntより大きい場合、主要タスク最大実行回数max_task_cntに主要タスク連続実行回数task_cntを代入して、主要タスク連続実行回数task_cntをゼロクリアする（ステップＳ１５６）。同様の処理をスリープ状態になるまで繰り返すと、結果的に主要タスク最大実行回数max_task_cntに連続して実行したタスクの最大回数が記録されることになる。

次に、現在のステートが停止中か否かを確認し（ステップＳ１５７）、停止中である場合、無条件に、ＣＰＵのスリープ命令を実行するため、ステップＳ１５９へと進む。また、停止中でない場合、現在のステートが動作中で、かつ、主要タスク連続未実行回数sleep_cntが閾値task_thresholdを超えたか否かを判断する（ステップＳ１５８）。現在のステートが動作中で、かつ、主要タスク連続未実行回数sleep_cntが閾値task_thresholdを超えた場合、同様に、ＣＰＵのスリープ命令を実行するためステップＳ１５９へと進む。ステップＳ１５９では、ＣＰＵのスリープ命令を実行してスリープ状態になる。

スリープ状態からの復帰直後、ＰＣＭバッファ１３４は２面以上あるか否かを判断する（ステップＳ１６０）。２面以上ある場合、スリープ遷移閾値task_thresholdに主要タスク最大実行回数max_task_cntを代入し（ステップＳ１６１）、ステップＳ１６３へと進む。一方、２面以上ない場合、スリープ遷移閾値task_thresholdに値１０を代入して（ステップＳ１６２）、ステップＳ１６３へと進む。ステップＳ１６３では、主要タスク最大実行回数max_task_cnt、主要タスク連続未実行回数sleep_cnt、及び主要タスク連続実行回数task_cntをゼロクリアする。その後、ＣＰＵは、スリープ動作検出タスクによる処理から復帰する。

一方、ステップＳ１５８において、主要タスク連続未実行回数sleep_cntが閾値task_thresholdを超えていない場合、スリープ動作検出タスクによる処理から復帰する。

上記処理において、スリープ状態への遷移条件は、図５の固定閾値に対して、スリープ遷移閾値task_thresholdの変数に置き換えられる。そしてこれを超えるとＣＰＵのスリープ命令を実行してスリープ状態になるスリープ遷移閾値task_thresholdの初期値は、図５と同様に、固定値１０から開始される。

また、上述より、スリープ遷移閾値task_thresholdの更新は、スリープ状態からの復帰直後に行われ、ＰＣＭバッファ１３４の蓄積量を判定し、あまりＰＣＭバッファ１３４に余裕が無ければスリープ遷移閾値task_thresholdを初期値の１０と余裕ある値にする。これは、ＰＣＭバッファ１３４に余裕があまり無いときには、極限のスリープ遷移閾値task_thresholdを回避することで、ＰＣＭバッファ１３４の破綻の可能性を極力排除する配慮である。

また、図５及び図６に示す処理の例では、連続してタスクが実行されたことを直前のスリープ状態の結果だけから判断しているが、いくつかのスリープ状態を累積した平均をとることもできる。つまり、急激なスリープ遷移閾値の変化を発生させないような配慮が可能である。

なお、ＶｉｄｅｏのＶＳＹＮＣは、１６．６ｍｓ間隔で定期的に入力されるので、１フレーム２４ｍｓ以内に１度は割り込みが入りスリープから解除される仕組みとなっている。したがって、スリープ遷移閾値を前回の処理量の状況に応じて自己学習し、最適なスリープ遷移閾値を求める仕組みによって、極限のスリープ遷移閾値にしても、デコード処理が遅れＰＣＭバッファ１３４が枯渇してしまうなどの破綻は回避される。

次に、図５及び図６に示すスリープ動作検出タスクによる夫々の処理を実行した場合のスリープ状態の例について図７及び図８で説明する。

図７は、図５に示すスリープ動作検出タスクによる処理を実行した場合のスリープ状態の例を示す図である。図７において、ビット列はスリープ状態になるまでのタスク動作判定フラグの値を示し、ｌｏｏｐ（ｉ）はスリープ状態になるまで図５に示すススリープ動作検出タスクが実行された回数を示し、スリープ遷移閾値task_thresholdは固定の値１０を示し、主要タスク連続未実行回数sleep_cntはスリープ状態になるまでの主要タスクが連続して実行されなかった回数を示す。スリープ状態が解除されると、ｌｏｏｐ（ｉ）はゼロクリアされ、また、スリープ状態になるまでカウントされる。

図７に示すように、図５に示すスリープ動作検出タスクによる処理では、スリープ遷移閾値task_thresholdが固定であるので、主要タスク連続未実行回数sleep_cntの値が１１をカウントするとスリープ状態になっていることが判る。

図８は、図６に示すスリープ動作検出タスクによる処理を実行した場合のスリープ状態の例を示す図である。図８において、ビット列はスリープ状態になるまでのタスク動作判定フラグの値を示し、ｌｏｏｐ（ｉ）はスリープ状態になるまで図５に示すスリープ動作検出タスクが実行された回数を示し、スリープ遷移閾値task_thresholdは初期値１０から自己学習によって変動し、主要タスク連続未実行回数sleep_cntはスリープ状態になるまでの主要タスクが連続して実行されなかった回数を示し、主要タスク最大実行回数max_task_cntはスリープ状態になるまでに主要タスクが連続して実行された最大回数を示し、主要タスク連続実行回数task_cntはスリープ状態になる前に主要タスクが連続して実行された回数を示している。主要タスク最大実行回数max_task_cntは、スリープ状態解除後にスリープ遷移閾値task_thresholdに設定される。

図８に示すように、スリープ遷移閾値task_thresholdが変動することによって、スリープ状態になるまでの主要タスク連続未実行回数sleep_cntが変化していることが判る。

図７及び図８に示す例で判るように、連続して主要タスクが何も実行されない回数をカウントして、その値が閾値を超えるとＣＰＵのスリープ動作に遷移することで、低消費電流のオーディオデコード装置を構成することが可能となる。更に、以前に連続してタスクが実行された場合をカウントして、この情報に基づいて適応的にスリープ遷移閾値を決定することによって、効率的にスリープ動作に遷移することが可能となる。

本発明は、例えば、ＤＶＤプレーヤ、デジタルＴＶをはじめ、特に、携帯性の高いムービーレコーダなどに適応することができる。

以上の説明に関し、更に以下の項を開示する。
（付記１）
圧縮されたストリームの復号に係る主要タスクが実行されたか否かを判断する主要タスク実行判断手段と、
前記主要タスクが実行されなかったと判断されると、スリープカウントをインクリメントするスリープカウント手段と、
前記主要タスクが実行されたと判断されると、前記スリープカウントをゼロクリアするスリープカウント初期化手段と、
ステートが動作中であって、かつ、前記スリープカウントがスリープ遷移閾値を越えているか否かを判断するスリープ判断手段と、
前記スリープカウントがスリープ遷移閾値を越えている場合、スリープ状態に遷移するスリープ状態遷移手段とを有することを特徴とするオーディオデコード装置。
（付記２）
前記スリープ判断手段は、前回のスリープ状態への遷移時での前記主要タスクが連続して実行された最大回数をスリープ遷移閾値として用いることを特徴とする付記１記載のオーディオデコード装置。
（付記３）
前記スリープカウント手段によって前記スリープカウントがインクリメントされると、前記主要タスクが連続して実行された回数が前記主要タスクが連続して実行された最大回数より大きいか否かを判断する最大回数判断手段と、
前記主要タスクが連続して実行された回数が前記主要タスクが連続して実行された最大回数より大きいと判断されると、該回数を該最大回数に代入する最大回数代入手段とを有することを特徴とする付記２記載のオーディオデコード装置。
（付記４）
スリープ状態が解除されると、音声出力するために復号されたストリームを蓄積するバッファが所定容量以上有るか否かを判断するバッファ容量判断手段と、
前記バッファが所定容量以上有る場合、前記スリープ遷移閾値に前記主要タスクが連続して実行された最大回数を代入する閾値代入手段とを有することを特徴とする付記３記載のオーディオデコード装置。
（付記５）
前記バッファが所定容量以上ない場合、前記スリープ遷移閾値に定値を代入する所定値代入手段とを有する付記４記載のオーディオデコード装置。
（付記６）
上記主要タスクは、ＰＥＳ転送タスク、ＥＳ抽出タスク、及びデコード処理タスクを含むことを特徴とする付記１乃至５のいずれか一項記載のオーディオデコード装置。
（付記７）
圧縮されたストリームの復号に係る主要タスクが実行されたか否かを判断する主要タスク実行判断手順と、
前記主要タスクが実行されなかったと判断されると、スリープカウントをインクリメントするスリープカウント手順と、
前記主要タスクが実行されたと判断されると、前記スリープカウントをゼロクリアするスリープカウント初期化手順と、
ステートが動作中であって、かつ、前記スリープカウントがスリープ遷移閾値を越えているか否かを判断するスリープ判断手順と、
前記スリープカウントがスリープ遷移閾値を越えている場合、スリープ状態に遷移するスリープ状態遷移手順とを有することを特徴とするスリープ制御方法。
（付記８）
圧縮されたストリームの復号に係る主要タスクが連続して所定回数実行されなかった場合、スリープ状態に遷移するスリープ状態遷移手段を有することを特徴とするオーディオデコード装置。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明に係るオーディオ装置の原理を説明するためのブロック図である。 本発明に係るＣＰＵによって実行される処理を説明するためのフローチャート図である。 １フレームデコードに着目した処理時間の内訳を示す図である。 複数フレームの処理時間タイミングを示す図である。 スリープ動作検出タスクによる処理の一例を説明するためのフローチャート図である。 スリープ動作検出タスクによる処理の他の例を説明するためのフローチャート図である。 図５に示すスリープ動作検出タスクによる処理を実行した場合のスリープ状態の例を示す図である。 図６に示すスリープ動作検出タスクによる処理を実行した場合のスリープ状態の例を示す図である。

符号の説明

１１０ ＣＰＵ及びメインメモリ
１１２ ＰＥＳバッファ
１１４ ＥＳバッファ
１１６ 一時バッファ
１２０ ＤＭＡ転送回路
１３０ ＳＤＲＡＭ
ＴＳＫ１ ＰＥＳ転送タスク
ＴＳＫ２ ＥＳ抽出タスク
ＴＳＫ３ デコード処理タスク
ＴＳＫ４ ＰＣＭ転送タスク
ＴＳＫ５ ＰＣＭ出力タスク

Claims (5)

1. 圧縮されたストリームの復号に係る主要タスクが実行されたか否かを判断する主要タスク実行判断手段と、
   前記主要タスクが実行されなかったと判断されると、スリープカウントをインクリメントするスリープカウント手段と、
   前記主要タスクが実行されたと判断されると、前記スリープカウントをゼロクリアするスリープカウント初期化手段と、
   ステートが動作中であって、かつ、前記スリープカウントがスリープ遷移閾値を越えているか否かを判断するスリープ判断手段と、
   前記スリープカウントがスリープ遷移閾値を越えている場合、スリープ状態に遷移するスリープ状態遷移手段とを有することを特徴とするオーディオデコード装置。
2. 前記スリープ判断手段は、前回のスリープ状態への遷移時での前記主要タスクが連続して実行された最大回数をスリープ遷移閾値として用いることを特徴とする請求項１記載のオーディオデコード装置。
3. 前記スリープカウント手段によって前記スリープカウントがインクリメントされると、前記主要タスクが連続して実行された回数が前記主要タスクが連続して実行された最大回数より大きいか否かを判断する最大回数判断手段と、
   前記主要タスクが連続して実行された回数が前記主要タスクが連続して実行された最大回数より大きいと判断されると、該回数を該最大回数に代入する最大回数代入手段とを有することを特徴とする請求項２記載のオーディオデコード装置。
4. スリープ状態が解除されると、音声出力するために復号されたストリームを蓄積するバッファが所定容量以上有るか否かを判断するバッファ容量判断手段と、
   前記バッファが所定容量以上有る場合、前記スリープ遷移閾値に前記主要タスクが連続して実行された最大回数を代入する閾値代入手段とを有することを特徴とする請求項３記載のオーディオデコード装置。
5. 圧縮されたストリームの復号に係る主要タスクが連続して所定回数実行されなかった場合、スリープ状態に遷移するスリープ状態遷移手段を有することを特徴とするオーディオデコード装置。
   

Images