昨日は急遽先輩の家で鍋をしてしまいました…。
TCP/IPの基礎の基礎から勉強中。
先日はメールを簡易的に送信するプログラムだったが、
本格的にwinsockを勉強となると資料が膨大な範囲
なのでゆっくりと読み進めてます。
一方先日のストリーミング再生は、こちらを参考に
その3 Oggファイルでストリーム再生
http://marupeke296.com/OGG_No3_Stream.htmlこれまた読解中。
マルチバッファ自体は、2つの波形データとヘッダを
用意するだけで実現できたが、スレッド動作で
任意にバッファを切り替えつつ読み込みをさせるとなるともうちょっと詳しくやらねばならぬ。
それも後半に載ってるので後は理解だけ。
ストリーム再生において、CreateFileの戻り値が
HANDLE型(VOID*)という事は、
無理矢理すればReadするメモリの場所を移動可能か?
バッファサイズ分だけメモリに保持して残りを
引き出さなきゃならんと考えているが、ファイルから
引き出すオーバーヘッドがどうも気になって調べた。
取得位置を保持していれば読み込みの最適化に
利用できないかなぁと思うものの、
パスからCreateしてるし微妙なヨカンはしつつ。
…もうちょっと考えてみるとしよう。
同日 19:36
WAVEOUTハンドルを2つ用意して、
別個のデータとヘッダをそれぞれ登録し、
スレッドで同時に再生してみた所、
Sleepは必要だったが、同時に再生した。
DirectSoundではこれはミキシングされて結果を
出す方法もあるらしい。何にせよ、直に二つの音が
同時に出る事を確認できた。
あとの問題は必要分の動的管理だけ・・・。
先程の件は、DirectSoundのセカンダリバッファに
ついて調査する事で進行中。
分かったのは、やはりCreateFileもDirectSoundの
セカンダリバッファもこれから再生すべきファイルの
先頭場所をキューで格納して軽量化してるという点。
つまりCreateFile自体はファイルオープン同様
これから開くべきアドレスをハンドラとして渡し、
用が済んだら速やかにcloseする必要があるだけで
バッファからの読み込み位置だけを注視すれば
ダブルバッファリングの実装自体は難しく無さそう。
複数同時再生も先程試したので、効果音のバッファと
BGMのダブルバッファを別管理すれば、
特に音に関して困る要素は無くなった予感。
実装して結果を見ないと後は何とも言えないが。