二週間のご無沙汰でした。ＳＡＬです。

前回、各標本点を通る解析関数が無数にあると言いましたが、もう少し立ち入って見ましょう。
簡単のため元の信号を振幅が１で角周波数がωの単振動とします。
つまり、sin(ω･t) です。
この信号を標本化周波数 fs で標本化します。
当然ながら、sin(ω･t) は、これら総ての標本点群を通りますが、
±sin{(n･ωs±ω)･t}　　…（複号同順）
も、同様に総ての標本点群を通ります。（証明は、ソフトウェアＤＡＣの付録１参照のこと）
ここで、n は任意の自然数、ωsは標本化の角周波数(2π･fs)です。
これらは、標本点が時間に関して不連続なために生じた結果で、元の信号に対して、エイリアス(Alias)と呼びます。

つまり、色々な繋ぎ方があるのは、目的の信号と無数に存在するエイリアスの混合の仕方に他なりません。
逆に、あるＤＡＣでアナログ波形を得るということは、この混合比を決定するということです。
勿論理想は、元の信号が１で、総てのエイリアスがゼロです。

前回の fs/12 で、各標本点を直線で繋いだ線と元の波形との差は、それほどでもないと思われた方もあるかもしれません。
しかしながら、差が見えるということは、１ドット以上（隙間があれば２ドット以上）の差があるわけで、
これは誤差が１％（２％）以上あることを示しており、オーディオと言う範疇では、問題です。
しかも、周波数が高くなればこの誤差は益々大きくなってしまいます。

上図は、fs/3 の場合です。

そこで、この周波数依存性を、簡単に考察してみましょう。
折れ線で繋ぐということは、ソフトウェアＤＡＣでも紹介したＰ０２アップサンプリングを、無限に繰り返すことに相当します。
（階段状のままならＰ０１の繰り返しですが、位相がずれていくので単純に振幅の積算にはなりません）

上図は、そこで発表したＰ０２のＳ－Ａ図です。
最初の一回分だけでも、目的の信号部分が削り取られてエイリアスになってしまう様子がお分かりいただけると思います。

このようなスペクトルから、信号部分だけをフラットに戻して取り出すアナログフィルタがあると思いますか？
例え、理想に近いフィルタを作ったとしても、位相はどうでしょうか？
これを解決するには、原点に戻って、誤差の少ないトレースをＤＡＣで実現するしかありません。
つまり、エイリアスの多いアナログ化をしてからでは、遅いのです。

追伸：報告するのを忘れていました！
以前ＬＥＯさんが報告しているように、３月２日以来、Windows8(CP版) で弊社開発アプリの動作テストを行っています。
ＳＡＬも二台の検証機にインストールして、ついでにＷＦＰの動作テスト＆息抜き時の鑑賞用としています。
１．AthlonX2 + 4GB/RAM + Win8(64bit) + Ph社DDC/USB(内蔵ドライバ) + Ki社DAC + 例のヘッドホンシステム
２．PentiumD + 3GB/RAM + Win8(32bit) + Ra社DAC/USB(専用ドライバ) + Ac社プリ + Ya社メイン + Ki社低能率ＳＰ
両機共、折角付いた 24bit/88.2KHz 共有モードなので、WFP4ExpはＰ４０アップサンプリングを主に使用しています。
本来が商用アプリのテスト用なので、ＯＳのチューニングは行っておりませんし、ＰＣのパフォーマンスも低レベルです。
（テスト目的なので、デフラグはスケジュールしておりません）
また、オーディオ装置も、「社内への持ち込み品」のレベルです。
で、肝心の音質ですが、（ＳＡＬの耳では）問題ないレベルだと判断しています。
但し、メンテナンス実行中は流石にＮＧなので、ウォーミングアップ時に済ませておくと良いでしょう。

二週間のご無沙汰でした。ＳＡＬです。

「２．高架道路を乗せる」ことについて述べる前に、ここまでのおさらいをしておきましょう。
① 正確な位置に橋脚を立てるためには、ＤＡＣに充分に低揺らぎ(Jitter)なクロックが必要です。
② ＤＡＣは等時処理(Isochronous)なので、そのクロックに同期したテンポで（高さ）データを供給する必要があります。
③ 一方、ＰＣ内部は多時間系なので、該当プロセスは仮想時間で不均一に進められます。
敢えてデータの流れと逆行して書いたのは、目的を優先したかった為です。

では、実際はどの様な流れで解決するのか見てみましょう。
②→①に関しては、データエラーをしない程度に同期していれば良いので、②に同じクロックを供給すればＯＫです。
逆に、②の出力にＰＬＬ等で同期して①を動作させることも可能ですが、この場合は②の持つ揺らぎだけでなく、データの伝送路で生じる揺らぎも加味されてしまいます。
（等間隔に時を刻むことの難しさは、実時間が確定*の為の時間と同じ軸-次元-であるためです。）
次に、③→② に関しては当然ながらハードウェアの助けが必要ですが、③の仮想時間の間欠部分を吸収するだけの遅延(Latency)がどうしても必要です。
どの程度の遅延が必要かは、実時間に対する仮想時間のギクシャクの度合いによります。
つまり、ＰＣの再生アプリ＆ドライバ及びその動作環境次第です。

ついでに、ここで言う遅延(Latency)に関して、大いなる誤解が生じているようなので、説明します。
最悪の誤解は、「遅延が大きいと波形が鈍る」と言うものです。
恐らくは、アナログ回路での経験からの誤解と思われます。
仮想時間で扱っているＰＣＭデータには、時間情報は含まれていません。ただ、順序だけが重要です。
（所謂ファーストインファーストアウトです）
時間が付け加わるのは、ＤＡＣに於いてクロックに合わせてアナログ値を生成する時です。
もう少し正確に言うと、②の供給側も等時処理の部分は、この実時間に縛られます。
但し、データを正確に渡せる（確定*）範囲であれば、多少は揺らいでも構いません。
つまり、仮想時間での遅延は、一時保存しているだけで、出力波形に何ら影響するものではりません。
影響するのは、ＤＡＣクロックの揺らぎ(Jitter)と、等時処理(Isochronous)に於けるデータエラーと、遅延で吸収し切れなかった仮想時間(Virtual-time)からの不均一性です。

つまり、遅延は大きく取ればその分多時間系の不均一問題を解決してくれます。
しかしながらＰＣでは、大きな遅延を許していません。
理由は、他の処理（例えば動画等の表示）とずれを生じてしまうためです。
しかしながら、我々の目的は、ＰＣをトランスポートの一つとすることなので、他と同期する必要はありません。
逆に、ＰＣをコントロールセンタとしたいのであれば、音質を犠牲にしてでも、遅延は少なくする必要があります。
この辺りの目的の違いを無視すると、様々な情報に惑わされることになってしまいます。

先送りになってしまいましたが、次回こそはＳＡＬがこの二年ほど取り組んできた、「２．高架道路を乗せる」ことについて述べます。

二週間のご無沙汰でした。ＳＡＬです。

前回は、「ＰＣの音声再生は、音源データの操作を前提としてる為に、それ以降は等時性が必須！」
と話ました。ＷＦＰのように、再生のみに特化し何も操作しないアプリでも、
既存のオーディオインターフェースを使う限り、この制約から逃れることはできません。
せいぜいが、この等時性の障害（邪魔）にならないようにするしかありません。

「アプリ側の方が、スレッド実行順位は低いから大丈夫」と思ってはいけません。
ストリーミングを行うには、どうしても再生中に、ＨＤやＮＩＣといった外部デバイスからデータを受け取り①、
それを、適当な単位でドライバに渡さ②なければなりません。
もう少し具体的に問題点を洗い出して見ましょう。

① Ｉ/Ｏ機器からのデータ取得には、ブロック転送等によるリソースの占拠期間があり、同様のＩ/Ｏ機器である音声装置へのアクセスに干渉します。
② アプリ側からの呼び出しにドライバ側が同期すると、実行順位の低さが等時性の足かせになります。
但し、②については、ＭＳの資料によれば「ＷＡＳＡＰＩの導入時に改善された」ようですが、逆に言うとＶｉｓｔａ以前は確実に影響が有ったということです。
更に注意して頂きたいのは、ＰＣフリークの言う「些細なこと」が、オーディオファイルの方にとっては「致命的」も有りうることです。

ＷＦＰは、アプリ側で一切ストリーミングを行わないことで、この問題を回避しています。
特に、Experimental では、ＰＣＭデータをメモリ上に置くことで、Ｉ/Ｏバスでの衝突も回避しています。
再生中のデータフローは「入力はメモリーから、出力はＩ/Ｏへ」と言う構造です。
また、等時性と言っても、若干の遅れ（Latency）を許せば、その分がゆとりになります。
一般的には評価の低いカーネルミキサーですが、ここでの遅れは意外と貴重です。
但し、レートコンバーターが働くと、データの有効桁数を大きく損ないますので、標本化周波数は必ず合わせておきます。

最後に、「私のマシンはビットパーフェクトが実証されているから大丈夫」と思っている方へ…
これまでの話で、お解りとは思いますが、ビットパーフェクトを実証する為には、ストリーミングを避けてはいけません。
何故なら、データを狂わす最大の原因がストリーミングだからです。
せめて、一曲分（五分程度）のデータをストリーミングで再生し、例えば S/PDIF 出力側で正確なテンポで正確な値を実証しなければなりません。
ストリーミングもしないような、小さなサイズのソースで行っても意味がありません。

但し、この問題を突破しても、ＤＡＣ迄の等時伝送や時間精度、ＤＡＣが抱える Alias による有効桁数の低下（音色の変化）が、次に控えています。

二週間のご無沙汰でした。ＳＡＬです。

前回は、「ディジタルデータを正確に扱うことと、リアルタイム性が両立できない場合がある。」
と話ました。では、一般のＰＣはどちらを優先させているのでしょうか？

勿論、前者であることは、改めて言うまでもありません。
通常のコンピュータ処理に於いて、「決められた時間間隔で次々と答えを出す」と言った作業は有りません。
寧ろ、「正確であることを満足すれば、早ければ早いほど宜しい」のです。
抽象的な言い方をすれば、それぞれの任務はそれぞれの時間で行っても構わないのです。
「３時までに報告書を提出しなさい！」と命令されることはあっても、
「結果は、正確に３時から１ページ３秒間隔で、提出しなさい。」何て言う上司はいません。
通常の業務では、ＰＣ内のプロセス達は、独自の時間で処理を行えば良いのです。
そもそも、ＰＣが提供するリソースはプロセスの数に比べて圧倒的に少ないわけですから、本当の意味で同時進行はできません。
つまり、各々のプロセスは、実時間に対してギクシャクした時間配分の中で、進行しているわけです。
このことは、ＯＳから与えられた仮想空間(memory,I/O)と同様に、仮想時間をイメージすると判り易いかもしれません。
即ち、ＯＳは個々のプロセスに、必要な仮想空間と共に仮想時間を与えると解釈し、全体を多時間系と見做すことにします。

逆に後者の典型は、制御用のコンピュータです。
制御用のコンピュータでは、刻々と変化する状況を捉え、実時間でコマンド処理を行わなければなりません。
言うなれば、一連の処理を総て一つの時計の下に進めなければなりません。
これを、等時処理或いは等時性（Isochronous）と呼びます。
例えば、具合の悪いデータがあるので、「この処理は後回しにする（時間分岐）」なんて訳には行きません。
平時に機能している組織が、緊急時に役に立たなくなるのは、一般の多時間的組織では等時処理ができない為です。
勿論、精度の悪いデータで制御する訳にはいきませんので、
必要な精度を保てるような、ハードウェアとリアルタイムカーネルを必要とします。

８０年代、ＳＡＬは多軸サーボシステムのコントロールソフト開発をメインに仕事をしていました。
当時のＰＣは、貧弱で当然ながらその様な用途には向いていませんでした。
しかしながら、ユーザの要望で使わざるを得ない場合は、必要なハードウェアの追加や改造を施すと共に、
総てのソフトウェアを自前で用意したものです。（内蔵ＬＳＩの初期化にＢＩＯＳを利用したことはありましたが…）
あれから２０数年、ＰＣは多大な進化を遂げましたが、リアルタイム処理が前提の機器ではありません。
しかしながら、ゲームやＤＶＤビデオの再生等に使用されることも前提なので、希望の光はあります。

準備が整ったので、ＰＣでの音楽プレイヤーに潜む問題を洗い出してみましょう。
今回は、ＤＡＣチップ自体の問題は問わないので、正確なアナログ出力をする理想のＤＡＣを前提にします。
信号の伝播経路を大雑把に、
①WAVファイル→②プレイヤーソフト→③デバイスドライバ→④サウンド装置側のコントローラ→⑤ＤＡＣチップ→⑥アナログ出力
とします。（途中ＬＡＮ、ＵＳＢ、ＤＤＣを介する場合もあるかもしれませんが、そこに潜む固有の問題は別の機会にします）
勿論、①～④の平均処理速度は、⑤が要求するレートを充分上回っていなければなりません。
重要なのは、ＰＣ側①②③が多時間系なのに対して、⑤ＤＡＣは完全な等時処理であることです。
では、この切り替えはどのステージで行うのが理想的でしょうか？
ＳＡＬが提唱するような、楽曲再生の為だけならば、④サウンド装置側のコントローラの内部で行うのが理想的です。
そうすることで、何時でも正確なデータを⑤ＤＡＣに必要なテンポで送り出すことができます。

ところで、この変換を行うためには、仮想時間系のギクシャクした時間を緩和するためのバッファ（空気室の様なもの）が必要です。
その容量は、与えられた仮想時間がもつ最大ギャップ（沈黙時間）を保障できなければなりません。
結果的に言えば、少なくともその程度の遅れ（Latency）は覚悟しなければなりません。
ところが、プレイヤーソフトに色々なエフェクターや表示当を付ける場合は、
その操作に関与したプロセス以降を等時処理しなければ、⑥アナログ出力と時間的なずれを生じてしまいます。
百歩譲っても、感覚的に違和感のない程度の遅れに留めなければなりません。
しかしながら、ＰＣ側のどのプロセス①②③も本来多時間系なので、遅れ縮小には限界があります。
つまり、仮想時間のばらつき以下にすれば、それだけでデータを正確に伝送できなくなります。
また、ばらつきを少なくしようと、該当プロセスの実行順位を無理やり上げても、今度は安定した動作が保障できなくなります。

二週間のご無沙汰でした。ＳＡＬです。

最近、ＰＣオーディオと言う言葉も定着してきた感がありますが、ＳＡＬが目指す方向との違いも徐々に感じられるようになりました。
どうも、ＰＣを使ったオーディオには二つの流れがあり、それらをＰＣオーディオと一つの言葉で括ってしまうことに、原因があるようです。
その二つとは、簡単に言うと「ＰＣありき」か「オーディオありき」かです。
「ＰＣありき」とは、ＰＣで音楽を聴くにしても、もっと楽しめる音にすること。
「オーディオありき」とは、従来からのオーディオソースにＰＣ音源も加えること。
と思ってください。
この二つは、将来的に合流する可能性もゼロではないかもしれませんが、少なくとも今は別の流れと考えた方が良さそうです。
ＰＣ雑誌のオーディオ記事の多くは、前者の立場で書かれたものが多いので、後者の方が読む場合は注意が必要です。
また、後者の立場での議論にも、ＰＣに対する誤解（迷信）が含まれている場合があり、こちらも要注意です。

そこで、これまでの話も含めて、ＰＣを使ったオーディオについて、何回かに分けてお話したいと思います。
先ずは、第一回目として表題の項目について述べてみます。
最終目標は、「ＰＣ音源の音質は他のアナログソースに匹敵、若しくは凌駕できるか？」に答えることです。
では、始めましょう。

「デジタルだから正確だ！」等と聞くことがあると思いますが、この主張はそれこそ正確ではありません。
有限の情報を「正確に保管する」或いは「正確に渡す」には、デジタル化は有効な手段ですが、充分ではありません。
正確さを保障するには、以下の二つが必要です。
① 誤り検出が可能であること
更に、誤り率が比較的高い場合には、
② 誤りがあった場合に、訂正若しくは再送が可能であること
です。このことをもう少し掘り下げて説明します。

① 誤り検出機能とは
実際に伝送や記録で使用されるメディア（物理媒体）は、アナログ量を利用するので、ほぼ無限とも言える情報量を保有しています。
デジタル情報は、その中から曖昧な部分を極力排除して、ほんの一部を有限な情報媒体として利用しています。
つまり、受け渡しに都合の良い部分だけを利用するので、つい正確だと思ってしまいますが、誤りが無い訳ではありません。
そこで、誤り検出を可能にする為に、本来の情報から算出される「余分（冗長）な情報」を加えます。
一番簡単な例がパリティビット(parity bit)です。
例えば、１バイト毎にパリティビットを加え９ビットを１デジットとして渡すこととします。
ここで加えた１ビットが冗長ビットになります。

偶パリティ(even parity)を例に、仕組みを簡単に述べてみます。
本来の情報は１バイト（２５６通り）なのですが、もしこの部分のＯＮのビット数が奇数の場合は、パリティビットもＯＮにします。
そうすると、正しいデータは「常にＯＮのビット数が偶数」になっている筈です。
偶然二つのビットが反転した場合も正しいと見なしますが、起こりうる確率は一つの場合の二乗程度になります。
言葉のあやですが、万に一つであれば、億に一つとなり、精度がぐっと上がります。
昔のＩＢＭ互換機のメインメモリ構成はこうなっていました。いかにも実務のＩＢＭらしいと思えます。
因みに、ホビーユースから発展してきた多くのＰＣは、パリティ無しでした。
ＩＢＭ互換機も、ＥＤＯを使う頃からはパリティ無しになってきましたが、
ＩＣ自体の信頼性向上というよりも、パリティエラー後の処理が問題だったのかもしれません。
業務用サーバ機等では、自己修復能力②のあるＥＣＣを採用して、対処しているようです。

② 訂正若しくは再送が可能とは
伝送の場合は、送り主がいる訳ですから、受け手でエラーを検出したら、再送を要求することも可能です。
こうすることで、よほどのことがない限りは、情報を正確に受け取ることができます。
欠点は、送り主が受け手や伝送経路の品質に縛られることです。（例えば、ブロードキャスト不可とか…）
別の視点で言うと、送り主が希望したテンポで送ることが保障されない点です。（リアルタイム性への障害）
例えば、皆さんが今使っている通信手順であるＴＣＰ/ＩＰを例に取ると分りやすいかもしれません。
ＴＣＰはＩＰの上位のプロトコルとしてスタックされています。
ＩＰはパケット単位の情報をネットワークを駆使して受け手に届けるための手順で、再送に関する手順はありません。
誤り訂正の為の再送プロトコルはＴＣＰの担当です。
皆さんが今使っているブラウザはこのＴＣＰの上位にあるアプリケーションなので、このブログもＷＦＰのダウンロードも正確に行えます。
逆に、ＩＰ電話が何故ＩＰなのかも、正確さよりリアルタイム性を重視する所以です。
実は、ＰＣにおける音楽再生もこの状況は同じです。（詳しくは、回を追って述べます）

データを保存する場合は、再送手段を持ちえませんので、自己修復方式がよく使われます。
折角なので、自己修復の仕組みを簡単な例で説明します。
先ほどのパリティビットに加えて、ある纏まったバイト数（仮に３２とする）単位でデータを括り、そこに一バイトのパリティデータを加えます。
冗長な一バイトは、それぞれのデータラインＤ0～Ｄ7のパリティを担当します。
（８×３２長方形の縦横方向にパリティチェックを行う）
今、５番目のバイトとＤ3がパリティエラーしていれば、５番目のＤ3ビットを反転すれば、正しいデータに戻ります。
実際にはより洗練されたチェック方式を使います。
たとえば互換機のＨＤでは、通常データは５１２バイトのセクター単位に分けられます。
これにアドレス等のヘッダ情報とお尻にＣＲＣと呼ばれるチェックデータを付けて記録されます。
このＣＲＣが、自己修復機能つきのチェックデータです。
勿論修復能力は完璧ではありませんので、駄目な場合はＣＲＣエラーとなります。
つまり、エラーなく読み込めた場合、そのデータ（例えばWAVファイル）は、書き込んだものと同一です。
万全を期すために、書き込み直後に読み出しチェックをする場合もあります。
こうすることで、書き込みエラーや不良メディアの検査になります。

今回は長話になってしまって申し訳ありません。
取り敢えず、以下のことを覚えておいてください。
「ディジタルデータは正確に伝える手段を持ち合わせていますが、
そのためにはリアルタイム性を犠牲にする場合が有りえます。」

二週間のご無沙汰でした。ＳＡＬです。

現在は、Hybrid2S が何故良い近似を与えるのか、数理に基づく解析を試みていますが、あまり芳しくありません。
フィルタの透過範囲(-fs/2～fs/2)を僅かに狭め、その差分周波数を微小パラメータにとると興味深い係数が現れたりしますが、まだまだ五里霧中といった段階です。

話は変わりますが、１月１２日の東京出張の帰りに、Ｋ’ｓさんが買った某技術系の雑誌を見せてもらいました。
理由は、「ＵＳＢデバイスをターゲットにしたＰＣオーディオ特集」が組まれていたからです。
良かったらＳＡＬも買おうかと思ったのですが、ＤＡＣの説明部分を読んで萎えてしまいました。

理由は、説明に使っていた変換対象のデジタルデータが、標本点間で１しか違っていなかったためです。
念のために言っておきますが、(1bit)ＤＳＤの説明ではありません！
確かに、動作原理は簡潔さを求められるので、「方便！」のつもりかもしれませんが、
次のステップ（標本点）までに、１単位（分解能ぎりぎり）しか変化しないのでは、繋ぎ方は完全にネグられます。
結果、オーディオソースとしての未解決問題を見過ごしてしまいます。

実際ＣＤのＰＣＭデータは、数千つまり３～４桁のオーダーで変化します。
１６ビットでこれですから２４ビットなら６桁の変化は当たり前です。
サンプリング周波数を４倍にしても、１桁も下がりません。（１０倍でやっと一桁です）

お好みのソースがどれくらいか知りたければ、Gradient.exe が提供する MaxGradient の値が参考になります。
但し表現は３２ビット１６進表記ですから、１６ビット換算する場合は、下二桁を無視してください。
例えば、0x00635d79 ならば、635d を関数電卓で１０進表示で見てください。
結果は、驚きの 25437 です。（最近のＣＤでは、おとなしい方かも）
場合によっては、符号付１６ビットの最大値 32767 を超える場合もありえます。
（最大傾きは、原理的に最大振幅のπ(≒3.14)倍までありえます。）
但し、この値は瞬間最大値であり、隣までの平均値でもないので、仮に半分の 12718 にしても４桁を超えています。
くどいようですが、次の標本点までの変化を１としたのでは、途中のアナログ値のでたらめさを隠蔽してしまうのです。
（上記のデータの最大変化量を１にしたかったら標本化周波数を更に25437倍しなければなりません）

ＳＡＬは、新聞なども含めて書籍の信頼度を測るのに、自分の得意分野の説明や論理を参考にします。
明らかな間違いや、単なる言葉の遊びに終始しているものは論外です。（意外と多い）
そうではなくても、以下のようなことには注意が必要です。
“複雑な現実をそのまま扱うことは不可能なので、通常は本質ではないと思われるファクタを取り除きなるべく単純化します。
このモデル化が、嘘（間違い）か方便（適切）かは、自己無矛盾性とネグった影響の大きさが試金石になります。”

先の例では、最大振幅が 11025 の入力を仮定した場合、ゼロからその値に到達するのに少なくとも 11025 標本点を要します。
此処までで1/4周期ですから、一周期に必要な標本点は 44100 個となり、サンプリング周波数が 44.1KHz なら、１秒の周期になります。
最早、「音」ですらありません。

二週間のご無沙汰でした。ＳＡＬです。

年明け第一回目の「ヘッドホンアンプ考」の最後で「-12dB のバーゲイン」と表現しましたが、これはパワーアンプの増幅率（電圧比率）への補正を表わしたものです。
本文の論旨からいけば、電力回路の減衰器なので、単体での電力伝達率として表現すべきでした。
その場合は、負荷インピーダンスに依存しますので、
取り敢えず、６４Ωで近似すると、更に -9dB 食われ、大体 -21dB ぐらいです。
８ΩＳＰドライブに対して、ミュートＳＷ入り(-20dB)程度と思っていただければ結構かと思います。

話は変わりますが、最近頂いたお便りの中に「ＣＰＵを替えると待ち時間の改善ができますか？」といった旨のものが有りました。
Ｐ４４及びリサンプリングは、倍精度浮動小数点演算を多用するので、かなり時間を食いますが、逆に言えば演算能力による影響も大です。
（Ｐ４０は傾きチャンクを利用することで、残りの計算時間はＰ２１～Ｐ３６と同程度になります。）
実際どの程度の依存性があるかを見る為に、「ＣＤデータを、192KHz にリサンプリングする」場合の待ち時間を測定しました。
また、内蔵の傾き算出時間は、Matrix24 を使った値です。
使ったＣＰＵは、①Core i7(920:7.4/7.4)、②Core2 Quad(Q9400:7.2/7.2)、③PentiumD(945:5.1/5.3) の三つです。
ＯＳは何れも Windows7 で、カッコ内のコロン以降の数値は、ＣＰＵとメモリーの評価サブスコアです。
楽曲ファイルの長さは、14:13(853sec.) です。
また、初回は実際のメディアからの読み出し時間という不確定な要素が追加されるので、二回目以降にしました。
（精度の悪い測定法ですが、複数回で同じ結果でした）

結果（時計を使った目視計測なので、秒単位です）
① 傾きチャンク１秒：傾き算出なら９秒：リサンプリング２２秒
② 傾きチャンク１秒：傾き算出なら１２秒：リサンプリング３４秒
③ 傾きチャンク１秒：傾き算出なら２０秒：リサンプリング５２秒

「改善」と言うからには半分以下にならなければなりません。
③→① であれば、５３秒が２３秒（傾きチャンク無しで、７２→３１）なので、
「効果有り」としても良さそうですが、③が現役の可能性は低いと思います。
但し、①も今となっては古々タイプなので、最新ＣＰＵならば結構良い値が期待できそうです。

WFP4Exp側もマルチコアを生かしていないので、その為だけでＣＰＵを替えることはお勧めできません。
もし買い換える場合には、実際のパフォーマンスを比較してから決めると良いでしょう。
（もし Atom 系からの変更であれば、効果は絶大ですが…）

結論：
当然、効果は有ります。
しかしながら、コストに見合っているかは、総ての面でケースバイケースでしょう。

今日は、ＳＡＬです。
お正月に楽曲ファイルを整理していて、以前報告した不具合の「読み出し」版に遭遇しましたので、対応できるように修正しました。
今回は、読み出し側なので、WFP4Exp gradient BindWavs Hybrid2S の四つが該当します。
古いＯＳ（Ver.5.2以前）でファイルサーバを利用する場合は、更新してください。

これとは別に「一時間半ほど連続再生していると音が途切れるようになる」と言う不具合報告が有ったので、
複数のＰＣで、２４時間耐久レースじゃなかったテストを行いましたが、症状は現れませんでした。
ＳＡＬの記憶では、ＵＳＢデバイス用の標準ドライバを使った時に、似たような症状を経験しています。

WFP4Exp は、アプリ側でジッタを増やさないよう、ドライバを通常とは違った風に使っています。
従って、それに耐えられないドライバがあるのかもしれません。
報告された症状は、あたかもＭＳ得意のガーベージコレクションが働いているようにも見えます。
（再生中にやっちゃいけないことですがね…）
WFP4Exp再起動（プロセスを一度ごわさんにする）で対処できることなら、対策法も有りそうなのですが、
「ＯＳリブートが必要」となると、残念ながらアプリ側では対処不可能と考えます。
（WFP4Exp は、再生中はメモリアロケーションどころか、ＵＩのイベント処理以外何も行いません）