ギター曲の読み込みが遅い
tp://yyagi.com/DTXMania_28021_20120405.zip
試しに1.のアイデアだけを実装してみたところ、演奏開始までの待ち時間が半分くらいに短縮された。しかし、何度かやっているとデコード失敗エラーになるチップ音が出てきてしまう。
んー、どこかに排他制御が必要なのかな。SoundDecoder.dllへのアクセスを少しずつlock()してみる予定。
一度この爆速・気持ちよさを味わってしまうと、もう昔には戻れない。がんばって調査せねば・・・
少なくとも oggOpen(), oggGetFormat(), oggClose() で AccessViolataionException が発生することを確認。
とはいえ、CSSoundOggVorbisクラスへのアクセスをクリティカルセクションにしてしまうのでは、全くといっていいほど高速化にならないわけで・・・困った。やはり SoundDecoder.dll をイチから作り直すしかないのか。
from SoundDecoder.dll はスレッドセーフじゃないですよー（涙
さらに言えば、ACM 関数もスレッドセーフじゃないのでこちらも要注意です。（←おそらく致命的？）
音声でも動画でも、コーデックをスレッドセーフかつ非同期に扱えるのは、今のところ DirectShow か Media Foundation しかないと思いますよ。
SoundDecoder.dll はスレッドセーフじゃないですよー（涙 さらに言えば、ACM 関数もスレッドセーフじゃないのでこちらも要注意です。（←おそらく致命的？）
ぐはぁ！ (情報ありがとうございます。まあ、実装前にまず調べろよって話ですが・・・。)
ACMがスレッドセーフじゃないと言うことは、3.のやり方もNGとなります(BGMのストリーム再生とかち合うはず)ので、素直にあきらめます。今回実装したロジックはBGAの読み込みにでも流用しておきます。(おばたけの読み込みが高速化されるな(笑))
一方、今回無理矢理マルチスレッド読み込みにしてみて分かったのは、 700個以上のギターサウンドファイルがある曲データのサウンド読み込み時間がウチの環境(AMD 2.3GHz 4コア)では1秒以下になること。 OSのファイルキャッシュにチップ音ファイルが収まっている前提ではありますが、これは気持ちよすぎです。
この気持ちよさをきちんと実現するために、WASAPIやMedia Foundationに移行したいのは山々ですが、FROMさんもよくご存知の通り、XPがー。旧曲データとの発音タイミングの互換性がー。
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 と決別します。
from 補足です。
Direct3D9 Device は、スレッドセーフではないとかいう条件よりもっとひどい状況で、「Multithreaded を付けない場合は、Device を生成したスレッドでなければ Device 関連のリソースにアクセスしてはならない」という決まりがあります。（実際はアクセスできるんですが、排他処理をしないので当然かち合ったらエラーになります。）
でもって、Direct3D9 Device にはウィンドウハンドルも渡しますので、「ウィンドウの操作はウィンドウを生成したスレッドでなければ行ってはならない」という条件も加わります。もう大変。
XP や Direct3D9 、VMR9 は、完全にシングルスレッド専用の設計ですね。
今回実装したロジックはBGAの読み込みにでも流用しておきます。(おばたけの読み込みが高速化されるな(笑))
Direct3D9 Device も実はスレッドセーフではないので要注意ですよ。
いえ、NowLoading画面でのまとめ読込を高速化する話なので、特に問題ないかと。
(よく考えてみれば、従来バージョンでも、NowLoading画面でストリーム再生を使うような長いサウンドを使用すると、他のチップ音読み込みとでACM使用がかち合ってアウトですね・・・)
それと、サウンドの読み込み高速化は、やっぱり捨てるのが惜しいので(笑)、排他問題に絡む例外が出たら安直にちょっと待ってからリトライするようにしてみます。
MediaFoundation等への移行については、過去資産が最大ネックであるものの、しかし結局は移行を後に延ばせば延ばすだけ過去資産が増えるという矛盾が。なのでいっそ過去資産は無視して、適切なタイミングで移行するのがよいのかなと思うようになりました。XPのサポートが切れるタイミングあたりが切り替えには妥当かなと。
from Direct3D9 Device も実はスレッドセーフではないので要注意ですよ。
いえ、NowLoading画面でのまとめ読込を高速化する話なので、特に問題ないかと。
ああ、演奏画面でないならガタつきの件は関係無いですね。
でも NowLoading画面での BGA 処理はひたすら画像を Direct3D9 テクスチャに読み込むわけですから、そこを並列化するならそこで Direct3D9 デバイスの排他処理が必要かと。（SlimDX が内部でテクスチャ読み込みに使ってる d3dx ライブラリもスレッドセーフじゃないです。）
なのでいっそ過去資産は無視して、適切なタイミングで移行するのがよいのかなと思うようになりました。XPのサポートが切れるタイミングあたりが切り替えには妥当かなと。
某法則に従うなら、Windows8 が不評でコケて Windows9 が発表されてるころですね（笑
過去資産を無視する前提なら、切替は今でもいいのでは？ XPユーザ重視？
p.s.
Microsoft の登録キーメールに登録キーが含まれてなかったおかげで、VC#2008 が最大30日しか起動できなくなりました。
……どうしよう（汗
でも 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
from あれっ。branches へのコミットかと思いきや、trunk へのマージなのですね。
実験ソースを trunk に入れてしまうのはどうかと思いますが……
とりあえずダウンロードしてみますね。
VC# 2008 ないけど。（汗
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() は不要なのでしたっけ？
……とまあこの辺りが気になりました。
見当違いなら済みません。
BMPの読み込み部分で、foreach でほぼ一斉に LoadTexture() を呼び出して個々にファイルを読み込み、終わったスレッドからコールバックの BMPLoadCallback() でテクスチャを作成する、といった設計に見えました。あってるでしょうか。
はい。合ってます。スレッドプールにつっこめるだけつっこんで、後はOSにお任せです。でもこれだとXPでは性能がイマイチでした。(Win7だとスレッド数を自前で制限するよりこのやり方の方が性能が出ました。) ぼちぼち対策しておきます。
もしあってるなら、BMPLoadCallback() は複数のスレッドから同時に呼ばれる可能性があります。
(以下略) 確かにメインスレッドの方はコールバックの終了待ちをしているだけですからね。 何を寝ぼけていたのだ私は。一晩寝てからチェックしないとダメですね。
読み込み終了のコールバックでは、cbmpと読み込んだデータをキューにつっこむだけにして、メインスレッド側でそいつを受け取ってOnDeviceCreated()するようにします。
あと、戻り値を受け取らない場合は EndInvoke() は不要なのでしたっけ？
はい。不要です。EndInvoke()することで、スレッドの終了待ち(ブロック動作)になりますが、EndInvoke()なしでもメインスレッド/バックグラウンドスレッド共に破綻はないです。
でも今回の件に関しては、コールバック内々で戻り値をもらうためにEndInvoke()してたと思いますよ。
# VS2010に移行しちゃいますか？ウチでは特に問題なくVS2010にプロジェクトを変換・ビルドできてます。(rev335が該当。)
from あともう一つだけ、スレッドの終了待ちですが、Sleep での定期ポーリング（Pull）よりは、全スレッドに Event を持たせて WaitAll() する方（Push）が リソースの無駄がなくていいと思いますがいかがでしょう。StrokeStyle<T> の３スレッド制御はその方式です。
# VS2010に移行しちゃいますか？ウチでは特に問題なくVS2010にプロジェクトを変換・ビルドできてます。(rev335が該当。)
VS2010 に移行するということは .NET 4 ClientProfile に移行するということなので、SlimDX なども .NET 4 版でビルドしないといけませんね。
（各 .proj を手動で書き換えれば 2010 でも .NET 4 以前での開発もできるようですが。）
DTXMania の場合、XP を切り離すタイミングでいいのではないでしょうか？
あと、どうも VC# 2008 をすっとばして 2010 だけをインストールすると、古い .sln をクリックしても無反応になる上に、ビルドしようとすると .NET 2.0 がないだとかおかしなこと言ってきます。バージョンセレクタがなんかおかしいみたいです。
クリーンインストールしてるので環境の問題とは思えないのですが……、前者の問題は明らかに環境依存でしょうねー。（涙
from まーた書き忘れた。
nLoadCompleted を interlocked するなら、メインスレッド側の while の中の nLoadCompleted も排他しとかないとまずいと思いますよ。
仕事がテンパって来てこっちになかなか時間を割けない今日この頃ですが・・・
VS2010 に移行するということは .NET 4 ClientProfile に移行するということなので、SlimDX なども .NET 4 版でビルドしないといけませんね。
SlimDX共々、.NET4(ClientProfile)でビルドできるプロジェクトファイルを build 358 でbranchにコミットしておきました。 (ただしウチの署名鍵を組み込む設定になっているので、そこだけは各自設定を変更下さい)
読み込み高速化の話はまだ修正未着手なので、後日改めて。
テクスチャ定義をメインスレッドで実行しなきゃならんということで、今日は2スレッド構成にしてみました。
これで正常に動作することは確認したのですが・・・シングルスレッドとほとんど大差ない処理時間に。
調べてみると、278x355なpng画像でのCTexture()実行に1回あたり10ms以上掛かっていて、これがボトルネックになっている様子。 ファイルアクセスの時間は(OSのファイルキャッシュにヒットすれば)1ファイルあたり1ms程度だったので、 確かにこれではシングルスレッドでの実行結果とほとんど大差ありません。
また、テクスチャ定義にこれくらいの時間が掛かるようだと、確かに演奏中のテクスチャ定義はかなり無謀ってことになりますね。
次はpngデコードの別スレッド化に挑戦してみます。( CTexture() にはraw画像を渡す。) 同じpng画像をnew Bitmap("foo.png")したときの実行時間は大体4～6msだと測定できているので、これで2倍程度の高速化になる腹づもりです。
from お疲れ様ッス。
ソースがアップされてないのでエスパーにチャレンジしてみますが、原因はたぶん、メインスレッドが複数同時に走ってる（かのように見える）か、VSync ON になっているかだと思います。
前者は、Game クラスが Application.Idle イベントをトリガにして回っていることに原因があります。
通常、コモンダイアログなどの STA コンポーネントをモーダルで使うと、メインスレッドはダイアログの実行に注力するので、ダイアログが閉じるまで呼び出し側は動かないことになります。しかし、ダイアログに移ったメインスレッドは、そちらでイベント待ちに入ります。そこで Idle イベントが発生してしまいます。すると、何とメインスレッドが、モーダルダイアログの表示中であるにもかかわらず、Application.Idle に登録された関数の実行を始めてしまうのです。
結果として、今回のケースでは、キューの入力を待ち始めた瞬間に Idle イベントが発生し、キュー待ちのはずなのにメインループ（Direct3DDevice9 の操作を含む）が回っているのではないでしょうか？その場合、当然メインループが一巡しないとキュー待ちには処理が返ってきません。処理の遅いPCではさら最悪なことに、メインループ中のメッセージ待ち関数でまた Idle が発生することになります。こうなったらゆくゆくはスタックオーバーフローですね。
それだけでも十分ネックですが、さらにその際、VSync が ON になっていると、当然 Present() した瞬間に最大 16.7 ミリ秒のブロックが発生します。ちなみに Present() では本当にスレッドがブロックされる（というか、実は中ではアイドリングしてない）ので、Idle イベントは発生しません。
今回のケースに当てはまってるかどうかは分かりませんが、ご参考になれば。
from 失礼、メッセージループとPresentの件は誤ってますね。
今回のケースにはあてはまらないだろうし、忘れて下さい。（汗
メインスレッドが複数同時に走ってる（かのように見える）か、
いやぁこれはさすがにないでしょうと思いながらも、ドキドキしながらThread.CurrentThread.ManagedThreadIdを確認しました。その結果、ちゃんと別IDでした。
VSync ON になっているかだと思います。
これは一応昨晩チェックしていて、ON/OFF両方確認しましたが結果は変わらずでした。
まだまだへっぽこですが、ソースをコミットしました。管理の都合上、更新のあったファイルを全て突っ込んでますが、今回の話はまだCDTX.cs内で直接全部やってます。
今日はもう寝ます・・・pngデコード部の分離はまた後日。
今までのシングルスレッドでのテクスチャ定義時間を測定してみましたが、(278x355の画像をテクスチャに転送する事例で) やはり十数msかかってますね。
ちとまじめにpng/jpegデコードの分離を考えます。
試しに、rev366で、#BMPなテクスチャ画像のデコードを、テクスチャ定義スレッドとは別のスレッド(ファイル読み出しスレッド)で行うよう修正してみたところ、テクスチャ定義時間が(先の278x355の事例で)5ms程度になり、結果テクスチャ定義時間が半分以下になりました。
# 注: まだ清書してないです
ただ、Texture()なオーバーロードにはcolorKeyを指定できるものが無く、今のところ黒抜きができなくなってます。おかげで、おばたけのBGAが悲惨なことに。またおばたけか。
自前で黒を透明色に置換するしかないか・・・。
from お疲れ様です。
自前で黒を透明色に置換するしかないか・・・
もはや、スレッドのオーバーヘッドや上記のような補助処理のために、シングルコアだと逆に重たくなってしまうのでは・・・（汗
Bitmapクラスのメソッドにしれっと MakeTransparent(Color) なんてものがあったので、サクッと使ってみたところあっさり黒透過できました。
ウチの4core CPUの場合ですと、これを加えたことによる速度ダウンは1割程度でした。ですがトータルではまだ従来比2倍強の性能を維持してます。
おっしゃる通り、シングルコア(かつXP)での性能劣化は確かに心配ですね。明日(ってもう今日ですね)にでも確認してみます。
なお、念のために、この機能はCONFIGでON/OFFできるようにしてあります(笑)
もはや、スレッドのオーバーヘッドや上記のような補助処理のために、シングルコアだと逆に重たくなってしまうのでは・・・（汗
計ってみました。ベンチマーク対象データは、チップ音/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の高速化の副作用で音が出なくなることがあります。そうなったらアプリを再起動して下さい。
from うちのドラム用PCは2コアのXPだから試そうとしたけど、yyagi.com が存在しないとか言われた・・・・
最近調子悪いな・・・＞宅外向けサーバ
一応DDNSの再登録と、Apacheの再起動をカマしておきました。 なお現時点でのIPアドレスは59.147.149.3です。
それと書き忘れましたが、BMP読み込みに掛かる時間などのデータは、DTXManiaLog.txtに出ます。
from 一瞬、私の書き込みが黙殺されたのかと思った。（汗
というわけで、実行結果です。（なお、ストレージはSSDです。）
| XP-2core(2.2GHz,HT無) | DTX読込パース | チップ音読込 | BMP読込み | その他諸々合計 |
| 1回目 | 0.171s | 3.33s | 4.16s | 7.89s |
| 2回目 | 0.125s | 3.11s | 4.16s | 7.58s |
| 高速化OFF(092 2回目) | 0.125s | 5.23s | 5.34s | 10.9s |
ちゃんと高速化の効果は出ているようですね。
ということは、やっぱりシングルコアのオーバーヘッドの疑いが・・・・
テストいただきありがとうございました。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 |
CPUコア数に応じたBMP/BMPTEX読み込みの処理振り分けを実装し、1coreと4coreのCPU動作確認しました。(→問題なし→branchにコミット済)
また、ここしばらくこれらの動作を見ていて全く問題が出ていませんので、これらのロジックをtrunkに取り込みました。
チップ音の読み込み高速化はtrunkに入れてません。これを入れるとギター曲の読み込みが超速くなるんですが、一方で読み込み失敗もそれなりの頻度で出ますので。SoundDecoder.dllを作り直す時に再検討します。
サウンドの読み込み高速化は現状困難ですが、BMP/BMPTEXの読み込み高速化ならびにDTXパースの高速化は実現済みのため、本チケットは一旦クローズいたします。
サウンドの読み込み高速化については、SoundDecoder.dllを作り直した際に再度検討します。
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)を削りたくなるな・・・。
ただ、まだ「とりあえず昔のコードをくっつけてみただけ」なので、色々制限があります。あしからず。
sf298yen お疲れさまです、やぎ。様が燃えていらっしゃる（笑
Win7でテストすべきかもしれませんが、とりあえずXP+ASIOで試してみました。結果約７秒→４秒と快速になっていますね！
ただ、気になるのは同じファイルを読んでいるはずなのにエラーが大量に（苦笑; やはり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] ----------------------
とりあえずレポートまで
ご報告ありがとうございます。こちらでもなにやらエラーが出ることがありましたので、この対応は棚上げにします。 (ただ、こちら(Win7 x64 WASAPI)では、ファイルオープンのエラーではなく、メモリ破壊云々のエラーになるようですが・・・)
仕事が立て込んできたので、しばらく更新ができなくなると思います。すみません。
sf298yen 車検って高いよね...orz
お疲れ様です。お仕事大変でしょうが、体調に気をつけてくださいませ。
（うちの会社では、たまたま一斉に体調不良で休まれてしまいフォローが大変なこと大変なこと･･･ﾌﾞﾁﾌﾞﾁ）
非常に興味のある内容ですので、落ち着きまして、気が向いたら是非対応をお願いしたいです。
Fork
ギターなど、チップ音が非常に多い曲データの場合、演奏開始の読み込みに非常に時間が掛かる。(経験的に、10～30秒くらいかかっている？)
これを何とか3～5秒程度に短縮できないものか。
高速化のアイデア: