AACも追加しよう

MCIドライバのバグも見つかってひと安心したので、さらなる機能追加をしようと思います。現在のところのコードサイズはこんな↓もんです。



コードは全部ARMモードなんですけど、それでも200KBほどしか使っていません。まだフラッシュは300KBも残っています。そこで、コードサイズが増えそうな機能拡張としてAACデコーダを追加しようと思います。我が家でもカミサンのiTuneライブラリから曲データを拝借するには、MP3よりもAACの方が都合がいいですし。

デコーダとしてはMP3と同じく、HelixにあるAACデコーダが使えそうです。MP3と比べるとCPUを喰いそうなのですが、MP3再生には半分くらいしかCPUを使わないことが確認できたので、良く知りませんがSBRとかいうのを使わなければ、AACも楽勝でしょう。SBRはRAMも使うようなので、CPUが間に合ってもメモリでアウトになりそうですし。

ちょっと検索してみたら、やはりARMでMP3/AACの両方を載せている人がいました。しかも、AT91SAM7を使っているじゃないですか。がんばってるなぁ。おまけに、ChaNさんのFatFs使ってるし、この人も赤外線リモコン使えるようにしているようです。まぁ、だいたい皆さん同じような事を考えるということですね。もっとも、FatFsはATMELがAT91SAMシリーズ用のライブラリ(at91lib)の中に含めているくらいなので、ATMELユーザにとっては世界的にお馴染みであるとも言えます。

記事に目をとおしてみましたが、やはりAT91SAM7Sではかなり苦労して動かしているようで、CPUを喰うルーチンはSRAMに配置するようにしているようです。AT91SAM7は個人的には大変好みのデバイスなのですが、LPC2000シリーズと比べた時の最大の欠点はフラッシュからのコードの実行が遅いことです。AT91SAM7はデバイスにより最大55MHz～60MHzのクロックでの動作が可能なのですが、フラッシュのコードを実行する場合には、クロック30MHz以上ではウエイトの挿入が必要になってしまいます。ウエイト無しで動作できるのは、内蔵SRAMのコードを実行する時になるので、処理時間を短縮するためには、コードをSRAMに再配置する必要があるのです。それに比べてLPC2388は、MAMの機能により内蔵フラッシュのコードもARMモードであっても高速に実行できるので、大助かりです。AT91SAM7にもフラッシュのキャッシュ機能はあるのですが、バッファが小さいためにThumbモードでしかご利益がありません。

ともかく、この人のコードを見れば、AACデコーダの使い方が簡単にわかりそうなので、使わせていただくつもりです。