3つのデコーダ

MP3, AAC, WAVの3種類のファイルが再生できるようになったので、その処理方法について書いておくことにします。それぞれのファイル形式に対しては、それぞれのデコーダを用意しています。ファイルを再生する際に、そのファイルの拡張子から対応するデコーダを判断し、それを処理するタスクを起動するようにしています。例えば、MP3ファイルを再生中のタスク状態はこんな感じ。



AACファイル再生中は、こうなります。



もちろんwavdecoder_taskはWAVファイルの再生を担当するタスクです。それぞれのタスクは、デコード結果として44.1KHz, 16bit, 2チャンネルのPCMデータを出力しますので、それをCODECあるいはUSBスピーカに出力してやることで音が出ます。この出力を担当するのがpcmsender_taskです。

MP3やAACのデコーダは、それぞれその動作に20KB以上のRAM領域を必要とします。しかしながら、合計で40KB以上のメモリを必要とするというわけでもありません。なぜなら、3種類のデコーダは同時に動作することはないので、それぞれのタスクが使用するバッファやメモリを共通のメモリプールから動的に獲得/解放することができるからです。

同じ理屈で、3つのデコーダ・タスクのスタック領域を共通化させることも可能ですが、残念ながらTOPPERS/JSPのコンフィギュレータには、そのようなタスク間でのスタック共用を表現する能力は用意されていないようです。LPC2388にはRAMがたくさんあるものの、こうしてタスク数が増えてくるとスタックで消費されるメモリ量の割合が大きくなってくるので、これら同時に動くことのないタスクに対して独立した充分なスタック領域を割り当ててしまうのもモッタイナイです。そこで、ちょっとした dirty trickを施してみました。

上記のデコーダ実行時のps コマンド出力のStack表示はスタック残量/スタック割り当て量を示しています。aacdecoder_taskとmp3decoder_taskのふたつのタスクのスタック残量はゼロになっており、スタック残量が不足していることを示しています。本来であればこのような事態はマズイことなのですが、wavdecoder_task, aacdecoder_task, mp3decoder_taskの3つのタスクは同時に実行されることはないうえに、これらのタスクのスタック領域は隣接して割り当てられています。そのため、mp3decoder_taskのスタックは、割り当て量で足りなくなるとaacdecoder_taskのスタック領域を侵食し、さらにそれでも足りなくてwavdecoder_taskのスタック領域まで浸食しています。aacdecoder_taskも同様に自分のタスクに割り当てられたスタック領域では足りずにwavdecoder_taskのスタック領域を侵食しています。このような侵食が生じても、3つのタスクが同時に実行されるわけではないので、実害は無いというわけです。



現在のメモリ使用状況はこんな↑です。AACとWAV入れたらtextサイズが100KBほど増えました。

今年の作業は、ここまでとします。それでは、皆さん、良いお年を。