#blognavi
#blognavi
以前にも紹介したことがある、携帯プレイヤーのためのオープンソース・ファームウェアプロジェクト、Rockboxに関してちょっと書いてみようと思います。
以前紹介した時と比べると、多くの機能が実装されデコーダの最適化なども進んだ結果、かなり使えるものになっています。メニューが整理されて分かりやすくなったのもかなり良い感じです。
また新しいコーデックのサポートや対応機種の増加も、ユーザーベースの拡大という意味で良いことでしょう。
また新しいコーデックのサポートや対応機種の増加も、ユーザーベースの拡大という意味で良いことでしょう。
ただ、相変わらず変わらない部分もあり、その一つにVorbisにおいてq-1以下でエンコードしたファイルの再生負荷がかなり高いことがあります。q0以上では以前より軽くなっていますが、ことq-1/-2に関してはほとんど変わっていない様に見えます。
ソースコードをざっと眺めた感じだと、高速化のための幾つかの手段は、ウインドゥサイズ2048/256ブロックに限定したものであり、それ以外のサイズのブロックを使用しているファイルでは相対的にデコードが遅くなるようです。上記のブロックサイズはサンプリング周波数32/44.1/48kHzのq0からq10で使われているため、その範囲ではかなり効率的に処理が可能だと思われます。
その中で特に問題なのは、ブロックサイズが大きいq-1/q-2です。ここで使われるブロックサイズは現状のエンコーダでは4096/512ブロックになります。このサイズだと、高速なCPU内蔵RAM(IRAM)を使った高速化手段の多くが適用されません。また一度に取り扱うデータ量が多いということはCPUキャッシュなどの仕組みも働きにくいと考えられるので、そういった意味でも不利かも知れません。
この問題を改善するには結構手間が掛かりそうです。再生するファイルに応じてIRAMに割り当てる部分を変更する必要がありそうですが、現状のRockboxのモデルでそれが可能なのかは分かりません。プログラミングの腕に覚えがある方がいればチャレンジしてみてください。
この問題を改善するには結構手間が掛かりそうです。再生するファイルに応じてIRAMに割り当てる部分を変更する必要がありそうですが、現状のRockboxのモデルでそれが可能なのかは分かりません。プログラミングの腕に覚えがある方がいればチャレンジしてみてください。
10月07日 追記
Rockbox 10月05日版にて、実際に某実機でデコードスピードを比較してみました。
q0が360.15%(x3.6)、q-1で139.85%(x1.4)でした。
ちなみに、q10だと183.55%(x1.8)という結果。
やはりq-1以下はかなり重いです。
Rockbox 10月05日版にて、実際に某実機でデコードスピードを比較してみました。
q0が360.15%(x3.6)、q-1で139.85%(x1.4)でした。
ちなみに、q10だと183.55%(x1.8)という結果。
やはりq-1以下はかなり重いです。
カテゴリ: [ソフトウェア] - &trackback() - 2007年08月31日 20:39:08
