DirectSoundでストリーム再生中に再生時間を効率よく取得するために…

質問

臨時に仕事を頼まれたので泣く泣くそれに悶えながら、時間を見つけてはしらべ、ようやくDirectSoundで2~4MB程度を上限とするストリーム再生をしつつ、その「波形データ全体における」再生位置（時間）を30FPS程度を目安に取得してms単位あるいはサンプル数単位で表示することができるようになりましたが…

WindowsAPIのwaveOut関連を使ったマルチバッファと比べ、waveOutResetの時の一瞬の音の途切れ自体は循環バッファのため自動的になくせるみたいだし、全部読みこんでしまえば自動的に再生位置取得するだけで再生時間が得られるようです。

…しかし

こっちもこっちでこういう事（ストリーミング）やろうとした時に微妙に仕様が引っかかる部分があるようで…これだけのことなのになんでこんなにステップ数が多いの？
っていう感じになってしまっています。

DirectSoundは手をつけ始めて数日程度なので、まだまだ改良の余地がたくさんあっても不思議ではない、あるいは勘違いがあると面倒な事態が蓄積してしまうと思うので、質問させてください。
（一つでも問題はないので、アドバイスいただけましたら幸いです。）

1.DSBUFFERDESC構造体で指定したバッファの長さは、セカンダリバッファを作ってしまってからは変更できませんか？
（これが変更できるとファイル単位のループ再生を考えた場合確実に必要物が減りそうです）

2.そもそもバッファの再生中に、現在の再生位置は影響を受けないような部分を書き換えても問題はない、という認識は完全に正しいですか？

3.Lock,UnLockを繰り返すと、以前のメモリは暗黙（？）に解放されたうえで確保されるのでしょうか？（見た感じはそれっぽく見えるのですが、小さな残骸も何も残らないと考えていいでしょうか？）

4.また、ファイルをfopen_sなどであらかじめ開きっぱなしにしておき、その際にfreadなどで読み込むだけ、という考え方で問題はないでしょうか？

5.これが本題ですが
文字数制限と「複数に分割して投稿した場合は削除の対象」ルールのため別途UPしたのでリンクさせてください。
http://www.geocities.jp/shank_long7_02/DirectSound/a.html

6.5について、判定以前にスレッドの仕組みとかそもそもスレッドにするべきかどうかとかいったあたりをCPUやメモリ、あるいは保守性の点で改良したりすることは可能でしょうか？

回答No.1

machongola · ベストアンサー

こんにちは。
　当方はDirectSound1を5年程前に使用しただけなのですが、

　1については、
　バッファの拡大は出来なかったかと記憶しています。新たに作り直す必要がある筈です。

　2については、
　はい。
　例えば2Mbyteバッファを割り当てて、前半1Mbyteを再生している最中に、後半1Mbyteに向かって次のデータを書き込む、次回では、後半1Mbyteを再生している最中に、前半1Mbyteに次なるデータを書き込む、以降はこれの繰り返し、と言う再生と書き込みのイタチゴッコが、DirectSoundの基礎定石であった筈です。

　3については、
　読み書き用のポインタを「取る、戻す」ですので、解放されている訳ではありません。変更されていない箇所には依然として、データは残り続けます。

　4については、
　再生に必要な場所を読み取って、バッファに書く、と言う方法でOKです。

　5については、
　う～む、これは実装それぞれによるものですので、何とも・・・。
　(2)辺りに、Sleep(0)を入れて見ては(意味が無いかもしれません)。

　6については、
　中央イベントが来た時に前半更新、終点イベントが来た時に後半更新。
　更新の際、楽曲のラストであれば、楽曲の繰り返しがONの時には、ファイルから更に先頭を読み込んで来て、継続、楽曲の繰り返しがOFFの時には、スレッドの終了。
　楽曲の繰り返しON/OFFに関わらず、楽曲の途中であれば、バッファのループ再生だけは継続・・・、と言った具合です。

　実は当方はその当時、シングルスレッド(アイドリングループ内)で実装したのですが、これに関しては、「決してお勧め出来ません」。
　どの様な手段を取るにしろ、かなり苦戦します。

お礼

おお♪こんにちは。
どうもご丁寧にありがとうございます♪

よく見たらその辺の大事な実装については概要すら書いてませんでしたね（汗

しかしまさにビンゴです。細部については奇跡的かもしれませんが、ぴったりいただいたアドバイスに沿うような仕様にしていました。
書き忘れていた状況でやり方が一致ということは、かなり自信が持てました。

3については、色々一辺に読んだため頭がこんがらがっていたようですｗ

冷静に考えると、CreateSoundBufferのあたりで確保、Releaseで解放
ってわけで、LockとUnlock付近はそこに読み込んでるだけなので確保も解放も関係なかったですねｗ

machongolaさんの一言がなければその「冷静に考え直す」までに無駄が多かったはずと思います。

それ以外の点について、それほど間違った認識はしていなかったと確認でき安心しました。
やはりかなり絞ったとしても、手数はかかるようですね。

5についてですが、もう少ししっかり調べなおしてみて
どうやらハードウェアに任せた場合に、他のアプリを起動するとまずいときがある、との事を知りました。

私はそれを知らなかったのでそれまでやっていませんでしたが、試しに

DSBUFFERDESC構造体のフラグに
DSBCAPS_LOCSOFTWARE

を付加しておけば、記述を見る限りその問題は改めて何かしなくてもOKのようです。

それでは・・・
というわけで、かわりにDSBCAPS_LOCHARDWARE
にしてみたら

私の環境ではCreateSoundBufferが失敗してしまう模様ですｗ

そのためハードウェアサイドでそういう現象が本当に起きるのか今のところチェックすることはできませんが
実は今までソフトウェア ミキシングをやってたと分かり

それでも（その場合はおそらく冗長になる）チェックがなければ、平均的にCPU使用量1%未満を出せる場合が多いようなので、ひとまずこれで十分と考えることにします。

しかしそうなると、単に再生するだけならWindowsAPIと比較しそれほど得をしていないか、若干コードが長くなったりスレッドやメンバが増えたり、DirectX使用可能な環境を強要するので、WindowsAPIのほうがいいかもしれませんが

DirectSoundの真価の一つであろう、複雑な処理をどの程度できるかについて調べてみようと思います。本当の判断はそれからですね。

重ねて、ご丁寧にありがとうございます☆