Soundがcaptureできれば...DirectX.Direct3D編
1. DirectX.Direct3Dで、描いてみました。
結論から申せば、
spectrumの、グラフの描画が遅いのは、FFTの計算量の多さが、原因でした。
GDI+で、描くのも、このプログラムでは、充分な速さを持っていました、なんのこっちゃ (^_~;;
しかし、よい経験でした。
２DをDirect3Dで描くのは、そんなに多くの知識を、必要としません。
グラフの頂点の集合を作り、その集合体が、どんな種類のpointの集まりなのかを指定してやれば、よいのです。
「C# ゲームプログラミング 赤坂玲音著 ソフトバンククリエイティブ社」より
この本、非常に為になる、よい本です。C#の画像関係なら、これしかない！
そんで、captureしたデータを、この集合体に、入れてやるのです。
全てのプログラムを、お見せしたいのですが、CaptureSoundプログラムから、延々と引き継いでいますので
まだ、整理が付きません、すまそ。
2. Normを追加する
Prodigy7.1XTの、LINE入力は、48KHｚサンプリングの時、少し、ノイズを持っています。（ジャックにプラグを指さないでも、そうなる。）
そんで、これを打ち消すプログラムを、追加（captureData_FFT_and_normalize()関数）。
この関数は、ノイズの大きさを、100回で平均して、これを、測定値から差し引いています。
（100回平均をとるのに要する時間は、充分、1秒以内ですから、captureしたデータを取り出すのは、充分速い。
8192個のデータ（16384byte）を、100回取り込んでいます。
となると、描画が遅くなる原因は、FFTに起因するちゅうことに、なります。）
いや、待てよ...
captureData_FFT_and_normalize(int m)関数も、FFTしてるから、FFTが遅い訳でもない.....
ちょっと、判らん.....何処が遅いんやろか... はて？.....
残るは、描画部分しかない.....Direct3Dでも、あかんか？
、
normあり
normなし
このほうが、見やすいでしょ。
このLINE INのノイズなんですが、
こうなってて、
ノイズのピークを０ｄBの所に持ってくると
実に、-120ｄBあたりも、観測できちゃってます、凄いダイナミックレンジ！
3. 肝心のFFTの部分の性能
CaptureSizeが、重要です。
FFTが16384ポイントの時、CapureSize（ =NotifySize )を、16384byteにするのと、その半分の、8192byteにするのでは
性能に、大きな差がでます。（同一の波形の観測 共に normあり）
FFTポイント数 ＝ CaptureSize( =NotifySize ）
にするのが、1番よい結果が、出ました。
CaptureSizeをFFTポイント数の2倍、3倍にしても、効果ありませんでした。
4. DirectX.Direct3Dを使うと、よい所、よくない所
よい所は
描画が早い
CPUの負担が、すごく少ない（タスクマネージャによると、7%から20%までの間）
よくない所
このまま、 windoｗを最大化すると、画面が粗い
windowのサイズが変わると、Direct3Dが、自動的に、調整してくれるのですが、
これは、Bitmapを拡大したように、粗く、なります。（私は、これ位、全然気になりません）
しかし、これは、最初から、大きな画面で、設計しておけば、済むことですね。
一方、前節で、ご紹介した、拙作のプログラムでは
最大化しても、画面の綺麗さは、変わりません。
しかし、CPUの負担が、少し、重いのです。
大体、30%から40%まで、位です。（私のPCmachineのCPUは、セレロン2.53GHzです。）
これ位のCPUの負担なら、これでも、よいのかも.....
最後に、96KHｚでのspectrum解析を、お見せします。
norm前
normあり
96KHｚサンプリングの時は、FFTは 32768ポイントが、丁度よいし、速度も、丁度よいです。（あまり速いと、目まぐるしくて....）
ちなみに、LINE INへの、外部発信器入力は、以前作ったAD9851DDS SGです、２KHｚ出力。
師匠と仰ぐ、efu様のWave Spectraの性能は、ほんま、凄い！....及ばん...
次は、周波数軸の範囲を、マウスで選択できるように、してみたいです。
H18.8.23