Zu Deiner Frage zur Eignung von LatencyMon. Das ist nach wie vor das beste Tool für Messungen unter Windows und immer noch aktuell und nützlich. Einige andere ältere Tools sind überholt und funktionieren nicht mehr mit Windows 10 und 11, weil sich im Kernel im Bereich Timer was geändert hat.
Eine Frage zum LatencyMon-Screenshot, den Du gepostet hattest:
Hast Du den Laptop neu gebootet und nur LatencyMon und nichts anderes laufen lassen?
Weitere Empfehlungen für die Anwendung, um gute Messwerte zu bekommen:
- Nach dem Einloggen warte auch erst einmal ab, bis die CPU-Aktivität deutlich heruntergeht. Selbst wenn alles Übliche auf dem Desktop geladen wurde, kann der Rechner immer noch damit beschäftigt sein, Services zu starten. Diese Rechnerlast möchtest Du ja nicht unbedingt mitmessen.
- Genauso sollte bei der Messung keine Keyboard- und Mausaktivität stattfinden.
- Lass die Messung mindestens zehn Minuten laufen, besser länger. Manche Treiber fallen nur alle paar Minuten unangenehm auf, und ein kurzer Lauf übersieht genau diese Ausreißer.
In den LatencyMon-Einstellungen solltest Du vor der Messung prüfen, ob auch die richtige Messung durchgeführt wird.
Unter Options -> "General" muss "Interrupt to user process latency" ausgewählt sein.
Die Option "Retrieve reported DPC and ISR information from the operating system" darüber bleibt aktiviert, sonst siehst Du hinterher nicht, welcher Treiber die Verzögerung verursacht hat.
Infos zu "Interrupt to user process latency"
Interrupt to user process latency misst, wie viel Zeit zwischen der Datenanforderung der Soundkarte und dem Moment vergeht, in dem die Audiosoftware auf einem CPU-Kern tatsächlich Rechenzeit erhält. Die Frage lautet also nicht, wie schnell das Programm rechnet, sondern: Wie lange muss es warten, bis Windows es überhaupt rechnen lässt?
Der Weg dorthin führt über mehrere Stationen. Die Soundkarte löst einen Interrupt aus, der Treiber nimmt ihn entgegen, reiht die weitere Verarbeitung in eine Kernel-Warteschlange ein, und erst am Ende dieser Kette wird der wartende Thread der Audioanwendung geweckt und einem Kern zugeteilt. Jede dieser Stationen kann sich verzögern, weil anderer Code den Kern gerade beansprucht.
Warum das zählt: Bei 64 Samples und 48 kHz stehen 1333 Mikrosekunden zur Verfügung, bis der nächste Datenblock fertig sein muss. Geht davon ein erheblicher Teil allein für das Warten verloren, bleibt für die eigentliche Audioberechnung zu wenig übrig und der Stream reißt. Das passiert unabhängig davon, wie leistungsfähig der Prozessor ist. Eine schnelle CPU hilft nicht, wenn sie zu spät startet.
Die Messung beantwortet damit genau eine Frage: Wie viel des verfügbaren Zeitbudgets geht verloren, bevor die Audioverarbeitung überhaupt beginnen kann? Je kleiner der eingestellte Puffer, desto weniger Spielraum bleibt und desto härter wirkt sich jede Verzögerung aus.
Wenn aber der Rechner gut eingestellt werden kann und die Treiber mitspielen, dann kann man tendenziell mit kleineren ASIO-Puffergrößen arbeiten. Ab 1000 Mikrosekunden meldet LatencyMon, dass das System Schwierigkeiten mit Echtzeitaudio hat. Diese Schwelle ist alles andere als streng, denn eine Millisekunde ist eine Menge. Ein grünes Ergebnis heißt nicht automatisch, dass kleine Puffer laufen. Wer mit 64 oder 128 Samples arbeitet, sollte deutlich unter den 1000 Mikrosekunden liegen.
Verursacht werden lange Wartezeiten in aller Regel nicht von konkurrierenden Programmen, sondern von Gerätetreibern. Deren Code läuft auf einer höheren Prioritätsebene als jede Anwendung und verdrängt sie vom Kern, ohne dass der Scheduler eingreifen kann, auch eine DAW mit Realtime-Priorität. Typische Kandidaten sind Netzwerk-, Grafik- und USB‑Treiber. Der Messwert selbst zeigt nur, wie groß die Verzögerung ist. Wer sie verursacht hat, steht nach dem Stoppen der Messung im Reiter "Drivers", sortiert nach der längsten Ausführungszeit.
Der Test läuft deshalb bei geschlossener DAW. Er prüft nicht, ob ein bestimmtes Projekt läuft, sondern ob das System überhaupt in der Lage ist, Audiodaten zuverlässig rechtzeitig durchzureichen. Darum auch keine andere CPU-Last generieren. Es soll ermittelt werden, wozu das System maximal in der Lage ist, da würden andere Prozesse stören. LatencyMon bildet den Ablauf einer Echtzeit-Audioanwendung bereits selbst nach, mit eigenem Treiber und eigener Testanwendung.
Warum LatencyMon mit "Interrupt to user process latency" richtig misst und ältere Tools nicht
Das alte Verfahren programmierte einen Kernel-Timer auf einen festen Zeitpunkt und wertete jede Abweichung beim Ablauf als Verzögerung durch Treiber. Gemessen wurde damit nie der Vorgang selbst, sondern ein "Behelf", aus dem man auf die tatsächliche Verzögerung schließen wollte. Seit Windows 8 ist der Systemtakt jedoch nicht mehr fest. Der Kernel verschiebt die Ablaufzeitpunkte selbst, um Aufwachvorgänge zu bündeln. Damit stammt die gemessene Abweichung vom Betriebssystem statt von Treibern, und es kommt auf jedem System rund eine Millisekunde heraus, ohne jeden Aussagewert.
LatencyMon nutzt ab Version 5 keinen Timer mehr. Ein eigener Kerneltreiber löst einen echten Interrupt aus, eine Testanwendung reagiert darauf, gemessen wird die Zeit dazwischen. Das ist genau der Ablauf, den auch eine Audioanwendung durchläuft, wenn die Soundkarte neue Daten anfordert. Statt eines Umwegs über einen Behelfswert wird der reale Vorgang nachgebildet, und das macht die Messung nicht nur wieder gültig, sondern auch näher an der Praxis als alles, was vorher möglich war.
Der DPC Latency Checker setzt bis heute auf das alte Timer-Verfahren und liefert deshalb seit Windows 8 keine brauchbaren Werte mehr. Thesycon hat das selbst eingeräumt und eine überarbeitete Version angekündigt, die nie erschienen ist.
Auch in LatencyMon lässt sich die alte Option "Kernel timer latency" noch auswählen. Sinnvoll ist das nur unter Windows 7, ab Windows 8 liefert sie dieselben unbrauchbaren Werte wie der DPC Latency Checker.
In Kürze
DPC-Latenzen erhöhen sich durch
- Energiesparfunktionen im BIOS (C-States, etc.). EIST kann nützlich sein, wenn Du über die Windows den Systemtakt und CPU‑Core-Parking tunen möchtest.
- Windows-Energiespareinstellungen (CPU Core Parking, selektives USB-Energiesparen, PCI-Express-Verbindungszustand)
- Schlecht geschriebene Treiber, die sich nicht an Programmierkonventionen halten, einen CPU-Kern nach einer gewissen Zeit wieder freizugeben. Microsoft gibt als Richtwerte vor, dass eine ISR unter 25 und eine DPC unter 100 Mikrosekunden abgeschlossen sein sollen. Wer das um das Zehn- oder Hundertfache überschreitet, blockiert den Kern für alles andere. Grundsätzlich: Windows ist kein Realtime-OS, genauso wenig wie macOS. Der Prozessscheduler kann hier nichts machen.
DPCs laufen auf einer Prioritätsebene (Kerneltreiber) oberhalb aller Anwendungen, auf der der Scheduler gar nicht erst zum Zug kommt. Das ist so gewollt, denn nur dadurch kann ein Treiber seine kritischen Abschnitte ohne Unterbrechung zu Ende bringen. Er gibt den Kern also selbst wieder frei, oder eben nicht schnell genug. Für Hersteller bedeutet mehr CPU‑Zeit oft auch einen Gewinn in Benchmarks. Da gibt es sicherlich hin und wieder einen Zielkonflikt.
Du siehst mit dem Tool, dass DPC-Latenzen steigen, wenn Du Energiesparen aktivierst, egal ob im BIOS oder in Windows.
Du siehst auch, welche Treiber ungewöhnlich hohe Latenzen erzeugen. Manchmal hilft ein Treiber-Update, manchmal muss man sich andere Hardware mit besseren Treibern besorgen.
Das Tool teilt Dir mit, welche Treiber CPU-Kerne zu lange belegen, wodurch sich unter anderem die DPC-Latenzen erhöhen und die Audiodaten nicht mehr rechtzeitig verarbeitet werden können. Das Ergebnis hörst Du als Knacken oder Aussetzer, weil der Audioprozess nicht rechtzeitig an die Reihe kommt und sein Puffer leer läuft.
Laptop
Bei Laptops lässt sich im BIOS aus thermischen Gründen nicht so viel einstellen.
Du musst, wie schon erwähnt wurde, schauen, dass die CPU nicht zu heiß und damit im Takt ausgebremst wird.
Es gibt Tools, die hier weiterhelfen können.
VILM care
Wurde auf dem RME‑User-Forum veröffentlicht. Hilft beim Überprüfen der wichtigsten Windows-Tuning-Einstellungen.
Beschränkt sich auf das Wichtigste:
[2.0.0]I built a free Win optimization tool for audio/video production (Page 1) — Tips & Tricks — RME User Forum —
forum.rme-audio.de
PowerSettingsExplorer
http://www.mediafire.com/file/wt37sbsejk7iepm/PowerSettingsExplorer.zip MD5 hash for zip-file: FA4CCB24CC2E7AD265AF341A4A6A1773 I got sick of fidgeting either in registry or in command line to unhide this or that power plan setting to edit its value in Windows`dialog with advanced power...
forums.guru3d.com
Hier hilft es, der CPU Beine zu machen, indem man einen Wert anpasst, damit schlafengelegte CPU‑Cores bei schon geringerer CPU‑Last aufwachen, sodass mehr Leistung schneller zur Verfügung steht.
Besonders hilfreich bei Laptops, wo Performance oder Ultimate Performance blockiert und per Default eine Menge Kerne schlafengelegt sind (CPU‑Core-Parking).
Mit dem Tool kann man sich auch gut eine Einstellung betrachten, wie sie in allen verfügbaren Energieprofilen parametrisiert ist, und das Ganze für den eigenen Bedarf anpassen.
Die Einstellung kannst Du ja mal wahlweise auf 20, 10, 5, oder 1 stellen und beobachten, ob das Gerät responsiver wird. Dabei beachten, wie sich die Temperatur verändert. Wird sie zu hoch, dann stell den Wert etwas höher, dass wieder mehr Kerne geparkt werden können.
QuickCPU
Noch mehr Möglichkeiten bietet QuickCPU, u.a. auch das Vergleichen von Energiesparplänen.
Quick CPU is a comprehensive performance tuning, system monitoring, and stability testing tool for Intel® and AMD® processors. Monitor temperatures, voltages, frequencies, core usage, power settings, and run advanced CPU stress tests to validate system reliability.
coderbag.com
QuickCPU vereint einige Tools inkl. ThrottleStop und CPU-Z in einer Oberfläche.
In Quick CPU gibt es auch zwei eigene Energiesparpläne, zusätzlich zu denen in Windows. Mit deren 'Höchstleistung' konnte jemand seinen Laptop dazu bringen, mit viel kleineren ASIO‑Buffer-Sizes, 48 statt 256 Samples @single-speed, knackserfrei zu arbeiten.
Mit dem enthaltenen Vergleicher können Unterschiede zwischen den verschiedenen Energiesparplänen leicht sichtbar gemacht werden. "Höchstleistung" von Microsoft hatte übrigens nichts gebracht. Beim Vergleich mit QuickCPU's Höchstleistung seien es nur wenige Änderungen in der CPU‑Steuerung gewesen, die einen deutlichen Unterschied machten und das Problem lösten.
Auch ohne Getöse der Dell Lüfter, die blieben zahm. Sollte man sich vielleicht auch mal anschauen.
ACHTUNG
Bei allem, was man tut: Backup (Disc-Image von der Windows-Systemdisk/SSD) nicht vergessen!!!
Und je nachdem, was es ist, Temperaturen von CPU und SSD/nVME beobachten.
Hier das Diff Tool für die Energiesparpläne
