一応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それぞれの間でどのくらいの遅延が発生しているかを何とか測定できないかと考えてみます。
aの測定方法: いきなり分かりませんｗ 飛ばします。
bの測定方法: 検証用のサンプルを作りました。 tp://yyagi.com/DTXManiaGR_CheckKBInputLag.zip
ShowTimingAboutHitSpaceKey.exeを実行すると、ウインドウが開きます。 これは全てのキー入力をフックして、その入力があった時刻だけを淡々と出力するアプリです。 (注: グローバルフックでキーを取ってきているだけです) これを(OSが入力受理した時刻)として、DTXManiaでの入力受理時刻と比較します。
ShowTime...のウインドウを開いたまま、上記のDTXManiaを開いて下さい。 タイトル画面でだけ、スペースを押すとDTXManiaLog.txtにその旨ログを残すようにしてあります。 スペースキーを何度か押してから、終了して下さい。 それと同時に、ShowTime...のウインドウにも入力時刻のログが出ていますので、 DTXMania本体の終了後、DTXManiaLog.txtとShowTime...のログで時刻比較して下さい。
sf298yen 
from 検証お疲れ様です。
ニュートリノが光速を超えたかどうかちょっと気になるので、検証ツールのソースを公開いただけますか？
あと……、もし a～h がすべて 0 だったとしても、60Hz のモニタなら、i は（フレーム遅延 0 だとしても） 0～16.6666...ms のどれかになりますね。 a～i で 10ms を超えないようにするための、最大の敵はモニタ自身かもです。
おかげさまで、ヒッグス粒子っぽいものは見つけることができましたよ。
あぁぁ・・・。システム時刻をmsオーダーで簡単に取ってくるはどうしたものか。ちょっと考えてみます。 ソースコード(プロジェクト一式)も添付しておきました。
おっしゃる通り、どうがんばってもモニタの遅延は最後まで残るでしょうね。 その意味では、ノートPCのモニタが低遅延で良いのですが、環境アンケートを見る限りノートPC利用者は少ないようです。
from システム時刻をmsオーダーで簡単に取ってくるはどうしたものか。ちょっと考えてみます。
FDK の CTimer を使ってやって下さいよー。
HT, MMT, gtg のどれにも対応していますよ。
どうがんばってもモニタの遅延は最後まで残るでしょうね。
すみません、語弊がありました。
正しくは、モニタではなくてグラボの出す出力信号速度（リフレッシュレート）ですね。
モニタの応答速度が例え 0ms であっても、入力信号が 60Hz ならば必ず 1～16.6666..ms の遅延は発生します。
120Hz のモニタもありますが、それでも 1～ 8.3333...ms の遅延ですね。
リフレッシュレート1000Hz出せるグラボと、それに耐えうる品質のモニタケーブルが登場すれば問題解決なのですが。
FDKのCTimerを使うように変更しました。 tp://yyagi.com/DTXManiaGRCheckKBInputLag2.zip
プロジェクトファイルはこのチケットに添付し直しました。(時刻の後に出てくる数値の方を、単位msとして使って下さい)
また、c区間の測定を止め、b区間のみにしました。
これで計ってみると、
| XP | Win7 |
| 22 | 12 |
| 5 | 3 |
| 8 | 9 |
| 6 | 11 |
| 11 | 5 |
1回目はいつも大きい値になるのでこれを除くと、XPとWin7とであまり大差ない結果になりました。 前回XPで15,6ms刻みの値になったのは、VSyncではなくて、システムタイマの割り込み間隔だったわけですね。納得です。
今回の測定ツール(とDTXMania本体)では、システムタイマの割り込み間隔を最小(1ms)にしています。 あわよくばこれで入力感度が上がっているといいなぁ。(多分変わらないと思いますが。)
sf298yen DTXManiaGRCheckKBInputLag2.zipを使って再測定しました。
| xp | Win7 |
| 13 | 9 |
| 13 | 10 |
| 7 | 11 |
| 4 | 11 |
| 12 | 6 |
キー入力に関しては差がほとんど認められないようなので影響はなさそうな気がします。
ちなみに私のWin7で使ってるディスプレイは3D Vision対応な為120Hz駆動が可能で、試しましたが…。
通常は３Ｄ滅多に使わないので60Hz駆動にしてます、なんとなく。
sf298yen 具体的に測定する方法がさーぱりなので・・・
画像に関する測定…（悩
サウンドに関してはエフェクトなど、ディレイが発生すると思われる要素を全部オフにして
最短で出力するようにしてみたりしてるのですが改善する気配がありませんorz
使ってるカードは「Sound Blaster X-Fi XtremeGamer」なのですが、もしかして相性が悪いとかなのでしょうか
サウンド出力でラグを感じる方、他にもいらっしゃるみたいですね。(別の某所でも見かけました) しかしまずはそのラグをどう計ったものか。
以前nyaさんがなさっていたみたいに、MIDIドラムの音声出力と実際のサウンド出力を録音して時間差を求めるか、いっそPCキーボードを激しく打鍵してその環境音とサウンド出力の録音・時間差計測でもするか。
あと、サウンド出力の遅延と決めつけて、そこだけ遅延対策してみるとか。例えばSSTのモジュールを一部拝借して、ASIO /WASAPI対応版とか試しに作れないものかな。
自分のメイン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対応を試してみますか・・・。
sf298yen 結局いろいろやってみたものの、もうすぐ８発売だなぁ・・・ということで７を諦めてＸＰでプレイしてました、ごめんなさい。
やぎ。さんの環境でもサウンドは(XPよりは)７ではラグが大きく感じるということですから、私の感覚＋ＰＣだけが変ということではなさそうですね。
webでいろいろサウンドについてみていると、
:遅延の根本原因は、Windows標準のDirect Sound APIがそもそも遅延が大きいものであることが影響している
ということでやはり悩んでおられる方がおり、ASIO/WASAPIで改善出来た、というので
SSTのソースを借用して、WASAPI/ASIO対応を試してみますか・・・。
には非常に興味があります。
ソース⇒ ttp://blogs.itmedia.co.jp/satohiroshi/2011/07/asiowasapi-3082.html
Bluetoothに関しての問題ですが、共通点はあるのかなと。
'ちなみにnyaさんが行っていた試験をやってみようと思ったのですが、私のＰＣではミキシングの問題でうまくいかなかったので嫌になって放置しましたorz
今頃ようやくですが、SSTのソースをパクってWASAPI対応したサンプルを作りました。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121220.zip
094か095の環境に上書きしてもらえれば、とりあえず固定的にWASAPI再生するバージョンができあがりです。 (ベースは094です。すみません)
これで反応遅延が改善するか、お試しいただけますでしょうか。 個人的には、改善しているっぽい気がします。(メインPCでしかまだ試していませんけれども。)
以下注意事項です。
sf298yen お忙しいと思われる中、対応ありがとうございます。
本日は都合によりテストできない為、明日か明後日中に確認させていただきたいと思います。
ダウンロードは済ませましたm(かおもじ)m
from yyagiさんお疲れ様です。 WASAPI版をWin7で試してみました。
BGMと譜面のタイミングはどの曲もばっちりでした。 ドラムチップ音については OFF にしているので分かりません（汗
ただし、譜面通りに叩いていると、Poor、よくて Great の連続になります。 Perfect を出すには、チップより早め（体感でずれてると分かるくらい）にヒットする必要があるようです。
ソースが公開されてない？ので原因は分かりませんが、 とりあえずWASAPIで自作しているタイマ値関連だと思いますので見直して頂けないでしょうか。
sf298yen お疲れ様です。
体調不良を理由に有休をとって遅れながらWin7で試してみました。
（体調不良は本当で昼まで寝てましたorz・・・本当ですよ！？）
§確認項目の確認
「キー入力してからの反応遅延」
⇒画面の表示：今までどおり遅れている感じです。（今回の修正とは関係ないはずですので当たり前ですが。）
⇒音のズレ：改善している気がします（※）。ＢＧＭと一致させるよう意識して入力したらほぼ-10～+30でした。
（通常と、Hiddenの使用で目押しによる補正があまり出ないよう意識してテスト。）
補足：
目押しを意識して入力した場合（→上記の通り遅れて表示されている感じの為かと思いますが）、遅い（+30～+50)と判定されました。
fromさんが指摘されているとおり「チップより早めにヒットする必要がある」と思います。
ですが、音のタイミングが合っているなら本質的な問題は少ないと思いますので、
表示上のタイミング問題は、例えば判定ラインを上げる・下げるとか、チップ表示のみを意図的に早くする、遅くするなどでクライアント差を吸収できる
と思います。
※私が持っている曲も私が作成している譜面もほとんどがxaの為、普段やらない曲でのテストとなりました。
私のテンポ感覚が完璧などとうぬぼれるつもりはありませんorz。その為、体調不良という言い訳も重なって後日体感意見が変わるかもしれません。
動作確認いただき、ありがとうございます。仕事があまりに忙しいので、現実逃避でWASAPI/ASIO対応してます・・・
fromさん: ソースはbranchに入れてます。24820ってやつです。先ほど、「XAに仮対応してみたけど、System.ExecutionEngineExceptionが出てしまうよ！」なコードをコミットしました(ぉぃ I/Fの定義と使い方は正しいはずなんですが・・・(アンマネDLLへのリンクなので、自動でピン止めされている前提)
タイマ関連と言いますのは、つまり「演奏用のタイマとメイン進行用のタイマが違うと、判定がずれるよ」的なお話でしょうか？(まだよく理解できていません。)
sf298さん: 動作確認用にxa対応が必要という話は余所でも聞きましたので、今やってます・・・が、エラーが出てます。ぬー。
それにしても、画面の表示の遅れが出ていますか。前にもご相談したような気がしますが、Aeroを切って、VSyncWait=Offにしてかつ(グラフの設定で)レンダリング前最大フレーム数やらフリップキューサイズやらを0にしても変わらないのですよね？
# 描画遅延ではなくて入力遅延かも知れませんが・・・。
from おお、入ってましたか。それは失礼しました。
現在SSTのほうに全力注力してるのであまり深くは突っ込めないかも知れませんが、拝見させて頂きます。
タイマ関連で気になるというのは、チップの「本当の時刻」と「表示する時刻」がずれてないかな？ということです（変数名は忘れた……）。 WASAPIから導き出したタイマが狂ってると、両者もずれてくるはずなので。
あと、SSTのほうを触ってて、ドライバにモノラルを指定していたバグを見つけましたので直しておきますね。 （……でもちゃんとステレオで聞こえてるし、ヘタにいじらないほうがいいかな？）
p.s. うちの実験環境（というか本番環境）は、Win7Proで、Aero ON、フレーム数はいいじらず、VSyncWaitもONです。 すわなちクリーンインストールして何もしてない状態です。念のため。
ソースについて少し補足しますと、
あと、ここで書くのも何ですが、SSTのソースを持ってきて気付いたことを少し・・・
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121222.zip
無事にxa対応ができました。これで大抵の曲をプレイできるようになると思いますので、これでWASAPI動作を見て下さいませ。 チップ音が多数定義されていると激重になる制限は、そのまま残っています。なのでギターありの曲データは悲惨なことになると思います。
ソースもコミット済みです(バグ調査用の汚いコードがそのまま残ってますが、これから清書します)
とりあえずxaの再生方法は、(ストリーム再生ではなくて)wavにデコードしてオンメモリ再生にしてます。
清書が終わったら、fromさんからご指摘いただいた、タイマー周りを見てみます。
from お疲れ様です。 結論から言いますと、分かりませんでした（汗。
私が懸念してたタイマ関係についても、完全にDTManiaとSSTとを混同しちゃってました。 （本当の時刻と表示時刻とに分かれて誤差修正してるのはSSTだけでした……）
……相当、忘れてるなあ。
BASSについては、ご指摘ありがとうございました。修正します。 あと、FLOAT に固定されているのは WASAPI の仕様だったかな？（内部的にはFLOATしか扱わないとか何とか） SST のソースをそのままコピーしたのであれば、ASIO のほうは内部 16bit 固定になっていると思います。
fromさん:
タイマーについて、承知しました。ちなみに、この試作品以前に、通常のDTXManiaでも同じような「入力ズレ」がありますでしょうか。(サウンドの出力ズレはともかくとして。)
ちなみに、演奏中のPAUSE/復帰で一部の演奏(ギターだけとか)がずれることがあるので、何かしら時刻周りの問題を抱えているのは間違いないと思います。(これはこの試作品に限った話で、通常のDTXManiaでは起きない現象ですが・・・。)
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121223.zip
お疲れ様です。
前にもご相談したような気がしますが、Aeroを切って、VSyncWait=Offにしてかつ(グラフの設定で)レンダリング前最大フレーム数やらフリップキューサイズやらを0にしても変わらないのですよね？
# 描画遅延ではなくて入力遅延かも知れませんが・・・。
以前の設定のままで、Aero Off / VSyncWait=Off / レンダリングは 0相当(のハズ)です。とにかく遅延が最小になるようにさせていただいております。
入力遅延の件はDTXManiaGRCheckKBInputLag2.zipを使って再測定したとおりですから問題はないと思っています。
当時と違うのはグラフィックドライバが最新になっています。
§「DTXManiaGR_094_WASAPI_20121223.zip」を少しですが試させていただきました。
XPにより近い体感に思えました＝改善していると思います。
（イメージ的にはＸＰが某Ｖ，７が某ＸＧ的な反応速度）
※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)
sf298yen のぅ・・・ログインしてなったorz ↑ 298yen です。
sf298yenさん
検証いただきありがとうございました。でも、どうか検証などなさらずにぐっすりお休み下さい・・・。
さて、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は読み込めるように修正しました。ご迷惑をおかけして申し訳ございません。体調が回復しましたら、試してみて下さいませ。
from ASIOのところって、SSTではちゃんとエラー無く動作しているのでしょうか・・・。
Sound Blaster X-Fi Xtreme Gamer (PCI、ASIO 2.0対応) でしか試してませんが、XP, 7 ともに正常に動作しましたよ。
USB外付けの Sound Blaster Digital Music HD は、ASIO は非対応でしたが、WASAPI には対応していました。 もっとも、USBの遅延が大きくてあまり追い込めませんでしたけども。
fromさん
コメントありがとうございます。SSTではASIO、動いてますよねぇ。
こちらでは、
こんな感じです。 後者は単純にDLLへのリンクに失敗しているとかなのでしょうけれども。
もうちょっと調べてみます。
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環境で確認してみます。
ただ、私のXP環境(CoreDuo1 1core 2GHz + UA-5 ASIO)だと、どうもサウンドがヨレて仕方がないですね。 凄く発音処理が重そうな感じ。
Config.ini の PolyphonicSounds を1にすると発音不可を大幅に軽減できます。でも、ウチは1でもまだちょっとキツかったです。(これを常用しようとは思わないくらいのキツさ・・・)
更に VSyncWait=0 にするとズレが減らせるかも知れません。(WASAPI/ASIO動作時の発音時刻の制御がまだ少し怪しいので。)
このあたりは、チップ音のライフタイム管理を入れて改善できないか試してみますが、何となくそれだけじゃない問題のような気がしています。(設計上、1coreじゃどーにもならないとか、そういうレベルの問題のような予感。)
sf298yen お疲れさまです。DTXManiaGR_094_WASAPI_20121225.zip 使用させていただきました。
§ＸＰ
XP+ASIO(SoundDeviceType=1) / XP+DirectShow(SoundDeviceType=0)
・チップの降ってくるタイミングは同じっぽいのですが、チップをヒットしてからの音の立ち上がりの差が激しいです。
ASIO :
チップをヒットしてからの音の立ち上がりがすごく遅い？感じです。
なのでヒット音を確認しているとリズムが崩れるます。（だんだん遅れる感じ？）
DirectShow : （今までの環境と同じくらいです。）
音の立ち上がりが非常によいです。
チップのヒット音を確認しながらでもリズムキープしやすいです。
⇒
ゆえにチップの音を鳴らさないで電子ドラム音を直接鳴らすタイプの方には影響はないと思います。
音を無視して、「目押しができる」「脳内リズムが完璧」ならばASIOでもプレイは出来ると思いますが、ＢＧＭとチップの音のタイミングのズレは大きいと思われます。
§７
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
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非対応の内蔵で……）
念のため、ご考慮ください。
その後一応、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さんがおっしゃるようなバス違いによる性能差の話が出てくるのだと思っています。
UA-5でのBASS_ERROR_UNKNOWNを回避できました。 ASIO_Start()のときに指定するバッファサイズを、FDKが計算で出してくる値ではなく、手動で直接適切な値を設定することで、エラーが出なくなりました。
今後はメインPCでASIOの動作確認ができます。これで捗る。
メインPC(Athlon II X4 2.3GHz, Win7 x64, UA-5)とASIOの組み合わせでDTXManiaを動かせるようになったので、 早速動作確認してみました。
チップ音が多すぎる曲の動作は相変わらずですが、普通の曲データでは他のPCで感じたような音切れやタイミングズレの感じはありませんでした。(バッファがショートしてたまに発振するけどｗ)
この環境で何より特質すべきは、入力に対する反応の良さ。この環境ではバッファサイズ(サンプル数)の調整で3ms程度にまで追い込めたのですが、従来のXP(ACM)以上にダイレクトな反応をすることに感動しました。これなら私、プレイする気になれますわ。(今まではXPでも遅延が気になってプレイする気になれませんでした。実は。)
一応、最新の試作モジュールを置いておきます。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121227.zip
ただ、音声処理そのものは何もいじっていないので、音が切れ切れとか動作が重いような感じと言ったようなところは多分変わらないと思います。(何故か私のメインPCではうまく動いているだけなのだと思います。)
なお、WASAPIのバッファサイズ(遅延)は、この環境でも60msを超えてしまいます。これで従来のXPくらいの感触。 最初USB音源だからかと思い、内蔵音源でも試してみましたが、同じくらいのバッファ量でした。 WASAPIの関連情報をぐぐってみると、余所では10msとか3msとか、いい感じの値が出ているようなのですが、 ウチだとダメのようです。ちくしょう・・・なんでや・・・。
sf298yen 睡眠導入剤の利用で限りなく熟睡させて元気になりました。心配いただきありがとうございます。
が、少々仕事のトラブルから気が滅入っているので差し引き少しマイナスという状況です。
だがしかし、
…入力に対する反応の良さ。この環境ではバッファサイズ(サンプル数)の調整で3ms程度にまで追い込めたのですが、従来のXP(ACM)以上にダイレクトな反応をすることに感動しました。これなら私、プレイする気になれますわ。
これを読んだら試さずにはいられないでしょう、いやー、ＸＰ以上ってもう・・・！
・・・なのになのに、Win7でASIO指定すると音がバグるorz なんでやねん…。
今日はもう寝る時間（夜勤）なので後日改めて挑戦しようと思います。
XPでASIO動作させると前回(-20121225.zip)はなぜか遅延がすごかったのですが、今回は快適でした。
余談でXPに「ASIO4ALL」インストールするとWin7でASIO指定したときと同じような音のバグが・・・（というかまったく同じ音？）
今まではXPでも遅延が気になってプレイする気になれませんでした。実は
実際の楽器を触られている方には多い意見なのかな？演奏時のレスポンスが遅いと「なんか違う」という感じになってしまって。
私は某XGとかはその点が特に気になっていて、ズレ？が大きい曲になると違和感がハンパなくて対応できません。
強制的に小節線を目押しで狙ってあとはリズムで強制補正すればいけるときはいけるのですが、どうしても遅れて鳴るチップ音につられて自爆するんですよねorz
すごいスコア出してる方はきっとそこらへんの補正がうまいか、そうとう目押し的な能力が強いのか。
中にはクラッシャーよろしくゲームの音じゃなくパッドの打音やギターのピック音でリズムを維持する方もいらっしゃるんでしょうけど。
なんて横道それましたが、これからはやぎ。様もDTXManiaのプレイに復帰されて開発（現実逃避）がより順調に！？
sf298さん
こちらではWin7/XP共に、内蔵音源(ASIO4ALL)とUA-5(ASIOドライバ)のどちらでも(この組み合わせ4パターン全てで)ちゃんとASIOで動作しています。 前回遅延やらモタリやらが酷かったのが劇的に改善したのは、バッファ量の設定をデバイスが持っている値を使うようにしたためだと思います。(ここを最初は50ms固定の設定にしていました。)
もし音が変とか言うことであれば、以下をチェックいただけますでしょうか。
「音がバグる」という現象が具体的にはどういったものなのか分かりませんが、まずは思いつくところをコメントいたしました。
sf298yen やぎ。様
アドバイスありがとうございます。無事一通り正常動作確認できました。
「ASIO4ALL」アンインストールしたら何事もなかったよーに。バッティングしてたのかな？
細かいテストはしていないので、あくまで現段階での快適さを体感順に記述しておきます。
１）XP+DirectShow ：問題なくプレイできる
２）Win7+ASIO ：問題なくプレイできる（が、描画がやや不満）
３）Win7+WASAPI / Win7+DirectShow ：やや遅延を感じる
４）XP+ASIO ：かなり遅延を感じる
※この順位は私のＰＣ環境と、年末仕様の体調による感じ方です。
音は両方ともSB X-FI Xtreme Gamer.
XP+ASIOですが、前回は快適と記述させていただいたのですが、選曲による勘違いだったようで、遅延がひどい（音の立ち上がりが遅い）ので個人的に実用にならず…。
・Config.iniのPolyphonicSoundsは1に設定させていただいています。
Win7+ASIOよりXP+DirectShowのが快適だと感じるのは、私の環境だと描画遅延がWin7のほうがXPより大きい為です。
ただ、Win7は、画面にとらわれずに演奏する分にはASIOを使うことでかなり改善しているように思えました。
個人的には後は描画遅延。XPで出来ている速度がなぜWin7で出ない・・・orz
sf298yenさん
状況を整理いただいて、ありがとうございます。わかりやすいです。
最近、こんな記事を見つけました(記事の最後の方を参照)。ドライバのバージョンによってもいろいろあるようです。 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/
sf298yenさん
すみません。もう一つ確認です。Win7での描画遅延について、電源オプションでグラフの設定は性能寄りの設定になさってますよね？
コントロールパネル - システムとセキュリティ - 電源オプション - (今お使いの電源プランの)プラン設定の変更 - 詳細な電源設定の変更 - (グラフ関係の設定(Intelグラフの場合は、Intel(R) Graphics Settings - Intel(R) Graphics Power Plan - 電源に接続 を、BalancedからMaxmimum Performance に変更。))
個人的にはバランス寄りの設定で問題ないはずだとは思っていますし、またグラフのプロパティで似たような設定をすでにいじっていらっしゃるとは思うのですが、念のため確認は必要かなと思いまして。
from お疲れ様ですー。
1227版を試してみたところ、前回生じたヒットのズレは解消されていました。 チップとBGMのタイミングはぴったりです。
ただ、曲によっては、小節線ごとに行う再生位置補正がひどいことになりました。（ならない曲もありました。） パルスノイズのような短いブツ切れではなく、体感ではっきりと分かる0.2秒ほどの無音領域が小節線ごとに入ります。 小節の長さは関係無いみたいです。
再生環境は Win7 Pro (SBX-FiXG)で、ログには WASAPI(192kHz, 8ch, 32bit)、遅延48ms(希望0）とありました…… が、これは（ソースの中にコメントがあったと思いますが）再生開始の瞬間に別の構成に変わると思いますので、正確な情報ではないと思われます。
その無音領域さえ無視すれば、無音が鳴っても全体としてチップ位置とBGMはぴったりあっていました。
from 思うのですが、DirectInput と再生位置自動補正機能で使用しているマルチメディアタイマを BGM 再生に使わないのであれば、再生位置自動補正機能は廃止するほうがいいと思いますがいかがでしょう。WASAPI や ASIO にしたことで、かえって環境依存の音ズレが発生することになります。
SST ではすでに廃止してます。 が、Midi入力もまたマルチメディアタイマを使っており、CSoundTimer との微妙なズレがありますので、それはこれから修正する予定です。
fromさん
ご確認いただきありがとうございます。
再生位置補正ですが、こちらでは、同じ曲でも無音領域が入る場合と入らない場合がありました。 ご指摘いただいたタイマーずれの懸念ももちろんあるのですが、 HDDアクセスの間BASSの処理が止まってるとか、そういうのもあるかもしれません。
タイマーの方は、おっしゃるとおりこれを機に新方式への移行(そして再生位置自動補正機能の廃止)が必要と考えていました。 ですが、上記の通り今のままでもなぜかうまく動くことがあるため、後回しにしてます。 (まあもちろん、理屈の上ではずれが出るのはわかっているのですが・・・)
WAV定義のライフタイム導入と、サウンド読み込み高速化(CSound.Cloneの実装)、タイマーの見直し。直近でやるべきところはこんなところかなと思ってます。 後は汚くなったCSoundの設計見直し。(xa/oggとか、ファイル読みだし/メモリ読み出しで似たような処理なのに個別に作り分けしているので、動作が落ち着いたら継承ですっきり書き直したい・・)
sf298yen やぎ。様
XP＋ASIOのサウンド遅延ですが、ASIOのバッファ量は適切に設定なさっていますか？
ご指摘のとおり、バッファ量の値が問題だったようです(50msとなっていました）。
標準のドライバでは設定する場所が見当たらなかった為、「Asio caps」というツールを使って変更しました。
「Asio caps」 ⇒ tp://otachan.com/ASIO%20caps.html
値は１０以下にするとノイズが入ってしまう為、２０msの設定を利用したところ、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でもテスト。ただ、２～３回しか試していないので正確さに欠ける可能性があります、すみません。
微妙に再生タイミングが違うのかバッファによる違いが出たのかはわかりません。
グラフボードには何をお使いでしたっけ？(NVIDIAの、何でしょう？)
DXDiagからの部分コピーです。
☆ＸＰ
☆Win７
電源オプションでグラフの設定は性能寄りの設定になさってますよね？
該当っぽい項目がなかったのですが、関連ありそうな項目はパフォーマンス優先側になっているのでおそらく問題はないと思います。
参考記事の件は大変興味深いですね、GPUViewのツールなどでテストしてみたいと思います。
sf298yenさん
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121231.zip
WASAPI/ASIO周りは1227版のままで、いじっていません。
sf298yen あけました。今年もよろしくお願いいたします ＞ all
やぎ。様
XP+ASIOでは、まだDirectSoundよりサウンド出力遅延が大きいと言うことなのですね。
⇒ASIOの設定をちゃんとすることで 「XP+DirectSound ≒ XP+ASIO」 という仮の結論でお願いします。
§20121231版を使わせていただきました。
・Win7+ASIO
サウンド処理のCPU負荷状況を、演奏中画面のDebug Infoに表示するようにした (あくまで目安の値。また、DirectShowでの動作は未確認。)
・Win7+WASAPI / Win7+DirectSound
○現段階での体感順位です。
'Win7での補足(20121231版 / Windowモードで使用)
こちらこそよろしくお願いします。>all
sf298yenさん
ご確認いただき、ありがとうございました。それでは、いったんASIOでの遅延の話は終わります。
WASAPIの遅延を感じるとのことですが、バッファ量はどのくらいになってますでしょうか(ログに出ているはずです)。 私の環境では60msちょいになって泣きそうです。また、これを調整する方法は今のところわかっていません。(APIでバッファ量を指定することはできるのですが、何を指定しても結果が60ms強になってしまう・・・)
エラーで落ちる件、失礼いたしました。下記0101版で修正済みです。それと、GPUをフラッシュするタイミングをほんの少しだけ変えてみました。 こちらでは、XP＋フルスクリーン＋VSyncWait=ONの時に限って描画遅延しているかなぁという感覚があったのですが、 この対応で少し描画遅延が減ったように感じました。
なお、フラッシュする実装自体は、OS/サウンド出力方式の区別なくすべて同じです。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130101.zip
from あけましておめでとうございます。
今年も死なないよう頑張ります。社会的に。
0101試しました。年明けから（年末から？）お疲れ様です。 例によってチップ音なしのWASAPIでしか試してませんが、曲によっては無音領域どころか逆に巻き戻される（曲の進行が譜面に比べて遅い）こともありました。そのときは、チップよりだいぶん早く叩かないと Perfect が出ないという例の現象が現れます。
明日の甥っ子が来る（ドラム好き）までには何とかしたいところですが……うーん。
fromさん
その現象はタイマーがらみの話かと思われ、私には今日中に何とかするのは無理っす(＾_＾;;
運がよければ、AdjustWaves=OFFで回避できることは釈迦に説法ですが、これはデータに依るでしょうね。
from やっぱり、譜面と入力にかかる部分はCTimerではなくCSoundTimerを使うようにしないと解決しなさそうです。 SST では正常に機能してますので、HDDアクセスなどの問題はないと確信しています。
このズレは、間違いなく異なるタイマを混同利用していることが原因です。 うまく動くこともあるため後回しにするということでしたが、こちらではまったくと言っていいほど遊べない状態（障害）ですので、コードの最適化や見直し（改善）よりも優先して頂きたい課題ではあります。
自分で直そうとしたら、想像以上にソースが変わってた…… Global 全滅ッスか！
はい。Globalは必要そうなのをCSound.cs(のCSound管理やCSound)にコピってます。障害だというご指摘には同意いたしますが、何にせよ今日中にタイマー修正は無理っすよ。
あと大事なことを書き忘れてました。まだPlaySpeedに未対応です。これはどうしたものか。BASSに中途半端な周波数ってつっこめるのなら話は早いが、大丈夫かな・・・。
まとめますと、TODOはこんなところだと思っています。まだまだ多いな・・・(泣;;
from 暫定処置完了！
ひとまず、「うちの環境では」正常に演奏できるようになりました。 （試奏してたら、XP時代より良い記録が出てしまった（汗））
ttp://mainori-se.sakura.ne.jp/temp/DTXManiaGR_094_WASAPI_20130101SoundTimerVer.zip
修正点は以下の通りです。
ソースは branch/130101～ に格納しておきました。これは、現時点での branch/120724～ から派生したものです。
なお、MIDI入力以外の入力時刻については修正してません。ですので、キーボードやジョイスティックだとヒット位置が環境依存でずれると思います（汗
また、サウンド関連のパラメータは一切触ってませんので、おそらく WASAPI のままです。遅延量もデフォルトです。ASIO は試していません。
これでなんとか、明日は甥っ子に受験勉強の発散をさせてやれそうですｗ
sf298yen やぎ。様
WASAPIの遅延を感じるとのことですが、バッファ量はどのくらいになってますでしょうか
補足：
まだそれほどテストしていないのですが、from先生が指摘されているような、
曲によっては無音領域どころか逆に巻き戻される
といった症状には出くわしておりません。
XPメインでテストしていることと、VSyncWaitは基本Offのせいも関係するのでしょうか。
補足２：
from あー。やっぱりXP時代に作られたDTXデータだとBGMに若干の遅れが……。
なんかＳが出ない出ないと思ってたんですが、ほんの少し早めに打てば Perfect でした。
こればっかりは当初から想定されていた曲データ側の問題ですから、本体側ではどうしようもありませんね。
fromさん
あ…ありのまま 今 起こった事を話すぜ！
『所用で出かけて戻ってきたら、タイマー主要部分の修正が終わっていた』
(以下略)
ありがとうございます。今後は0101のBranchの方を活用させていただきます。 キーボードとジョイパッドのタイマーはこちらで何とかします。(rc演奏用タイマに変えるだけで済みそうですし)
XP時代に作られたDTXデータでBGMがずれるのは、致し方無しですね。BGMのタイミング調整機能はついていますので、書くユーザーにそれで対応してもらうようにしましょう。 (特定の日付以前のデータは無条件に一定値ずらすオプションをつけてもよいかも。)
sf298yenさん
WASAPI再確認、ありがとうございました。これでWASAPIがイマイチなのは私のところだけですね・・・うーん。
120Hzの件、GPUの強制フラッシュを入れる前(1227版)でも同じでしょうか。 また、フルスクリーン/ウインドウモード問わず同じでしょうか。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121225.zip
キーボードとジョイパッド(とマウス)の、直接入力(BufferedInput=OFF)について、タイマーをrc演奏用タイマに変更しました。 バッファ入力(BufferInput=ON)の時は、まだシステムタイマーのままです。しまった、これは盲点だった。
DirectInputが中でどんなタイマーを使っているかは分かりませんので、こんな考え方で対応予定です。
例: ダミー入力の rc演奏用タイマベースでの時刻を td_p, システムタイマベースでの時刻を td_s, 実際の入力の システムタイマベースでの時刻を t_sとすると、 実際の入力の rc演奏用タイマベースでの時刻 t_pは、 t_p = t_s - td_s + td_p と近似できる。
sf298yen やぎ。様
これでWASAPIがイマイチなのは私のところだけですね・・・うーん。
120Hzの件、GPUの強制フラッシュを入れる前(1227版)でも同じでしょうか。 また、フルスクリーン/ウインドウモード問わず同じでしょうか。
⇒テストはXP+095で行っています。デバイスドライバ側の設定の垂直同期は「3D アプリ設定を使用」。120Hz駆動
⇒デバイスドライバ側の垂直同期設定「（強制）オフ」
60Hz駆動ではドライバの設定が連動/Off、Window.Sync.On/Offを含めて全てスムーズです。
よって気になるのは「●」の２パターンです。
’
余談ですが、メッセージのやりとりみてて思ったこと。
from先生の仕事はえぇ... しかも子供思いというのがニクイ演出ですね
tp://yyagi.com/DTXManiaGR_094_WASAPI_20121225.zip
sf298yenさん
ご回答いただきありがというございました。fpsの件は正直心当たりがないのですが、意識しておくようにいたします。 (動作からおわかりの通り、60Hzに特化した作りにはなっていないのですが・・・。)
強は特にzipでは公開いたしませんが、今日の対応で
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130103.zip
tp://msdn.microsoft.com/ja-jp/library/bb219640(v=vs.85).aspx
出先で使っているノートPCが死にました。別のPCに開発環境を設定するのに一苦労でした。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130104.zip
sf298yen 出先で使っているノートPCが死にました。
Ω＼(-""-) ご愁傷様です……
質問？なのですが、以前からですがBufferdInput=ONのときに表示されるラグタイムですが、似たような数字だけが出るケースがありますが、それは仕様的レベルでしょうか？
「１、７、１，１，７，７・・・」みたいに似たような数字が続く場合があるんです。これが誤差最小化の結果、ということなのでしょうか？
CONFIGURATIONの画面でSoundDeviceTypeとASIOBufferSizeを設定できるようにしました
BufferedInput=ONの件、「以前から」ということでしたら、対応時期から言って、誤差最小化云々は関係ございません。多分OS内部で入力をスキャンしている間隔が、BufferedInput=OFFの時よりも長い、ということなのだと思います。
なお、BufferedInput=OFFの時は、明示的に毎フレームごとに入力をスキャンしています。1000fpsなら、1ms間隔でのスキャンということになりますので、sf298yenさんの環境でしたらOFFのほうがよさそうですね。(こちらの環境では100～300fps位なので、ONのほうがよさげです)
ASIOBuffedSizeの設定操作についてご提案ありがとうございます。そのうち入れ込んでみます。
sf298yen 福沢さん１人と夏目さん１０人ではどちらが喜ばれますかね・・・
BufferedInput=ONの件、「以前から」ということでしたら、対応時期から言って、誤差最小化云々は関係ございません。多分OS内部で入力をスキャンしている間隔が、BufferedInput=OFFの時よりも長い、ということなのだと思います。
(こちらの環境では100～300fps位なので、ONのほうがよさげです)
sf298yenさん
私は2千円札をよく包んでました・・・。
BufferedInputのON/OFFどちらがよいかについては、「環境による」ということなのだと思います。私は今回初めて「似たような数字しか出ない事例」を聞きましたし・・・。
OSが何ms刻みでキーボードやマウスの状態を確認しているか、が重要なのであって、FPSは特に関係しないはずです(なので目安にならない)。これと言ってよい確認方法はありませんので、結局のところは「ONとOFF両方試してみて、調子が良さそうな方を使って下さい」となるかなと思います。
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にも適用下さいませ。
from 検証お疲れ様です。ちたにうむ買いましたかー。豪華だ！
で、さっそく CSoundDeviceASIO.cs を拝見させて頂きました。
おおう。確かにヘルプには「0 = first device」とか書いてますね。BASS では「0 = no device」なのに……紛らわしい。
で、少し気になった点がいくつか。
とはいえ、参考にさせて頂きます－。 ありがとうございます。
from p.s.
……とは言え、SST の動作環境は「Win7 以上」なので、ぶっちゃけ ASIO 非対応でも全然問題ないんですけどね（笑
WASASPI 標準搭載バンザイ。
fromさん
from 一応ch1もChannelEnableしてみましょうかね。
ch.1 は ch.0 に Join してるので、ch.0 しか Enable できないと思いますよ。
そうではなくて、出力デバイスが 8ch になっているなら ch.2～7 も ch.0 に Join させる必要があるのでは？とか何とか考えたり。
てか、ASIO の標準ステレオデバイスは ch.0 と 1 が左右チャンネルになっているはずなのですが……
出力デバイスが 8ch になっているなら ch.2～7 も ch.0 に Join させる必要があるのでは？
これで解決しました。お騒がせしました。ただ、他に色々いじってしまっているので、コミットは後日別途。
# よくみたらそんな実装の名残が残ってましたね。
それと、ASIOの既定デバイス取得のところですが、うまく動いていないようです(涙;;;
何度やっても、1台目として見えているCreative ASIOではなく、2番目に見えているがつなげていないUA-5が既定デバイス見えしてしまう・・・(当然、OS上の既定デバイス設定は済ませています)
sf298yen 二千円札・・・自販機で美琴様が爆笑していましたね（謎
確かに珍しい２枚のほうが樋口さん１枚より騙s~bs~bs喜ばれるかもしれないですね。
よし、私もこれからはそうしよう。
私は今回初めて「似たような数字しか出ない事例」を聞きましたし・・・。
「BufferdInput On/Off」
これと言ってよい確認方法はありませんので、結局のところは「ONとOFF両方試してみて、調子が良さそうな方を使って下さい」
kairera0467 更新お疲れ様です。プレイしていて気づいたのですが、 デバイスがDirectShowの時にpresoundにmp3形式のファイルが指定されているものを選択すると、本体側で再生される前に一瞬変な音が鳴ります。 それからDirectShowの時にpresoundがループせず、WASAPIの場合は2回目の途中で切れてしまいます。
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秒したら動的にサウンドをミキサーから削除するようにしていたため。)
あと、私のところでは、Titanium HDを使うと曲のテンポがふらついて演奏に耐えられません。動的なミキサー制御を外しても同様です。基本処理で負荷を増やすようなことは特にしていないはずですが・・・
ASIOのバッファ量を小さくしたら現象が出なくなりました。お騒がせしました。
私の場合、Titanium HDのデフォルト設定が50msになっているところを、20や10, 5msなどにしたところ改善しました。
しかし、この手の話は普通バッファが小さすぎるときに出るものだと思っていましたが、何故に逆の出方をするのだか。
sf298yen お疲れさまです。
環境や曲にもよるのでしょうが、ASIO/WASAPI共に50ms以上だといろいろきつい感じですね...
私の環境では10ms以下に設定するとノイズが入ってしまう為、やむを得ず20msで勤しんでいただかせています。
10msや5msで動かせるなんて羨ましい（呪 ちなみに私の感覚では30ms以下までなら快適だと思えました。
40ms前後で少々違和感が大きくなり、50ms以上では厳しいかもしれない・・・という印象です。
Win7+DSで感じた違和感も、ASIO/WASAPIで解決できるとわかって今後が非常に楽しみです。
'
一番最初のWASAPIサンプルに含まれていた vshost.exeが気になっております：）
ご確認いただきありがとうございます。
WASAPIの方も、バッファサイズを個別に設定できるようにするつもりでいます。ASIOと違って、WASAPIはバッファ量を自動設定に任せると、私の環境だと70ms程度に設定されてしまうのですが、プログラム内で10msとかを設定すると、14msなど悪くない値になるようなので。
vshost.exe は、VisualStudioでビルドすると生成される、デバッグ用のexeです。変な期待を抱かせてしまって申し訳ございませんが、どうぞお気になさりませぬよう。
とはいえ、私は元々ネット経由でのセッションやIRとかをやりたくて本体の開発に入ってきた次第だったりします。 そして、まず第一段階はバグ取りと、最低限の基本機能の底上げを行い(後は区間内の繰り返し練習機能さえ実現できれば・・・)、第二段階として出力ラグを削っているような状況ですので、今のところ順番通りに対応できているとは言えます。 仕事の都合で、開発の進みが非常に遅いのが申し訳ないところですが。
sf298yen 爆弾低気圧は怖いですね・・・
WASAPIの方も、バッファサイズを個別に設定できるようにするつもりでいます。 ・・・プログラム内で10msとかを設定すると、14msなど悪くない値になるようなので。
vshost.exe は、VisualStudioでビルドすると生成される、デバッグ用のexeです。
とはいえ、私は元々ネット経由でのセッションやIRとかをやりたくて本体の開発に入ってきた次第だったりします。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130115.zip
取り立てて代わり映えするものではございませんが、
バグ修正:
既知の問題: (いい機会なのでまとめておきます)
sf298yen とりあえず１週間以上IPアドレスが通知されていないそうです（謎
お疲れさまです。更新はもちろん楽しみにしているのですが、なにぶん私よりもはるかにお忙しいご様子。 無理などされないようにお願いします。
’ 私は主にドラム譜面しかやらない（というかギター譜面がほぼない）のですが、コメントを読んでいると時々思うのはやぎ。様はギター譜面の利用頻度も高い？
ギター譜面については、私が開発で必ずテストするようにしてます(後述する信心ワールドエンドなど)。 以前は全然テストしていなかったので、ギター周りのバグがものすごいことになっていたのですよ・・・。
さて、おかげさまで、昨晩は随分と開発が進みました。既知問題の内、負荷分散の話以外は全て対応できました。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130117.zip
具体的な対応内容は・・・たくさんありますので、詳細はコミット(rev494,495)のログを直接ご覧下さい。
これで性能的なところはほぼ問題ないレベルに落ち着きましたので、さらなる負荷分散の対応は取りあえず棚上げとします。 1.6GHz/2CoreなCPU・XP SP3・UA-5のASIO(バッファ17ms)・信心ワールドエンドExtremeで60fpsをキープできていますので、個人的にはこれで満足です。
WASAPI/ASIO/DirectSound対応はこんなところかなと思っていますが、何か問題があればお知らせ下さい。
sf298yen ギターの信心ワールドエンドexは、スキル６ｋしかない私には無理！orz
どうせギターをやるなら３レーンじゃなく５～６レーンのほうがいいなぁ・・・。
さて、本題。更新お疲れ様です。
テストというほどまだ動かしていないのですが、気づいた点を。
ご確認いただき、ありがとうございます。
sf298yen おつかれさまです。３時間ほど動かしてみました。
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() については明記されていません。 なので、プリロードされる可能性は少しは残っているのかなと思う次第です。
from 追記：
考えてみれば、bass がデコードした後のデータを受け取るはずの bassmix が、入力の前段階であり自分の管轄外であるはずのデコードまで停止してしまうんでしょうね。ストリームの入力を停止する、ならわかるのですが。
ストリームの入力を停止するだけなら、bassmix 側で pause していても、bass 側でのストリームのデコードは続けられると思うのですが。
BASS_MIXER_PAUSE により bassmix から bass の BASS_ChannelPause() を呼び出しているのであれば、この関数でもデコード自体が停止してしまう可能性は高いですね。
……まだまだよく分からないですね。
コメントいただきありがとうございます。
BASSやBASS.NETのソースは公開されていませんので全部想像にはなってしまうのですけれども、fromさんのおっしゃる理屈は凄く筋が通っています。
ただ、結局は試してみないと分からないところだと思いますので・・・早速作りました。
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130120.zip
修正点は、fromさんの見解を見てこちらでも考えては見ましたが、結局はfromさんのご提案と同じです。
こちらで少し動かしてみた限りでは、以下の感触を受けました。
ASIO等の処理で数百msも割り込み停止するとは思えないので、考えられるのはBassNet.DLL内でGCが発生したか、私の環境のサウンドドライバ(Creativeぅ・・)が腐っているか。どちらにせよこちらとしてはミキサー操作が同時に多数発生しないように負荷分散するくらいしか手がなさそう。
ただ、別の意味ではサウンドドライバが腐っている模様。サウンドカードを挿してからというものの、非常に頻繁にBSODや動作停止に見舞われるようになった。俺、WASAPI/ASIO対応の正式版をリリースしたら、とっととTitamumHDをシステムから外すんだ・・・状態。
sf298yen お疲れ様です。夜勤から帰ってきたので早速試させていただきました。(DTXManiaGR_094_WASAPI_20130120.zip)
申し訳ないのですが、やはりBGMズレ発生します・・・。
Windowsを立ち上げて最初にプレイした１曲目で（今のところ）１００％ズレます。
２曲目以降や、DTXManiaを再起動後は（今のところ）発生しません。
サウンドカードを挿してからというものの、非常に頻繁にBSODや動作停止に見舞われるようになった。
sf298yen BGMズレについて追記：
そちらのXPでBGMズレする理由はまだ分かりませんが・・・
tp://yyagi.com/DTXManiaGR_094_WASAPI_20130121.zip
これで、WASAPI/ASIO時にVSyncWaitをOFFにしてスクロール速度を上げても、がたつきが全く目立たなくなりました。 数百msの動作停止も今のところ発生していません。
一応Win7+ASIOで動作確認してます。これからWin7+DSや、XP+ASIOでも確認してみます。
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130122.zip
sf298yen お疲れ様です。「DTXManiaGR_095_WASAPI_20130122.zip」
１時間(XP+ASIOのみ)程ですが、動かしてみました。
Case : XP / AdjustWaves.On / VSyncWait.Off(BufferdInput.off) / AVI.On / ASIO(BuffSize.20)
§ 小節毎に音が切れる症状が発生しました。
Case : XP / AdjustWaves.Off / VSyncWait.Off(BufferdInput.off) / AVI.On / ASIO(BuffSize.20)
(ユーザーフォーラム#67035 プチフリーズ現象)
演奏画面でのGC(Garbage Collection)を止めるようにした
DTXMania起動中にWASAPI/ASIOの設定が反映されるように対応しました。(設定変更のためにアプリを再起動させなくてよくなりました)
§ タスクマネージャでメモリ使用量を見ていましたが、徐々に使用量があがっていきました。
明日・明後日は休みなので時間が取れたらWin7をメインにガッツリ動かそうとたくらんでいます。
sf298yen 外出予定のため少ししか動かせていませんが、Win7でプレイした追記です。
厄介な話ばかりでいつもすみません（涙
「DTXManiaGR_095_WASAPI_20130122.zip」
Case : Win7 / AdjustWaves.Off / VSyncWait.On(BufferdInput.On) / AVI.On / ASIO(BuffSize.20) | WASAPI(BuffSize.20)
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)
※ここでの重い・軽いはキー入力に対してのレスポンスの体感です。
'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() エラーだゴメン！（涙
ご確認いただきありがとうございました。
バッファを小さくすればするほど、応答性は上がりますが、その一方で全体処理は重くなりますので、少しバッファを大きくする体感の重さが変わるかも知れません。
しかし、こちらではいくらやってもASIO→DirectSound時の大量メモリリークは発生しませんでした。 ASIO4ALLとCreativeASIOの両方を使っているとき限定で発生するとかでしょうかね。
とりあえずASIO4ALL(だけ)を入れて試してみますので、お使いのバージョンを教えていただけますでしょうか。 確か正式版と、最新ベータ版があったと思います。どちらをお使いでしょうか？
# ・・・バージョン番号を確認しようとasio4allのサイトに行ってみたら、サイトが消滅していた・・・(驚
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 ASIOConfig.ini設定でASIODeveice=0,1 共に試しましたが同じ結果です。
§再現方法です。
３と４（時々２）を繰り返すとどんどんメモリ使用量が増えていきます。（XP/7)
今からASIO4ALL削除してテストしてみます。
sf298yen XPのみですが、ASIO4ALLを削除して、PC再起動して試しました。
やはりメモリ使用量は増えていくみたいです..
ASIO4ALLを削除した時に発生したのですが、Config.iniでASIODeviceの値が存在する数よりも大きい値を指定しているとConfig画面でインデックスエラーが発生します。
こちらでも現象を確認しました。
ASIO云々と言うより、DirectSound使用時の問題のように見えます。
一つ対策を加えたモジュールを出しますので、お試しいただけますでしょうか。 DirectSound時のサウンド読み込み高速化処理を止めただけですが、メモリ解放に失敗することはなくなりました。 (非DirectSound時のmixer数が負の数になったりするのは無視して下さい)
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130130.zip
ASIOデバイス指定で範囲外エラーになる問題は修正しました。いつもご指摘済みません。
sf298yen 適当と思われる場所がなかったので仮ですがこちらで。
至らぬところばかりでご迷惑おかけすると思いますが、改めてよろしくお願いします＞All
簡単すぎますが、わからない人にはなんのことだかという挨拶はおいておいて、
DTXManiaGR_095_WASAPI_20130130.zip
をXP/7で動かさせていただきました。メモリ増加は見られなくなりました。ありがとうございます。
現段階で私の環境において発生している問題は次の１点です。
こちらこそよろしくお願いします。
メモリリークが無くなったようで、安心しました。Clone()さえなんとかすればよいということで、検討対象がかなり限定されました。
ガタつきについてですが、095以降画面描画関係でいじっているところはGPUのフラッシュしかありません。なので、これを削除したものを作りました。これでガタつきがなくなればよいのですが。
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130131.zip
sf298yen DTXManiaGR_095_WASAPI_20130131.zip
対応ありがとうございます。7で動かして見ましたが、やはりDSではカクツキました。
VSyncWaitありとなし、Window/全画面、共にカクツキがあり、095/WASAPI/ASIOでは目だって発生しません。
グラフドライバの設定も関係あるのかとパフォーマンス重視でいろいろいじってみてますが変化は見られません・・・なんでやorz
⇒垂直同期関連・レンダリング関連など。
sf298yen 問題点の追加(Windows 7)（ASIO/WASAPI）
§「全画面でプレイすると描画遅延」
（DS）
フルスクリーンでの描画遅延は、1つ前のバージョン(GPUフラッシュが入っているバージョン)である
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130130.zip
でも同様でしょうか？
sf298yen DTXManiaGR_095_WASAPI_20130130.zipで試しましたが同じでしたので、調べなおしました。
フルスクリーンでの遅延の原因ですが、どうやらドライバの問題（設定の問題）な感じです（？）。
NVIDIAのGe Forceを使っています。
というわけでWASAPI/ASIO関連の調整とは無縁な感じです。すみませんでした（汗
それにしてもどうしてもDSで動作させるとカクツキが出ます、なぜだーー？
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130202.zip
フルスクリーンでの描画遅延の問題が改善するかも知れない対策を入れました。(解像度切り替えによるフルスクリーン表示を止めて、ウインドウ引き延ばしによる最大化を使用)
また、GPUのフラッシュも復活させました。
DirectSound時のカクつきは未修正です。私のところではスクロールがガクガクするというのはありませんが、スクロールの滑らかさが少し足りないかなと感じています。sf28yenさんのところで起きている現象は、こういう動作でしょうか？
sf298yen yyagi.com/DTXManiaGR_095_WASAPI_20130202.zip 早速の対応ありがとうございます。
DirectSound時のカクつきは未修正です。私のところではスクロールがガクガクするというのはありませんが、スクロールの滑らかさが少し足りないかなと感じています。sf28yenさんのところで起きている現象は、こういう動作でしょうか？
補足：とはいえ、WASAPI/ASIOでプレイしていると一時的にこのDSのカクツキ(?)と同じような感じになることがあるので、原因の追究は必要なのかも・・？
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.で進める(＝問題の先送り)かなぁ(笑)
すみません。GPUのFlushは削除しました。動画あり＋フルスクリーン＋VSyncWait=ONの条件で、カクツキが目立つためです。(ASIOやDirectSoundとかに関係なく発生します)
tp://yyagi.com/DTXManiaGR_095_WASAPI_20130203.zip
は、GPUフラッシュ無しのものに入れ替えました。
sf298yen DTXManiaGR_095_WASAPI_20130203.zip ⇒
対応ありがとうございます。
試しに、DirectSound時のCSoundTimerの動作を、CTimer相当に戻しています。 私のところではこれでスクロールが滑らかになりましたが、いかがでしょうか。
もしこれが効果有りだとすると、今後の対応のやり方が悩ましいです。
§Windows 7での現状の遅延問題は、
といった感じでしょうか？
選択肢は1.で行きます(笑)。
Windows 7での遅延問題は、
で、前者は Vista以降 + DirectSound では必ず発生する問題なので、今回WASAPI/ASIOで解決した。
後者は調査中、となります。
さて、後者について、プログラム側でレンダリング前最大フレーム数を設定する版を昔試作したことがあります。 念のため試していただけませんか。 (開発者向け注: 今のソースツリーをTEST_Direct3D9Exマクロを付与してビルドしただけです)
tp://yyagi.com/DTXManiaGR_095_WASAPI_D3D9Ex_20130204.zip
ただし、試作なので色々難アリです。XPで動かない、動画有りだと画面端が異常でスクロールが激重になる、など。 ご注意下さい。
sf298yen 後者について、 DTXManiaGR_095_WASAPI_D3D9Ex_20130204.zip ⇒
プログラム側でレンダリング前最大フレーム数を設定する版
DTXMania:Win7でFull/VSyncWait=ON/AVI=OFF GeForceドライバ:レンダリング前最大フレーム数=3D アプリケーション設定を使用する/垂直同期=オン
一応ドライバの３Ｄ設定をメモしておきます。間違いや指摘ありましたらお願いします。
CUDA - GPU : すべて アンチエイリアシング - FXAA : オフ アンチエイリアシング - ガンマ修正 : オン アンチエイリアシング - トランスペアレンシー : オフ アンチエイリアシング - モード : オフ アンチエイリアシング - 設定 : なし アンビエント オクルージョン : オフ スレッドした最適化 : 自動 テクスチャ フィルタリング - クオリティ : ハイ パフォーマンス テクスチャ フィルタリング - トリリニア最適化 : オン テクスチャ フィルタリング - ネガティブ LOD バイアス : 許可 テクスチャ フィルタリング - 異方性サンプル最適化 : オン トリプル バッファリング : オフ マルチディスプレイ/ミックス GPU アクセラレーション : マルチディスプレイ パフォーマンス モード（※） レンダリング前最大フレーム数 : 3D アプリケーション設定を使用する 垂直同期 : オン 異方性フィルタリング : オフ 電源管理モード : 適応 ※：シングルディスプレイパフォーマンスモードでも結果は同じです。
tp://yyagi.com/DTXManiaGR_095_WASAPI_D3D9Ex_20130205.zip
MaximumFrameLatencyに1を指定するようにしただけです。(前日のものは0を指定していましたが、今SlimDXのドキュメントを再確認したら、設定可能な値は1～16とありました・・・)
これでダメなら、アプリ側からはもう打つ手無しです。はい。まあ仮にこれで改善したとしても、これを実際に使えるレベルにして投入するのはずっと先の話ですが・・・(まずはWASAPI/ASIO対応版を正式リリースしませんとね。)
sf298yen 対応ありがとうございます。
DTXManiaGR_095_WASAPI_D3D9Ex_20130205.zip ⇒
MaximumFrameLatencyに1を指定するようにしただけです。
というわけで（？）、
会社から：備忘録：DirectSoundでスクロールがなめらかでなくなった件は、timeBeginPeriod()でMultiMediaタイマーの精度を上げていないから、って可能性はないか？ 帰ったらCSoundTimerを確認する。
timeBeginPeriod()はちゃんと使われていました。これじゃなかったか・・・。
というのはともかく、安定動作してきましたので096のbeta版としてビルドしました。後でフォーラムの方にも出しておきます。
tp://yyagi.com/DTXMania096(130214)_beta.zip
ASIOデバイスが一つも登録されていないシステムでCONFIGURATION画面を出すと、例外になる問題を修正しました。(現象をタレこんで下さった方、ありがとうございました。)
正式なWASAPI/ASIO対応が完了いたしましたので、本チケットもクローズとさせていただきます。
Fork
WinXPとWin7の双方でDTXManiaを動かすと、Win7の方が反応が鈍く、 キー入力してからチップ音が再生されるまでのラグが長い。
以下の環境で検証予定。
ここにHDDを2台用意して、XPSP3(x86)とWin7SP1(x64)を導入。ドライバ類は各々のOS用に最新のものを適用した。 この2つのHDDをとっかえひっかえして、動作確認する。実際の遅延は、キー入力してから最終的に絵や音が出るまでの間に
というステップをたどると仮定して、 a～iそれぞれの間でどのくらいの遅延が発生しているかを何とか測定できないか考察する。