オーディオインターフェースのASIOバッファを少なく抑えつつ、オーディオドロップアウト（音の途切れやノイズの発生）を防いでDAWを安定動作させるには、様々なアプローチがあります。
今回はその中でも「DPCレイテンシー対策」に絞り、実体験を踏まえながら解説していきます。
なお私の制作環境は、Cubase Pro 14、Windows10、i5-8400、Rubix22、GT1030です（2025年現在）。
DPCレイテンシーとは何か
DPCは「Deferred Procedure Call」の略で、Windowsが複数のタスクやデバイスドライバーの処理に優先順位をつけ、効率的に実行するための仕組みの一つです。
簡単に言うと、OSが「後回し」にできる処理を一時的にキューにためておき、優先度の高い処理が終わってから実行する、というような仕組みのことです。
そもそもDAWのオーディオ信号は、非常に短い時間間隔で連続的に処理される必要があります。
しかし、もしOSが他のデバイスドライバー（例えばネットワークアダプターやUSBデバイスなど）のDPC処理に想定以上の時間をかけてしまうと、オーディオドライバーの処理が後回しにされてしまい、データのやり取りが間に合わなくなってしまいます。
これが「DPCレイテンシーが大きい状態」であり、下記のような現象を引き起こします。
- プチノイズやプツプツといった音切れ
- クリックノイズ
- 音飛び（ドロップアウト）
- ひどい場合は、DAWやオーディオインターフェースが認識しなくなる
これらはDAWの安定動作に致命的で深刻な影響を与えるため、DPCレイテンシー対策は重要です。
LatencyMonでDPCレイテンシーを確認する
DPCレイテンシーを確認するためには「LatencyMon」というアプリを使用します。
LatencyMonを使うとDPCとISRのレイテンシーをリアルタイムで計測でき、大きなレイテンシーを生じさせているデバイスドライバーを特定することが可能になります。
確認方法は、LatencyMonの計測を開始し、普段通りにDAWを5分以上操作します。また、DAWを起動せずに何も操作しない「OSのアイドリング状態」でも同様に計測しておきます。
計測を終えたら、Driversタブに表示された個々のデバイスドライバーについて対策を進めていくことになります。
一連の作業の流れと各デバイスドライバーの対策方法について、Native Instruments社が分かりやすい動画と資料を公開していますので参考にして下さい（日本語字幕版）。
許容できるDPCレイテンシーの目安
DPCレイテンシーが数値として把握できるようになると、どうしても「出来るだけ少なく抑えたい」という気持ちが起こってしまうものです。
しかし過剰なチューニングに陥って本来の音楽制作を疎かにしては本末転倒です（これはあらゆるDAWカスタマイズチューニングに言えることです）。
そこで、あらかじめ目安となるDPCレイテンシーの値を把握しておくことで、程よく安定したDAW環境を目指すことが可能でしょう。
具体的には経験上、以下の数値に収まっていてDAWの通常操作時にノイズや音飛びが発生しなければOKとするのが目安と思われます。
- 個々のデバイスドライバー：500マイクロ秒以下
- トータルのレイテンシー値：1,000マイクロ秒以下
私の環境の場合（Windows10、i5-8400、Rubix22、GT1030）、対策した結果、個々のデバイスドライバーのレイテンシーは最大のもので300～500マイクロ秒ほど、トータルでも最大500マイクロ秒程度に収まっています。
対策前はトータル値が約1,000マイクロ秒になったケースがありましたが、それでもノイズや音飛びは確認できませんでした。
ASIOバッファを64サンプル以下にするなどの設定にしている場合は、この目安値だとオーディオドロップアウトが発生する可能性がありますが、256サンプル以上の設定であれば大抵問題になることは無いと思われます。
ちなみに、44.1khzで64サンプルだと許容時間は約1,450マイクロ秒、256サンプルだと約5,800マイクロ秒になります。
この許容時間内にDPCレイテンシーを含めた実際のDAWやOSでの各種処理が完了していれば、オーディオドロップアウトの問題は起こらないということになります。
対策の具体例：ネットワークアダプター（NIC）の設定
私の環境の場合「ndis.sys」のレイテンシーが大きく、800マイクロ秒を頻繁に超え、時には1,000マイクロ秒を大きく超えるケースも見られました。
使用しているオンボードのネットワークアダプターは「Realtek PCIe GbE Family Controller」です。
デバイスマネージャーからネットワークアダプターのプロパティを開き、以下のように設定を行いました。
- 「割り込みモデレーション」を無効にする。
- オフロード（チェックサム処理等をNICで行う）を無効にする。
この結果、当初の半分以下にまでレイテンシーを下げることが出来ました（DAW使用時の最大値で約400マイクロ秒以下に抑えられた）。
「割り込みモデレーション」を無効にする
今回のケースでは特に、割り込みモデレーションをオフにすることが効果的でした。
「割り込みモデレーション」とは、データパケットが届くたびに即座に割り込みをかけるのではなく、いくつかのパケットが貯まるか、あるいは一定の時間が経過するまで待ってから、まとめて一度の割り込みでCPUに通知する仕組みです。
割り込みモデレーションを無効にするとデータパケット処理を随時行うことになるため、これは一見するとCPU負荷が高まるように感じます。
しかし現在のCPU性能的には誤差の範囲でしかなく、処理待ちによるレイテンシーの影響の方が大きく目立つ結果になっており、今回のような大きな改善につながっています（実際、CPU負荷や消費電力に変化は見られませんでした）。
オフロード（チェックサム処理等をNICで行う）を無効にする
下記の項目を無効にします。
- IPv4チェックサム オフロード
- TCPチェックサム オフロード（IPv4）
- TCPチェックサム オフロード（IPv6）
- UDPチェックサム オフロード（IPv4）
- UDPチェックサム オフロード（IPv6）
オフロードを無効にすることの効果はわずかでしたが、有効時にはWdf01000.sysやCLASSPNP.sysが1,000マイクロ秒を超えるレイテンシーを生じさせることがあったものが、無効にすることで見られなくなりました（直接的な関連性があったのかは不明です）。
本来であればチェックサム処理などをNICに肩代わりさせると処理が軽くなるはずですが、実際には必ずしもそうならなかったり、大きなDPCレイテンシーを生じてしまうケースがあります。
その原因の仮説としては、IPデータのインテグリティ（完全性）を担保するために、OS内部で種々のロックを行う必要があり、それによってかえって処理が遅くなってしまう事象が起こっているのではないかと推測されます。
その他のNIC設定について
他にも下記のような対策がありますが、今回の場合は設定しても変化が見られませんでした（環境によってはレイテンシーの改善が見られる可能性があります）。
- 大量送信オフロード（大容量送信データ分割処理をNICで行う）を無効にする。
- 受信側スケーリング（RSS：マルチコア処理）を無効にする。
- 省電力設定を無効にする。
ちなみにNICの省電力機能はオンオフの切り替えが極めて速く、この機能がレイテンシーに影響を及ぼす可能性は低いと考えられ、実際に私の環境では影響は観測されませんでしたので、運用上は省電力機能はオンにしています。
対策の具体例：グラフィックドライバーの設定
もう一つ大きな改善につながったのが、グラフィックドライバーの設定でした。
具体的には、Windowsの設定にある「ハードウェア アクセラレータによるGPUスケジューリング」をオフにすることで、DPCレイテンシーを大きく改善することが出来ました。
当初は700～1,000マイクロ秒という最大レイテンシーが計測されていましたが、対策後は突発的な最大値で500マイクロ秒程度になり、通常のDAW使用時では最大300マイクロ秒程度に収まるようになりました。
使用しているのはNVIDIA GT1030という古い設計のグラフィックカードなので、これは一般的な対策とは言い難いのですが、とても効果があったためお伝えしておきます。
この設定はWindows 11では標準でオンになっているものなので、あえてオフにすることには相応の理由が求められると思います。
今回の場合ですと、CPUとGPUの性能のアンバランス（GPUの性能不足）によって、かえってCPU側に負荷や処理待ちが生じていた可能性が考えられます。
もしくはGPUの設計の古さから、ドライバーやOSが想定通り機能していないという想像もできます。
いずれにせよ、DPCレイテンシーの実測で明らかな改善があったため、私の環境では「ハードウェア アクセラレータによるGPUスケジューリング」をオフにして運用しています。
「ハードウェア アクセラレータによるGPUスケジューリング」について
この機能は2020年、Windows 10でリリースされました。
その名前が示すように、GPUスケジューリングの大部分をCPUから専用のGPUベースのスケジューリングプロセッサにオフロードするものです（肩代わりさせる）。
GPUスケジューリングがハードウェアアクセラレーションによって処理されることで、CPUの負荷 (GPUスケジューリングのオーバーヘッド) が削減され、特定の処理においてパフォーマンスとシステム遅延が改善されます。
しかし実際のところ、この機能を用いてもパフォーマンスには変化が見られないケースが目立ちます。
その理由は、既に開発プログラマーたちが従来のGPUスケジューリングの効率的な対処法（最適化）を見つけ出しおり、パフォーマンスの限界をほぼ達成していたためだと言われています。
Microsoftがこの機能で目指したのは、単なるパフォーマンス向上のためではなく、グラフィックシステムの近代化とその先への道筋をつけるためだったと考えられます。
ntoskrnl.sysの対策について
LatencyMonで「ntoskrnl.sys」が大きなレイテンシーを示す場合は、問題の特定が難しくなります。
というのも、ntoskrnl.sysはWindows OSの核となるカーネル自体であり、特定のハードウェアドライバーのように「このデバイス」と紐づけにくいからです。
ntoskrnl.sys がDPCレイテンシーを生むのは、カーネルが以下のいずれかの理由で待機状態になっているか、処理に時間がかかっていることを意味します。
- カーネル自身の処理：
OSの根幹部分（スケジューリング、メモリ管理、プロセス管理、I/O管理など）での処理に時間がかかっている。 - 他のドライバーやシステムイベントの代理処理：
多くのドライバーは、ハードウェアとのやり取りやOSサービスへの要求をntoskrnl.sys を通じて行う。そのため他のドライバーの非効率な処理や待ち時間が、あたかも ntoskrnl.sysが原因であるかのように見えることがある。 - システム全体の特定の状態変化：
電源状態の遷移、CPU周波数の変更、あるいはSMIs（BIOSが処理する非常に優先度の高い割り込み）などのシステムレベルのイベント処理が、ntoskrnl.sysの活動として計測される結果、それらがレイテンシーとなって現れる。
これらのことから、ntoskrnl.sysのDPCレイテンシーが大きい場合、まず最初に対策するべきなのは電源関連の設定（省電力設定）だと考えられます。
CPUや各種ドライバーの省電力設定を見直し、省電力機能を個々にオフにしながらレイテンシーの変化を計測してみましょう。
ASIOバッファを小さくする必要がある場合、BIOSでC-stateを無効にして高パフォーマンス化したり、 OSの電源管理プロファイルを「高パフォーマンス」に設定することも効果的です。
とはいえ、上記のようにntoskrnl.sysのレイテンシーの原因を特定することは困難ですので、現実的な目安を参考にして程々のレイテンシーに収まっていれば良しとするのがおすすめです。
実際、私のケースだと、NICやグラフィックドライバーの対策後のntoskrnl.sysの最大レイテンシーは、通常作業時で500マイクロ秒を大きく超えることはなかったので、これ以上の対策は時間コストに見合わないと判断しました。
DPCレイテンシー対策～最後に
DAWのDPCレイテンシー対策については、LatencyMonの使い方を始めとして、ネット上で様々な詳しい情報が見つかります。
そこでこの記事では、私の制作環境での具体的なケースに絞って紹介しました。
実際にDPCレイテンシー対策に取り組んだ情報が、あなたの環境改善に役立てば幸いです。
