チケット #28914

Win7での反応遅延

登録: 2012-07-05 01:11 最終更新: 2013-04-10 00:13

報告者:
担当者:
(未割り当て)
チケットの種類:
状況:
完了
コンポーネント:
マイルストーン:
優先度:
5 - 中
重要度:
5 - 中
解決法:
受領
ファイル:
1
投票
点数: 0
No votes
0.0% (0/0)
0.0% (0/0)

詳細

WinXPとWin7の双方でDTXManiaを動かすと、Win7の方が反応が鈍く、 キー入力してからチップ音が再生されるまでのラグが長い。

以下の環境で検証予定。

MB: SAPPHIRE PURE FUSION MINI E350
APU: E350 (1.6GHz, DualCore)
GA: RADEON HD6310 (チップセット内蔵)
サウンド: チップセット内蔵 (Realtekのチップも載っているが、HDMI接続時はこっちが使われるみたい)
メモリ: 4GBx2
モニタ: MITSUBISHI MDT242WG (1920x1200, HDMI接続)
キーボードとマウス: 安物を適当にUSB接続 (OS標準のHIDドライバを使用)
ここにHDDを2台用意して、XPSP3(x86)とWin7SP1(x64)を導入。ドライバ類は各々のOS用に最新のものを適用した。 この2つのHDDをとっかえひっかえして、動作確認する。

実際の遅延は、キー入力してから最終的に絵や音が出るまでの間に

(キーボード入力) =a=> (OSが入力受理) =b=> (FDKが入力受理) =c=> (DTXManiaが入力受理)
(以下dとgに分岐)
=d=> (OSにサウンド再生指示) =e=> (チップがサウンド再生) =f=> (モニタやスピーカーがサウンド出力)
=g=> (OSに描画指示)         =h=> (グラフチップが描画)   =i=> (モニタが描画出力)

というステップをたどると仮定して、 a~iそれぞれの間でどのくらいの遅延が発生しているかを何とか測定できないか考察する。

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

2012-07-05 01:11 更新者: yyagi
  • 新しいチケット "Win7での反応遅延" が作成されました
2012-07-05 02:05 更新者: yyagi
コメント

一応XPとWin7とで動作確認する環境を合わせたかったので、まず下記のような環境を用意しました。

MB: SAPPHIRE PURE FUSION MINI E350
APU: E350 (1.6GHz, DualCore)
GA: RADEON HD6310 (チップセット内蔵)
サウンド: チップセット内蔵 (Realtekのチップも載っているが、HDMI接続時はこっちが使われるみたい)
メモリ: 4GBx2
モニタ: MITSUBISHI MDT242WG (1920x1200, HDMI接続)
キーボードとマウス: 安物を適当にUSB接続 (OS標準のHIDドライバを使用)

ここにHDDを2台用意して、XPSP3とWin7SP1を導入。ドライバ類は各々のOS用に最新のものを適用しました。 この2つのHDDをとっかえひっかえして、動作確認します。

で、遅延ですが、キー入力してから最終的に絵や音が出るまでの間に

(キーボード入力) =a=> (OSが入力受理) =b=> (FDKが入力受理) =c=> (DTXManiaが入力受理)
(以下dとgに分岐)
=d=> (OSにサウンド再生指示) =e=> (チップがサウンド再生) =f=> (モニタやスピーカーがサウンド出力)
=g=> (OSに描画指示)         =h=> (グラフチップが描画)   =i=> (モニタが描画出力)

というステップをたどるとして、 a~iそれぞれの間でどのくらいの遅延が発生しているかを何とか測定できないかと考えてみます。

2012-07-05 02:07 更新者: yyagi
  • 詳細が更新されました
コメント

aの測定方法: いきなり分かりませんw 飛ばします。

bの測定方法: 検証用のサンプルを作りました。 tp://yyagi.com/DTXManiaGR_CheckKBInputLag.zip

ShowTimingAboutHitSpaceKey.exeを実行すると、ウインドウが開きます。 これは全てのキー入力をフックして、その入力があった時刻だけを淡々と出力するアプリです。 (注: グローバルフックでキーを取ってきているだけです) これを(OSが入力受理した時刻)として、DTXManiaでの入力受理時刻と比較します。

ShowTime...のウインドウを開いたまま、上記のDTXManiaを開いて下さい。 タイトル画面でだけ、スペースを押すとDTXManiaLog.txtにその旨ログを残すようにしてあります。 スペースキーを何度か押してから、終了して下さい。 それと同時に、ShowTime...のウインドウにも入力時刻のログが出ていますので、 DTXMania本体の終了後、DTXManiaLog.txtとShowTime...のログで時刻比較して下さい。

2012-07-05 02:29 更新者: yyagi
コメント
(このコメントは削除されました)
2012-07-05 02:29 更新者: yyagi
  • 詳細が更新されました
2012-07-05 03:16 更新者: sf298yen
コメント
(このコメントは削除されました)
2012-07-05 13:45 更新者: from
コメント

検証お疲れ様です。

ニュートリノが光速を超えたかどうかちょっと気になるので、検証ツールのソースを公開いただけますか?

あと……、もし a~h がすべて 0 だったとしても、60Hz のモニタなら、i は(フレーム遅延 0 だとしても) 0~16.6666...ms のどれかになりますね。 a~i で 10ms を超えないようにするための、最大の敵はモニタ自身かもです。

2012-07-07 19:19 更新者: yyagi
  • 添付ファイル ShowTimingAboutHitSpaceKey2.zip (File ID: 4800) が付加されました
2012-07-07 19:21 更新者: yyagi
コメント

おかげさまで、ヒッグス粒子っぽいものは見つけることができましたよ。

  • 検証ツールでは時刻測定に DateTime クラスを使っているが、MSDN曰く精度が10~15ms

あぁぁ・・・。システム時刻をmsオーダーで簡単に取ってくるはどうしたものか。ちょっと考えてみます。 ソースコード(プロジェクト一式)も添付しておきました。

おっしゃる通り、どうがんばってもモニタの遅延は最後まで残るでしょうね。 その意味では、ノートPCのモニタが低遅延で良いのですが、環境アンケートを見る限りノートPC利用者は少ないようです。

2012-07-07 19:42 更新者: from
コメント

システム時刻をmsオーダーで簡単に取ってくるはどうしたものか。ちょっと考えてみます。

FDK の CTimer を使ってやって下さいよー。

HT, MMT, gtg のどれにも対応していますよ。

どうがんばってもモニタの遅延は最後まで残るでしょうね。

すみません、語弊がありました。

正しくは、モニタではなくてグラボの出す出力信号速度(リフレッシュレート)ですね。

モニタの応答速度が例え 0ms であっても、入力信号が 60Hz ならば必ず 1~16.6666..ms の遅延は発生します。

120Hz のモニタもありますが、それでも 1~ 8.3333...ms の遅延ですね。

リフレッシュレート1000Hz出せるグラボと、それに耐えうる品質のモニタケーブルが登場すれば問題解決なのですが。

2012-07-07 23:50 更新者: yyagi
  • 添付ファイル ShowTimingAboutHitSpaceKey2.zip (File ID: 4800) が削除されました
2012-07-07 23:50 更新者: yyagi
  • 添付ファイル ShowTimingAboutHitSpaceKey2.zip (File ID: 4801) が付加されました
2012-07-08 00:01 更新者: yyagi
コメント

FDKのCTimerを使うように変更しました。 tp://yyagi.com/DTXManiaGRCheckKBInputLag2.zip

プロジェクトファイルはこのチケットに添付し直しました。(時刻の後に出てくる数値の方を、単位msとして使って下さい)

また、c区間の測定を止め、b区間のみにしました。

これで計ってみると、

XPWin7
2212
53
89
611
115

1回目はいつも大きい値になるのでこれを除くと、XPとWin7とであまり大差ない結果になりました。 前回XPで15,6ms刻みの値になったのは、VSyncではなくて、システムタイマの割り込み間隔だったわけですね。納得です。

今回の測定ツール(とDTXMania本体)では、システムタイマの割り込み間隔を最小(1ms)にしています。 あわよくばこれで入力感度が上がっているといいなぁ。(多分変わらないと思いますが。)

2012-07-08 01:20 更新者: yyagi
  • 添付ファイル ShowTimingAboutHitSpaceKey2.zip (File ID: 4801) が削除されました
2012-07-10 03:06 更新者: sf298yen
コメント

DTXManiaGRCheckKBInputLag2.zipを使って再測定しました。

xpWin7
13 9
1310
711
411
12 6

キー入力に関しては差がほとんど認められないようなので影響はなさそうな気がします。
ちなみに私のWin7で使ってるディスプレイは3D Vision対応な為120Hz駆動が可能で、試しましたが…。
通常は3D滅多に使わないので60Hz駆動にしてます、なんとなく。

2012-07-11 23:21 更新者: sf298yen
コメント

具体的に測定する方法がさーぱりなので・・・

画像に関する測定…(悩
サウンドに関してはエフェクトなど、ディレイが発生すると思われる要素を全部オフにして
最短で出力するようにしてみたりしてるのですが改善する気配がありませんorz

使ってるカードは「Sound Blaster X-Fi XtremeGamer」なのですが、もしかして相性が悪いとかなのでしょうか

2012-07-23 22:49 更新者: yyagi
コメント

サウンド出力でラグを感じる方、他にもいらっしゃるみたいですね。(別の某所でも見かけました) しかしまずはそのラグをどう計ったものか。

以前nyaさんがなさっていたみたいに、MIDIドラムの音声出力と実際のサウンド出力を録音して時間差を求めるか、いっそPCキーボードを激しく打鍵してその環境音とサウンド出力の録音・時間差計測でもするか。

あと、サウンド出力の遅延と決めつけて、そこだけ遅延対策してみるとか。例えばSSTのモジュールを一部拝借して、ASIO /WASAPI対応版とか試しに作れないものかな。

2012-07-24 01:26 更新者: yyagi
コメント

自分のメインPC(Win7(x64))と、自分の耳で、ちょっと試してみた限りでは・・・

PCキーボード(PS/2)とMIDIキーボード(USB-MIDI接続; UX16; x64ドライバ経由での接続)経由の入力を試す限りでは、明らかにPCキーボードの方が大きなラグを感じました。どれくらいの時間差かは計ってないですけど、10ms以上の差は確実にあります。

しかしPCキーボードをUSBのやつに変えてみたところ、USB-MIDI経由と大差ないフィーリングになりました。接続方式の違いなのか、キーボードそのものの素性の違いなのか、何とも言えませんけれど。(同じキーボードでUSBとPS/2接続の両方を試せばいいんですが。)

サウンド出力遅延については、確かにXPとWin7を比べるとWin7の方が(同じPCキーボードを使っていても)出力ラグが少し大きく感じるんですが、原因は分からずです。DTXManiaとFDKでは特に変なことはしていませんでしたので、SlimDXで何かやってないか、ソースを読んでみるか・・・

# 単にWin7だと(HWアクセラレーションが使えない関係で)サウンド出力が遅くなってるってだけだというオチだったらイヤですね。SSTのソースを借用して、WASAPI/ASIO対応を試してみますか・・・。

2012-08-28 02:52 更新者: sf298yen
コメント

結局いろいろやってみたものの、もうすぐ8発売だなぁ・・・ということで7を諦めてXPでプレイしてました、ごめんなさい。
やぎ。さんの環境でもサウンドは(XPよりは)7ではラグが大きく感じるということですから、私の感覚+PCだけが変ということではなさそうですね。

webでいろいろサウンドについてみていると、
:遅延の根本原因は、Windows標準のDirect Sound APIがそもそも遅延が大きいものであることが影響している
ということでやはり悩んでおられる方がおり、ASIO/WASAPIで改善出来た、というので

SSTのソースを借用して、WASAPI/ASIO対応を試してみますか・・・。

には非常に興味があります。

ソース⇒ ttp://blogs.itmedia.co.jp/satohiroshi/2011/07/asiowasapi-3082.html
Bluetoothに関しての問題ですが、共通点はあるのかなと。

'ちなみにnyaさんが行っていた試験をやってみようと思ったのですが、私のPCではミキシングの問題でうまくいかなかったので嫌になって放置しましたorz

2012-12-21 01:41 更新者: yyagi
コメント

今頃ようやくですが、SSTのソースをパクってWASAPI対応したサンプルを作りました。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121220.zip

094か095の環境に上書きしてもらえれば、とりあえず固定的にWASAPI再生するバージョンができあがりです。 (ベースは094です。すみません)

これで反応遅延が改善するか、お試しいただけますでしょうか。 個人的には、改善しているっぽい気がします。(メインPCでしかまだ試していませんけれども。)

以下注意事項です。

  • Vista以降でないと動作しません。(WASAPIはXP非対応です。XPはASIOでカバーすることになります)
  • xaの音は鳴りません。(対応させるのは簡単ですが、まずは遅延改善有無の確認を優先します)
  • チップ音の定義が非常にたくさんあると、激重になります。ギター音ありのデータを使う場合はご注意下さい。(これの対策は大変そうです。チップ音のライフタイム管理を新たに実装する必要がありますので。)
2012-12-21 23:35 更新者: sf298yen
コメント

お忙しいと思われる中、対応ありがとうございます。
本日は都合によりテストできない為、明日か明後日中に確認させていただきたいと思います。
ダウンロードは済ませましたm(かおもじ)m

2012-12-22 15:09 更新者: from
コメント

yyagiさんお疲れ様です。 WASAPI版をWin7で試してみました。

BGMと譜面のタイミングはどの曲もばっちりでした。 ドラムチップ音については OFF にしているので分かりません(汗

ただし、譜面通りに叩いていると、Poor、よくて Great の連続になります。 Perfect を出すには、チップより早め(体感でずれてると分かるくらい)にヒットする必要があるようです。

ソースが公開されてない?ので原因は分かりませんが、 とりあえずWASAPIで自作しているタイマ値関連だと思いますので見直して頂けないでしょうか。

2012-12-22 18:20 更新者: sf298yen
コメント

お疲れ様です。
体調不良を理由に有休をとって遅れながらWin7で試してみました。
(体調不良は本当で昼まで寝てましたorz・・・本当ですよ!?)

§確認項目の確認
「キー入力してからの反応遅延」
⇒画面の表示:今までどおり遅れている感じです。(今回の修正とは関係ないはずですので当たり前ですが。)
⇒音のズレ:改善している気がします(※)。BGMと一致させるよう意識して入力したらほぼ-10~+30でした。
(通常と、Hiddenの使用で目押しによる補正があまり出ないよう意識してテスト。)

補足:
目押しを意識して入力した場合(→上記の通り遅れて表示されている感じの為かと思いますが)、遅い(+30~+50)と判定されました。
fromさんが指摘されているとおり「チップより早めにヒットする必要がある」と思います。
ですが、音のタイミングが合っているなら本質的な問題は少ないと思いますので、
表示上のタイミング問題は、例えば判定ラインを上げる・下げるとか、チップ表示のみを意図的に早くする、遅くするなどでクライアント差を吸収できる
と思います。

※私が持っている曲も私が作成している譜面もほとんどがxaの為、普段やらない曲でのテストとなりました。
私のテンポ感覚が完璧などとうぬぼれるつもりはありませんorz。その為、体調不良という言い訳も重なって後日体感意見が変わるかもしれません。

2012-12-22 21:23 更新者: yyagi
コメント

動作確認いただき、ありがとうございます。仕事があまりに忙しいので、現実逃避でWASAPI/ASIO対応してます・・・

fromさん: ソースはbranchに入れてます。24820ってやつです。先ほど、「XAに仮対応してみたけど、System.ExecutionEngineExceptionが出てしまうよ!」なコードをコミットしました(ぉぃ I/Fの定義と使い方は正しいはずなんですが・・・(アンマネDLLへのリンクなので、自動でピン止めされている前提)

タイマ関連と言いますのは、つまり「演奏用のタイマとメイン進行用のタイマが違うと、判定がずれるよ」的なお話でしょうか?(まだよく理解できていません。)

sf298さん: 動作確認用にxa対応が必要という話は余所でも聞きましたので、今やってます・・・が、エラーが出てます。ぬー。

それにしても、画面の表示の遅れが出ていますか。前にもご相談したような気がしますが、Aeroを切って、VSyncWait=Offにしてかつ(グラフの設定で)レンダリング前最大フレーム数やらフリップキューサイズやらを0にしても変わらないのですよね?

# 描画遅延ではなくて入力遅延かも知れませんが・・・。

2012-12-22 22:14 更新者: from
コメント

おお、入ってましたか。それは失礼しました。

現在SSTのほうに全力注力してるのであまり深くは突っ込めないかも知れませんが、拝見させて頂きます。

タイマ関連で気になるというのは、チップの「本当の時刻」と「表示する時刻」がずれてないかな?ということです(変数名は忘れた……)。 WASAPIから導き出したタイマが狂ってると、両者もずれてくるはずなので。

あと、SSTのほうを触ってて、ドライバにモノラルを指定していたバグを見つけましたので直しておきますね。 (……でもちゃんとステレオで聞こえてるし、ヘタにいじらないほうがいいかな?)

p.s. うちの実験環境(というか本番環境)は、Win7Proで、Aero ON、フレーム数はいいじらず、VSyncWaitもONです。 すわなちクリーンインストールして何もしてない状態です。念のため。

2012-12-22 22:39 更新者: yyagi
コメント

ソースについて少し補足しますと、

  • 基本的には、DTXManiaとSSTのサウンド設計の違いを、CSound.cs の中で吸収してます(というほどのものでもないですが。タイマー設計の違いは無視してますし)。CSound管理 も、CSound.csの中にいます。その他はほとんどそのままSSTソースのファイルコピーです。
  • タイマー周りはSSTからファイルをコピーして、DTXManiaソース用のラッパーを追加しているだけです。なので、ちゃんと使えていないはずです。
  • CCounter.csは、DTXManiaのコードそのままです。(SSTのコードは未使用)

あと、ここで書くのも何ですが、SSTのソースを持ってきて気付いたことを少し・・・

  • BASSのMixerにStreamAddChannelする時点で、flagにてPAUSE指定できますよ。
  • なにげに BASSFlag.BASS_SAMPLE_FLOAT 指定されていて、貧乏性の私はびびりました・・・。
2012-12-23 01:20 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121222.zip

無事にxa対応ができました。これで大抵の曲をプレイできるようになると思いますので、これでWASAPI動作を見て下さいませ。 チップ音が多数定義されていると激重になる制限は、そのまま残っています。なのでギターありの曲データは悲惨なことになると思います。

ソースもコミット済みです(バグ調査用の汚いコードがそのまま残ってますが、これから清書します)

とりあえずxaの再生方法は、(ストリーム再生ではなくて)wavにデコードしてオンメモリ再生にしてます。

清書が終わったら、fromさんからご指摘いただいた、タイマー周りを見てみます。

2012-12-23 06:44 更新者: from
コメント

お疲れ様です。 結論から言いますと、分かりませんでした(汗。

私が懸念してたタイマ関係についても、完全にDTManiaとSSTとを混同しちゃってました。 (本当の時刻と表示時刻とに分かれて誤差修正してるのはSSTだけでした……)

……相当、忘れてるなあ。

BASSについては、ご指摘ありがとうございました。修正します。 あと、FLOAT に固定されているのは WASAPI の仕様だったかな?(内部的にはFLOATしか扱わないとか何とか) SST のソースをそのままコピーしたのであれば、ASIO のほうは内部 16bit 固定になっていると思います。

2012-12-23 14:50 更新者: yyagi
コメント

fromさん:

タイマーについて、承知しました。ちなみに、この試作品以前に、通常のDTXManiaでも同じような「入力ズレ」がありますでしょうか。(サウンドの出力ズレはともかくとして。)

ちなみに、演奏中のPAUSE/復帰で一部の演奏(ギターだけとか)がずれることがあるので、何かしら時刻周りの問題を抱えているのは間違いないと思います。(これはこの試作品に限った話で、通常のDTXManiaでは起きない現象ですが・・・。)

2012-12-23 14:58 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121223.zip

  • WASAPIだけでなく、ASIO, DirectShowに対応しました。Config.iniのSoundDeviceTypeで切り替えできます。なお、WASAPIが使えないときはASIOに、ASIOが使えないときはDirectShowに自動でフォールバックします。実際にどのタイプが使われているかは、DTXManiaLog.txtを見れば分かります :-)
  • 将来的にはDirectShowの代わりに(従来互換のために)ACMに対応したいと思ってますが、現在既にサウンド周りを全取っ替えしたような状態なので、難しいかも・・・。(とはいえ従来より互換性重視の方針で作ってましたので、何とかしたいところです)
  • XPでの動作は未確認です。ASIOでの動作も未確認です。(Win7上で、WASAPIとDirectShowでの動作を確認しています。)
  • WASAPIとASIOを使う場合は、チップ音が多いと激重になります。Config.iniのPolyphonicSoundsを1にすると緩和されます。(追々何とかします)
  • DirectShowを使う場合は、oggの読み込みが遅いです。(追々何とかします)
2012-12-23 21:12 更新者: None
コメント

お疲れ様です。

前にもご相談したような気がしますが、Aeroを切って、VSyncWait=Offにしてかつ(グラフの設定で)レンダリング前最大フレーム数やらフリップキューサイズやらを0にしても変わらないのですよね?
# 描画遅延ではなくて入力遅延かも知れませんが・・・。


以前の設定のままで、Aero Off / VSyncWait=Off / レンダリングは 0相当(のハズ)です。とにかく遅延が最小になるようにさせていただいております。
入力遅延の件はDTXManiaGRCheckKBInputLag2.zipを使って再測定したとおりですから問題はないと思っています。

当時と違うのはグラフィックドライバが最新になっています。


§「DTXManiaGR_094_WASAPI_20121223.zip」を少しですが試させていただきました。

XPにより近い体感に思えました=改善していると思います。
(イメージ的にはXPが某V,7が某XG的な反応速度)
※BGMのタイミング上下(プレイ中にShiftとカーソルの↑↓で変更できる数値)が反映されないようなので、XPでその数値が0でぴったりだった曲でテストしています。
…頭痛の為、薬を服用してのテストです。後日意見変わるかもしれませんorz。
SSが取れる曲でテストしています。


§「XP環境」で「DTXManiaGR_094_WASAPI_20121223.zip」を095環境に上書きして試してみました。

・そのままでは音が出ません。
ASIOで動作を試みているようですが、xaファイル読み込みで大量にエラー出てました>ログ

・Config.iniで SoundDeveiceType=0にして動作させたところ通常通り演奏できました。
ただし、曲の読み込みが遅かったです。(インジケーターのところにDirectShowのアイコンが出たり消えたり。)

・Oggファイルはエラーでした。
--抜粋(DTXManiaLog.txt)-
2012/12/23 20:49:36.325 ERROR ファイルを再生できません。 この形式はサポートされていません。
2012/12/23 20:49:36.325 WARNING システムサウンドの読み込みに失敗しました。(Sounds\Decide.ogg)

2012-12-23 21:13 更新者: sf298yen
コメント

のぅ・・・ログインしてなったorz ↑ 298yen です。

2012-12-24 11:52 更新者: yyagi
コメント

sf298yenさん

検証いただきありがとうございました。でも、どうか検証などなさらずにぐっすりお休み下さい・・・。

  • 画面出力の遅延を細小になさっている旨、承知いたしました。
  • BGMのタイミング上下に絡むコードはいじっていないはずですが・・・追々確認します。

さて、ASIOで音が出ない件、ウチのWin7でも音が出ないみたいです・・・。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121224.zip

にて、ASIOのエラー検出強化(とログ出力強化)をしたら、ウチのWin7 + UA-5では、BASS_ASIO_Start()のところで BASS_ERROR_UNKNOWN なるものが出てコケているようです。 (そしてDirectShowにフォールバックして動作する)

BASS_ERROR_UNKNOWN とは、APIのヘルプを見る限りでは "Some other mystery problem!" という意味なんだそうで(汗;;;;

ASIOのところって、SSTではちゃんとエラー無く動作しているのでしょうか・・・。

なお、oggは読み込めるように修正しました。ご迷惑をおかけして申し訳ございません。体調が回復しましたら、試してみて下さいませ。

2012-12-24 12:36 更新者: from
コメント

ASIOのところって、SSTではちゃんとエラー無く動作しているのでしょうか・・・。

Sound Blaster X-Fi Xtreme Gamer (PCI、ASIO 2.0対応) でしか試してませんが、XP, 7 ともに正常に動作しましたよ。

USB外付けの Sound Blaster Digital Music HD は、ASIO は非対応でしたが、WASAPI には対応していました。 もっとも、USBの遅延が大きくてあまり追い込めませんでしたけども。

2012-12-24 17:47 更新者: yyagi
コメント

fromさん

コメントありがとうございます。SSTではASIO、動いてますよねぇ。

こちらでは、

  • Win7 + ASIO(UA-5): BASS_ASIO_Start() でエラーになる
  • WinXP + ASIOALL: 最初の Bass.BASS_GetVersion() で例外

こんな感じです。 後者は単純にDLLへのリンクに失敗しているとかなのでしょうけれども。

もうちょっと調べてみます。

2012-12-25 01:24 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121225.zip

XP+ASIOで動作確認済みです。ASIOを使う場合は、Config.iniでSoundDeviceType=1を指定して下さい。(初期値の2のままだと、正常動作しません。)


結局、(私の環境の)XPで動かなかったのは、単にdllが不足していたからでした。 dllを補ったところ、ASIOで正しく動作するようになりました。

ただ、WASAPIの初期化に失敗してフォールバックでASIOの動作をさせようとすると、ASIO_Init()は通るのですが、 その後StreamCreateFile()でBASS_ERROR_INITになってしまうようです。

(私の環境の)Win7では、未だBASS_ERROR_UNKNOWNが出て動作しませんが、多分私の環境側の問題かなと思っています。 後日、別のWin7環境で確認してみます。

2012-12-25 02:13 更新者: yyagi
コメント

ただ、私のXP環境(CoreDuo1 1core 2GHz + UA-5 ASIO)だと、どうもサウンドがヨレて仕方がないですね。 凄く発音処理が重そうな感じ。

Config.ini の PolyphonicSounds を1にすると発音不可を大幅に軽減できます。でも、ウチは1でもまだちょっとキツかったです。(これを常用しようとは思わないくらいのキツさ・・・)

更に VSyncWait=0 にするとズレが減らせるかも知れません。(WASAPI/ASIO動作時の発音時刻の制御がまだ少し怪しいので。)

このあたりは、チップ音のライフタイム管理を入れて改善できないか試してみますが、何となくそれだけじゃない問題のような気がしています。(設計上、1coreじゃどーにもならないとか、そういうレベルの問題のような予感。)

2012-12-25 04:24 更新者: sf298yen
コメント

お疲れさまです。DTXManiaGR_094_WASAPI_20121225.zip 使用させていただきました。


§XP

XP+ASIO(SoundDeviceType=1) / XP+DirectShow(SoundDeviceType=0)

・チップの降ってくるタイミングは同じっぽいのですが、チップをヒットしてからの音の立ち上がりの差が激しいです。

ASIO :

…Windows7でDTXManiaをプレイしたときのもっさり感が再び?(XPなのにorz)。

チップをヒットしてからの音の立ち上がりがすごく遅い?感じです。
なのでヒット音を確認しているとリズムが崩れるます。(だんだん遅れる感じ?)

DirectShow : (今までの環境と同じくらいです。)
音の立ち上がりが非常によいです。
チップのヒット音を確認しながらでもリズムキープしやすいです。


ゆえにチップの音を鳴らさないで電子ドラム音を直接鳴らすタイプの方には影響はないと思います。
音を無視して、「目押しができる」「脳内リズムが完璧」ならばASIOでもプレイは出来ると思いますが、BGMとチップの音のタイミングのズレは大きいと思われます。


§7

WASAPI :
XPでのDirectShowと同じ体感です。

ASIO :
理由はわかりませんが、音がバグってまともにプレイできませんでした。音以外はたぶん正常です。

DirectShow :
XPでのDirectShow / 7でのWASAPIと同じ体感でした。

なぜか今回は描画が遅い?という認識が出ませんでした。実は修正済み?グラフィックドライバが新しくなったから?
胸焼けで眠れないから飲んだパンシ○ンの効果?


○現段階での判定:(あくまでチップ音を鳴らす前提でのプレイ感)
XP+DirectShow ≒ Win7+WASAPI ≒ Win7+DirectShow


横道:

※BGMのタイミング上下(プレイ中にShiftとカーソルの↑↓で変更できる数値)が反映されない…


この件ですが、「リアルタイムで変更できない」です。
以前はプレイ中に変更するとその都度反映されていたのですが、今は一度曲を終了するかポーズ(SHIFT+F1)後、再開すると反映されます。
そこで思ったのですが、ポーズ中にも値を変更できるように出来るとプレイヤーに優しいかもしれません。
プレイ中に変更しようとするとmiss連発で閉店します(検証中はStageFailed=offにしています)。

ポーズもSHIFT+F1とか押しにくいのじゃなくワンタッチで出来るといいなーと思ったけど、私マクロ機能付キーボード使ってるじゃん・・・。問題なかったですorz

2012-12-25 07:03 更新者: from
コメント

少し気になったので横槍を。

ただ、私のXP環境(CoreDuo1 1core 2GHz + UA-5 ASIO)だと、どうもサウンドがヨレて仕方がないですね。 凄く発音処理が重そうな感じ。

DTMならともかく、USB外付けの音源はリアルタイムゲームには向いてないと思いますよ。

私が Sound Blaster Digital Music Premium HD を買ってすぐに売却したのもそのせいです。 (これは ASIO には対応していませんが、6コア(Phenom II X6) の Win7 上の WASAPI ですら発声タイミングが安定しませんでした。しかしデバイスを内蔵音源に切り替えるとサクサクになるという…… ついでに言えば、AMD 対応マザーで標準でインストールされる AMD USB Audio Filter とやらも大変な負荷とノイズになる一因でした。)

なので、私は今でもドラム用PCには PCI 接続の Sound Blaster X-Fi Xtreme Gamer を使ってます。(メインPCはASIO非対応の内蔵で……)

念のため、ご考慮ください。

2012-12-26 22:29 更新者: yyagi
コメント

その後一応、Win8上でもWASAPIでとりあえず動作することを確認しました。 NET Framwrork 3.5と、DirectX9.0cの追加インストールが必要ですので注意。 (DTXManiaの初回起動後しばらく待っていると、OSが.NET Framerowk 3.5の自動インストールを促してきます。)

sf298yenさん

ウチもASIOは音が切れたりで動作が重い感じがしてます。XP/Win7どちらも。 でもASIO動作でCPUはあまり使っていないっぽい(2,3%程度っぽい)ので、何かプログラム的に見直さないといけないところがありそうです。それがどこなのかはさっぱり分からないのですが。 なお、描画関係は全然いじってないですよ。

PAUSEメニューいいですね。簡単なCONFIGや、「最初から演奏し直し」のようなメニューが欲しいなぁ。

fromさん

どうもUA-5だとBASS_ERROR_UNKNOWNの魔の手から逃れられず、また代わりにUW10を使うと今度はBASS_ERROR_DRIVERになる・・・ので、取りあえず安直にASIO4ALL+内蔵音源で動作確認してみました。

・・・ですが、ぱっと見の動作(音の切れ切れ具合とか、何となく重そうな動作の度合いとか)が、USB接続の音源である上記2種と比べて大差なかったです。

「ASIO4ALLだから」なのかもしれませんが、それ以前に多分、今の動作がどこかおかしいのだろうと思います。そこを直せば、fromさんがおっしゃるようなバス違いによる性能差の話が出てくるのだと思っています。

2012-12-27 02:00 更新者: yyagi
コメント

UA-5でのBASS_ERROR_UNKNOWNを回避できました。 ASIO_Start()のときに指定するバッファサイズを、FDKが計算で出してくる値ではなく、手動で直接適切な値を設定することで、エラーが出なくなりました。

今後はメインPCでASIOの動作確認ができます。これで捗る。

2012-12-28 01:39 更新者: yyagi
コメント

メインPC(Athlon II X4 2.3GHz, Win7 x64, UA-5)とASIOの組み合わせでDTXManiaを動かせるようになったので、 早速動作確認してみました。

チップ音が多すぎる曲の動作は相変わらずですが、普通の曲データでは他のPCで感じたような音切れやタイミングズレの感じはありませんでした。(バッファがショートしてたまに発振するけどw)

この環境で何より特質すべきは、入力に対する反応の良さ。この環境ではバッファサイズ(サンプル数)の調整で3ms程度にまで追い込めたのですが、従来のXP(ACM)以上にダイレクトな反応をすることに感動しました。これなら私、プレイする気になれますわ。(今まではXPでも遅延が気になってプレイする気になれませんでした。実は。)

一応、最新の試作モジュールを置いておきます。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121227.zip

  • ASIOのバッファサイズを、Config.iniで変更できるようにしました。
  • ASIOのバッファサイズの初期値を変更しました。(50ms分→デバイスに設定されている値を使用)
  • ウインドウタイトルに、サウンドのモードを表示するようにしました。(WASAPI, ASIO, DirectSound)

ただ、音声処理そのものは何もいじっていないので、音が切れ切れとか動作が重いような感じと言ったようなところは多分変わらないと思います。(何故か私のメインPCではうまく動いているだけなのだと思います。)

なお、WASAPIのバッファサイズ(遅延)は、この環境でも60msを超えてしまいます。これで従来のXPくらいの感触。 最初USB音源だからかと思い、内蔵音源でも試してみましたが、同じくらいのバッファ量でした。 WASAPIの関連情報をぐぐってみると、余所では10msとか3msとか、いい感じの値が出ているようなのですが、 ウチだとダメのようです。ちくしょう・・・なんでや・・・。

2012-12-28 10:13 更新者: sf298yen
コメント

睡眠導入剤の利用で限りなく熟睡させて元気になりました。心配いただきありがとうございます。
が、少々仕事のトラブルから気が滅入っているので差し引き少しマイナスという状況です。

だがしかし、

…入力に対する反応の良さ。この環境ではバッファサイズ(サンプル数)の調整で3ms程度にまで追い込めたのですが、従来のXP(ACM)以上にダイレクトな反応をすることに感動しました。これなら私、プレイする気になれますわ。


これを読んだら試さずにはいられないでしょう、いやー、XP以上ってもう・・・!


・・・なのになのに、Win7でASIO指定すると音がバグるorz なんでやねん…。
今日はもう寝る時間(夜勤)なので後日改めて挑戦しようと思います。

XPでASIO動作させると前回(-20121225.zip)はなぜか遅延がすごかったのですが、今回は快適でした。
余談でXPに「ASIO4ALL」インストールするとWin7でASIO指定したときと同じような音のバグが・・・(というかまったく同じ音?)


今まではXPでも遅延が気になってプレイする気になれませんでした。実は


実際の楽器を触られている方には多い意見なのかな?演奏時のレスポンスが遅いと「なんか違う」という感じになってしまって。

私は某XGとかはその点が特に気になっていて、ズレ?が大きい曲になると違和感がハンパなくて対応できません。
強制的に小節線を目押しで狙ってあとはリズムで強制補正すればいけるときはいけるのですが、どうしても遅れて鳴るチップ音につられて自爆するんですよねorz

すごいスコア出してる方はきっとそこらへんの補正がうまいか、そうとう目押し的な能力が強いのか。
中にはクラッシャーよろしくゲームの音じゃなくパッドの打音やギターのピック音でリズムを維持する方もいらっしゃるんでしょうけど。


なんて横道それましたが、これからはやぎ。様もDTXManiaのプレイに復帰されて開発(現実逃避)がより順調に!?

2012-12-29 14:43 更新者: yyagi
コメント

sf298さん

こちらではWin7/XP共に、内蔵音源(ASIO4ALL)とUA-5(ASIOドライバ)のどちらでも(この組み合わせ4パターン全てで)ちゃんとASIOで動作しています。 前回遅延やらモタリやらが酷かったのが劇的に改善したのは、バッファ量の設定をデバイスが持っている値を使うようにしたためだと思います。(ここを最初は50ms固定の設定にしていました。)

もし音が変とか言うことであれば、以下をチェックいただけますでしょうか。

  • バッファ量の設定: Config.iniのASIOBufferSize。初期値は0で、このときはデバイスの設定値(ASIO4ALLのオフラインツールとかで設定している値)をそのまま使います。必要に応じてここを調整して下さい。ただし、ここにおかしな値を設定すると、ASIOデバイスの初期化に失敗してDirectShowにフォールダウンするのでご注意下さい。
  • 多重再生の設定: Config.iniのPolyphonicSounds。初期値は4で、このときは個々のチップ音毎に最大4重再生を許すという設定なのですが、今のWASAPI/ASIO用の設計では「全定義WAV数の4倍のストリームを生成し、その全てをリアルタイムに合成して再生する」ようになっているため、チップ定義が多くなると劇的にサウンド合成処理が重くなります。なので、この数字を1にすると、処理を1/4にでき、負荷を下げることができますので、音がおかしくなる可能性が低くなります。(追々改善しますが、直近ではここをいじって下さい)

「音がバグる」という現象が具体的にはどういったものなのか分かりませんが、まずは思いつくところをコメントいたしました。

2012-12-30 10:27 更新者: sf298yen
コメント

やぎ。様
アドバイスありがとうございます。無事一通り正常動作確認できました。
「ASIO4ALL」アンインストールしたら何事もなかったよーに。バッティングしてたのかな?

細かいテストはしていないので、あくまで現段階での快適さを体感順に記述しておきます。

1)XP+DirectShow :問題なくプレイできる
2)Win7+ASIO :問題なくプレイできる(が、描画がやや不満)
3)Win7+WASAPI / Win7+DirectShow :やや遅延を感じる
4)XP+ASIO :かなり遅延を感じる

※この順位は私のPC環境と、年末仕様の体調による感じ方です。
音は両方ともSB X-FI Xtreme Gamer.

XP+ASIOですが、前回は快適と記述させていただいたのですが、選曲による勘違いだったようで、遅延がひどい(音の立ち上がりが遅い)ので個人的に実用にならず…。
・Config.iniのPolyphonicSoundsは1に設定させていただいています。


Win7+ASIOよりXP+DirectShowのが快適だと感じるのは、私の環境だと描画遅延がWin7のほうがXPより大きい為です。
ただ、Win7は、画面にとらわれずに演奏する分にはASIOを使うことでかなり改善しているように思えました。
個人的には後は描画遅延。XPで出来ている速度がなぜWin7で出ない・・・orz

2012-12-30 13:15 更新者: yyagi
コメント

sf298yenさん

状況を整理いただいて、ありがとうございます。わかりやすいです。

  • XP+ASIOのサウンド遅延ですが、ASIOのバッファ量は適切に設定なさっていますか? DTXMania側はASIOBufferSize=0でよいとして、デバイス側の設定の方です。(もしくは、ASIOBufferSize=128などと個別に設定。) 最終的に使用されるバッファ量(=発音遅延時間)は、DTXManiaLog.txtに出ているので、参考にしてください。(希望0msに対して、22ms、といったような出力になってます)
  • これを除けば、サウンド周りと言うよりは描画遅延の方が問題のようですね。グラフボードには何をお使いでしたっけ?(NVIDIAの、何でしょう?)

最近、こんな記事を見つけました(記事の最後の方を参照)。ドライバのバージョンによってもいろいろあるようです。 tp://jehupc.exblog.jp/11464034/

こんな記事もありました。私のところでも、測定環境を作ってみるか・・・ tp://shikihuiku.wordpress.com/2012/06/12/directx%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E6%8F%8F%E7%94%BB%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%81%AE%E9%81%85%E5%BB%B6%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/

2012-12-30 13:24 更新者: yyagi
コメント

sf298yenさん

すみません。もう一つ確認です。Win7での描画遅延について、電源オプションでグラフの設定は性能寄りの設定になさってますよね?

コントロールパネル - システムとセキュリティ - 電源オプション - (今お使いの電源プランの)プラン設定の変更 - 詳細な電源設定の変更 - (グラフ関係の設定(Intelグラフの場合は、Intel(R) Graphics Settings - Intel(R) Graphics Power Plan - 電源に接続 を、BalancedからMaxmimum Performance に変更。))

個人的にはバランス寄りの設定で問題ないはずだとは思っていますし、またグラフのプロパティで似たような設定をすでにいじっていらっしゃるとは思うのですが、念のため確認は必要かなと思いまして。

2012-12-30 23:38 更新者: from
コメント

お疲れ様ですー。

1227版を試してみたところ、前回生じたヒットのズレは解消されていました。 チップとBGMのタイミングはぴったりです。

ただ、曲によっては、小節線ごとに行う再生位置補正がひどいことになりました。(ならない曲もありました。) パルスノイズのような短いブツ切れではなく、体感ではっきりと分かる0.2秒ほどの無音領域が小節線ごとに入ります。 小節の長さは関係無いみたいです。

再生環境は Win7 Pro (SBX-FiXG)で、ログには WASAPI(192kHz, 8ch, 32bit)、遅延48ms(希望0)とありました…… が、これは(ソースの中にコメントがあったと思いますが)再生開始の瞬間に別の構成に変わると思いますので、正確な情報ではないと思われます。

その無音領域さえ無視すれば、無音が鳴っても全体としてチップ位置とBGMはぴったりあっていました。

2012-12-30 23:46 更新者: from
コメント

思うのですが、DirectInput と再生位置自動補正機能で使用しているマルチメディアタイマを BGM 再生に使わないのであれば、再生位置自動補正機能は廃止するほうがいいと思いますがいかがでしょう。WASAPI や ASIO にしたことで、かえって環境依存の音ズレが発生することになります。

SST ではすでに廃止してます。 が、Midi入力もまたマルチメディアタイマを使っており、CSoundTimer との微妙なズレがありますので、それはこれから修正する予定です。

2012-12-31 01:11 更新者: None
コメント

fromさん

ご確認いただきありがとうございます。

再生位置補正ですが、こちらでは、同じ曲でも無音領域が入る場合と入らない場合がありました。 ご指摘いただいたタイマーずれの懸念ももちろんあるのですが、 HDDアクセスの間BASSの処理が止まってるとか、そういうのもあるかもしれません。

タイマーの方は、おっしゃるとおりこれを機に新方式への移行(そして再生位置自動補正機能の廃止)が必要と考えていました。 ですが、上記の通り今のままでもなぜかうまく動くことがあるため、後回しにしてます。 (まあもちろん、理屈の上ではずれが出るのはわかっているのですが・・・)

WAV定義のライフタイム導入と、サウンド読み込み高速化(CSound.Cloneの実装)、タイマーの見直し。直近でやるべきところはこんなところかなと思ってます。 後は汚くなったCSoundの設計見直し。(xa/oggとか、ファイル読みだし/メモリ読み出しで似たような処理なのに個別に作り分けしているので、動作が落ち着いたら継承ですっきり書き直したい・・)

2012-12-31 12:48 更新者: sf298yen
コメント

やぎ。様

XP+ASIOのサウンド遅延ですが、ASIOのバッファ量は適切に設定なさっていますか?


ご指摘のとおり、バッファ量の値が問題だったようです(50msとなっていました)。
標準のドライバでは設定する場所が見当たらなかった為、「Asio caps」というツールを使って変更しました。
「Asio caps」 ⇒ tp://otachan.com/ASIO%20caps.html

値は10以下にするとノイズが入ってしまう為、20msの設定を利用したところ、DirectSoundと違いがわからないレベルでした。

-- DTXManiaLog.(抜粋)
2012/12/31 12:14:10.524 INFO BASS (ASIO) の初期化を開始します。
2012/12/31 12:14:10.586 INFO BASS を初期化しました。(ASIO, デバイス:"SB X-Fi ASIO EC00", 入力10, 出力2, 48000Hz, バッファ48~32768sample (1~682.667ms), フォーマット:BASS_ASIO_FORMAT_32BIT)
2012/12/31 12:14:10.586 INFO ASIO デバイス出力開始:バッファ960sample(希望0) 20ms(希望0ms)


この設定(20ms)でBGM通りに演奏すると、DirectSoundでは-20~+20の曲が、ASIOだと+20~+60という判定になりました。
音につられないようにHitSound=offでもテスト。ただ、2~3回しか試していないので正確さに欠ける可能性があります、すみません。
微妙に再生タイミングが違うのかバッファによる違いが出たのかはわかりません。



グラフボードには何をお使いでしたっけ?(NVIDIAの、何でしょう?)


DXDiagからの部分コピーです。

☆XP

  • Card name: NVIDIA GeForce GTX 560 Ti
    DAC type: Integrated RAMDAC
    Display Memory: 1024.0 MB
    Current Mode: 1920 x 1080 (32 bit) (120Hz)
    Driver Name: nv4_disp.dll
    Driver Version: 6.14.0013.1070 (English)
    DDI Version: 9 (or higher)
    Driver Attributes: Final Retail
    WHQL Logo'd: Yes


☆Win7

  • Card name: NVIDIA GeForce GTX 470
    DAC type: Integrated RAMDAC
    Display Memory: 3020 MB
    Dedicated Memory: 1233 MB
    Shared Memory: 1787 MB
    Current Mode: 1920 x 1080 (32 bit) (60Hz)
    Output Type: HDMI
    Driver Name: nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um
    Driver File Version: 9.18.0013.0697 (English)
    Driver Version: 9.18.13.697
    DDI Version: 11
    Driver Model: WDDM 1.1
    Driver Attributes: Final Retail
    WHQL Logo'd: Yes



電源オプションでグラフの設定は性能寄りの設定になさってますよね?


該当っぽい項目がなかったのですが、関連ありそうな項目はパフォーマンス優先側になっているのでおそらく問題はないと思います。


参考記事の件は大変興味深いですね、GPUViewのツールなどでテストしてみたいと思います。

2013-01-01 00:29 更新者: yyagi
コメント

sf298yenさん

  • XP+ASIOでは、まだDirectSoundよりサウンド出力遅延が大きいと言うことなのですね。ここから先はちょっと私にもわからないです。ただ、前述したとおり、WASAPI/ASIO時はサウンド合成にめちゃくちゃ負荷がかかる設計になっていますので、ここを改めることで改善すればよいのですが・・・。
  • 画面描画遅延について、先の参考記事から、フレーム描画終了時にGPUをflushするようなコードを追加してみました。見よう見まねなので効果があるかはわかりませんが、ちょっとお試しいただけますか。(EndSceneの直前に入れるのか直後に入れるのか、どちらがよいのだろうか・・・commitしたコードでは直前に入れてますが、下記のzipではその後思い直して直後に入れるように変更してます。)

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121231.zip

  • 描画遅延対策として、GPUのフラッシュを加えた
  • サウンド処理のCPU負荷状況を、演奏中画面のDebug Infoに表示するようにした (あくまで目安の値。また、DirectShowでの動作は未確認。)

WASAPI/ASIO周りは1227版のままで、いじっていません。

2013-01-01 05:15 更新者: sf298yen
コメント

あけました。今年もよろしくお願いいたします > all

やぎ。様

XP+ASIOでは、まだDirectSoundよりサウンド出力遅延が大きいと言うことなのですね。


言葉足らずですみません。ASIOの設定が不完全のために遅延が発生していたらしく、20msに設定したことでDirectSoundと同等以上のレスポンスになりました。
判定のタイミング(BGMの再生タイミング?)がDirectSoundとASIOで微妙に違っているように感じたのですが、勘違いの可能性も高いので保留でお願いします。

⇒ASIOの設定をちゃんとすることで 「XP+DirectSound ≒ XP+ASIO」 という仮の結論でお願いします。



§20121231版を使わせていただきました。

・Win7+ASIO

ASIO(20ms)+1231版でプレイした印象ですが、「あれ?XPでプレイ中だっけ?」と思ったくらい快適でした。
このレスポンスであればXPからWin7に切り替えることに躊躇うことはないと思います。
(問題は・ASIO対応環境が必要なこと・ASIOの設定を適正にする必要があるなど、そのまま使える確率が高いと思うXPより、設定のハードル高いかも。)
音、描画のともに年始仕様の体調では問題なく完璧に思えました。


サウンド処理のCPU負荷状況を、演奏中画面のDebug Infoに表示するようにした (あくまで目安の値。また、DirectShowでの動作は未確認。)


プレイ中ずっと1%前後(高くても1.5%、低いと0.5%あたり)でした。



・Win7+WASAPI / Win7+DirectSound

もしこれがASIOと同じ描画遅延対策で動いているとしたら、音の遅延が描画の感覚を巻き込んで錯覚している部分があるのかもしれません・・・。
とりあえずこのモードでは(音の遅延と)描画遅延を感じました。



○現段階での体感順位です。

  1. XP+DirectSound :問題なくプレイできる
  2. XP+ASIO / Win7+ASIO :問題なくプレイできる(微妙にXP+DSよりも処理が重く感じる。Sound合成処理の為でしょうか。)
  3. Win7+WASAPI / Win7+DirectSound:遅延を感じる




'Win7での補足(20121231版 / Windowモードで使用)

Windowを移動するとエラーで落ちます(マウスや、ALT+SPACE+Mの移動でも)
VSyncWaitを切り替えるとエラーで落ちます
2013-01-01 15:17 更新者: yyagi
コメント

こちらこそよろしくお願いします。>all

sf298yenさん

ご確認いただき、ありがとうございました。それでは、いったんASIOでの遅延の話は終わります。

WASAPIの遅延を感じるとのことですが、バッファ量はどのくらいになってますでしょうか(ログに出ているはずです)。 私の環境では60msちょいになって泣きそうです。また、これを調整する方法は今のところわかっていません。(APIでバッファ量を指定することはできるのですが、何を指定しても結果が60ms強になってしまう・・・)

エラーで落ちる件、失礼いたしました。下記0101版で修正済みです。それと、GPUをフラッシュするタイミングをほんの少しだけ変えてみました。 こちらでは、XP+フルスクリーン+VSyncWait=ONの時に限って描画遅延しているかなぁという感覚があったのですが、 この対応で少し描画遅延が減ったように感じました。

なお、フラッシュする実装自体は、OS/サウンド出力方式の区別なくすべて同じです。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130101.zip

2013-01-01 16:25 更新者: from
コメント

あけましておめでとうございます。

今年も死なないよう頑張ります。社会的に。

0101試しました。年明けから(年末から?)お疲れ様です。 例によってチップ音なしのWASAPIでしか試してませんが、曲によっては無音領域どころか逆に巻き戻される(曲の進行が譜面に比べて遅い)こともありました。そのときは、チップよりだいぶん早く叩かないと Perfect が出ないという例の現象が現れます。

明日の甥っ子が来る(ドラム好き)までには何とかしたいところですが……うーん。

2013-01-01 16:45 更新者: yyagi
コメント

fromさん

その現象はタイマーがらみの話かと思われ、私には今日中に何とかするのは無理っす(^_^;;

運がよければ、AdjustWaves=OFFで回避できることは釈迦に説法ですが、これはデータに依るでしょうね。

2013-01-01 17:06 更新者: from
コメント

やっぱり、譜面と入力にかかる部分はCTimerではなくCSoundTimerを使うようにしないと解決しなさそうです。 SST では正常に機能してますので、HDDアクセスなどの問題はないと確信しています。

このズレは、間違いなく異なるタイマを混同利用していることが原因です。 うまく動くこともあるため後回しにするということでしたが、こちらではまったくと言っていいほど遊べない状態(障害)ですので、コードの最適化や見直し(改善)よりも優先して頂きたい課題ではあります。

自分で直そうとしたら、想像以上にソースが変わってた…… Global 全滅ッスか!

2013-01-01 17:48 更新者: yyagi
コメント

はい。Globalは必要そうなのをCSound.cs(のCSound管理やCSound)にコピってます。障害だというご指摘には同意いたしますが、何にせよ今日中にタイマー修正は無理っすよ。

あと大事なことを書き忘れてました。まだPlaySpeedに未対応です。これはどうしたものか。BASSに中途半端な周波数ってつっこめるのなら話は早いが、大丈夫かな・・・。

まとめますと、TODOはこんなところだと思っています。まだまだ多いな・・・(泣;;

  • タイマー統一 (譜面進行とサウンド出力、キー入力/MIDI入力/PAD入力。これらすべてで同じタイマーを使う、もしくはそれに準じた処理をする)
  • タイマー統一に伴う、AdjustWavesの廃止
  • チップのライフタイム導入 (BASSに同時に入力するチャネル数(ストリーム数)を減らして、WASAPI/ASIOのMIX処理を軽減する)
  • サウンド読み込み処理の高速化 (CSound.Clone()の追加)
  • PlaySpeed対応
  • CSound設計見直し
2013-01-01 18:23 更新者: from
コメント

暫定処置完了!

ひとまず、「うちの環境では」正常に演奏できるようになりました。 (試奏してたら、XP時代より良い記録が出てしまった(汗))

ttp://mainori-se.sakura.ne.jp/temp/DTXManiaGR_094_WASAPI_20130101SoundTimerVer.zip

修正点は以下の通りです。

  • 演奏・譜面に関するタイマをすべて CDTXMania.Timer から FDK.CSound管理.rc演奏用タイマ に変更。(アニメーションなど、演奏と関係無い部分は CDTXMania.Timer のまま)
  • WAV再生位置自動補正機能を廃止。(Config画面やiniには残るけど補正は行わない)

ソースは branch/130101~ に格納しておきました。これは、現時点での branch/120724~ から派生したものです。

なお、MIDI入力以外の入力時刻については修正してません。ですので、キーボードやジョイスティックだとヒット位置が環境依存でずれると思います(汗

また、サウンド関連のパラメータは一切触ってませんので、おそらく WASAPI のままです。遅延量もデフォルトです。ASIO は試していません。

これでなんとか、明日は甥っ子に受験勉強の発散をさせてやれそうですw

2013-01-01 18:30 更新者: sf298yen
コメント

やぎ。様

WASAPIの遅延を感じるとのことですが、バッファ量はどのくらいになってますでしょうか

…ここでごめんなさい。遅延を感じた最大の理由ですが、ASIO4ALLをインストールしたり削除したりしたときに、サウンドの設定をいろいろ変更してみたのを戻し忘れていたことが発覚しました。
⇒排他使用を許可しない設定になってました。WASAPI共有モードで動作!そりゃー遅いわけだ...orz
設定を修正してテストしました。⇒ バッファ294912bytes 48ms(更新間隔は6ms)
この状態では快適です。
よって、私の環境で問題レベルの遅延は Win7+DSの組み合わせだけとなりました。

補足:

Win7 / WASAPI / VSyncWait.On ⇒ CPU負荷:5%前後
Win7 / WASAPI / VSyncWait.Off ⇒ CPU負荷:2%前後



まだそれほどテストしていないのですが、from先生が指摘されているような、

曲によっては無音領域どころか逆に巻き戻される

といった症状には出くわしておりません。
XPメインでテストしていることと、VSyncWaitは基本Offのせいも関係するのでしょうか。

でも、この件はすでに議題に出ているぽいので現段階で私はスルーします。



補足2:

from先生はVSyncWaitをOnにしているということでしたのでこの切り替えも含めてテストするようにしたのですが、そのときに気づいたことを。ただ、120Hzで利用する人は少ないと思います。
リフレッシュレートを120Hzにしていると、VSyncWait.Onにするとすさまじくカクツキます。
Deleteキーで表示される情報を表示していると約100fps / オフで115-120fps(外部ツールでリアルタイム計測・表示しています)でした。
120fpsに近づいたときだけカクツキがやや減りました。
⇒リフレッシュレートを60Hzに変更すれば60fpsで動作し、カクツキはなく。
VSyncWait.Offならば2000fps程度出る環境なのに、120fps制限をかけてると思われる状態で期待したfpsにならないのは少し悔しい?というかモヤモヤしますね。
2013-01-01 19:15 更新者: from
コメント

あー。やっぱりXP時代に作られたDTXデータだとBGMに若干の遅れが……。

なんかSが出ない出ないと思ってたんですが、ほんの少し早めに打てば Perfect でした。

こればっかりは当初から想定されていた曲データ側の問題ですから、本体側ではどうしようもありませんね。

2013-01-01 21:32 更新者: yyagi
コメント

fromさん

あ…ありのまま 今 起こった事を話すぜ!

『所用で出かけて戻ってきたら、タイマー主要部分の修正が終わっていた』

(以下略)

ありがとうございます。今後は0101のBranchの方を活用させていただきます。 キーボードとジョイパッドのタイマーはこちらで何とかします。(rc演奏用タイマに変えるだけで済みそうですし)

XP時代に作られたDTXデータでBGMがずれるのは、致し方無しですね。BGMのタイミング調整機能はついていますので、書くユーザーにそれで対応してもらうようにしましょう。 (特定の日付以前のデータは無条件に一定値ずらすオプションをつけてもよいかも。)

sf298yenさん

WASAPI再確認、ありがとうございました。これでWASAPIがイマイチなのは私のところだけですね・・・うーん。

120Hzの件、GPUの強制フラッシュを入れる前(1227版)でも同じでしょうか。 また、フルスクリーン/ウインドウモード問わず同じでしょうか。

2013-01-02 01:51 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20121225.zip

キーボードとジョイパッド(とマウス)の、直接入力(BufferedInput=OFF)について、タイマーをrc演奏用タイマに変更しました。 バッファ入力(BufferInput=ON)の時は、まだシステムタイマーのままです。しまった、これは盲点だった。

DirectInputが中でどんなタイマーを使っているかは分かりませんので、こんな考え方で対応予定です。

  • 毎フレームなり、1秒に1回なり、SendInput()でダミーのキーボード入力をする。その際、rc演奏用タイマベースでの入力時刻を覚えておく。
  • バッファから取り出したキー入力には、システムタイマーベースでの入力時刻が付随している。
  • 一般の入力は、このダミー入力と比較して、rc演奏用タイマベースでの入力時刻を近似的に算出する。
例:
ダミー入力の rc演奏用タイマベースでの時刻を td_p, システムタイマベースでの時刻を td_s,
実際の入力の システムタイマベースでの時刻を t_sとすると、
実際の入力の rc演奏用タイマベースでの時刻 t_pは、
t_p = t_s - td_s + td_p
と近似できる。
2013-01-02 03:56 更新者: sf298yen
コメント

やぎ。様

これでWASAPIがイマイチなのは私のところだけですね・・・うーん。

私が我慢できる範囲、という意味ですので、私の環境でやぎ。様が試された場合にOKかイマイチと感じるかはわかりませんよ…。
特に私の感覚は頻繁に変わるという自覚がありますので(滝汗


120Hzの件、GPUの強制フラッシュを入れる前(1227版)でも同じでしょうか。 また、フルスクリーン/ウインドウモード問わず同じでしょうか。

095版でも同じ症状でしたので、今回の修正(GPUフラッシュ等?)とはあまり関係はないと思っています。
ですが、話として出たので一応記述させていただきます。


⇒テストはXP+095で行っています。デバイスドライバ側の設定の垂直同期は「3D アプリ設定を使用」。120Hz駆動

  • Window.Sync.On ⇒ カクカクします。フレームが120fpsに近づいたときに少しだけスムーズに。(100-120fps)
    Window.Sync.Off ⇒ スムーズです。(900-2000fps)
  • Full.Sync.On ⇒ スムーズです。ですが、なぜかフレームレートが75fpsに固定されます。(75fps)
    Full.Sync.Off ⇒ スムーズです。(900-2000fps)


⇒デバイスドライバ側の垂直同期設定「(強制)オフ」

全てスムーズです。(900-2000fps)


60Hz駆動ではドライバの設定が連動/Off、Window.Sync.On/Offを含めて全てスムーズです。

よって気になるのは「●」の2パターンです。



’ 余談ですが、メッセージのやりとりみてて思ったこと。
from先生の仕事はえぇ... しかも子供思いというのがニクイ演出ですね


tp://yyagi.com/DTXManiaGR_094_WASAPI_20121225.zip

バージョンバック?勝手に下記ファイルかと検討つけてダウンしてみました。ダウンロードもちゃんと出来たし(ぉ
DTXManiaGR_094_WASAPI_20130102.zip
2013-01-03 02:07 更新者: yyagi
コメント

sf298yenさん

ご回答いただきありがというございました。fpsの件は正直心当たりがないのですが、意識しておくようにいたします。 (動作からおわかりの通り、60Hzに特化した作りにはなっていないのですが・・・。)


強は特にzipでは公開いたしませんが、今日の対応で

  • PlaySpeedに対応しました。従来と同じ、周波数を変更する方式です。実はBassFxでタイムストレッチ(ピッチを変えずにテンポ変更する)ができるようなので試行錯誤してみたのですが、うまくいきませんでした。BassMix使っているとタイムストレッチできないんだろうか。BASSの設計思想からすると、そんなことないと思うのですけれどね。
  • BufferedInput=ONのときの入力誤差最小化は、今日のところは対応できませんでした。なぜかSendInput()で自動文字入力できず。SendInput()だけのテストプログラムを作ってこれまた試行錯誤しましたがダメでした。なんでー。
  • チップのライフタイム導入は未着手。上記2つでちょっと詰まってしまったので、明日はここをやってみようかなと思ってます。
2013-01-03 03:44 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130103.zip

  • PlaySpeedに対応しました。
  • BufferedInput=ONのときの入力誤差最小化に対応しました。DirectInputが内部でmultimediaタイマー(timeGetTime())を使っている前提で決め打ちです。下記を見る限り、それで作ってしまって実用上差し支えなさそうでしたので。

tp://msdn.microsoft.com/ja-jp/library/bb219640(v=vs.85).aspx

2013-01-04 00:39 更新者: yyagi
コメント

出先で使っているノートPCが死にました。別のPCに開発環境を設定するのに一苦労でした。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130104.zip

  • CONFIGURATIONの画面でSoundDeviceTypeとASIOBufferSizeを設定できるようにしました(デバッグをやっていてこの辺をいじるのがだんだん面倒になってきたので・・・)。ただ、設定反映にはアプリ再起動が必要です。(SSTの設計では再起動不要になっていますが、とりあえず再起動ありでサクッと機能を突っ込みました)
  • 演奏画面の演奏情報に、ストリーム数(おおよそ、WAV定義数*PolyphonicSoundsの値)と、ミキサーに登録しているストリーム数を表示するようにしました。これもデバッグ用です。
  • チップ音の簡単なライフタイム制御を入れました。再生開始時にミキサーに登録して、再生終了時にミキサーから削除しています。これでギターありの曲データもWASAPI/ASIOで再生できるようにはなりました。ただ、ピクピク動作が重くなってます。真面目に負荷分散しないとダメそうです(発音の数秒前に少しずつミキサーに登録する、ミキサーからの削除は発音終了後直ちには行わず少し待つ。)
2013-01-04 22:08 更新者: sf298yen
コメント

出先で使っているノートPCが死にました。

Ω\(-""-) ご愁傷様です……


質問?なのですが、以前からですがBufferdInput=ONのときに表示されるラグタイムですが、似たような数字だけが出るケースがありますが、それは仕様的レベルでしょうか?
「1、7、1,1,7,7・・・」みたいに似たような数字が続く場合があるんです。これが誤差最小化の結果、ということなのでしょうか?

CONFIGURATIONの画面でSoundDeviceTypeとASIOBufferSizeを設定できるようにしました


このバッファサイズの指定ですが、上下が1ずつだと大変なので、デフォルトで16ずつとか128ずつとかの単位で上下するようにしてみてはどうでしょうか?
例えば、普通の↑↓で16ずつ、Shiftキーと同時で128ずつ、Ctrlと同時で1ずつ、、、みたいにするとよりスムーズかも、、と思ってみた。 でもこの機能つけるほうが面倒!という気がしないでもない:)
2013-01-05 10:39 更新者: yyagi
コメント

BufferedInput=ONの件、「以前から」ということでしたら、対応時期から言って、誤差最小化云々は関係ございません。多分OS内部で入力をスキャンしている間隔が、BufferedInput=OFFの時よりも長い、ということなのだと思います。

なお、BufferedInput=OFFの時は、明示的に毎フレームごとに入力をスキャンしています。1000fpsなら、1ms間隔でのスキャンということになりますので、sf298yenさんの環境でしたらOFFのほうがよさそうですね。(こちらの環境では100~300fps位なので、ONのほうがよさげです)

ASIOBuffedSizeの設定操作についてご提案ありがとうございます。そのうち入れ込んでみます。

2013-01-05 22:15 更新者: sf298yen
コメント

福沢さん1人と夏目さん10人ではどちらが喜ばれますかね・・・

BufferedInput=ONの件、「以前から」ということでしたら、対応時期から言って、誤差最小化云々は関係ございません。多分OS内部で入力をスキャンしている間隔が、BufferedInput=OFFの時よりも長い、ということなのだと思います。


なるほど、そうでしたか。回答していただきありがとうございます。
漠然とONのほうが正確に判定してもらえるのかなーと盲目的に思っていました。
きっとこんな誤解をしているのは私だけじゃない・・・ハズ!(汗

(こちらの環境では100~300fps位なので、ONのほうがよさげです)

そうなると「Sync=ONな場合は」BufferdInput=ONのほうがよい可能性が高い、ということですよね?
逆にOffのほうがよいのは、一概には言えないのでしょうが、500fps以上出る環境の場合とかそういうイメージでよいのでしょうか。
2013-01-06 21:19 更新者: yyagi
コメント

sf298yenさん

私は2千円札をよく包んでました・・・。

BufferedInputのON/OFFどちらがよいかについては、「環境による」ということなのだと思います。私は今回初めて「似たような数字しか出ない事例」を聞きましたし・・・。

OSが何ms刻みでキーボードやマウスの状態を確認しているか、が重要なのであって、FPSは特に関係しないはずです(なので目安にならない)。これと言ってよい確認方法はありませんので、結局のところは「ONとOFF両方試してみて、調子が良さそうな方を使って下さい」となるかなと思います。

2013-01-06 21:41 更新者: yyagi
コメント

fromさん

一応PCIexなサウンドカードでもWASAPI/ASIOの動作確認(というか遅延の程度の比較)が必要かと思い、SoundBlaster X-Fi Titanium HDを買ってきました。(これしか売ってなかった・・・)

で、ASIOで動作確認してみたのですが、とんでもない音が出ます。基本はサンプリングレートがずれたような感じなのですが、そこに更にノイズその他色々変な要素が混じるような感じ。

そこでFDKのASIO対応部のソースをこねくり回したところ、BASS_Mixerの出力チャネル数を2に固定することで問題回避できました。 (他のデバイスでの副作用が心配でしたので、一応、回避する/しないのConfigをつけました)

また、ASIO対応でだけ、「既定の出力デバイス」でなく「enumerateして最初に出てきた出力デバイス」を使っていたようですので、これも既定デバイスを使うよう修正しました。(TitaniumとUA-5の両方挿しという豪華環境で現象確認(笑))

どちらもrev490のCSoundDeviceASIO.csにて対応しましたので、必要に応じてSSTにも適用下さいませ。

2013-01-07 00:12 更新者: from
コメント

検証お疲れ様です。ちたにうむ買いましたかー。豪華だ!

で、さっそく CSoundDeviceASIO.cs を拝見させて頂きました。

おおう。確かにヘルプには「0 = first device」とか書いてますね。BASS では「0 = no device」なのに……紛らわしい。

で、少し気になった点がいくつか。

  • BASS_ASIO_Init() で BASS_ASIO_DEFAULT が指定されていますが、このフラグはこの関数には使えないはずですよ。C++ で組むと該当するフラグが存在しないのですぐ分かりますが、BASS.NET ではこの辺の区別を付けてないので非常に紛らわしいんですよね。一応ヘルプでも確認しました。
  • Init() のあとに BASS_ASIO_SetDevice() をされていますが、これは「calls in the current thread」で使うためのデバイスの指定だそうです。Init() で ASIO デバイスを別スレッドで起動するフラグを付けていますので、この関数は無効になるのでは?
  • 強制的に 2ch にしなければ音がおかしいということですが、ちたにうむの標準デバイスは 8ch (7.1ch) だと思います。私はもともと、デバイス出力が何チャンネルあろうが、出力チャンネル(≠ストリームチャンネル)は ch.1 を BASS_ASIO_ChannelJoin() した ch.0 しか BASS_ASIO_ChannelEnable() していませんでしたので、その辺りの影響は考えられないでしょうか?(というか、うちも標準 8ch なのですけど……)

とはいえ、参考にさせて頂きます-。 ありがとうございます。

2013-01-07 00:18 更新者: from
コメント

p.s.

……とは言え、SST の動作環境は「Win7 以上」なので、ぶっちゃけ ASIO 非対応でも全然問題ないんですけどね(笑

WASASPI 標準搭載バンザイ。

2013-01-07 00:28 更新者: yyagi
コメント

fromさん

  • BASS_ASIO_DEFAULT : ヘルプには書いてないのですが、サンプルコードには書かれていたのですよ。まあ元の問題現象との関係はないことが分かりましたので、削っておきますね。
  • SetDevice()はおっしゃる通りかと存じます。ご指摘ありがとうございます。これも削っておきます。
  • 8chだか2chだかの件、こちらでも、Reltekの内蔵音源(+ASIO4ALL)はたくさんのチャンネルが出てくるんですが、こちらは特に小細工しなくても元のソースのままで正常動作しました。が、一応ch1もChannelEnableしてみましょうかね。(ヘルプではChannelJoinすると以後Joinされた側のattributeに従うって書いてありましたけれど・・・(volumeを除く)・・・まあ騙されることはよくあることなので、とにかく試してみましょう。
2013-01-07 01:23 更新者: from
コメント

一応ch1もChannelEnableしてみましょうかね。

ch.1 は ch.0 に Join してるので、ch.0 しか Enable できないと思いますよ。

そうではなくて、出力デバイスが 8ch になっているなら ch.2~7 も ch.0 に Join させる必要があるのでは?とか何とか考えたり。

てか、ASIO の標準ステレオデバイスは ch.0 と 1 が左右チャンネルになっているはずなのですが……

2013-01-07 02:11 更新者: yyagi
コメント

出力デバイスが 8ch になっているなら ch.2~7 も ch.0 に Join させる必要があるのでは?

これで解決しました。お騒がせしました。ただ、他に色々いじってしまっているので、コミットは後日別途。

# よくみたらそんな実装の名残が残ってましたね。

2013-01-07 02:23 更新者: yyagi
コメント

それと、ASIOの既定デバイス取得のところですが、うまく動いていないようです(涙;;;

何度やっても、1台目として見えているCreative ASIOではなく、2番目に見えているがつなげていないUA-5が既定デバイス見えしてしまう・・・(当然、OS上の既定デバイス設定は済ませています)

2013-01-07 05:24 更新者: sf298yen
コメント

二千円札・・・自販機で美琴様が爆笑していましたね(謎

確かに珍しい2枚のほうが樋口さん1枚より騙s~bs~bs喜ばれるかもしれないですね。
よし、私もこれからはそうしよう。

私は今回初めて「似たような数字しか出ない事例」を聞きましたし・・・。

出る数字が、例えば6単位「...-6,0,6,12...」のように飛び飛びになり、その間の数字が出ない(出にくい?)現象です。
しばらくすると今度は「...-5,1,7,13...」のようになり・・といった感じでした。
Offでそういうのは見かけなくなったので大丈夫だと思われます。お騒がせしました。

「BufferdInput On/Off」

これと言ってよい確認方法はありませんので、結局のところは「ONとOFF両方試してみて、調子が良さそうな方を使って下さい」

了解しました。
2013-01-08 21:56 更新者: kairera0467
コメント

更新お疲れ様です。プレイしていて気づいたのですが、 デバイスがDirectShowの時にpresoundにmp3形式のファイルが指定されているものを選択すると、本体側で再生される前に一瞬変な音が鳴ります。 それからDirectShowの時にpresoundがループせず、WASAPIの場合は2回目の途中で切れてしまいます。

2013-01-11 00:22 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130110.zip

WASAPI/ASIO時、動的にBass.Mixerへのチャネル追加/削除を行うようにしました。(発音予定時刻の1秒前にミキサー追加、発音終了予定時刻の0.8秒後に削除)。これにより、ギター曲などチップ定義が多い曲データも支障なく演奏できるようになりました。

ただし、ミキサーの追加/削除の負荷は結構大きいみたいで、画面スクロールにがたつきが出ることがあります。 これが気になる場合は、Config.ini の DynamicBassMixerManagement を0にしてください。 動的制御をしなくなります。(ドラム曲であればほぼ支障なく演奏できます)

将来的にはミキサーへの追加削除の負荷をうまく散らすようにして、演奏画面に支障が出ないようにしたいところです。 (別スレッドでミキサーへの追加削除を管理するクラスを動かして、同時に多数の追加削除が発生しないようにすればよいのかなと考えていますが、これは試してみないと何とも言えないところです)

あと、私のところでは、Titanium HDを使うと曲のテンポがふらついて演奏に耐えられません。動的なミキサー制御を外しても同様です。基本処理で負荷を増やすようなことは特にしていないはずですが・・・

kairera0467さん

動作確認いただいてありがとうございます。 申し訳ないのですが、ここ(Branch)ではWASAPI/ASIOの試作を目的としているため、DirectShow時の動作は特に行っていません。 presoundがループしないのは確かにそうだと思います(実装無し。) WASAPIの場合にループが途中で止まるのは今回のモジュールでは解消していると思います。 (前回のバージョンでは、再生完了後3秒したら動的にサウンドをミキサーから削除するようにしていたため。)

2013-01-11 02:46 更新者: yyagi
コメント

あと、私のところでは、Titanium HDを使うと曲のテンポがふらついて演奏に耐えられません。動的なミキサー制御を外しても同様です。基本処理で負荷を増やすようなことは特にしていないはずですが・・・

ASIOのバッファ量を小さくしたら現象が出なくなりました。お騒がせしました。

私の場合、Titanium HDのデフォルト設定が50msになっているところを、20や10, 5msなどにしたところ改善しました。

しかし、この手の話は普通バッファが小さすぎるときに出るものだと思っていましたが、何故に逆の出方をするのだか。

2013-01-12 21:45 更新者: sf298yen
コメント

お疲れさまです。
環境や曲にもよるのでしょうが、ASIO/WASAPI共に50ms以上だといろいろきつい感じですね...

私の環境では10ms以下に設定するとノイズが入ってしまう為、やむを得ず20msで勤しんでいただかせています。
10msや5msで動かせるなんて羨ましい(呪 ちなみに私の感覚では30ms以下までなら快適だと思えました。
40ms前後で少々違和感が大きくなり、50ms以上では厳しいかもしれない・・・という印象です。

Win7+DSで感じた違和感も、ASIO/WASAPIで解決できるとわかって今後が非常に楽しみです。
'
一番最初のWASAPIサンプルに含まれていた vshost.exeが気になっております:)

2013-01-15 00:59 更新者: yyagi
コメント

ご確認いただきありがとうございます。

WASAPIの方も、バッファサイズを個別に設定できるようにするつもりでいます。ASIOと違って、WASAPIはバッファ量を自動設定に任せると、私の環境だと70ms程度に設定されてしまうのですが、プログラム内で10msとかを設定すると、14msなど悪くない値になるようなので。

vshost.exe は、VisualStudioでビルドすると生成される、デバッグ用のexeです。変な期待を抱かせてしまって申し訳ございませんが、どうぞお気になさりませぬよう。

とはいえ、私は元々ネット経由でのセッションやIRとかをやりたくて本体の開発に入ってきた次第だったりします。 そして、まず第一段階はバグ取りと、最低限の基本機能の底上げを行い(後は区間内の繰り返し練習機能さえ実現できれば・・・)、第二段階として出力ラグを削っているような状況ですので、今のところ順番通りに対応できているとは言えます。 仕事の都合で、開発の進みが非常に遅いのが申し訳ないところですが。

2013-01-15 19:55 更新者: sf298yen
コメント

爆弾低気圧は怖いですね・・・

WASAPIの方も、バッファサイズを個別に設定できるようにするつもりでいます。 ・・・プログラム内で10msとかを設定すると、14msなど悪くない値になるようなので。

それはよさそうな感じですね、楽しみにしています。

vshost.exe は、VisualStudioでビルドすると生成される、デバッグ用のexeです。

ぬぉ…そういうオチだったとはorz
こんな紛らわしい名前をつけたMS・・・。 某VirtualDubのASFファイルのソースコードを適用する!

とはいえ、私は元々ネット経由でのセッションやIRとかをやりたくて本体の開発に入ってきた次第だったりします。

お忙しい中がんばってらっしゃる姿には本気で感服・感謝しております。
以前その件がらみでfrom先生に怒られたよーな違うよーな(苦笑
セッションといえば相手も同じファイルを持っていることが前提になりますので、相手に譜面をコピーすることを考えて以前ちらっとチケットに出した譜面のコンパイル(?)もこの為に使うのはありかもしれませんね。
2013-01-16 02:33 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130115.zip

取り立てて代わり映えするものではございませんが、

  • WASAPIのサウンドバッファ量をConfigで設定できるようにしました。0で自動設定ですが、どうも70msなど大きめの値になるので、手動設定すべきです。1~99999(ms)を設定すると、それより小さくならない値で近い値を自動設定します。私の環境の場合、10msを設定すると12msとなりましたが音がブチブチで使い物にならず。20msを指定すると28msになり、これだとまあまあでした。実際に設定された値は、DTXManiaLog.txtを参照してください。
  • これにあわせて、Config.iniの ASIOBufferSize を、ASIOBufferSizeMs に名称変更し、ASIOのバッファサイズもWASAPIと同じようにms単位で設定するように変更しました(というかSSTでの元の仕様に戻しました)
  • PolyphonicSoundsの初期値を、4から2に変更しました。また、#NOWLOADING_SOUND を、演奏開始前に開放(ミキサーから削除)するようにしました。どちらもミキシングの負荷削減のための処置です。

バグ修正:

  • ASIOのバッファ量の設定で、0以外の値を設定したときに正しく設定されていなかった問題を修正しました。
  • サウンドファイルが存在しないチップ音を鳴らしたときに例外発生していた問題を修正しました。

既知の問題: (いい機会なのでまとめておきます)

  • XPなど、WASAPIが使えない状態でWASAPIを指定すると、WASAPIだけでなくASIOの設定にも100%失敗し、必ずDirectShowでの再生となります。当面は、ASIO使用時はASIOを明示的に指定して下さい。
  • ASIO指定時、特定のサウンドデバイスを固定的に使用する(最初に見つけたデバイスで固定)。どうも通常のサウンドデバイスの概念とASIOデバイスの概念は別物で、これらは同期していないようなので、いわゆる「既定のサウンドデバイス」として設定されているものがASIOのサウンドデバイスだとどれに該当するかの関連を確実に取得する手段がありません。申し訳ないのですが、ASIO使用時はデバイスをユーザーに明示的に選択させるようにしないと駄目そうです。
  • PolyphonicSoundsを4に戻すと、ギター曲のもたつきがまだ大きいです。ギターのチップのライフタイムは、ドラムのそれとは区別して扱うべきかも知れません。(生存期間をより短くする、同時発音数を変える、など)
  • 演奏が激しいとスクロールががたつきます。ミキサーへの登録/削除を激しく行うためです。同時に多数のミキサー制御を発生させることの無いよう、負荷分散のロジックを追加する必要があります。
  • DirectShowでの動作はほとんど未確認です。ただ、少なくとも以下の問題を把握しています。
  • * mp3再生開始時にノイズが入る。(原因不明)
  • * サウンドの読み込みが非常に遅い。(サウンドのDuplicateに対応する前の実装に戻っているため。現在の実装に戻せばよい)
2013-01-16 21:14 更新者: sf298yen
コメント

とりあえず1週間以上IPアドレスが通知されていないそうです(謎

お疲れさまです。更新はもちろん楽しみにしているのですが、なにぶん私よりもはるかにお忙しいご様子。 無理などされないようにお願いします。

’ 私は主にドラム譜面しかやらない(というかギター譜面がほぼない)のですが、コメントを読んでいると時々思うのはやぎ。様はギター譜面の利用頻度も高い?

2013-01-17 21:32 更新者: yyagi
コメント

ギター譜面については、私が開発で必ずテストするようにしてます(後述する信心ワールドエンドなど)。 以前は全然テストしていなかったので、ギター周りのバグがものすごいことになっていたのですよ・・・。

さて、おかげさまで、昨晩は随分と開発が進みました。既知問題の内、負荷分散の話以外は全て対応できました。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130117.zip

具体的な対応内容は・・・たくさんありますので、詳細はコミット(rev494,495)のログを直接ご覧下さい。

  • tp://sourceforge.jp/projects/dtxmania/scm/svn/commits/494
  • tp://sourceforge.jp/projects/dtxmania/scm/svn/commits/495

これで性能的なところはほぼ問題ないレベルに落ち着きましたので、さらなる負荷分散の対応は取りあえず棚上げとします。 1.6GHz/2CoreなCPU・XP SP3・UA-5のASIO(バッファ17ms)・信心ワールドエンドExtremeで60fpsをキープできていますので、個人的にはこれで満足です。

WASAPI/ASIO/DirectSound対応はこんなところかなと思っていますが、何か問題があればお知らせ下さい。

2013-01-19 00:14 更新者: sf298yen
コメント

ギターの信心ワールドエンドexは、スキル6kしかない私には無理!orz
どうせギターをやるなら3レーンじゃなく5~6レーンのほうがいいなぁ・・・。

さて、本題。更新お疲れ様です。
テストというほどまだ動かしていないのですが、気づいた点を。

  • 演奏開始時に微妙にBGMがズレる場合があります(Shift+F1のポーズを挟む等すると直る)。(ASIO使用時でした。WASAPIでは不明)
    ⇒毎回再現できるわけではないのが厄介です。。。負荷の関係でしょうか?少なくとも3回程遭遇しています。


  • 演奏時1小節消える場合がありました。いきなり音が飛んで、コンボが消えてゲージがいきなりガクっと減ったので・・・飛んだ小節の部分はミス判定になっているのかと。(ASIO使用時でした。WASAPIでは不明)
    ⇒例えば・・・151節、152節、153節と順番に再生されるはずが151節、153節・・・と再生な感じでした。
    ⇒2回程遭遇したのですが、その2回とも発生箇所が違った上に再現しない・・・。たまたま私の環境による偶発的なものだったのかもしれません。


  • Win7+DSでは画面がカクカクになりましてヨ?
    fps計測ツールでは1500fps以上なのに、表示されている速度は30fps相当?ってなくらいカクカク・・・かも。私の環境だけかもしれません。
    WASAPIとASIOがあるからいいやー!って思ってみましたが、WASAPI/ASIOでもしばらくプレイしているとカクカクになるケースがorz
2013-01-19 21:21 更新者: yyagi
コメント

ご確認いただき、ありがとうございます。

  • 演奏開始時のBGMずれは確かに負荷かなと言う気がしますが、こちらでも確認してみます。ただ、こちらでは今のところ再現できておらず。
  • 小節スキップはタイマ絡みの問題の可能性もありますが、とりあえず(WASAPI/ASIO時は)AdjustWaveをOFFにすると改善するかも知れません。ただしAsjustWavesをOFFにすると、BGMの位置補正がきかなくなるかもですが。
  • Win7+DSでこちらはカクカクになることはありませんが・・・なんでだろ・・・。
2013-01-20 02:05 更新者: sf298yen
コメント

おつかれさまです。3時間ほど動かしてみました。

  • 演奏開始時のBGMズレが時々発生します。XP/Win7共に.
    再発確認しました。DTXMania起動直後に選曲した中でで発生することが多いのでやはり負荷なのかも?


  • 小節スキップの件
    AdjustWaveをOn/Off切り替えながら数時間試しましたが今のところ確認できないので保留お願いします。


'Bug ⇒ AdjustWavesですが、Config画面からの変更が終了時に保存されません。(Config.iniの値が継続。)


  • Win7+DSですがやはりカクカクしています。カクカク、、というと極端なイメージをされるかもしれませんが、60fps程滑らかでない、という表現のほうがが正しく伝わるでしょうか。Full/Window共に必ず発生します。また、この症状はASIO/WASAPIでも、しばらく演奏していると同様な症状が発生しちゃいます。ただASIO/WASAPIは症状が出たり消えたりです。
2013-01-20 10:44 更新者: from
コメント

お疲れ様です。

BGMズレの件ですけど、BASS関係の今のDTXManiaの仕様(初回再生時にミキサーに追加する)だと、プリロードが出来ない(&ミキサ内部でプレバッファの追加合成が起きる)ためにデコード遅延が発生していて、そのせいで次回のASIOのバッファフリップにデータ出力が間に合わず、次々回に繰り越しされている可能性はないでしょうか?

例えば ASIO のバッファを 20ms にしている場合、繰り越しが発生しなければ 20~40ms、発生すれば40~60ms(かそれ以上、プリロードが完了するまでの時間に依存)の間でズレが発生すると思われます。

また、WASAPIの場合はバッファサイズではなく更新間隔が対象になりますので、バッファを 20ms、更新間隔を 4ms にしている場合は、繰り越しが発生しなければ 20~24ms、発生すれば 24~28ms(かそれ以上、理由は同上)の間のズレになると思います。

参考までに、DirectSound の場合は、サウンドバッファを作成した時点で先頭の数ミリ秒を内部にプリロードしており、Play 指示が来たときには即座にカーネルミキサーにデータ出力ができるようになっています。

ということで、BGM だけでもチャンネル生成時からミキサに追加し、さらに、初期の仕様(チャンネル作成直後にチャンネルを一時停止)に戻してみてはいかがでしょうか?(デコード自体を即時停止してしまう BASS_MIXER_PAUSE を指定するとプリロードも行われない可能性が高いかと)


ややこしいですが、BASS.NET にある BASS_Mixer_ChannelPause() という関数は、bassmix.dll には存在しません。 おそらく内部では bass.dll の BASS_ChannelPause() にマッピングされているものと思われます。

BASS_MIXER_PAUSE は間違いなく「デコードを停止する」と記載がありますが、(ミキサアドオンを考慮していないはずの)BASS_ChannelPause() については明記されていません。 なので、プリロードされる可能性は少しは残っているのかなと思う次第です。

2013-01-20 11:00 更新者: from
コメント

追記:

考えてみれば、bass がデコードした後のデータを受け取るはずの bassmix が、入力の前段階であり自分の管轄外であるはずのデコードまで停止してしまうんでしょうね。ストリームの入力を停止する、ならわかるのですが。

ストリームの入力を停止するだけなら、bassmix 側で pause していても、bass 側でのストリームのデコードは続けられると思うのですが。

BASS_MIXER_PAUSE により bassmix から bass の BASS_ChannelPause() を呼び出しているのであれば、この関数でもデコード自体が停止してしまう可能性は高いですね。

……まだまだよく分からないですね。

2013-01-20 12:34 更新者: yyagi
コメント

コメントいただきありがとうございます。

BASSやBASS.NETのソースは公開されていませんので全部想像にはなってしまうのですけれども、fromさんのおっしゃる理屈は凄く筋が通っています。

ただ、結局は試してみないと分からないところだと思いますので・・・早速作りました。

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130120.zip

修正点は、fromさんの見解を見てこちらでも考えては見ましたが、結局はfromさんのご提案と同じです。

  • BGM だけは、チャンネル生成時からミキサに追加する
  • 初期の仕様(チャンネル作成直後にチャンネルを一時停止)に戻す

こちらで少し動かしてみた限りでは、以下の感触を受けました。

  • チップ音の読み込み時間が長くなっている。→ 今までホントにサウンドデータをプリロードしていなかった? 私には俄には信じられないことだが・・・。
  • たまに演奏が数百msほど固まり、その間DTXManiaの動作が固まるようになった。17日版の開発時にこの現象が出始めて、演奏中のGCを停止することで現象が出なくなったのだが、そのコードが残っているにも関わらずまた出るようになった。

ASIO等の処理で数百msも割り込み停止するとは思えないので、考えられるのはBassNet.DLL内でGCが発生したか、私の環境のサウンドドライバ(Creativeぅ・・)が腐っているか。どちらにせよこちらとしてはミキサー操作が同時に多数発生しないように負荷分散するくらいしか手がなさそう。

ただ、別の意味ではサウンドドライバが腐っている模様。サウンドカードを挿してからというものの、非常に頻繁にBSODや動作停止に見舞われるようになった。俺、WASAPI/ASIO対応の正式版をリリースしたら、とっととTitamumHDをシステムから外すんだ・・・状態。

2013-01-21 10:03 更新者: sf298yen
コメント

お疲れ様です。夜勤から帰ってきたので早速試させていただきました。(DTXManiaGR_094_WASAPI_20130120.zip)

申し訳ないのですが、やはりBGMズレ発生します・・・。
Windowsを立ち上げて最初にプレイした1曲目で(今のところ)100%ズレます。
2曲目以降や、DTXManiaを再起動後は(今のところ)発生しません。

  • チップ音の読み込み時間が長くなっている。
    これは私は体感できませんでした。(チップ数が少ない曲でしかやっていないのでそのせいかもしれませんが。)
    もしくはやぎ。様と私が動かしているプログラムは違う?(タイトルは 「DTXMania .NET style release 095(121201) (ASIO)」)


  • たまに演奏が数百msほど固まり、その間DTXManiaの動作が固まるようになった。17日版の開発時にこの現象が出始めて…
    この現象も私には発生しません。ただAVIを再生していると似たようなプチフリーズは稀に発生します。(テスト中はAVIオフにしてます)


サウンドカードを挿してからというものの、非常に頻繁にBSODや動作停止に見舞われるようになった。

サウンドカードでのトラブルは結構報告多いのですよね・・・。 しかしBSODは本当に痛いですね。
釈迦に説法でしょうが、BSODでのトラブルで多かった原因はカードの接触不良(ゴミやノイズ)というケースとドライバの不良、相性問題などなどでしたでしょうか。最近のドライバはそこまで不良は多くないと信じたいのですが・・・。一度カードの挿し直しで直ったりしませんか?
2013-01-21 18:44 更新者: sf298yen
コメント

BGMズレについて追記:

発生するのは(私の)XP環境だけかも...。Win7では何回か試しましたが発生しませんでした:(
2013-01-21 22:35 更新者: yyagi
コメント

そちらのXPでBGMズレする理由はまだ分かりませんが・・・

tp://yyagi.com/DTXManiaGR_094_WASAPI_20130121.zip

  • ベースバージョンをを095にしました。
  • ミキサー制御の負荷分散機能を導入(同時に複数のミキサー制御を行わず、最低7msの間隔を空けて行うようにした)。別スレッドでミキサー制御することなども試みましたが、結局メインスレッドからミキサー制御するのが一番低負荷(画面描画がカクつくほどの長時間、ミキサー制御に拘束されない)でした。
  • 演奏画面でほんの少しだけ高速化(負荷削減)をしました。

これで、WASAPI/ASIO時にVSyncWaitをOFFにしてスクロール速度を上げても、がたつきが全く目立たなくなりました。 数百msの動作停止も今のところ発生していません。

一応Win7+ASIOで動作確認してます。これからWin7+DSや、XP+ASIOでも確認してみます。

2013-01-23 02:12 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130122.zip

  • DTXMania起動中にWASAPI/ASIOの設定が反映されるように対応しました。(設定変更のためにアプリを再起動させなくてよくなりました)
  • ギタレボ画面でサウンドのミキサー制御の実装を入れ忘れてましたので入れました。すみません。
  • AdujustWaveが動作していなかったので対応しました。へっぽこミス、すみません。ただ、近いうちに、AdjustWavesはDirectSound時のみ動作するようにして、WASAPI/ASIO時は動作させないようにするつもりです。
2013-01-23 12:16 更新者: sf298yen
コメント

お疲れ様です。「DTXManiaGR_095_WASAPI_20130122.zip」
1時間(XP+ASIOのみ)程ですが、動かしてみました。


Case : XP / AdjustWaves.On / VSyncWait.Off(BufferdInput.off) / AVI.On / ASIO(BuffSize.20)

§ 小節毎に音が切れる症状が発生しました。

⇒ AdjustWaves.Offで直る(症状がでない)
ですが、ASIO/WASAPIでは使わない方向らしいので気にしないでよさげですかね



Case : XP / AdjustWaves.Off / VSyncWait.Off(BufferdInput.off) / AVI.On / ASIO(BuffSize.20)

(ユーザーフォーラム#67035 プチフリーズ現象)

演奏画面でのGC(Garbage Collection)を止めるようにした

動かした時間が短いので断言は出来ませんが、確かに大きめのフリーズが軽減したように感じました。
ですが無くなってはいません。別の要因なのかやはり時々プチフリは発生します。
※また今回は時間の都合でAVI.Offのでテストをしていません。今までOffではプチフリは発生していませんが・・・。

DTXMania起動中にWASAPI/ASIOの設定が反映されるように対応しました。(設定変更のためにアプリを再起動させなくてよくなりました)

何気にこれがちょーーー便利:)いいよ、これ(ジュルリ

§ タスクマネージャでメモリ使用量を見ていましたが、徐々に使用量があがっていきました。

起動直後 : 約43MB前後
1時間程後 : 約150MB前後


明日・明後日は休みなので時間が取れたらWin7をメインにガッツリ動かそうとたくらんでいます。

2013-01-24 09:28 更新者: sf298yen
コメント

外出予定のため少ししか動かせていませんが、Win7でプレイした追記です。
厄介な話ばかりでいつもすみません(涙
「DTXManiaGR_095_WASAPI_20130122.zip」

Case : Win7 / AdjustWaves.Off / VSyncWait.On(BufferdInput.On) / AVI.On / ASIO(BuffSize.20) | WASAPI(BuffSize.20)

プチフリはあるけど、VSyncWait.Offよりは軽微。 ただ、なんとなくプレイ感覚が「重い」。

Case : Win7 / AdjustWaves.Off / VSyncWait.Off(BufferdInput.Off) / AVI.On / ASIO(BuffSize.20) | WASAPI(BuffSize.20)

プチフリはある(長いのも)。プレイ感覚は「軽い」。

Case : Win7 / * / AVI.Off / ASIO(BuffSize.20) | WASAPI(BuffSize.20)

プチフリは発生しにくい(今のところ知覚出来たのはないです)。

※ここでの重い・軽いはキー入力に対してのレスポンスの体感です。

AVIを使う前提ならば、Sync.Onの60fpsでプレイすればプチフリの影響は最少でいけそうです。
Sync.Offだと長いプチフリが発生するので実用ではないレベルかもしれませんorz
AVIを使用しないならば、Sync.Offで軽い演奏が楽しめますが・・・やはり画像が欲しい...(贅沢ですか(悩

'Bug? ASIO → DirectShowに切り替えたらメモリ不足で落ちた。(タスクマネージャ上は800,000k超えてた。)
ASIO/WASAPIからDirectShowに切り替えるとメモリ使用量が増えるぽい。(+100M程度?)

-- ログ抜粋 --

2013/01/24 09:01:35.499 [INFO] ■ コンフィグ
2013/01/24 09:01:35.499 [INFO] コンフィグステージを活性化します。
2013/01/24 09:01:35.499 [INFO]     コンフィグステージの活性化を完了しました。
2013/01/24 09:01:35.537 [INFO] ASIO Device 0: ASIO4ALL v2
2013/01/24 09:01:35.537 [INFO] ASIO Device 1: Creative ASIO
2013/01/24 09:01:40.014 [INFO] コンフィグステージを非活性化します。
2013/01/24 09:01:40.015 [INFO]     ASIO Device 0: ASIO4ALL v2
2013/01/24 09:01:40.015 [INFO]     ASIO Device 1: Creative ASIO
2013/01/24 09:01:40.278 [INFO]     DirectSound の初期化を開始します。
2013/01/24 09:01:40.374 [INFO]     DirectSound を初期化しました。(Priority)
2013/01/24 09:01:58.322 [INFO]     E_OUTOFMEMORY: Ran out of memory (-2147024882)
2013/01/24 09:01:58.377 [INFO]     未対応の SoundDeviceType です。[Unknown]
2013/01/24 09:01:58.378 [INFO]     コンフィグステージの非活性化を完了しました。
System.Exception: サウンドデバイスの初期化に失敗しました。
   場所 FDK.CSound管理.t初期化(ESoundDeviceType soundDeviceType, Int32 _nSoundDelayExclusiveWASAPI, Int32 _nSoundDelayASIO, Int32 _nASIODevice)
   場所 DTXMania.CActConfigList.On非活性化()
   場所 FDK.CActivity.On非活性化()
   場所 DTXMania.CStageコンフィグ.On非活性化()
   場所 DTXMania.CDTXMania.Draw(GameTime gameTime)
   場所 SampleFramework.Game.DrawFrame()
   場所 SampleFramework.Game.Tick()
   場所 SampleFramework.Game.Application_Idle(Object sender, EventArgs e)
   場所 System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FDoIdle(Int32 grfidlef)
   場所 System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
   場所 System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   場所 System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   場所 System.Windows.Forms.Application.Run(Form mainForm)
   場所 SampleFramework.Game.Run()
   場所 DTXMania.Program.Main()
エラーだゴメン!(涙

2013-01-28 22:34 更新者: yyagi
コメント

ご確認いただきありがとうございました。

バッファを小さくすればするほど、応答性は上がりますが、その一方で全体処理は重くなりますので、少しバッファを大きくする体感の重さが変わるかも知れません。

しかし、こちらではいくらやってもASIO→DirectSound時の大量メモリリークは発生しませんでした。 ASIO4ALLとCreativeASIOの両方を使っているとき限定で発生するとかでしょうかね。

とりあえずASIO4ALL(だけ)を入れて試してみますので、お使いのバージョンを教えていただけますでしょうか。 確か正式版と、最新ベータ版があったと思います。どちらをお使いでしょうか?

# ・・・バージョン番号を確認しようとasio4allのサイトに行ってみたら、サイトが消滅していた・・・(驚

2013-01-29 23:20 更新者: sf298yen
コメント

お疲れさまです。いつも失礼な書き込みに丁寧な返答ありがとうございます。(謝

プチフリーズの件はバッファを変更してみましたがやはり発生する模様…。
ですがこのプチフリーズ、今回のASIO/WASAPIの対応とは別問題な気がしますし、
原因もはっきりしないので、よければこの問題は保留しようと思います。
AVI=OFF等で動画再生しなければ発生しないみたいですので。すみません。

さて、ASIO4ALLのサイト、確かに見れなくなってますね…

ASIO4ALLはVersion2.10を使用しています。正式版かと思ってますが、違うというオチだったらごめんなさい。
tp://jp-net.sakura.ne.jp/tr/
不要かと思いますが上記アドレスにコピーして置いておきます。
ASIO4ALL_2_10_English.exe(415,759byte) ウイルスバスター クラウドでスキャン済みです。

-ログ-

ASIO Device 0: ASIO4ALL v2
ASIO Device 1: Creative ASIO
Config.ini設定でASIODeveice=0,1 共に試しましたが同じ結果です。

§再現方法です。

1)DTXManiaを起動する
2)何かしらの曲をプレイする(←これ大事)
3)Configを呼び出し、モードを切り替える(ASIO⇒DirectS)
⇒メモリ使用量が増える
4)Configを呼び出し、モードを切り替える(DirectS⇒ASIO)
⇒メモリ使用量は一時的に少し減る

3と4(時々2)を繰り返すとどんどんメモリ使用量が増えていきます。(XP/7)

今からASIO4ALL削除してテストしてみます。

2013-01-29 23:52 更新者: sf298yen
コメント

XPのみですが、ASIO4ALLを削除して、PC再起動して試しました。
やはりメモリ使用量は増えていくみたいです..

ASIO4ALLを削除した時に発生したのですが、Config.iniでASIODeviceの値が存在する数よりも大きい値を指定しているとConfig画面でインデックスエラーが発生します。

2013-01-30 23:31 更新者: yyagi
コメント

こちらでも現象を確認しました。

ASIO云々と言うより、DirectSound使用時の問題のように見えます。

一つ対策を加えたモジュールを出しますので、お試しいただけますでしょうか。 DirectSound時のサウンド読み込み高速化処理を止めただけですが、メモリ解放に失敗することはなくなりました。 (非DirectSound時のmixer数が負の数になったりするのは無視して下さい)

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130130.zip

ASIOデバイス指定で範囲外エラーになる問題は修正しました。いつもご指摘済みません。

2013-01-31 17:09 更新者: sf298yen
コメント

適当と思われる場所がなかったので仮ですがこちらで。

至らぬところばかりでご迷惑おかけすると思いますが、改めてよろしくお願いします>All

簡単すぎますが、わからない人にはなんのことだかという挨拶はおいておいて、

DTXManiaGR_095_WASAPI_20130130.zip

をXP/7で動かさせていただきました。メモリ増加は見られなくなりました。ありがとうございます。

現段階で私の環境において発生している問題は次の1点です。

  • Win7でDirectSで動作させると画面のスクロールが滑らかではない
AdjustWaves / VSyncWait等、設定をいろいろいじってみてますが滑らかでない現象は発生します。
VsyncWait.Onだとコンフィグでのカーソル移動も妙にカクカクします・・・。何が悪いんだろう。
ちなみに一般配布の095版ではこの現象は起きないんです。
やぎ。様の環境でも発生しないということだっと思いますが、他の方はこの現象発生しないのでしょうか?
2013-02-01 00:11 更新者: yyagi
コメント

こちらこそよろしくお願いします。

メモリリークが無くなったようで、安心しました。Clone()さえなんとかすればよいということで、検討対象がかなり限定されました。

ガタつきについてですが、095以降画面描画関係でいじっているところはGPUのフラッシュしかありません。なので、これを削除したものを作りました。これでガタつきがなくなればよいのですが。

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130131.zip

2013-02-01 10:29 更新者: sf298yen
コメント

DTXManiaGR_095_WASAPI_20130131.zip

対応ありがとうございます。7で動かして見ましたが、やはりDSではカクツキました。
VSyncWaitありとなし、Window/全画面、共にカクツキがあり、095/WASAPI/ASIOでは目だって発生しません。

グラフドライバの設定も関係あるのかとパフォーマンス重視でいろいろいじってみてますが変化は見られません・・・なんでやorz
⇒垂直同期関連・レンダリング関連など。

2013-02-01 10:43 更新者: sf298yen
コメント

問題点の追加(Windows 7)(ASIO/WASAPI)

§「全画面でプレイすると描画遅延」

画面どおりに(目押しで)叩くと平均60ms程度遅いと判定されます。
60Hz駆動にしていますが、Aeroオフ設定(のハズ)で、レンダリングも0~4で変更しているにも関わらず、大体3フレーム遅延していることに?
BGMにあわせてヒットすると判定はあうので描画だけずれていると思います。
Windowモードにすれば音・描画のズレは少ないようです。
これは個人的な環境の設定問題なんでしょうかorz

(DS)

DirectSは現在カクツキから判定が困難な為、保留しています。
2013-02-01 22:46 更新者: yyagi
コメント

フルスクリーンでの描画遅延は、1つ前のバージョン(GPUフラッシュが入っているバージョン)である

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130130.zip

でも同様でしょうか?

2013-02-02 11:32 更新者: sf298yen
コメント

DTXManiaGR_095_WASAPI_20130130.zipで試しましたが同じでしたので、調べなおしました。

フルスクリーンでの遅延の原因ですが、どうやらドライバの問題(設定の問題)な感じです(?)。

NVIDIAのGe Forceを使っています。

ドライバ設定で「レンダリング前最大フレーム数」を、「3Dアプリケーション設定を使用する」で使用していたのですが(この設定は0相当になっていると信じてました)、 フルスクリーンではどうやらデフォルトで3~4の値を持っているような感じの挙動なのです。
テスト時は垂直同期を行って60fpsまで落としていたので 1000ms/60fps*3frame(or4) ms の描画遅延が発生していた、という感じでした。
試しにレンダリング前最大フレーム数を1に設定すると約20ms平均の遅延、2にすると約40ms平均の遅延となりました(目押しによるので正確さは欠けますが)。
垂直同期を強制オフで1000fps以上にした場合は(この理論でいくと1000ms/1000fps*3frameで3msの遅延しか発生しない)、描画遅延は感じませんでした。
ただわからないのは、Windowモードにすると60fpsにも関わらず描画の遅延が発生していないようなのです(?)。

というわけでWASAPI/ASIO関連の調整とは無縁な感じです。すみませんでした(汗

それにしてもどうしてもDSで動作させるとカクツキが出ます、なぜだーー?

2013-02-02 16:21 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130202.zip

フルスクリーンでの描画遅延の問題が改善するかも知れない対策を入れました。(解像度切り替えによるフルスクリーン表示を止めて、ウインドウ引き延ばしによる最大化を使用)

また、GPUのフラッシュも復活させました。

DirectSound時のカクつきは未修正です。私のところではスクロールがガクガクするというのはありませんが、スクロールの滑らかさが少し足りないかなと感じています。sf28yenさんのところで起きている現象は、こういう動作でしょうか?

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

yyagi.com/DTXManiaGR_095_WASAPI_20130202.zip 早速の対応ありがとうございます。

DirectSound時のカクつきは未修正です。私のところではスクロールがガクガクするというのはありませんが、スクロールの滑らかさが少し足りないかなと感じています。sf28yenさんのところで起きている現象は、こういう動作でしょうか?

おそらく同じことを言ってくれていると思います。 WASAPI/ASIOでは滑らかですし、Win7でDSだと私の環境では音が遅延しているので、DSは使わないと割り切ってしまえばよいのでしょうかね(汗。

補足:とはいえ、WASAPI/ASIOでプレイしていると一時的にこのDSのカクツキ(?)と同じような感じになることがあるので、原因の追究は必要なのかも・・?

2013-02-04 02:01 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130203.zip

095から描画関係はGPUのFlush以外変えてませんので、それ以外でDirectSound関連で変えているところ・・・タイマー関連・・・を変えてみました。

試しに、DirectSound時のCSoundTimerの動作を、CTimer相当に戻しています。 私のところではこれでスクロールが滑らかになりましたが、いかがでしょうか。

もしこれが効果有りだとすると、今後の対応のやり方が悩ましいです。以下の三択になりますので。

1. CTimerに戻したままにする。スクロールの滑らかさと入力タイミングは095相当の動作にはなるが、将来DirectShowで動画を表示しようとしたときに、このままだと動画と音が同期しなくなる。

2. CSoundTimerのチューニングをして、CSoundTimerの精度をCTimer並みに引き上げる。大変そう。

3. 第三のやり方を考える。うへぇ。

まあ現実的には1.で進める(=問題の先送り)かなぁ(笑)

2013-02-04 03:39 更新者: yyagi
コメント

すみません。GPUのFlushは削除しました。動画あり+フルスクリーン+VSyncWait=ONの条件で、カクツキが目立つためです。(ASIOやDirectSoundとかに関係なく発生します)

tp://yyagi.com/DTXManiaGR_095_WASAPI_20130203.zip

は、GPUフラッシュ無しのものに入れ替えました。

2013-02-04 09:13 更新者: sf298yen
コメント

DTXManiaGR_095_WASAPI_20130203.zip ⇒

対応ありがとうございます。

試しに、DirectSound時のCSoundTimerの動作を、CTimer相当に戻しています。 私のところではこれでスクロールが滑らかになりましたが、いかがでしょうか。

Win7+DirectSで試したところ、滑らかでございやした。

もしこれが効果有りだとすると、今後の対応のやり方が悩ましいです。

VISTA以降であれば大抵はWASAPIかASIOが標準となるでしょうが、XP以前の環境ではASIO以外の方は~ですか。 でも選択肢の内容的に1しか選べないよーな?wということでそれでよろしくお願いしますm()m
GPUフラッシュ、了解です。


§Windows 7での現状の遅延問題は、

  • DS+Vsync.On+FullScreenだと音・描画遅延(DSでもVSync.Offで高速fpsだと影響は少ないかも?)
  • (GeForceで)全画面+Vsync.Onだと描画遅延(DS/ASIO/WASAPI共)


⇒ 音の遅延はWASAPI/ASIOで解決対応済

といった感じでしょうか?

2013-02-04 23:02 更新者: yyagi
コメント

選択肢は1.で行きます(笑)。

Windows 7での遅延問題は、

  • DirectSound時遅延大 (FullscreenだとかVSyncだとかに関係なく)
  • (GeForceで) 全画面+VSyncWait=ONだと描画遅延有り

で、前者は Vista以降 + DirectSound では必ず発生する問題なので、今回WASAPI/ASIOで解決した。

後者は調査中、となります。

さて、後者について、プログラム側でレンダリング前最大フレーム数を設定する版を昔試作したことがあります。 念のため試していただけませんか。 (開発者向け注: 今のソースツリーをTEST_Direct3D9Exマクロを付与してビルドしただけです)

tp://yyagi.com/DTXManiaGR_095_WASAPI_D3D9Ex_20130204.zip

ただし、試作なので色々難アリです。XPで動かない、動画有りだと画面端が異常でスクロールが激重になる、など。 ご注意下さい。

2013-02-05 12:37 更新者: sf298yen
コメント

後者について、 DTXManiaGR_095_WASAPI_D3D9Ex_20130204.zip ⇒

プログラム側でレンダリング前最大フレーム数を設定する版

 DTXMania:Win7でFull/VSyncWait=ON/AVI=OFF
 GeForceドライバ:レンダリング前最大フレーム数=3D アプリケーション設定を使用する/垂直同期=オン
で試させて頂きました。
残念ながら描画遅延したままなようです。うーむ・・・。ドライバとは別に問題があるのかな?
サウンドをミュートした上でテストしているので音につられてはいないと思います。

一応ドライバの3D設定をメモしておきます。間違いや指摘ありましたらお願いします。

CUDA - GPU : すべて
アンチエイリアシング - FXAA : オフ
アンチエイリアシング - ガンマ修正 : オン
アンチエイリアシング - トランスペアレンシー : オフ
アンチエイリアシング - モード : オフ
アンチエイリアシング - 設定 : なし
アンビエント オクルージョン : オフ
スレッドした最適化 : 自動
テクスチャ フィルタリング - クオリティ : ハイ パフォーマンス
テクスチャ フィルタリング - トリリニア最適化 : オン
テクスチャ フィルタリング - ネガティブ LOD バイアス : 許可
テクスチャ フィルタリング - 異方性サンプル最適化 : オン
トリプル バッファリング : オフ
マルチディスプレイ/ミックス GPU アクセラレーション : マルチディスプレイ パフォーマンス モード(※)
レンダリング前最大フレーム数 : 3D アプリケーション設定を使用する
垂直同期 : オン
異方性フィルタリング : オフ
電源管理モード : 適応

※:シングルディスプレイパフォーマンスモードでも結果は同じです。

2013-02-06 00:55 更新者: yyagi
コメント

tp://yyagi.com/DTXManiaGR_095_WASAPI_D3D9Ex_20130205.zip

MaximumFrameLatencyに1を指定するようにしただけです。(前日のものは0を指定していましたが、今SlimDXのドキュメントを再確認したら、設定可能な値は1~16とありました・・・)

これでダメなら、アプリ側からはもう打つ手無しです。はい。まあ仮にこれで改善したとしても、これを実際に使えるレベルにして投入するのはずっと先の話ですが・・・(まずはWASAPI/ASIO対応版を正式リリースしませんとね。)

2013-02-06 03:18 更新者: sf298yen
コメント

対応ありがとうございます。

DTXManiaGR_095_WASAPI_D3D9Ex_20130205.zip ⇒

MaximumFrameLatencyに1を指定するようにしただけです。

試しました。おそらくレンダリング前最大フレーム数=1と同等のほぼ約20ms遅延な感じでした。
このレベルの遅延であれば、プレイできるレベルだと私は思いますが、
同じ症状の方が他にもいるようであれば、フルスクリーンでプレイされる方には垂直同期をオフにするか、
Windowモードで試してもらうことを推奨することでとりあえず解決できそうかな?
他の環境の方のレポートがないので不安がないわけではないですが・・・。

というわけで(?)、

WASAPI/ASIOの正式対応をぜひお願いします。
最初Win7でプレイしたときに正直もっさり感にがっかりしていたのですが、快適な環境が見えたのは素直に嬉しいです:)
2013-02-06 11:19 更新者: yyagi
コメント

会社から:備忘録:DirectSoundでスクロールがなめらかでなくなった件は、timeBeginPeriod()でMultiMediaタイマーの精度を上げていないから、って可能性はないか? 帰ったらCSoundTimerを確認する。

2013-02-06 23:31 更新者: yyagi
コメント

timeBeginPeriod()はちゃんと使われていました。これじゃなかったか・・・。

というのはともかく、安定動作してきましたので096のbeta版としてビルドしました。後でフォーラムの方にも出しておきます。

tp://yyagi.com/DTXMania096(130214)_beta.zip

ASIOデバイスが一つも登録されていないシステムでCONFIGURATION画面を出すと、例外になる問題を修正しました。(現象をタレこんで下さった方、ありがとうございました。)

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

正式なWASAPI/ASIO対応が完了いたしましたので、本チケットもクローズとさせていただきます。

添付ファイルリスト

編集

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