建築・設備見積りソフト、見積システムの事なら 和田特機株式会社

建設業向け 業務支援タブレットアプリシリーズ 好評発売中

和田特機株式会社HP

WFP4Exp.exe の 64bit 化について

二週間のご無沙汰でした。SALです。

最近は、352.8/384KHz での再生がメインになっている関係で、ストリームバッファサイズの限界からくる再生時間制限が障害になってきました。
ご承知の通り、WFP4Exp は、アプリ本体では「ストリーミングしない」ことで、よりスムースな再生を目指しています。
従って、この問題をクリアするには、64bit Application に移行するしかありません。
例えば、SALの実験機なら、24bit/384KHz の再生は、9分前半が限界です。(深さ 16bit でも13分程度)
そこで今回は、最近作成した x64(Amd64)版の Experimental について、お話します。

Wave File Player プロジェクトをスタートさせたのは、2003年の正月休みでした。
当時の Windows は、32bit 環境が当たり前だったことに加えて、「先読み+アップサンプリング」の構想も未だなかったので、32bit 専用のコーディングを行いました。
普通に考えれば、せいぜいが Unicode(DBCS) と Shift-JIS(MBCS) の共用にするぐらいです。
扱うデータが RIFF-WAVE 型式と決まっていたのもあって、32bit Shift-JIS Application とした次第なのですが…。
尤も、当時 4GByte を超えるメインメモリのPCを想定する方があり得なかったです。

言い訳はこれくらいにして、兎に角LPの片面相当ぐらいは、24bit/384KHz で再生したいのは無理からぬ思いでしょう。
ところで、64bit 化への障害は、これ以外にもMFCバージョンの大幅変更による、特殊処理モジュールの互換性があります。
こちらの方は、メモリの少ないPCを対象にしないことと、UIの枝葉の違いは気にしないことにして、そういった部分は破棄しました。
手順としては、先ずは新たな開発環境に 32bit プロジェクトとして移植しました。(こちらは使いません)
次に、64bit(x64) プロジェクトと共用になるように修正を行いました。
こうして、オリジナルの x86版と、x64版で重要なモジュール(再生のコントロール、アップ/リサンプリング処理)を完全共用としました。
理由は、将来に渡って差異を作らないこと。つまり、同じ音質を保つ為です。

但し、重要なモジュールの完全共用化からの制限で、再生用のバッファサイズが 4GByte 以下に制限されてしまいました。
具体的に言うと、24bit/384KHz 再生で、31分程度です。24bit/192KHz なら1時間程になります。
取り敢えず、当初の目標はクリアできたので、良しとしました。
副産物としては、アップ/リサンプリング前処理のスピードアップがあります。
実は、ファイルやストリームデータが、32bit の整数や浮動小数点型なので、「若干遅くなるかも」と覚悟していたのですが、
同じ 64bit OS上で走らせた場合は、2倍程に早くなっていました。
前処理の待ち時間も欠点の一つだったので、改善されたことは素直に喜ぶこととします。

最後に、x64版 WFP4Exp.exe の限界まで使う為に必要なメインメモリサイズを求めてみます。
勿論、他にメモリを大食らいするアプリを使っていないことが条件です。
ソースのデータ型式を、16bit/44.1KHz(CD)とすると、
① 24bit/384KHz 再生では、6GByte 以上
② 24bit/192KHz 再生では、8GByte 以上
③ 24bit/96KHz 再生では、12GByte 以上
あれば、スワップファイルを必要としません。
尤も、③では2時間程度の再生ファイルなので、本当に必要かは不明です。
44.1系の場合も同じメモリ容量と考えて構いません。こちらですと1割ほど再生可能時間が延びます。
また、16bit 出力にすれば、再生可能時間は単純に 1.5 倍になりますが、ソースと作業領域の拡大で必要メモリもその分多くなります。
SALの場合、前回にも紹介した比較用の旧PC代表機(Core2/Q9400)は、4GByte から 8GByte に増設しました。
残念ながら DDR2 だったので、中古品にしました。(DDR3 なら安いのに…)

下図は、28分17秒の楽曲を再生中の実メモリ消費状況です。

コメント