Du verwendest Windows 8, das ist schade. Dazu habe ich keine Vergleichswerte.
Seit Windows 8 hat Microsoft etwas im OS geädert, so dass LatencyMon eine andere Meßmethode finden mußte. Die scheint irgendwo im Prozeß Scheduler Bereich zu liegen, da werden immer Werte um die xxx Milisekunden gemessen. Bei Windows 7 hatte man es besser, der Kernel Latency Timer ermöglichte Messungen im Microsekunden Bereich.
Zwischen Deiner Messung von über 100ms und meiner kleinsten Messung, die bei 1-2µs Mikrosekugen liegt Faktor 10000 dazwischen.
Mir persönlich gefällt das nicht, weil man das Rad wieder neu erfinden muß, bis man wieder Methoden gefunden hat, ob die Einstellungen gut oder optimierungswürdig sind.
Falls Du noch Windows 7 hast, dann mach auf einer separaten Platte eine Vergleichsinstallation und verwende LatencyMon 4.02. Da bekommst Du dann gut vergleichbare Werte und vor allem genauere Werte im µs Bereich.
Solange Du keine Audio Aussetzer hast und mit moderat üblichen ASIO Buffersizes, je nach Projekt zwischen 64 und 512, auskommst, dann würde ich mir da auch erstmal keine grauen Haare wachsen lassen.
Was auch stimmt: schlimm sind vor allem die Latency Spikes, die über einen gewissen Schwellwert gehen, bei dem ein Core länger belegt ist, auf dem aber auch ein Audio Prozess auf Abarbeitung wartet und dann nicht schnell genug die Daten weitertransportiert.
Ich würde sagen, teste mit Windows 7 oder nimms erstmal gelassen hin. Wenn Du Deine Projekte bearbeitet bekommst ist ja erstmal gut.
Das ganze Tuning für Audio tut man im Grunde genommen für 2 Dinge
- die Spikes wegbekommen durch das Reduzieren unnötiger Prozesse und falls möglich Ausmerzen schlechter Treiber und das Entfernen nicht benötigter Geräte
- die Latenzen auf ein geringeres Grundniveau bringen, indem man
--- alles im BIOS abdreht, das häufige Taktwechsel oder sleep/wakeup verursacht
--- im OS Höchstleistung aktiviert und CPU core parking (auf Desktops) deaktiviert
Das verändert keineswegs die Ende zu Ende oder Rount Trip Time von Audio Signalen von Micro zu DAW und zurück zum Kopfhörer .....
Aber es erhöht den "Headroom", dass man bei gegebener DAW Last mit geringeren ASIO Buffersizes arbeiten kann
bzw umgekehrt
dass man mit gegebener ASIO Buffersize höhere DAW workloads ohne Aussetzer fahren kann.
Wichtig ist halt, dass die zeitkritischen Audio Prozesse eine Chance haben, rechtzeitig genug auf einem der Core abgearbeitet zu werden und die Cores dafür "responsiv" arbeiten, also weitgehendst frei dafür sind, also nicht blockiert durch irgendwelche Tasks oder DPCs, die non interruptable sind (Stichwort schlecht geschriebene Treiber).