CuBeatSystems

オーディオ・プラットフォーム・プロジェクトであるBlueTankも、ベース基板が上がってきて半年が経とうとしています。その間にベア・メタルなアプリケーションは幾つか実装したのですが、そろそろ色々な不満が出てきました。

Analog Devices社Blackfin BF592搭載オーディオ・プラットフォームBlueTank BF592を使ったグラフィカル・スペクトラム・アナライザーです。

[フレーム]

2x8文字のLCDですが、都合の良い事に8文字のユーザ・フォントを登録する事ができます。
1文字1バンドで考えてしまうと8バンドしか表示できません。

でも、1ピクセル1バンドとして考えると5ドットx8文字で最大40バンドの表示が可能になります。
この基板設計時に考えた事をようやく実現する事ができました。
8文字表示のLCDを選択したのは、単に「コンパクトだから」というわけではなかったのです。

今回のサンプリング周波数は48,000[Hz]でFFT計算サイズは64です。
なので周波数軸での分解能は750[Hz]という事になります。

750[Hz]の分解能で40バンドまで表示できる事を考えると、ナイキスト周波数の範囲まで十分に表示できる事がわかります。
FFT計算サイズの内部定義を一行書きかえるだけで、表示側も連動するように実装しました。
折り返し成分を表示しないようなガードも入れてあります。

BlueTank BF592に対するオーディオ・フレームワークの実装もかなり進みました。
上記のコードはフレームワーク層のコードを除くとコメントを含んで約300行の実装で済みます。
(コメントが何行なんだ！)

アプリケーション共通の処理は全てオーディオ・フレームワーク側に隠ぺいしました。
main.cみたいな小さなアプリケーションの実装のみで上記のような処理を実現する事ができます。

ちなみに、上記のアプリケーションは天ノ岩戸のmayaさんが実装したFFTアナライザを改造して作りました。この場を借りてお礼申し上げます。

そして、オーディオ・フレームワークについてはDSP空挺団の酔漢さんの作られたUZUMEにかなり影響を受けています。最初はUZUMEのミニマム・プラットフォームとしてBlueTank BF592を仕立てる計画でしたが、似ても似つかない物になってしまったのでもじってUZURAというフレームワーク名を付けました。変なフレームワークで本家や市場に混乱や迷惑をかけない措置です。

ちょっと借り物競走みたいなプロジェクトになってきましたが、まだまだBlueTank BF592遊びは続けようと考えています。

まえがき

先日からBlueTankだとか何とか書いていて、経緯を知らない人にとっては「何を言っているの？」という感じです。この記事では、オーディオ・プラットフォームBlueTankの始まりとUZUMEオーディオ・フレームワークについて触れたいと思います。

前々からオーディオ装置の開発をやりたいなぁと考えているわけですが、それっぽい入口を仕立てる度にシェルを作るのに忙しくなったり、デバッグ用ツールを作るのに忙しくなったりと何をやっているんだという状態です。

そうは言えども、徐々に何をどう進めようかという指針が明確になってきました。

まずは下回りを固めようという事でオーディオを簡単に扱うためのフレームワークを構築しようと考えるわけですが、実はDSP空挺団をホストされている酔漢さんが既に完成度の高いフレームワークを構築されています。

ということで、後はお手頃なハードウェア・プラットフォームを構築して、その上でフレームワークを使って楽しめば良いじゃないかとなるわけなのです。

ハードウェア・プラットフォーム

以前にBlackTankを設計した時に面倒な思いをして、「これを続けるのは大変だなぁ」と考えていました。
もっと手軽なプラットフォームで開発したいと考えたわけです。

そこに現れたのが金子システム社のDSP基板です。
お値段とサイズがコンパクトなのでほぼリスクなし。

基板マニアの私としては、この手作り感がどうしても許せません。
そして、複数個作れと言われても作る気になれません。
要するに、手作業でユニバーサル基板に配線する事に手軽さを感じませんでした。

結局のところ簡単なベース基板を設計する事にしました。
それがBlueTankとなったのです。
とはいえ、DSP基板上にほとんど必要な部品が搭載されているため、ベース基板の回路はスカスカです。


BlueTankで実現するかどうかわかりませんが、装置モノとして筺体設計も考えています。
BlueTankの基板はTAKACHIのLCS135-Hに収まるように設計してあります。

UZUMEオーディオ・フレームワーク

UZUMEオーディオ・フレームワークは、オーディオ処理に必要なリアルタイム制御部分を遮蔽し、オーディオの処理のみに注力できるように考えられているフレームワークです。


フレームワークでは、予め想定された用途の範囲でAPIが整備されています。

一部はBlueTankに適用できないので、対応はこれから考えますが、UZUMEオーディオ・フレームワークの比較的小さなプラットフォームの部類にBlueTankを該当させたい考えです。

「コンパクトなハードウェアで各種オーディオ処理の実験が可能！」というのがBlueTankの位置付けでしょうか。

プロジェクト・ページ

• オーディオ・プラットフォームBlueTank
• UZUMEオーディオ・フレームワーク

「ACB-BF592とUMB-SSM2603のベース基板を設計する」とか「外装から考えるDSPオーディオプラットフォーム - BlueTank ACB-BF592」で検討した金子システム社製DSP基板を使ったオーディオ実験用プラットフォームBlueTankの進捗状況です。

スケッチはこんな感じです。
できるだけダサい感じを醸し出す為に何回かスケッチしてからCADに移行しました。


設計当初、リモコンでしか制御できない「リモコンで制御するオーディオプラットフォーム」でした。




よくよく考えてみると、ボードを使いたいユーザが同じリモコンを使えるとは限りません。
本体だけで手軽にデバッグしたい事だってあります。
いや、もしかしたら「リモコンで制御するオーディオプラットフォーム」の方がゴロが良かったかも。

先日の記事「ACB-BF592とUMB-SSM2603のベース基板を設計する」で基板設計者の視点でベース基板を仕立てたわけですが、「EAGLEの図面からアクリ屋ドットコムさんに頼むアクリル外装部品のサイズを簡単に得る方法」とか「KOZOS EXPBRDの最終組み立て (廣杉計器さんのスペーサが届いたので組み立てた)」の作業をするうちに、別の視点から検討してみたくなりました。

金子システム株式会社さんのコンパクトで高性能なDSP基板ACB-BF592の準備を随分前の記事で始めたわけですが、なかなか納得のいく進め方を見つけられずに放置状態でした。

WAVファイルを手軽にきちんと扱いたい！

WAVファイルを手軽にきちんと扱いたくなったので仕様や巷の実装を調べていました。

WAVファイルはチャンク構造になっていて、内部データ表現を自由に選ぶ事ができます。
自由に選ぶ事が出来ると言う事は、それなりにきちんと設計実装したプログラムでなければ正しく扱えない事を意味します。


手元にあった書籍（名前は出しませんが）や巷の実装を見ると、随分と厳しい暗黙の前提条件が用いられていて、色々なWAVファイルをあまり正しく読める事を期待できないなぁという感じでした。

また、データ保持の方式が「スタックにずんっと置く」ような実装だったり、「ファイルサイズに応じて超巨大なメモリをヒープから取る」ような実装だったりと、いくら巨大なメモリがPCに搭載されている昨今とは言え、何だかなぁ～という感じです。

そこで、巷の実装例を少し紹介した後で、設計実装したWAVファイルライブラリを御紹介します。

巷の実装を見てみる

今回設計したライブラリの紹介の前に、巷の実装を見てみましょう。
実装をそのまま掲載する事はできないので、ちょっと修正してあります。

巷の実装例（とある書籍のサンプルコード）

この実装は、出現するチャンク構造の順序に暗黙の前提条件が使用されている例です。

fp = fopen(file_name, "rb");
fread(riff_chunk_ID, 1, 4, fp);
fread(&riff_chunk_size, 4, 1, fp);
fread(riff_form_type, 1, 4, fp);
fread(fmt_chunk_ID, 1, 4, fp);
fread(&fmt_chunk_size, 4, 1, fp);
fread(&fmt_wave_format_type, 2, 1, fp);
fread(&fmt_channel, 2, 1, fp);
fread(&fmt_samples_per_sec, 4, 1, fp);
fread(&fmt_bytes_per_sec, 4, 1, fp);
fread(&fmt_block_size, 2, 1, fp);
fread(&fmt_bits_per_sample, 2, 1, fp);
fread(data_chunk_ID, 1, 4, fp);
fread(&data_chunk_size, 4, 1, fp);

この実装の場合、出現するチャンク構造の順序が異なるだけで全く正しい処理ができません。
そして、この後の処理が以下のようになっています。

pcm->fs = fmt_samples_per_sec;
pcm->bits = fmt_bits_per_sample;
pcm->length = data_chunk_size / 2;
pcm->s = calloc(pcm->length, sizeof(double));
Tiny WAV I/O Moduleプロジェクト

Tiny WAV I/O Moudleプロジェクトとは、小規模組み込みシステムで使用可能なWAVファイルライブラリを作ろうという目的で作られたプロジェクトです。

今回実装したライブラリは、その設計の前段にあたるもので、「どういったインターフェースなら使いやすいかなぁ」というのを検討する為のもの。libcが使用可能な環境でのみ使用可能です。成果物はTiny WAV I/O Moduleプロジェクトのlibc-basedに追加しました。

まぁ、ざっくり言うとlibc-basedは「パソコンで使えるお手軽WAVライブラリ」ですね。

wavfileモジュールの特徴

以下に今回設計実装したお手軽WAVライブラリ、wavfileモジュールの特徴を示します。

• 省メモリ設計。（ライブラリ側では巨大なメモリを要求しない。）
• ファイル形式に依らず0.0から1.0で正規化されたデータ入出力インターフェースを採用。
• 複数チャネルデータに対応。
• ヘッダの実装詳細を把握しなくても使える。

どんな風に使えるの？

単にデータを読みたい場合

よくあるやりたい仕事の1つが、とにかくデータを読んでみたい！というものです。
Tiny WAV I/O Moduleのlibc-based実装を使えば簡単に実現できてしまいます。

WavFileResult result;
wavfile_info_t info;
wavfile_data_t data;
WAVFILE *wf = wavfile_open("YourWavFileName.WAV", WavFileModeRead, &result);
if (wf != NULL) {
wavfile_read_info(wf, &info);
while (1) {
wavfile_read_data(wf, &data);
if (data.num_channels == 0) {
// 読むべきデータが無くなったらチャネル数に0を返してくる。
break;
}
// ここでデータを確認すれば良い。
}
wavfile_close(wf);
}

ソースコード

ソースコードは、以下からダウンロード可能です。
http://pt.sourceforge.jp/projects/tinywavio/

ライセンスはMITです。

今後の計画

最近は色々と忙しくて基板設計まで手が回らないので、今年は中途半端に拘るのを諦め、外販されているモジュールを活用してシステム物をやりたいなぁと計画しています。

実は、金子システム株式会社さんからUMB-SSM2603なるものが販売されています。


そうなのです。
このモジュールはACB-BF592と組み合わせてもミニサイズなのです。


動作も高速なので、実は今回のlibc-basedな実装もそのまま動かせたりして？！なんて甘い考えを持っていたりします。ファイルシステム周辺は何らかの抽象化層に乗せようかなぁ。

とにかく組み込み装置としてエレガントにWAVを扱えるようしていこうと考えています。