チケット #28021

ギター曲の読み込みが遅い

登録: 2012-04-04 22:41 最終更新: 2013-03-05 02:15

報告者:
担当者:
チケットの種類:
状況:
オープン [担当者決定済み]
コンポーネント:
マイルストーン:
優先度:
5 - 中
重要度:
5 - 中
解決法:
受領
ファイル:
なし
投票
点数: 0
No votes
0.0% (0/0)
0.0% (0/0)

詳細

ギターなど、チップ音が非常に多い曲データの場合、演奏開始の読み込みに非常に時間が掛かる。(経験的に、10~30秒くらいかかっている?)

これを何とか3~5秒程度に短縮できないものか。

高速化のアイデア:

  1. チップ読み込みのマルチスレッド化。現在の実装では、基本的にはシングルスレッドでチップ音を読み込んでraw wavに展開して、次のチップ音を読み込んで・・・をチップ音の数だけ繰り返しているだけなので、(HDDからの読み込み処理以上に展開処理に時間が掛かっているようならば)マルチスレッド化することでトータルでの処理時間の短縮が見込める。
  2. 1.を実施した上で、BGM用のチップ音を最初に読み出すようにする。現在の実装では、たとえストリーム再生するBGM音であっても一旦全部読み込んで展開しているように思えるが、マルチスレッド化して他のチップ音と平行して読み出すようにすることで、処理時間を隠蔽できる。
  3. 後で使うチップ音の遅延読み込み。演奏開始前は曲の最初の方のギター音だけを読み出すようにして、後は演奏しながら裏で読み出すようにすることで、演奏開始までの待ち時間を大幅に短縮できるはず。ただしこの方法は、演奏負荷を増やすことになるため、影響が小さくなるように慎重な対応が必要と思われる。

チケットの履歴 (38 件中 3 件表示)

2012-04-04 22:41 更新者: yyagi
  • 新しいチケット "ギター曲の読み込みが遅い" が作成されました
2012-04-06 03:37 更新者: yyagi
コメント

tp://yyagi.com/DTXMania_28021_20120405.zip

試しに1.のアイデアだけを実装してみたところ、演奏開始までの待ち時間が半分くらいに短縮された。しかし、何度かやっているとデコード失敗エラーになるチップ音が出てきてしまう。

んー、どこかに排他制御が必要なのかな。SoundDecoder.dllへのアクセスを少しずつlock()してみる予定。

一度この爆速・気持ちよさを味わってしまうと、もう昔には戻れない。がんばって調査せねば・・・

2012-04-07 00:41 更新者: yyagi
コメント

少なくとも oggOpen(), oggGetFormat(), oggClose() で AccessViolataionException が発生することを確認。

とはいえ、CSSoundOggVorbisクラスへのアクセスをクリティカルセクションにしてしまうのでは、全くといっていいほど高速化にならないわけで・・・困った。やはり SoundDecoder.dll をイチから作り直すしかないのか。

2012-04-07 00:58 更新者: from
コメント

SoundDecoder.dll はスレッドセーフじゃないですよー(涙

さらに言えば、ACM 関数もスレッドセーフじゃないのでこちらも要注意です。(←おそらく致命的?)

音声でも動画でも、コーデックをスレッドセーフかつ非同期に扱えるのは、今のところ DirectShow か Media Foundation しかないと思いますよ。

2012-04-07 08:57 更新者: yyagi
コメント

SoundDecoder.dll はスレッドセーフじゃないですよー(涙 さらに言えば、ACM 関数もスレッドセーフじゃないのでこちらも要注意です。(←おそらく致命的?)

ぐはぁ! (情報ありがとうございます。まあ、実装前にまず調べろよって話ですが・・・。)

ACMがスレッドセーフじゃないと言うことは、3.のやり方もNGとなります(BGMのストリーム再生とかち合うはず)ので、素直にあきらめます。今回実装したロジックはBGAの読み込みにでも流用しておきます。(おばたけの読み込みが高速化されるな(笑))

一方、今回無理矢理マルチスレッド読み込みにしてみて分かったのは、 700個以上のギターサウンドファイルがある曲データのサウンド読み込み時間がウチの環境(AMD 2.3GHz 4コア)では1秒以下になること。 OSのファイルキャッシュにチップ音ファイルが収まっている前提ではありますが、これは気持ちよすぎです。

この気持ちよさをきちんと実現するために、WASAPIやMedia Foundationに移行したいのは山々ですが、FROMさんもよくご存知の通り、XPがー。旧曲データとの発音タイミングの互換性がー。

2012-04-07 09:17 更新者: from
コメント

今回実装したロジックはBGAの読み込みにでも流用しておきます。(おばたけの読み込みが高速化されるな(笑))

Direct3D9 Device も実はスレッドセーフではないので要注意ですよ。

Multithreaded フラグを付けて Device を生成することもできますが、この場合、ありとあらゆるすべての Device メソッド(垂直同期のため長時間待機する Present 含む)がクリティカルセクションになってしまいます。

VMR9 がゲームに適さない理由の一端もこれですね。

なので、演奏中にファイル読み込み&テクスチャ作成(Direct3D デバイスのロック)をやると、かなり高速な PC でない限り、譜面がガタつきますよ。

そして、60fps を維持したままテクスチャをロードできるような高速な PC なら、そもそも読み込み高速化なんて不要じゃないかという結論に……


WASAPIやMedia Foundationに移行したいのは山々ですが、FROMさんもよくご存知の通り、XPがー。旧曲データとの発音タイミングの互換性がー。

一番の難所ですね。

XP については DirectShow で高速化出来ることが StrokeStyle<T> で証明済みですが、既存資産の問題は致命的ですね。

StrokeStyle<T> ではもう XP と決別します。

2012-04-07 09:26 更新者: from
コメント

補足です。

Direct3D9 Device は、スレッドセーフではないとかいう条件よりもっとひどい状況で、「Multithreaded を付けない場合は、Device を生成したスレッドでなければ Device 関連のリソースにアクセスしてはならない」という決まりがあります。(実際はアクセスできるんですが、排他処理をしないので当然かち合ったらエラーになります。)

でもって、Direct3D9 Device にはウィンドウハンドルも渡しますので、「ウィンドウの操作はウィンドウを生成したスレッドでなければ行ってはならない」という条件も加わります。もう大変。

XP や Direct3D9 、VMR9 は、完全にシングルスレッド専用の設計ですね。

2012-04-08 00:23 更新者: yyagi
コメント

今回実装したロジックはBGAの読み込みにでも流用しておきます。(おばたけの読み込みが高速化されるな(笑))

Direct3D9 Device も実はスレッドセーフではないので要注意ですよ。

いえ、NowLoading画面でのまとめ読込を高速化する話なので、特に問題ないかと。

(よく考えてみれば、従来バージョンでも、NowLoading画面でストリーム再生を使うような長いサウンドを使用すると、他のチップ音読み込みとでACM使用がかち合ってアウトですね・・・)

それと、サウンドの読み込み高速化は、やっぱり捨てるのが惜しいので(笑)、排他問題に絡む例外が出たら安直にちょっと待ってからリトライするようにしてみます。

MediaFoundation等への移行については、過去資産が最大ネックであるものの、しかし結局は移行を後に延ばせば延ばすだけ過去資産が増えるという矛盾が。なのでいっそ過去資産は無視して、適切なタイミングで移行するのがよいのかなと思うようになりました。XPのサポートが切れるタイミングあたりが切り替えには妥当かなと。

2012-04-08 08:14 更新者: from
コメント

Direct3D9 Device も実はスレッドセーフではないので要注意ですよ。

いえ、NowLoading画面でのまとめ読込を高速化する話なので、特に問題ないかと。

ああ、演奏画面でないならガタつきの件は関係無いですね。

でも NowLoading画面での BGA 処理はひたすら画像を Direct3D9 テクスチャに読み込むわけですから、そこを並列化するならそこで Direct3D9 デバイスの排他処理が必要かと。(SlimDX が内部でテクスチャ読み込みに使ってる d3dx ライブラリもスレッドセーフじゃないです。)


なのでいっそ過去資産は無視して、適切なタイミングで移行するのがよいのかなと思うようになりました。XPのサポートが切れるタイミングあたりが切り替えには妥当かなと。

某法則に従うなら、Windows8 が不評でコケて Windows9 が発表されてるころですね(笑

過去資産を無視する前提なら、切替は今でもいいのでは? XPユーザ重視?

p.s.

Microsoft の登録キーメールに登録キーが含まれてなかったおかげで、VC#2008 が最大30日しか起動できなくなりました。

……どうしよう(汗

2012-04-09 21:47 更新者: yyagi
  • 担当者(未割り当て) から yyagi に更新されました
コメント

でも NowLoading画面での BGA 処理はひたすら画像を Direct3D9 テクスチャに読み込むわけですから、そこを並列化するならそこで Direct3D9 デバイスの排他処理が必要かと。

はい。最初は何も考えずに new CTexture()なところをそのまんまマルチスレッドな呼び出しにしたところ、やっぱり一部テクスチャが転送されて無くて黒表示になりました。

そこで、HDDアクセスだけ別スレッドに回して、テクスチャ定義そのものはメインスレッドだけで行うようにしたところ、上記のやり方とほぼ同じ性能を得つつも正しくテクスチャ定義できるようになりました。

ただ・・・私のメイン環境(Win7, 2.3GHz 4core 4GB)だとこれでうまくいっていますが、サブ環境(XP, 2GHz 1core 2GB)だと一部絵が欠けておばたけがしょんぼりでした。なんでやー。

それと、以前Noneさんから、高速起動対応以降Hitエフェクトがおかしくなったと報告いただいてましたが、ウチのXP環境で再現しました。常時おかしくなりっぱなし。このあたりはしばらく触ってないんですが。なんでやー。

みなさま

一応、現時点での実装を置いておきます。wav/bmpの読み込み高速化は共にリスクがあるので、CONFIG/SystemでON/OFFできるようにしておきました。初期値はどちらもOFFなのでご注意下さい。(両方ONにするとかなり読み込み速度が速くなりますが、その代わり一部音やBGIが消えることがあります。) ソースは後でコミットしておきます。

tp://yyagi.com/DTXMania_28021_20120409.zip

2012-04-09 23:13 更新者: from
コメント

あれっ。branches へのコミットかと思いきや、trunk へのマージなのですね。

実験ソースを trunk に入れてしまうのはどうかと思いますが……

とりあえずダウンロードしてみますね。

VC# 2008 ないけど。(汗

2012-04-10 00:21 更新者: from
コメント

ソースを見ました。やっぱりVC#2010ではコンパイルすらできませんでしたが……

って、よく考えたらノートPCにもドラム用PCにもVC#2008入れてあるんだった。良かった。これを壊さぬようにせねば……。


で、本題ですが。

BMPの読み込み部分で、foreach でほぼ一斉に LoadTexture() を呼び出して個々にファイルを読み込み、終わったスレッドからコールバックの BMPLoadCallback() でテクスチャを作成する、といった設計に見えました。あってるでしょうか。

もしあってるなら、BMPLoadCallback() は複数のスレッドから同時に呼ばれる可能性があります。

このコールバックは最終的にスレッドセーフでない new CTexture() を呼び出しますので、ファイル読み込みより OnDeviceCreated() の方が速く終わるような PC でない限り、BMPLoadCallback() 内の OnDeviceCreated() が複数スレッドから同時に呼ばれることになります。

コメントには「メインスレッドで実行する、コールバック部」との記述がありますが、ASyncCallback で作ったコールバックは、メインスレッドではなく BeginInvoke したときのスレッドが実行します。(スレッドを1個だけ作って、LoadTexture() と BMPLoadlCallback() のそれぞれの Thread.CurrentThread.ManagedThreadId を比較してみれば、同一のスレッドであることがわかると思います。というかこちらで試したらそうなりました。)

また、メインスレッドで動作するなら nLoadCompleted を Interlocked する必要もないはずです。(メインスレッドしかアクセスしないことになりますので。)

あと、戻り値を受け取らない場合は EndInvoke() は不要なのでしたっけ?


……とまあこの辺りが気になりました。

見当違いなら済みません。

2012-04-10 00:31 更新者: yyagi
コメント

失礼しました。先ほど#28021のbranchを作成した上で、trunkをrev350にロールバックしました。(=trunk嬢での#28021の修正取り消し)

2012-04-10 01:01 更新者: yyagi
コメント

BMPの読み込み部分で、foreach でほぼ一斉に LoadTexture() を呼び出して個々にファイルを読み込み、終わったスレッドからコールバックの BMPLoadCallback() でテクスチャを作成する、といった設計に見えました。あってるでしょうか。

はい。合ってます。スレッドプールにつっこめるだけつっこんで、後はOSにお任せです。でもこれだとXPでは性能がイマイチでした。(Win7だとスレッド数を自前で制限するよりこのやり方の方が性能が出ました。) ぼちぼち対策しておきます。

もしあってるなら、BMPLoadCallback() は複数のスレッドから同時に呼ばれる可能性があります。

(以下略) 確かにメインスレッドの方はコールバックの終了待ちをしているだけですからね。 何を寝ぼけていたのだ私は。一晩寝てからチェックしないとダメですね。

読み込み終了のコールバックでは、cbmpと読み込んだデータをキューにつっこむだけにして、メインスレッド側でそいつを受け取ってOnDeviceCreated()するようにします。

あと、戻り値を受け取らない場合は EndInvoke() は不要なのでしたっけ?

はい。不要です。EndInvoke()することで、スレッドの終了待ち(ブロック動作)になりますが、EndInvoke()なしでもメインスレッド/バックグラウンドスレッド共に破綻はないです。

でも今回の件に関しては、コールバック内々で戻り値をもらうためにEndInvoke()してたと思いますよ。

# VS2010に移行しちゃいますか?ウチでは特に問題なくVS2010にプロジェクトを変換・ビルドできてます。(rev335が該当。)

2012-04-10 07:22 更新者: from
コメント

あともう一つだけ、スレッドの終了待ちですが、Sleep での定期ポーリング(Pull)よりは、全スレッドに Event を持たせて WaitAll() する方(Push)が リソースの無駄がなくていいと思いますがいかがでしょう。StrokeStyle<T> の3スレッド制御はその方式です。


# VS2010に移行しちゃいますか?ウチでは特に問題なくVS2010にプロジェクトを変換・ビルドできてます。(rev335が該当。)

VS2010 に移行するということは .NET 4 ClientProfile に移行するということなので、SlimDX なども .NET 4 版でビルドしないといけませんね。

(各 .proj を手動で書き換えれば 2010 でも .NET 4 以前での開発もできるようですが。)

DTXMania の場合、XP を切り離すタイミングでいいのではないでしょうか?


あと、どうも VC# 2008 をすっとばして 2010 だけをインストールすると、古い .sln をクリックしても無反応になる上に、ビルドしようとすると .NET 2.0 がないだとかおかしなこと言ってきます。バージョンセレクタがなんかおかしいみたいです。

クリーンインストールしてるので環境の問題とは思えないのですが……、前者の問題は明らかに環境依存でしょうねー。(涙

2012-04-10 07:30 更新者: from
コメント

まーた書き忘れた。

nLoadCompleted を interlocked するなら、メインスレッド側の while の中の nLoadCompleted も排他しとかないとまずいと思いますよ。

2012-04-16 00:19 更新者: yyagi
コメント

仕事がテンパって来てこっちになかなか時間を割けない今日この頃ですが・・・

VS2010 に移行するということは .NET 4 ClientProfile に移行するということなので、SlimDX なども .NET 4 版でビルドしないといけませんね。

SlimDX共々、.NET4(ClientProfile)でビルドできるプロジェクトファイルを build 358 でbranchにコミットしておきました。 (ただしウチの署名鍵を組み込む設定になっているので、そこだけは各自設定を変更下さい)

読み込み高速化の話はまだ修正未着手なので、後日改めて。

2012-04-17 02:31 更新者: yyagi
コメント

テクスチャ定義をメインスレッドで実行しなきゃならんということで、今日は2スレッド構成にしてみました。

  • バックグラウンドスレッド:列挙したファイルを1つずつひたすら読み込んでは、キューに突っ込む
  • メインスレッド:ひたすらキューからCBMPを拾っては、CTexture()する

これで正常に動作することは確認したのですが・・・シングルスレッドとほとんど大差ない処理時間に。

調べてみると、278x355なpng画像でのCTexture()実行に1回あたり10ms以上掛かっていて、これがボトルネックになっている様子。 ファイルアクセスの時間は(OSのファイルキャッシュにヒットすれば)1ファイルあたり1ms程度だったので、 確かにこれではシングルスレッドでの実行結果とほとんど大差ありません。

また、テクスチャ定義にこれくらいの時間が掛かるようだと、確かに演奏中のテクスチャ定義はかなり無謀ってことになりますね。

次はpngデコードの別スレッド化に挑戦してみます。( CTexture() にはraw画像を渡す。) 同じpng画像をnew Bitmap("foo.png")したときの実行時間は大体4~6msだと測定できているので、これで2倍程度の高速化になる腹づもりです。

2012-04-17 07:28 更新者: from
コメント

お疲れ様ッス。

ソースがアップされてないのでエスパーにチャレンジしてみますが、原因はたぶん、メインスレッドが複数同時に走ってる(かのように見える)か、VSync ON になっているかだと思います。

前者は、Game クラスが Application.Idle イベントをトリガにして回っていることに原因があります。

通常、コモンダイアログなどの STA コンポーネントをモーダルで使うと、メインスレッドはダイアログの実行に注力するので、ダイアログが閉じるまで呼び出し側は動かないことになります。しかし、ダイアログに移ったメインスレッドは、そちらでイベント待ちに入ります。そこで Idle イベントが発生してしまいます。すると、何とメインスレッドが、モーダルダイアログの表示中であるにもかかわらず、Application.Idle に登録された関数の実行を始めてしまうのです。

結果として、今回のケースでは、キューの入力を待ち始めた瞬間に Idle イベントが発生し、キュー待ちのはずなのにメインループ(Direct3DDevice9 の操作を含む)が回っているのではないでしょうか?その場合、当然メインループが一巡しないとキュー待ちには処理が返ってきません。処理の遅いPCではさら最悪なことに、メインループ中のメッセージ待ち関数でまた Idle が発生することになります。こうなったらゆくゆくはスタックオーバーフローですね。

それだけでも十分ネックですが、さらにその際、VSync が ON になっていると、当然 Present() した瞬間に最大 16.7 ミリ秒のブロックが発生します。ちなみに Present() では本当にスレッドがブロックされる(というか、実は中ではアイドリングしてない)ので、Idle イベントは発生しません。

今回のケースに当てはまってるかどうかは分かりませんが、ご参考になれば。

2012-04-17 07:38 更新者: from
コメント

失礼、メッセージループとPresentの件は誤ってますね。

今回のケースにはあてはまらないだろうし、忘れて下さい。(汗

2012-04-18 00:25 更新者: yyagi
コメント

メインスレッドが複数同時に走ってる(かのように見える)か、

いやぁこれはさすがにないでしょうと思いながらも、ドキドキしながらThread.CurrentThread.ManagedThreadIdを確認しました。その結果、ちゃんと別IDでした。

VSync ON になっているかだと思います。

これは一応昨晩チェックしていて、ON/OFF両方確認しましたが結果は変わらずでした。

まだまだへっぽこですが、ソースをコミットしました。管理の都合上、更新のあったファイルを全て突っ込んでますが、今回の話はまだCDTX.cs内で直接全部やってます。

今日はもう寝ます・・・pngデコード部の分離はまた後日。

2012-04-23 00:53 更新者: yyagi
コメント

今までのシングルスレッドでのテクスチャ定義時間を測定してみましたが、(278x355の画像をテクスチャに転送する事例で) やはり十数msかかってますね。

ちとまじめにpng/jpegデコードの分離を考えます。

2012-04-24 01:03 更新者: yyagi
コメント

試しに、rev366で、#BMPなテクスチャ画像のデコードを、テクスチャ定義スレッドとは別のスレッド(ファイル読み出しスレッド)で行うよう修正してみたところ、テクスチャ定義時間が(先の278x355の事例で)5ms程度になり、結果テクスチャ定義時間が半分以下になりました。

# 注: まだ清書してないです

ただ、Texture()なオーバーロードにはcolorKeyを指定できるものが無く、今のところ黒抜きができなくなってます。おかげで、おばたけのBGAが悲惨なことに。またおばたけか。

自前で黒を透明色に置換するしかないか・・・。

2012-04-24 01:14 更新者: from
コメント

お疲れ様です。

自前で黒を透明色に置換するしかないか・・・

もはや、スレッドのオーバーヘッドや上記のような補助処理のために、シングルコアだと逆に重たくなってしまうのでは・・・(汗

2012-04-24 01:33 更新者: yyagi
コメント

Bitmapクラスのメソッドにしれっと MakeTransparent(Color) なんてものがあったので、サクッと使ってみたところあっさり黒透過できました。

ウチの4core CPUの場合ですと、これを加えたことによる速度ダウンは1割程度でした。ですがトータルではまだ従来比2倍強の性能を維持してます。

おっしゃる通り、シングルコア(かつXP)での性能劣化は確かに心配ですね。明日(ってもう今日ですね)にでも確認してみます。

なお、念のために、この機能はCONFIGでON/OFFできるようにしてあります(笑)

2012-04-24 23:34 更新者: yyagi
コメント

もはや、スレッドのオーバーヘッドや上記のような補助処理のために、シングルコアだと逆に重たくなってしまうのでは・・・(汗

計ってみました。ベンチマーク対象データは、チップ音/BGAが共にたっぷりある、DMPお試し版の信心ワールドエンド(Ext)です。

シングルコアだと、本当に重たくなっちゃってるよ!(汗;;;;)

Win7-4core (2.3GHz HT無)DTX読込パースチップ音読込BMP読込その他諸々合計
1回目 0.17s 4.49s 7.60s 13.17s
2回目 0.14s 2.05s 2.35s 4.78s
高速化OFF(092 2回目)1.5s 6.36s 4.86s 12.94s
XP-1core(2.0GHz HT無)DTX読込パースチップ音読込BMP読込その他諸々合計
1回目 0.28s 7.35s 7.25s 15.23s
2回目 0.17s 5.09s 6.98s 12.44s
高速化OFF(092 2回目)1.7s 5.53s 5.74s 13.25s

シングルコアの問題なのか、それとも(無いとは思いますが)XPの問題なのか、切り分けたいところです。 XPのデュアルコア環境で測定すればいいんですが、ウチのデュアルコア環境はXPをインストールできないマザーばかりで・・・(泣;;;

お暇な方がいらしたら、これでお試しいただけるとありがたいです。 tp://yyagi.com/DTXMania093_28021test.zip (注) 初期設定では高速化OFFです。CONFIG/Systemに、WAVとBMPの高速化設定があります。 また、WAVの高速化の副作用で音が出なくなることがあります。そうなったらアプリを再起動して下さい。

2012-04-24 23:44 更新者: from
コメント

うちのドラム用PCは2コアのXPだから試そうとしたけど、yyagi.com が存在しないとか言われた・・・・

2012-04-24 23:54 更新者: yyagi
コメント
(このコメントは削除されました)
2012-04-24 23:55 更新者: yyagi
コメント

最近調子悪いな・・・>宅外向けサーバ

一応DDNSの再登録と、Apacheの再起動をカマしておきました。 なお現時点でのIPアドレスは59.147.149.3です。

それと書き忘れましたが、BMP読み込みに掛かる時間などのデータは、DTXManiaLog.txtに出ます。

2012-04-25 00:18 更新者: from
コメント

一瞬、私の書き込みが黙殺されたのかと思った。(汗

というわけで、実行結果です。(なお、ストレージはSSDです。)

XP-2core(2.2GHz,HT無)DTX読込パースチップ音読込BMP読込みその他諸々合計
1回目0.171s3.33s4.16s7.89s
2回目0.125s3.11s4.16s7.58s
高速化OFF(092 2回目)0.125s5.23s5.34s10.9s

ちゃんと高速化の効果は出ているようですね。

ということは、やっぱりシングルコアのオーバーヘッドの疑いが・・・・

2012-04-25 00:29 更新者: yyagi
コメント

テストいただきありがとうございました。XPでも2coreだと高速化の効果が少しは出るようですね。(でもやはりXPだと2coreでもBMP読込が爆速にはならないのね・・・)

それでは明晩、BMP読み込みの処理を、コア数によって振り分けるようにします。

それにしても、SSDはやっぱし速いんですね。参考までに、ウチの高速化OFFの1回目はこうです。遅すぎ。(だからこそ高速化しようという気になるんですけれどもね)

Win7-4core (2.3GHz HT無)DTX読込パースチップ音読込BMP読込その他諸々合計
高速化OFF(1回目) 0.19s 12.83s 11.99s 26.56s
2012-04-26 01:00 更新者: yyagi
コメント

CPUコア数に応じたBMP/BMPTEX読み込みの処理振り分けを実装し、1coreと4coreのCPU動作確認しました。(→問題なし→branchにコミット済)

また、ここしばらくこれらの動作を見ていて全く問題が出ていませんので、これらのロジックをtrunkに取り込みました。

チップ音の読み込み高速化はtrunkに入れてません。これを入れるとギター曲の読み込みが超速くなるんですが、一方で読み込み失敗もそれなりの頻度で出ますので。SoundDecoder.dllを作り直す時に再検討します。

2012-04-28 19:16 更新者: yyagi
  • チケット完了時刻2012-04-28 19:16 に更新されました
  • 状況オープン から 完了 に更新されました
  • 解決法なし から 受領 に更新されました
コメント

サウンドの読み込み高速化は現状困難ですが、BMP/BMPTEXの読み込み高速化ならびにDTXパースの高速化は実現済みのため、本チケットは一旦クローズいたします。

サウンドの読み込み高速化については、SoundDecoder.dllを作り直した際に再度検討します。

2013-03-01 01:47 更新者: None
コメント

tp://yyagi.com/DTXManiaGR_096_fastload_20130228.zip (096に上書きして下さい)

そういえばBASSを使っているときは別スレッドでサウンドファイルを開いてもオッケーだよねということで、 昔作ったマルチスレッドなチップ音読み込みコードを性懲りもなく適用してみました。

その結果・・・爆速です! これこれ、これだよ!

例によってDMPの信心ワールドエンド(Ext)で時間測定してみました。 以下DTXManiaLog.txtからの抜粋ですが、ウチではこんな感じです。(Win7-4core 2.3GHzにて。HDDキャッシュがヒットする2回目の測定にて。)

DTX読込所要時間:           00:00:00.1180067
WAV読込所要時間( 709):     00:00:00.4110235
WAV/譜面後処理時間( 418):  00:00:01.3130751
BMP/AVI読込所要時間( 418): 00:00:02.2541290
総読込時間:                00:00:04.1032347

ちなみに、高速化前(素の096)だとこんな感じでした。測定条件は上と同じ。

DTX読込所要時間:           00:00:00.1120064
WAV読込所要時間( 709):     00:00:04.0252303
WAV/譜面後処理時間( 418):  00:00:01.3430768
BMP/AVI読込所要時間( 418): 00:00:02.4051376
総読込時間:                00:00:07.8874512

ぬー、このレベルになると、譜面後処理時間(1.3s)を削りたくなるな・・・。

ただ、まだ「とりあえず昔のコードをくっつけてみただけ」なので、色々制限があります。あしからず。

  • WASAPI/ASIO時のみ効果有り。DirectSound時は効果無し、というかDirectSoundで動かすと、ガード処理をまだ入れていないので誤動作する。
  • 暫定的にPolyphonicSounds=1相当の動作になる。
  • NowLoading画面でのチップファイル名表示を削除しました。(十分に読み込みが速くなった&下手に表示を増やすとかえって読み込みが遅くなるので。このあたりを両立できるようなら復活させます)
2013-03-01 01:48 更新者: yyagi
  • 状況完了 から オープン に更新されました
2013-03-01 10:47 更新者: sf298yen
コメント

お疲れさまです、やぎ。様が燃えていらっしゃる(笑

Win7でテストすべきかもしれませんが、とりあえずXP+ASIOで試してみました。結果約7秒→4秒と快速になっていますね!

ただ、気になるのは同じファイルを読んでいるはずなのにエラーが大量に(苦笑; やはりWin7でテストしないとダメかな

Env : XP SP3 Core2 Quad @6600 @2.40GHz

XP : DTXManiaGR_096_timestretch_20130225 / TimeStretch=OFF / ASIO(3ms)

2013/03/01 10:32:23.537 [INFO] ----曲情報-----------------
2013/03/01 10:32:23.537 [INFO] TITLE: 信心ワールドエンド
2013/03/01 10:32:23.537 [INFO] ---------------------------
2013/03/01 10:32:23.537 [INFO] DTX読込所要時間:           00:00:00.0780715
2013/03/01 10:32:26.706 [INFO] WAV読込所要時間( 716):     00:00:03.1697029
2013/03/01 10:32:27.050 [INFO] WAV/譜面後処理時間( 418):  00:00:00.3435146
2013/03/01 10:32:30.219 [INFO] BMP/AVI読込所要時間( 418): 00:00:03.1697029
2013/03/01 10:32:30.219 [INFO] 総読込時間:                00:00:06.7609919
2013/03/01 10:32:30.719 [INFO] ----------------------

XP : DTXManiaGR_096_fastload_20130228 / ASIO(3ms)

2013/03/01 10:36:47.582 [INFO] ----曲情報-----------------
2013/03/01 10:36:47.582 [INFO] TITLE: 信心ワールドエンド
2013/03/01 10:36:47.582 [INFO] ---------------------------
2013/03/01 10:36:47.582 [INFO] DTX読込所要時間:           00:00:00.0937080
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_02.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_01.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_03.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_04.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_05.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\vo_06.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドの作成に失敗しました。()(C:\dtx\dtx\dtx_mdata\music\DTXFiles\DTXmania Original Package MUSIC PARADISE\02_STANDARD\2851_worldend_dtx\out.ogg)
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [ERROR] サウンドストリームの生成に失敗しました。(BASS_StreamCreateFile)[BASS_ERROR_FILEOPEN]
2013/03/01 10:36:47.988 [INFO] WAV読込所要時間( 716):     00:00:00.4060680
2013/03/01 10:36:48.331 [INFO] WAV/譜面後処理時間( 418):  00:00:00.3435960
2013/03/01 10:36:51.517 [INFO] BMP/AVI読込所要時間( 418): 00:00:03.1860720
2013/03/01 10:36:51.517 [INFO] 総読込時間:                00:00:04.0294440
2013/03/01 10:36:52.017 [INFO] ----------------------

とりあえずレポートまで

2013-03-05 02:15 更新者: yyagi
コメント

ご報告ありがとうございます。こちらでもなにやらエラーが出ることがありましたので、この対応は棚上げにします。 (ただ、こちら(Win7 x64 WASAPI)では、ファイルオープンのエラーではなく、メモリ破壊云々のエラーになるようですが・・・)

仕事が立て込んできたので、しばらく更新ができなくなると思います。すみません。

2013-03-07 11:31 更新者: sf298yen
コメント

車検って高いよね...orz

お疲れ様です。お仕事大変でしょうが、体調に気をつけてくださいませ。

(うちの会社では、たまたま一斉に体調不良で休まれてしまいフォローが大変なこと大変なこと・・・ブチブチ)

非常に興味のある内容ですので、落ち着きまして、気が向いたら是非対応をお願いしたいです。

添付ファイルリスト

添付ファイルはありません

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする