graphedtでもう一つ

今日もフィルタのデバッグを続けています。

graphedtを使っていて気がついたことがもう一点あります。

フィルタのテストなので当然ながらソースを修正し、ビルド後にgraphedtを起動してテスト用のグラフを読み込んでテストを繰り返します。

フィルタの出力側のデータサイズ変更を行ってデバッグをしようとしたところサイズの変更が反映されていなくて、大きなサイズのデータを要求されメモリーアクセスエラーが発生しました。ソースを見直しても修正ミスではないししばらく悩みました。

試しにはじめからグラフを作り直すと直ってしまいました。どうも保存と読込の時に接続情報も一緒に細かく読み書きしているようです。graphedt がてっきりフィルタと接続関係だけを保存していて詳細な状況は読込時に接続をやり直していると思っていたのですがそうではないようです。

デバッグ作業を考えるとちょっと面倒ですね。全部を作り直さなくても直接関係している接続だけ一度削除して繋ぎ直せばいいのですが、うっかり忘れて今回のように悩むことが出てきそうで。

" フィルタを修正したら接続をやり直す "を肝に銘じておかなければ。

DirectShowフィルタのデバッグ

DirectShow のフィルタを作っています。これまでにもファイル出力関係のライターを何本か作ったのですが、基本的にはサンプルの焼き直し程度ですむようなものなのであんまり苦労しませんでした。

今回のものはもっと込み入っているのでデバッグで苦労しそうだと思って始めたんですが、特殊なモジュールにもかかわらず普通にデバッガが使えるんですね。Visual Studio の環境も悪くない。

Windows では普通のアプリケーションくらいしか作ったことがなかったのでちょとびっくり。もっとも、普段は Borland C++ Builderを使っているのでVisual Studioについては勉強不足だっただけですが。

試しに実行プログラムに graphedt を登録してテストするフィルタを含むグラフを実行したところブレークポイントもちゃんと効いてデバッグできました。もっとも、フィルタという性質上リアルタイム性が重要なのでトレースかけてのデバッグは難しいかもしれませんが。

・graphedt を使っていて焦ったこと

テスト中に graphedt がじゃまになったので最小化しておいた。タスクバーに入った状態のままでコンテキストメニューから閉じるを選んで終了させました。

その後でフィルタのデバッグのために Visual Studio から実行すると graphedt が起動するはずなのですが、画面が出てこないので焦ってしまいました。一瞬、起動で問題が起こるようなバグを組み込んだのかと思ったのですが、考えてみるとgraphedt が起動する段階では私のフィルタは関係ないはずだ。しばし悩んでしまいました。

よく見るとタスクバーにはちゃんと graphedt がいました。graphedtって最小化のままで終了すると次もそのまま起動するんですね。考えてみればステータスをちゃんと保存するのがあたりまえかもしれませんが、ちょっと気に入らない気もします。最大化状態で終了時に最大化のままで起動してくるならまだわかりますが、最小化の時くらい解除した状態で起動してもらった方がいいような気がするのですが。

DirectSoundのハードウェアバッファ

今年は春物件が少なくてそれほど忙しくなかったけど、苦労させられたトラブルが１件。
久しぶりの書き込みでその失敗について書いておきます。

この春には近場の現場に導入されたので打ち合わせがてらソフトの動作状況を確認に行きました。
その時点では何もなく事務所に戻りました。ところが事務所に着く頃に現場からエラーがでているとの連絡が入
りました (トラブルとは不思議とこんなタイミングで起きます)。
とりあえず確認してほしいことを伝えて翌朝改めて連絡したところやはり何らかの問題が発生している模様。

早速現場に向かって再現性をチャックしました。普通に使用している分にはいいのですが、テストのためにいろいろなボタン連打をするとかなりの確率でおかしくなります。このソフトは相当数の納入実績もあり他の現場でも同じテストは行っているのでここでだけ起きるのは理解できません。

早速再現パターンを見つけるためにいろいろと試し、３０分ほどかかってそれらしきものを見つけました。

このソフトはサウンドの録音／再生ソフトなのですが、録音と再生を短時間で繰り返すと発生するようです。内部的には再生→停止→録音となるのですが、再生といっても普通のプレイヤーとは違ってDirectSound で二つのバッファを作って同時に再生しています。

早速持ち込んだ hp のノートパソコンで同じことをやってみましたが、どんなに繰り返しても再現しません。もしかすると DirectX のバージョンかと思い DirectX 診断ツールで詳細なバージョンを確認したが一致。
ところが DirectSound のテストを実行して違いが見つかりました。納入されているＰＣは N 社製のデスクトップなのですが、こちらのＰＣはハードウェアバッファによる再生をサポートしていません。どうもここに問題がありそうです。試しにノートパソコンの方でアクセラレーションの使用をオフにするとこちらでも発生するようになりました。

微妙なタイミングの問題なのでデバッガを使って追うこともできずOutputDebugString を使ってイベントを書き出す方法と想像力を駆使して何とか原因を突き止めました。

トラブルの原因は DirectSound の再生時の動作タイミングがソフトバッファだと微妙に変わってくることでした。
一番大きな問題としては同じサイズの音声をバッファ A,バッファB で再生した時。当然ながら本当の意味で同時ということはなく再生開始にミリ秒単位の時間差があるはずです。同じサイズなので終了も A,B の順のはずなのですが、まれに B,A の順序で各スレッドの終了イベントが逆転して発生するのが確認できました。
また、途中で再生を止める時には A を止めて停止を確認してからB を止めるのですが、A に STOP を発行してから実際に終了イベントがくるまでの時間が結構長いようでその間に B の再生が終わってしまい、この場合にも逆転現象が起きてしまいます。
ロジック的に逆転を想定していなかったのでこれがトラブルの原因となってしまいました。

かなりしつこくやってみたのですが、ハードウェアバッファを使っている環境ではこの現象の再現が確認できませんでした。

ちなみにハードウェアバッファをサポートしていないＰＣがどのくらいあるかは把握できていませんが、手元の同じ N 社のノートパソコンも同じでサポートしていませんでした。CPU パワーが大きくなったこととコストダウンの要求からこのようなＰＣが増えているんでしょう。

ことがことだけに原因がわかるまでにすごく苦労しました。