Es gibt verschiedene Ansätze, um den stabilen Betrieb einer DAW sicherzustellen, während gleichzeitig der ASIO-Puffer des Audio-Interfaces niedrig gehalten und Audio-Aussetzer (Unterbrechungen oder Rauschen im Ton) verhindert werden.
Dieses Mal konzentrieren wir uns speziell auf „Maßnahmen gegen DPC-Latenz“ und erläutern diese anhand praktischer Erfahrungen.
Meine Produktionsumgebung ist Cubase Pro 14, Windows 10, i5-8400, Rubix22, GT1030 (Stand 2025).
Was ist DPC-Latenz?
DPC ist die Abkürzung für „Deferred Procedure Call“ und ist einer der Mechanismen, die Windows verwendet, um die Verarbeitung mehrerer Aufgaben und Gerätetreiber zu priorisieren und effizient auszuführen. Einfach ausgedrückt handelt es sich um einen Mechanismus, bei dem das Betriebssystem Verarbeitungsvorgänge, die „aufgeschoben“ werden können, vorübergehend in einer Warteschlange speichert und sie ausführt, nachdem Verarbeitungsvorgänge mit höherer Priorität abgeschlossen sind.
DAW-Audiosignale müssen grundsätzlich in sehr kurzen Zeitintervallen kontinuierlich verarbeitet werden. Wenn das Betriebssystem jedoch mehr Zeit als erwartet für die DPC-Verarbeitung anderer Gerätetreiber (wie z. B. Netzwerkadapter oder USB-Geräte) benötigt, wird die Verarbeitung des Audio-Treibers aufgeschoben und die Datenübertragung kommt ins Stocken. Dies ist ein Zustand „hoher DPC-Latenz“ und führt zu folgenden Phänomenen:
- Tonunterbrechungen wie Knacken oder Ploppen
- Klickgeräusche
- Tonaussetzer (Dropouts)
- In schweren Fällen werden die DAW oder das Audio-Interface nicht mehr erkannt
Diese Probleme haben schwerwiegende und fatale Auswirkungen auf den stabilen Betrieb einer DAW, daher sind Maßnahmen gegen DPC-Latenz wichtig.
DPC-Latenz mit LatencyMon überprüfen
Um die DPC-Latenz zu überprüfen, verwenden Sie eine Anwendung namens „LatencyMon“. Mit LatencyMon können Sie die DPC- und ISR-Latenz in Echtzeit messen und die Gerätetreiber identifizieren, die eine hohe Latenz verursachen.
Die Methode besteht darin, die Messung mit LatencyMon zu starten und Ihre DAW wie gewohnt mindestens 5 Minuten lang zu bedienen. Führen Sie die Messung auch im „Leerlaufzustand des Betriebssystems“ durch, ohne die DAW zu starten oder irgendetwas zu tun.
Nach Abschluss der Messung gehen Sie zur Behebung der einzelnen Gerätetreiber über, die auf der Registerkarte „Drivers“ angezeigt werden.
Native Instruments hat verständliche Videos und Materialien zum Ablauf der Arbeiten und zu Maßnahmen für einzelne Gerätetreiber veröffentlicht (mit japanischen Untertiteln), die Sie als Referenz verwenden können:
Richtwert für akzeptable DPC-Latenz
Sobald Sie die DPC-Latenz als numerischen Wert erfassen können, entsteht natürlich der Wunsch, sie so niedrig wie möglich zu halten. Es wäre jedoch kontraproduktiv, in übermäßiges Tuning zu verfallen und die eigentliche Musikproduktion zu vernachlässigen (dies gilt für jegliches DAW-Anpassungs-Tuning). Daher sollte es möglich sein, ein moderat stabiles DAW-Umfeld anzustreben, indem man die Richtwerte für die DPC-Latenz im Voraus kennt.
Konkret scheint es aus Erfahrung heraus angemessen, es als in Ordnung zu betrachten, wenn die Werte innerhalb der folgenden Bereiche liegen und bei normalem DAW-Betrieb keine Geräusche oder Aussetzer auftreten:
- Einzelne Gerätetreiber: 500 Mikrosekunden oder weniger
- Gesamter Latenzwert: 1.000 Mikrosekunden oder weniger
In meiner Umgebung (Windows 10, i5-8400, Rubix22, GT1030) liegt die maximale Latenz für einzelne Gerätetreiber nach der Durchführung von Maßnahmen bei etwa 300-500 Mikrosekunden, und die maximale Gesamtlatenz bei etwa 500 Mikrosekunden. Vor der Durchführung von Maßnahmen gab es Fälle, in denen der Gesamtwert etwa 1.000 Mikrosekunden erreichte, aber selbst dann wurden keine Geräusche oder Aussetzer festgestellt.
Wenn Sie Einstellungen wie einen ASIO-Puffer von 64 Samples oder weniger verwenden, können bei diesen Richtwerten Audio-Aussetzer auftreten, aber bei Einstellungen von 256 Samples oder mehr ist dies im Allgemeinen unwahrscheinlich.
Bei 44,1 kHz beträgt die akzeptable Zeit für 64 Samples etwa 1.450 Mikrosekunden und für 256 Samples etwa 5.800 Mikrosekunden.
Wenn die verschiedenen Prozesse innerhalb der DAW und des Betriebssystems, einschließlich der DPC-Latenz, innerhalb dieser akzeptablen Zeit abgeschlossen sind, tritt das Problem der Audio-Aussetzer nicht auf.
Konkretes Maßnahmenbeispiel: Einstellungen des Netzwerkadapters (NIC)
In meiner Umgebung war die Latenz von „ndis.sys“ signifikant und überschritt häufig 800 Mikrosekunden, manchmal sogar deutlich 1.000 Mikrosekunden. Der von mir verwendete Onboard-Netzwerkadapter ist der „Realtek PCIe GbE Family Controller“. Ich habe die Eigenschaften des Netzwerkadapters im Geräte-Manager geöffnet und die folgenden Einstellungen vorgenommen:
- „Interrupt-Moderation“ deaktivieren.
- Offload deaktivieren (NIC übernimmt Checksummen-Verarbeitung etc.).
Dadurch konnte ich die Latenz auf weniger als die Hälfte des ursprünglichen Werts reduzieren (während der DAW-Nutzung auf unter ca. 400 Mikrosekunden maximal begrenzt).
Deaktivieren der „Interrupt-Moderation“
In diesem speziellen Fall war das Deaktivieren der Interrupt-Moderation besonders effektiv. „Interrupt-Moderation“ ist ein Mechanismus, bei dem nicht bei jedem eintreffenden Datenpaket sofort ein Interrupt ausgelöst wird, sondern gewartet wird, bis sich mehrere Pakete ansammeln oder eine bestimmte Zeit verstreicht, und dann die CPU mit einem einzigen kombinierten Interrupt benachrichtigt wird.
Das Deaktivieren der Interrupt-Moderation bedeutet, dass die Verarbeitung von Datenpaketen erfolgt, sobald sie eintreffen, was auf den ersten Blick die CPU-Last erhöhen mag. Mit der aktuellen CPU-Leistung liegt dies jedoch nur innerhalb der Fehlerspanne, und die Auswirkungen der Latenz aufgrund von Verarbeitungswartezeiten sind deutlich ausgeprägter, was zu großen Verbesserungen wie in diesem Fall führt (tatsächlich wurde keine Änderung der CPU-Last oder des Stromverbrauchs festgestellt).
Deaktivieren von Offload (NIC übernimmt Checksummen-Verarbeitung etc.)
Deaktivieren Sie die folgenden Elemente:
- IPv4-Prüfsummen-Offload
- TCP-Prüfsummen-Offload (IPv4)
- TCP-Prüfsummen-Offload (IPv6)
- UDP-Prüfsummen-Offload (IPv4)
- UDP-Prüfsummen-Offload (IPv6)
Das Deaktivieren von Offload hatte eine geringe Wirkung, aber es eliminierte Fälle, in denen Wdf01000.sys und CLASSPNP.sys manchmal Latenzzeiten über 1.000 Mikrosekunden verursachten, wenn Offload aktiviert war (ob ein direkter Zusammenhang bestand, ist unklar).
Ursprünglich sollte die Auslagerung von Checksummen-Verarbeitung und ähnlichem auf die NIC die Verarbeitungsleistung entlasten, aber in der Realität ist dies nicht immer der Fall, und manchmal verursacht es hohe DPC-Latenz. Die Hypothese für die Ursache ist, dass zur Gewährleistung der Integrität von IP-Daten verschiedene Sperren innerhalb des Betriebssystems erforderlich sind, was paradoxerweise die Verarbeitung verlangsamen kann.
Über andere NIC-Einstellungen
Andere Gegenmaßnahmen umfassen Folgendes, aber in meinem Fall wurde auch nach der Einstellung keine Änderung festgestellt (Latenzverbesserung kann je nach Umgebung möglich sein):
- Large Send Offload deaktivieren (NIC übernimmt die Segmentierung großer Sendedatenpakete).
- Receive Side Scaling (RSS: Multi-Core-Verarbeitung) deaktivieren.
- Energiespareinstellungen deaktivieren.
Nebenbei bemerkt schaltet sich die Energiesparfunktion der NIC extrem schnell ein/aus, und es wird als unwahrscheinlich angesehen, dass diese Funktion die Latenz beeinflusst. Da in meiner Umgebung keine Auswirkungen beobachtet wurden, lasse ich die Energiesparfunktion aus betrieblichen Gründen aktiviert.
Konkretes Maßnahmenbeispiel: Einstellungen des Grafiktreibers
Ein weiterer Bereich, der zu einer signifikanten Verbesserung führte, waren die Einstellungen des Grafiktreibers. Genauer gesagt konnte ich die DPC-Latenz erheblich verbessern, indem ich die „Hardware-beschleunigte GPU-Planung“ in den Windows-Einstellungen deaktiviert habe. Anfangs wurden maximale Latenzen von 700-1.000 Mikrosekunden gemessen, aber nach den Maßnahmen lagen die spontanen Maximalwerte bei etwa 500 Mikrosekunden, und bei normaler DAW-Nutzung blieben sie innerhalb von etwa 300 Mikrosekunden maximal.
Da ich eine alte Grafikkarte wie die NVIDIA GT1030 verwende, kann dies nicht als allgemeine Maßnahme bezeichnet werden, aber ich erwähne es aufgrund seiner Wirksamkeit.
Diese Einstellung ist in Windows 11 standardmäßig aktiviert, daher muss es einen triftigen Grund geben, sie bewusst zu deaktivieren. In diesem Fall könnte das Ungleichgewicht der Leistung zwischen CPU und GPU (Mangelnde GPU-Leistung) paradoxerweise zu Last oder Verarbeitungsverzögerungen auf der CPU-Seite geführt haben. Alternativ ist es denkbar, dass der Treiber oder das Betriebssystem aufgrund des Alters des GPU-Designs nicht wie vorgesehen funktioniert.
Auf jeden Fall gab es eine deutliche Verbesserung der gemessenen DPC-Latenz, daher betreibe ich in meiner Umgebung die „Hardware-beschleunigte GPU-Planung“ deaktiviert.
Über „Hardware-beschleunigte GPU-Planung“
Diese Funktion wurde 2020 in Windows 10 veröffentlicht. Wie der Name schon sagt, lagert sie einen großen Teil der GPU-Planung von der CPU auf einen dedizierten GPU-basierten Planungs-Prozessor aus. Durch die Hardware-beschleunigte Verarbeitung der GPU-Planung wird die CPU-Last (Overhead der GPU-Planung) reduziert, was die Leistung und die Systemlatenz bei bestimmten Prozessen verbessert.
Tatsächlich sind jedoch Fälle, in denen bei Verwendung dieser Funktion keine Leistungsänderung festgestellt wird, prominent. Der Grund dafür soll sein, dass Entwickler bereits effiziente Wege (Optimierungen) gefunden hatten, um mit der traditionellen GPU-Planung umzugehen, und die Leistungsgrenzen nahezu erreicht hatten. Es wird angenommen, dass das Ziel von Microsoft mit dieser Funktion nicht nur die Leistungsverbesserung war, sondern die Modernisierung des Grafiksystems und die Vorbereitung des Weges für die Zukunft.
Maßnahmen für ntoskrnl.sys
Wenn LatencyMon eine signifikante Latenz für „ntoskrnl.sys“ anzeigt, wird die Identifizierung des Problems schwierig. Denn ntoskrnl.sys ist der Kernkernel des Windows-Betriebssystems selbst und lässt sich schwer mit einem bestimmten Hardware-Treiber wie „dieses Gerät“ verknüpfen.
Wenn ntoskrnl.sys DPC-Latenz verursacht, bedeutet dies, dass der Kernel aus einem der folgenden Gründe in einem Wartezustand ist oder die Verarbeitung lange dauert:
- Eigene Verarbeitung des Kernels: Die Verarbeitung in den fundamentalen Teilen des Betriebssystems (Planung, Speicherverwaltung, Prozessverwaltung, E/A-Verwaltung usw.) dauert lange.
- Stellvertretende Verarbeitung für andere Treiber oder Systemereignisse: Viele Treiber interagieren mit Hardware und stellen Anfragen an Betriebssystemdienste über ntoskrnl.sys. Daher kann ineffiziente Verarbeitung oder Wartezeit, die durch andere Treiber verursacht wird, so aussehen, als wäre ntoskrnl.sys die Ursache.
- Spezifische systemweite Zustandsänderungen: Systemereignisse wie Übergänge in Energiezustände, Änderungen der CPU-Frequenz oder SMIs (sehr hoch priorisierte Interrupts, die vom BIOS verarbeitet werden) werden als Aktivität von ntoskrnl.sys gemessen, wodurch sie als Latenz erscheinen.
Aus diesen Gründen sollten bei hoher ntoskrnl.sys DPC-Latenz als Erstes strombezogene Einstellungen (Energiespareinstellungen) angegangen werden. Überprüfen Sie die Energiespareinstellungen für die CPU und verschiedene Treiber und messen Sie die Änderungen der Latenz, während Sie einzelne Energiesparfunktionen deaktivieren.
Wenn Sie einen kleinen ASIO-Puffer verwenden müssen, kann das Deaktivieren von C-States im BIOS zur Leistungssteigerung oder das Einstellen des Energieverwaltungsprofils des Betriebssystems auf „Hohe Leistung“ ebenfalls effektiv sein.
Dennoch ist die Identifizierung der Ursache für ntoskrnl.sys-Latenz, wie oben erwähnt, schwierig. Es empfiehlt sich daher, basierend auf realistischen Richtwerten ein moderates Latenzniveau anzustreben und zufrieden zu sein, wenn es innerhalb dieses Bereichs bleibt. In der Tat überschritt die maximale Latenz von ntoskrnl.sys in meinem Fall nach den Maßnahmen für NIC- und Grafikkartentreiber bei normaler Arbeit nicht signifikant 500 Mikrosekunden, daher entschied ich, dass weitere Maßnahmen den Zeitaufwand nicht wert waren.
Maßnahmen gegen DPC-Latenz ~ Fazit
Bezüglich der Maßnahmen gegen DPC-Latenz bei DAWs finden Sie im Internet zahlreiche detaillierte Informationen, beginnend mit der Verwendung von LatencyMon. Daher habe ich mich in diesem Artikel darauf konzentriert, spezifische Fälle in meiner Produktionsumgebung vorzustellen. Ich hoffe, die Informationen über die tatsächliche Behebung von DPC-Latenzproblemen sind hilfreich für die Verbesserung Ihrer Umgebung.
