前回：
楽にノイズ除去したいなぁ，車輪を再発明したくないなぁと思って
web上をアッパー気味にウロつき，諦めた

今回：
三次元仮想空間にVoiceChat機能を組み込んだ

内容：
DATTE 報告会が近いJAN！（ファイター　＜　乙女チック）
Get you 修羅場モードJAN！（ストレス　＜　ロマンス）

ということで，以前に作っていた三次元仮想空間に
出来上がったボイスチャットを組み込んでみました．

俗な言い方をすれば
超しょっぱいネットゲーにボイチャ機能つけたお！(^ ^ )/

各ユーザのIPや位置座標などの情報は
TCP通信でサーバを経由して他のユーザに送っています．
そこで取得したIP情報をUDP送信に用いています．
ボイスデータはサーバを経由していないということですね．

また，多人数化のためにVoicePlayerクラスに大きく手を加えました．
参加しているユーザ分の
SecondaryBuffer,  Buffer3D,  Buffer3DSettings　を
それぞれ用意して，個別に設定を行ないます．

そしてUDPで飛んできたバッファの先頭に付いているユーザIDを用いて
対応するSecondaryBufferに書き込みを行ないます．

モチロンTCPで送信されてきたユーザの位置情報を
Buffer3DSettingsのPositionプロパティに反映させることも忘れないさ！

そうそう，
このPosition設定の話なんですが，
Listener3DSettingsのPositionに自分の位置を設定し，
そしてBuffer3DSettingsのPositionに音源の位置を設定すると
その位置にあわせて3Dサウンドがミキシングされるはずなんですが
何故か自分の位置が常に原点（0,0,0）にあるようにミキシングされます．
デバッグでパラメータを見ると値の代入はできているのですが・・・？

仕方が無いので，音源位置設定の際は
自己位置との相対を設定するようにしています．
まぁ内部でも同じようなことをやっているはずさ！

今後は・・・なにしろ音量が小さいのをどうにかしたいと考えています．
イコライザをいじってなんとかしてみよう・・・

エフェクタを色々試していると，声が甲高くなったりして面白いので
こういう機能も無駄に搭載していきたいですネ．
（そして報告会で「それ意味なくね？」とか教授に言われたいネ）

設定課題：
音量調整
エフェクトの追加
シーケンスIDの追加（今のところ無くても動作していますが）

前回：
三次元仮想空間にVoiceChat機能を組み込んだ

今回：
DirectSoundのエフェクトを用いて音量を調整した

内容：
「音が小さい」という大きな欠点を克服したいと思い
音量を上げる方法について探りました．

・ＯＳの音量出力を上げる
・スピーカの出力を上げる
・入力側のマイク感度を上げる
・音声再生時にデータを加工する

上三つを全部やってもまだ音が小さいので
最後の項目を何とかして何とかします．（曖昧）

DirectSoundには
音声にエコーやコーラスなどのエフェクトをかける機能があります．
それらをうまく用いて，その・・・アレする．（口下手）

使用したのはパラメトリックイコライザの機能です．
これで全帯域の出力を増幅してみると，
使用前よりも音が大きくなりました．

より大きくするには，自分でバッファをいじるしかないと思うのですが，
単純に振幅を増幅するだけではダメっぽいので（音が割れました）
音圧を上げる行為にはいろいろな工夫が必要なようです．

・・・めんどいので，終了！
いずれまた会うこともあるだろう・・・（ライバル風に）

今後の課題：
再生地点の調整
（バッファ受信時に一つ前のバッファから再生して音の途切れを防止する）
圧縮の導入（ADPCMまたはDPCM）
シーケンスIDの追加

今回，wave（というよりはriff）ファイルに関することを少し勉強したので，
圧縮については以前よりも見通しが立つようになりました．
年内には無理ですが，今年度中には導入していきたいと思います．

前回：
DirectSoundのエフェクトを用いて音量を調整した

今回：
ADPCM変換を導入して音質を向上させた

内容：
色々と調べた結果，なんとか音声圧縮導入に至りました．以下に経緯を示します．

SecondaryBufferのコンストラクタで
wavファイルのパスを指定するオーバーロードを使うと
BufferDescriptionの記述を省略してバッファを構築できます．

そこでADPCM音源サウンドを読み込むと，
プロパティのwaveformatTagの値は"Pcm"になります．
読み込み時に既に変換を行っているのでしょうか？

また，キャプチャバッファのBufferDescriptionを設定する際，
riffで既定のADPCMフォーマットIDをwaveformatTagに代入しても
録音はリニアPCMで行われる模様です．

なんだよそれ！MSDNでは「圧縮キャプチャをサポート」とか書いてるくせに！
私の使い方が悪いのでしょうか．

仕方が無いので，自力でADPCM変換処理を実装することにしました．
面倒そうだなぁ，と思っていたのですが
一日勉強すればサインカーブの符号化と復号化のサンプルを作れました．
実装は思ったより簡単です．理論を考えた人は偉大だなぁ・・・

あとはバイトオーダに気をつけながらVoiceChatに組み込んで実装完了です．
今回実装した処理で16bitの音声データが4bitに圧縮できました．

現在までは8800Hz 16bitで録音していましたが,
これによって44000Hz 16bitで録音しても問題ないでしょう．

現在は1/8秒毎にデータをUDP送信しているので，
通信量を比較すると以下のような感じになるのでしょうか．

8800Hz 16bit (PCM)    : (1100*16 + 32)*8 = 141056 bps 
44000Hz 16bit (ADPCM) : (5500* 4 + 32)*8 = 176256 bps

通信量を1.25倍にするだけで音質は5倍良くなるということですね．

もちろん，等価交換で送受信端末での計算量が増えています．
計算機性能のおかげで特に問題はありませんが，
巨大な変換テーブルを用意することで計算量を減らすこともできるようです．

・・・まぁ，問題になってきたら導入すっか！（先送りキング）

44000Hzで録音すると，音声はかなり明瞭に聞こえます．
導入してよかった．

今後の課題：
再生位置の補正
シーケンスIDの追加

この２つは時間さえかければなんとかなりそうです．
もう少しで一区切りだ！がんばるぞ！