アマレコ・オーディオ・レンダラー デバックログとビデオキャプチャ編
アマレコ・オーディオ・レンダラーやPCのオーディオデバイスに付いてもう少し詳しくお話します。
またビデオキャプチャカードに搭載されているオーディオデバイスについてもふれます。
アマレコ・オーディオ・レンダラーのデバックログを見ると録音デバイス、再生デバイスの挙動がある程度見えてきます。主に次のことがわかります。
・録音デバイスが何ミリ秒単位で録音処理しているか（実際のアロケータサイズ）
・録音デバイスが何ミリ秒間隔でデータを送ってくるか（インターバルタイム）
・再生デバイスの実再生レート（再生サンプリングレート）
・そのとき再生デバイスにバッファリングされているデータ量（Latency）
・アマレコ・オーディオ・レンダラーの可変再生速度により補正された様子
１．デバックログのとり方
AmaAudioRenderer.iniのiDebugLogを1にするとAmaRecTV.exeまたはAmaMix.exeと同じフォルダに
「AmAudioRenderer(日時)[デバイス名].txt」と言ったファイル名でデバックログが作成されます。
２．デバックログの見方
例
３．デバックログの例
遅延の実測はステレオ（左右同音）の片チャンネルだけPCのLine入力に接続し、PCのLine出力端子の様子と、PCを通さなかったもう一方のチャンネルの波形を記録します。PCを通さなかった方を基準にしPCを通したチャネルがどれだけ遅れたかを観察します。
３．１．オンボードのオーディオデバイスのLine入力とLine出力
アロケータサイズが40msなので本来ならインターバルタイムは40msなりますが、デバックログを見ると所々31ms間隔になっているのがわかります。
これは、40ms間隔でデータを送るべきところを僅かに遅れ41ms間隔でデータが送られていて、その遅れが徐々に蓄積し10msの遅れに達したとき30ms間隔にすることでバランスをとるよう録音デバイスが動作しているためです。
長い目で見れば遅れた分を取り戻すように動作してるため問題になりませんが、遅延をできるだけ減らそうとした場合は厄介です。 結局この録音デバイスはアロケータサイズによる遅延（40ms）と動作タイミングのばらつきによる遅延（10ms）をあわせた50msの遅延が最低でも生じることになります。
３．２．キャプチャカードSC-500N1/DVI とオンボードLineアウト
アロケータサイズは40msで固定。
インターバルタイムも40msで安定しているのでまずまずの性能です。最後にまとめますが遅延の実測値は64msです。
一箇所マイクロフィードバック制御が働いています（オレンジ部）が、マイクロフィードバック制御はどのオーディオデバイスでも必ず発生するので問題ありません。
３．３．キャプチャカードGV-USB2とオンボードLineアウト
アロケータサイズは50msで固定。
インターバルタイムが30msから60msでばらつくため性能は悪いと言えます。
アロケータサイズが大きめなことと、インターバルタイムがばらつく分、遅延の実測値も悪く101msです。
３．４．ビデオキャプチャカードSD-USB2CUP4 とオンボードLineアウト
アロケータサイズは約32msで固定。
良く見ると受け取るサンプル数（recv）が1536の場合と1535の場合があります。恐らく端数の帳尻を合わせるためと思われますが、これは問題ありません。
インターバルタイムも安定していて、アロケータサイズも小さ目なため遅延の実測値は58msと良好です。
ただ、何で32msなんだろうという疑問はあります。33msなら映像とあわせる為かなと思いますが、小さくできるならもっと小さくてもいいのに・・・
４．まとめ
前回のテストでオンボードのアロケータサイズを20ms以下にしても頭打ちされたと書きましたが、 アマレコ・オーディオ・レンダラーの設定の最小バッファサイズ（iMinimumBuffSizeMS）が20msなので、その部分で頭打ちされていました。
iMinimumBuffSizeMSを0とすることで20ms以下のアロケータサイズのテストができますのでその部分を再テストしました。 その結果も合わせて最後にデータをまとめて記します。
またビデオキャプチャカードに搭載されているオーディオデバイスについてもふれます。
アマレコ・オーディオ・レンダラーのデバックログを見ると録音デバイス、再生デバイスの挙動がある程度見えてきます。主に次のことがわかります。
・録音デバイスが何ミリ秒単位で録音処理しているか（実際のアロケータサイズ）
・録音デバイスが何ミリ秒間隔でデータを送ってくるか（インターバルタイム）
・再生デバイスの実再生レート（再生サンプリングレート）
・そのとき再生デバイスにバッファリングされているデータ量（Latency）
・アマレコ・オーディオ・レンダラーの可変再生速度により補正された様子
１．デバックログのとり方
AmaAudioRenderer.iniのiDebugLogを1にするとAmaRecTV.exeまたはAmaMix.exeと同じフォルダに
「AmAudioRenderer(日時)[デバイス名].txt」と言ったファイル名でデバックログが作成されます。
２．デバックログの見方
例
| 0:02:46.341s(41ms):Smp( recv=1920, write=1901( 99%+0), 48000Hz), Latency=29(20)ms, FALSE= 0, Pos=07981185, 48040, 0:######### |
| 項目 | 例 | 説明 |
| 最初 | 0:02:46.341s(41ms) | データを記録した時間です。例ではプレビューを開始してから2分46秒341ミリ秒経過したときに録音デバイスからデータを受け取っています。 カッコ内は前のデータからの間隔（インターバルタイム）です。例では41ミリ秒間隔でデータを受け取っています。 |
| Smp | Smp( recv=1920, write=1901( 99%+0), 48000Hz) | recvは録音デバイスから受け取ったデータのサンプル数（＝アロケータサイズ）。例では1920サンプル（約40ミリ秒分の音声）のデータを受け取りました。 writeは再生デバイスの再生バッファへ書き出したデータのサンプル数。例では1901サンプル（約39.6ミリ秒分の音声）のデータを書き出しています。 カッコ内は可変再生速度による補正がどのように行われたかを記録しています。 100%なら補正を行っていません。99%なら1%再生時間が短くなるよう補正しています。 101%なら1%再生時間が長くなるよう補正しています。 パーセントの後の+0はさらに細かい制御（マイクロフィードバック制御）情報です。+1か-1になることがあります。 それぞれ1サンプル分再生時間を長く（短く）なるよう補正したことを表します。 最後に再生デバイスの再生レート（サンプリングレート）の実測値を10秒間の平均値で記録しています。 |
| Latency | Latency=29(20)ms | その時点での反応時間です。再生バッファに溜まっているデータ量を1ミリ秒単位で記録しています。 カッコ内は設定値の目標反応時間です。この値に近づくよう可変再生速度が働きます。 例では目標が20ミリ秒に対し現在の反応速度が29ミリ秒と遅れているため、再生時間を短くし、反応時間が20ミリ秒に近づくよう可変再生速度による補正が行われています。 |
| FALSE | FALSE= 0 | 可変再生速度により補正が行われた回数をカウントしています。 必ず必要な補正（プレビューの開始直後や途中で設定値が変更された場合）はカウントされません。 また、マイクロフィードバック制御の場合もカウントしません。 例では補正が行われていますが、直前に目標反応時間が30から20に変更された事による補正のためカウントされていません。 |
| Pos | Pos=07981185,48040,0 | 再生デバイスのその時点での再生位置です。余り重要ではありません。 48040,0はLatencyの値を計算するのに使う補正値です。余り重要ではありません。 |
| 最後の# | ######### | 補正の様子を#の個数で表示します。100%の時#を10個表示します。99%の時は9個と1%ごとに#が減ります。 |
３．デバックログの例
| OS | Windows7 x64 Professional SP1 | |
| CPU | Intel(R) Core(TM) i5-3470S CPU @ 2.90GHz Ivy Bridge | |
| MB | ASRock H77 Pro4-M (Intel H77) | |
| Memory | DDR3 1600 8GB(4GBx2 Dual Cannel)read=23.7GB/s write=12.2GB/s | |
| Software | アマミキ！ Ver1.01 AmAudioRenderer Ver2.30 | |
| Audio Device | オンボードのLine入力、Line出力 Realtek High Definition Audio | Driver:6.0.1.6482 |
| Capture Card | GV-USB2 S端子 | Driver:1.1.0.93.5, 2010.06.28 |
| SD-USB2CAP4 S端子 | Driver:5.2009.917.0 | |
| SC-500N1/DVI コンポーネント端子 | Driver:1.1.0.108.0, 2011.08.09 |
遅延の実測はステレオ（左右同音）の片チャンネルだけPCのLine入力に接続し、PCのLine出力端子の様子と、PCを通さなかったもう一方のチャンネルの波形を記録します。PCを通さなかった方を基準にしPCを通したチャネルがどれだけ遅れたかを観察します。
３．１．オンボードのオーディオデバイスのLine入力とLine出力
| 0:04:51.861s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14006198, 47999, 639:########## 0:04:51.892s(31ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14007678, 48000, 9:########## 0:04:51.932s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14009637, 48001, 8:########## 0:04:51.972s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14011559, 48002, 8:########## 0:04:52.013s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14013520, 48003, 7:########## 0:04:52.054s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14015479, 48004, 6:########## 0:04:52.095s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14017436, 48005, 5:########## 0:04:52.135s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14019357, 48006, 5:########## 0:04:52.176s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14021320, 48007, 5:########## 0:04:52.217s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14023280, 48008, 4:########## 0:04:52.257s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14025240, 48009, 3:########## 0:04:52.297s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14027158, 48010, 3:########## 0:04:52.338s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14029119, 48011, 2:########## 0:04:52.379s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14031080, 48012, 1:########## 0:04:52.420s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14033040, 48012, 0:########## 0:04:52.460s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14034958, 48012, 0:########## 0:04:52.501s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14036920, 47999, 639:########## 0:04:52.532s(31ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14038399, 48000, 9:########## 0:04:52.572s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14040358, 48001, 8:########## 0:04:52.612s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14042280, 48002, 8:########## 0:04:52.653s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14044240, 48003, 7:########## 0:04:52.694s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14046199, 48004, 6:########## 0:04:52.735s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14048159, 48005, 5:########## 0:04:52.775s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14050087, 48006, 5:########## 0:04:52.816s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14052046, 48007, 4:########## 0:04:52.857s(41ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=14054007, 48008, 4:########## |
アロケータサイズが40msなので本来ならインターバルタイムは40msなりますが、デバックログを見ると所々31ms間隔になっているのがわかります。
これは、40ms間隔でデータを送るべきところを僅かに遅れ41ms間隔でデータが送られていて、その遅れが徐々に蓄積し10msの遅れに達したとき30ms間隔にすることでバランスをとるよう録音デバイスが動作しているためです。
長い目で見れば遅れた分を取り戻すように動作してるため問題になりませんが、遅延をできるだけ減らそうとした場合は厄介です。 結局この録音デバイスはアロケータサイズによる遅延（40ms）と動作タイミングのばらつきによる遅延（10ms）をあわせた50msの遅延が最低でも生じることになります。
３．２．キャプチャカードSC-500N1/DVI とオンボードLineアウト
| 0:01:01.171s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=02923357, 48000, 0:########## 0:01:01.211s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=02925278, 48000, 0:########## 0:01:01.251s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02927197, 48000, 0:########## 0:01:01.291s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=02929117, 48000, 0:########## 0:01:01.331s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=02931037, 48000, 0:########## 0:01:01.371s(40ms):Smp( recv=1920, write=1921(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=02932959, 48000, 0:########## 0:01:01.411s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02934878, 48000, 0:########## 0:01:01.451s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02936798, 48000, 0:########## 0:01:01.491s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02938718, 48000, 0:########## 0:01:01.531s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02940640, 48000, 0:########## 0:01:01.571s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02942557, 48000, 0:########## 0:01:01.611s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02944478, 48000, 0:########## 0:01:01.651s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02946398, 48000, 0:########## 0:01:01.691s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02948318, 48000, 0:########## 0:01:01.731s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02950237, 48000, 0:########## 0:01:01.771s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02952158, 48000, 0:########## 0:01:01.811s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02954078, 48000, 0:########## 0:01:01.851s(40ms):Smp( recv=1920, write=1920(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=02955999, 48000, 0:########## |
アロケータサイズは40msで固定。
インターバルタイムも40msで安定しているのでまずまずの性能です。最後にまとめますが遅延の実測値は64msです。
一箇所マイクロフィードバック制御が働いています（オレンジ部）が、マイクロフィードバック制御はどのオーディオデバイスでも必ず発生するので問題ありません。
３．３．キャプチャカードGV-USB2とオンボードLineアウト
| 0:03:58.300s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11425086, 48005, 20:########## 0:03:58.360s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11427963, 48006, 10:########## 0:03:58.420s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11430844, 48006, 0:########## 0:03:58.450s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11432284, 48007, 20:########## 0:03:58.509s(59ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11435117, 48008, 11:########## 0:03:58.570s(61ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11438044, 48008, 0:########## 0:03:58.600s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11439484, 48009, 19:########## 0:03:58.659s(59ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11442318, 48010, 10:########## 0:03:58.720s(61ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11445242, 47999, 0:########## 0:03:58.750s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11446684, 48001, 20:########## 0:03:58.809s(59ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11449518, 48002, 11:########## 0:03:58.870s(61ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11452442, 48002, 0:########## 0:03:58.900s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11453885, 48003, 20:########## 0:03:58.960s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11456762, 48004, 10:########## 0:03:59.020s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11459644, 48004, 0:########## 0:03:59.050s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11461084, 48005, 20:########## 0:03:59.109s(59ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11463961, 48006, 10:########## 0:03:59.169s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11466844, 48006, 0:########## 0:03:59.199s(30ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11468284, 48007, 19:########## 0:03:59.259s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11471160, 48008, 10:########## 0:03:59.319s(60ms):Smp( recv=2400, write=2400(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=11474045, 47999, 0:########## |
アロケータサイズは50msで固定。
インターバルタイムが30msから60msでばらつくため性能は悪いと言えます。
アロケータサイズが大きめなことと、インターバルタイムがばらつく分、遅延の実測値も悪く101msです。
３．４．ビデオキャプチャカードSD-USB2CUP4 とオンボードLineアウト
| 0:02:00.536s(32ms):Smp( recv=1536, write=1537(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05714798, 48000, 0:########## 0:02:00.568s(32ms):Smp( recv=1536, write=1537(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05716334, 48000, 0:########## 0:02:00.600s(32ms):Smp( recv=1536, write=1537(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05717869, 48000, 0:########## 0:02:00.632s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05719404, 48000, 0:########## 0:02:00.664s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05720940, 48000, 0:########## 0:02:00.696s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05722476, 48000, 0:########## 0:02:00.728s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05724012, 48000, 0:########## 0:02:00.760s(32ms):Smp( recv=1535, write=1536(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05725550, 48000, 0:########## 0:02:00.792s(32ms):Smp( recv=1535, write=1535(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05727084, 48000, 0:########## 0:02:00.824s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05728620, 48000, 0:########## 0:02:00.856s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05730157, 48000, 0:########## 0:02:00.888s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05731693, 48000, 0:########## 0:02:00.920s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05733229, 48000, 0:########## 0:02:00.952s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05734764, 48000, 0:########## 0:02:00.984s(32ms):Smp( recv=1536, write=1537(100%+1), 48000Hz), Latency= 9(10)ms, FALSE= 0, Pos=05736302, 48000, 0:########## 0:02:01.016s(32ms):Smp( recv=1536, write=1536(100%+0), 48000Hz), Latency=10(10)ms, FALSE= 0, Pos=05737837, 48000, 0:########## |
アロケータサイズは約32msで固定。
良く見ると受け取るサンプル数（recv）が1536の場合と1535の場合があります。恐らく端数の帳尻を合わせるためと思われますが、これは問題ありません。
インターバルタイムも安定していて、アロケータサイズも小さ目なため遅延の実測値は58msと良好です。
ただ、何で32msなんだろうという疑問はあります。33msなら映像とあわせる為かなと思いますが、小さくできるならもっと小さくてもいいのに・・・
４．まとめ
前回のテストでオンボードのアロケータサイズを20ms以下にしても頭打ちされたと書きましたが、 アマレコ・オーディオ・レンダラーの設定の最小バッファサイズ（iMinimumBuffSizeMS）が20msなので、その部分で頭打ちされていました。
iMinimumBuffSizeMSを0とすることで20ms以下のアロケータサイズのテストができますのでその部分を再テストしました。 その結果も合わせて最後にデータをまとめて記します。
| 録音デバイス | 設定 | 遅延 実測値 | 補足 | |
| アロケータ サイズ | iLatency | |||
| Lineイン | 40ms | 40ms | 104ms | |
| Lineイン | 40ms | 30ms | 94ms | 初期値 |
| Lineイン | 40ms | 20ms | 84ms | |
| Lineイン | 40ms | 10ms | 74ms | |
| Lineイン | 30ms | 40ms | 88ms | |
| Lineイン | 20ms | 40ms | 78ms | |
| Lineイン | 10ms | 40ms | 68ms | iMinimumBuffSizeMS=0 |
| Lineイン | 20ms | 20ms | 58ms | このあたりが妥当 |
| Lineイン | 10ms | 10ms | 44ms | iMinimumBuffSizeMS=0 |
| SC-500N1/DVI | 40ms | 10ms | 64ms | アロケータサイズは40msで固定 |
| GV-USB2 | 50ms | 10ms | 101ms | アロケータサイズは50msで固定 |
| SD-USB2CUP4 | 32ms | 10ms | 58ms | アロケータサイズは32msで固定 |
※ 遅延の実測値には±5ms程度の誤差があります。
オンボードLineインのアロケータ40ms、iLatency10msとキャプチャカードのSC500を比べるとアロケータサイズ、Latencyが同じなので遅延の実測値も近くなるはずですが、10msオンボードのほうが遅れています。これはデバックログのところでお話した録音デバイスのインターバルタイムが不安定なためです。同様にLineインのほかの実測値も10ms余計に多くなっているものと推測できます。もし、インターバルタイムが安定していたらアロケータ10ms、iLatency10msで実測遅延34msとなるのかもしれません。
一方ビデオキャプチャカードの方はアロケータサイズの変更ができないためこれ以上遅延を減らすことができません。もう一歩踏み込んでアロケータサイズの変更に対応してもらえると良いなと思います。
ビデオキャプチャカードのタイミングと遅延
「アマレコTV用 デインターレースフィルタ Ver2.20d ベータ版」で触れたようにアマレコTVがビデオキャプチャカードからデータを受け取る際のタイミングにはばらつきがあります。
それを確認するためにAmDeinterlace.axと同じフォルダにある「AmDeinterlace.ini」をメモ帳で開いて「iDebugLog」を”1”にするとアマレコTVがデータを受け取った際の時刻やステータスを記録したログファイルを作成することができます。また、「iWaitDeliver」は今回のタイミング調整を行うかどうかの設定です。0なら調整を行わない（今まで通りの動作）。1でタイミング調整を行うようになります。初期値は1です。なお、タイミング調整はアマレコTVのプレビュー設定でソフトウエアデインターレースを使う場合に限り行われます。デインターレースを行わなかったり、ハードウエアデインターレースを使う場合はタイミング調整は行われません（今のところ必要ないので）。
■テスト環境
PlayStation2本体でPS1のゲーム「雷電プロジェクトの雷電II」を使用。
このゲームのビデオ信号は擬似NTSC（240p 60fps）になります。
■GV-USB2の結果
各行にデータを受け取った時刻とステータスが記録されています。
赤枠の部分は一つ前のデータからの経過時間（インターバルタイム）でビデオキャプチャカードのタイミングを観察できます（今回注目する値）。
IdleはアマレコTVのデータ処理が終わり次のデータが届くまでの暇な時間（アイドルタイム）。この時間が少ないと遅延している（急いでデータが送られてきている）可能性があります。
IdleCountはIdleが小さい時にカウントが増えます。一定値に達すると遅延を回復するため意図的にプレビューの画像をドロップします。
Sizeは受け取ったデータ量。上記では720 x 480 x 2=691,200バイトになります。
SP、Pl、DcはDirectShowフィルターのステータス。
行の最後にはインターバルタイムを“#”の個数で表示しています。#ひとつが5msです。
GV-USB2の場合、擬似NTSCのビデオ信号を秒間30フレームのデータ（インターレースのようにインターリーブされたデータ）として送ってきますので、正常なインターバルタイムは33msとなります。
しかし、ところどころ約64msになっており33msより大きく遅れているのがわかります。 その後、数フレームを33msより早いタイミングで送ることで平均的に見て33msとなるよう動作しています。
背景が青くなっている23フレーム分（約0.8秒）が一つのサイクルになっているようです。
■SD-USB2CAP4の結果
SD-USB2CAP4も秒間30フレームのデータとして送ってきますので正常なインターバルタイムは33msです。
GV-USB2の時と同様インターバルタイムが33msより遅くなることがありますが約40msとGV-USB2より遅れは少なくなっています。
こちらも青くした6フレーム（約0.2秒）を1サイクルとして平均33msになるよう動作しています。
■SC500N1/DVIの結果
SC500では擬似NTSCのビデオ信号を720 x 240プログレッシブ 60fps（59.94fps）でキャプチャするため正常なインターバルタイムは16.6msです。
テスト結果から約16.7msで安定しているのがわかります。
これは、アマレコTVでタイミング調整することなく滑らかなプレビューができるだけでなく遅延も少ない事を意味します。
■遅延に付いて
遅延に付いて語るのは難しいのですが、今回の結果からビデオキャプチャカードにより生じる遅延の最小値（最低でもこれだけは遅延すると言う値）は次のようになります。
※ この他に、ビデオレンダラーによる遅延とビデオカードによる遅延が生じます（両方あわせて約17ms）。また、Windows7でデスクトップコンポジションを行う場合はデスクトップコンポジションによる遅延も生じます。
■最後に
GV-USB2とSD-USB2CAP4でタイミングがばらつく原因は判りませんが、 もうすこしタイミングが安定されると良いなと思います。あと擬似NTSCがキャプチャできるだけでも有難いけど、SC500の様に240pでキャプチャできればパソコンの画面を見ながらゲームしやすくなると思うので、そういった商品も今後出てくると良いなと思います。
それを確認するためにAmDeinterlace.axと同じフォルダにある「AmDeinterlace.ini」をメモ帳で開いて「iDebugLog」を”1”にするとアマレコTVがデータを受け取った際の時刻やステータスを記録したログファイルを作成することができます。また、「iWaitDeliver」は今回のタイミング調整を行うかどうかの設定です。0なら調整を行わない（今まで通りの動作）。1でタイミング調整を行うようになります。初期値は1です。なお、タイミング調整はアマレコTVのプレビュー設定でソフトウエアデインターレースを使う場合に限り行われます。デインターレースを行わなかったり、ハードウエアデインターレースを使う場合はタイミング調整は行われません（今のところ必要ないので）。
| 【注意】 ビデオキャプチャカードのタイミングを観察するときはアマレコTVのタイミング調整が影響してしまうので「iWaitDeliver」を0にしてタイミング調整しない状態で観察してください。 |
■テスト環境
| OS | Windows7 x64 Professional SP1 | |
| CPU | Intel(R) Core(TM) i5-3470S CPU @ 2.90GHz Ivy Bridge | |
| MB | ASRock H77 Pro4-M (Intel H77) | |
| Memory | DDR3 1600 8GB(4GBx2 Dual Cannel)read=23.7GB/s write=12.2GB/s | |
| Software | アマレコTV Ver2.20c AmDeinterlace.ax Ver2.20d | |
| Capture Card | GV-USB2 S端子 | Driver:1.1.0.93.5, 2010.06.28 |
| SD-USB2CAP4 S端子 | Driver:5.2009.917.0 | |
| SC-500N1/DVI コンポーネント端子 | Driver:1.1.0.108.0, 2011.08.09 | |
PlayStation2本体でPS1のゲーム「雷電プロジェクトの雷電II」を使用。
このゲームのビデオ信号は擬似NTSC（240p 60fps）になります。
■GV-USB2の結果
各行にデータを受け取った時刻とステータスが記録されています。
赤枠の部分は一つ前のデータからの経過時間（インターバルタイム）でビデオキャプチャカードのタイミングを観察できます（今回注目する値）。
IdleはアマレコTVのデータ処理が終わり次のデータが届くまでの暇な時間（アイドルタイム）。この時間が少ないと遅延している（急いでデータが送られてきている）可能性があります。
IdleCountはIdleが小さい時にカウントが増えます。一定値に達すると遅延を回復するため意図的にプレビューの画像をドロップします。
Sizeは受け取ったデータ量。上記では720 x 480 x 2=691,200バイトになります。
SP、Pl、DcはDirectShowフィルターのステータス。
行の最後にはインターバルタイムを“#”の個数で表示しています。#ひとつが5msです。
GV-USB2の場合、擬似NTSCのビデオ信号を秒間30フレームのデータ（インターレースのようにインターリーブされたデータ）として送ってきますので、正常なインターバルタイムは33msとなります。
しかし、ところどころ約64msになっており33msより大きく遅れているのがわかります。 その後、数フレームを33msより早いタイミングで送ることで平均的に見て33msとなるよう動作しています。
背景が青くなっている23フレーム分（約0.8秒）が一つのサイクルになっているようです。
■SD-USB2CAP4の結果
SD-USB2CAP4も秒間30フレームのデータとして送ってきますので正常なインターバルタイムは33msです。
GV-USB2の時と同様インターバルタイムが33msより遅くなることがありますが約40msとGV-USB2より遅れは少なくなっています。
こちらも青くした6フレーム（約0.2秒）を1サイクルとして平均33msになるよう動作しています。
■SC500N1/DVIの結果
SC500では擬似NTSCのビデオ信号を720 x 240プログレッシブ 60fps（59.94fps）でキャプチャするため正常なインターバルタイムは16.6msです。
テスト結果から約16.7msで安定しているのがわかります。
これは、アマレコTVでタイミング調整することなく滑らかなプレビューができるだけでなく遅延も少ない事を意味します。
■遅延に付いて
遅延に付いて語るのは難しいのですが、今回の結果からビデオキャプチャカードにより生じる遅延の最小値（最低でもこれだけは遅延すると言う値）は次のようになります。
| ビデオキャプチャカード | 遅延（最小値） |
| GV-USB2 | 約64ms |
| SD-USB2CAP4 | 約40ms |
| SC500N1/DVI | 約17ms |
※ この他に、ビデオレンダラーによる遅延とビデオカードによる遅延が生じます（両方あわせて約17ms）。また、Windows7でデスクトップコンポジションを行う場合はデスクトップコンポジションによる遅延も生じます。
■最後に
GV-USB2とSD-USB2CAP4でタイミングがばらつく原因は判りませんが、 もうすこしタイミングが安定されると良いなと思います。あと擬似NTSCがキャプチャできるだけでも有難いけど、SC500の様に240pでキャプチャできればパソコンの画面を見ながらゲームしやすくなると思うので、そういった商品も今後出てくると良いなと思います。
