das *kopfschütteln* war von meiner Seite im Kontext zum Thema bezogen:
da fragt jmd, was er am besten beim Neuafsetzen des PCs beachten soll und Du machst extremste Profiteinstellungen im µs-Bereich als wichtigen Punkt...
andere "Profis" gehen seit einiger Zeit her und erklären, daß der ganze Latenzkram falsch verstanden wird und man eher mal drüber nachdenken sollte, wann eine niedrige Latenz wirklich benötigt wird usw.
aber egal, da muß der TE sich ja im Prinzip mit auseinander setzen
bin halt immer öfter erschrocken, was hier manchmal für superduperhastenichttgesehenextrem Tips gegeben werden (Achtung, jetzt werfe ich Dir Deine Kritik zurück) ohne erstmal zu klären, ob der Fragensteller Hobbiest oder Amateur oder Semiprofi oder Profi sein will/ist...
zum Ton:
kannst endlich mal bitte aufhören mit so Sachen wie "vielleicht geht Dir dann ein Licht auf, oder eben nicht", "dummes erzählt" usw.!
Du kennst mich gar nicht persönlich, somit auf meine Intelligenz zu urteilen bzw. mir mangelnde zu unterstellen finde ich schon sehr seltsam...hatte Dich (bezogen auf andere Posts von Dir) für reifer & älter gehalten!
@TE:
sorry für diesen Kram dazwischen...
hab meine Auslagerungsdatei auf 16GB eingestellt, denke mal ist nicht so verkehrt...
deaktivieren würde ich sie nicht, denn sollte mal sich aus welchen gründen auch immer im Speicher "hochsummieren" dann kann es notfalls ja die Auslagerungsdatei nutzen, wenn aber keine da, kann im schlimmsten Fall der PC abstürzen
Du verwechselst immer noch Audio Latenz mit der Kernel Latenz, das sind 2 unterschiedliche Dinge, sie hängen aber miteinander zusammen.
Die CPU kann sich nur dann effizient Audio Prozesse abarbeiten, wenn nicht zu viel anderes dazwischen kommt. Dazu muß man erstmal das System soweit in den Griff bekommen, dass die CPU nicht unnötig blockiert wird.
Das tuning der kernel Latenz liefert Dir erstmal eine gesunde Ausgangsbasis, so dass die *Wahrscheinlichkeit* des Verlusts von Audio Daten minimiert wird indem die CPU von unnötigen Prozessen und unnötigen Low Level Prozessen möglichst freigehalten wird. Diese DPCs (deferred procedure calls) sind Treiber Prozesse auf unterster Ebene die durch einen Interrupt der Hardware ausgelöst werden. Diese können nicht vom Prozessscheduler des Betreibssystems unterbrochen werden. Darum können zB schlechte Treiber zu einer Situation führen, dass auf einem Core auf dem eigentlich auch ein Audio Prozess laufen möchte, dieser Kern aber nicht freigegeben werden kann, weil die DPC low level (=Treiber) routine so lange läuft, wie der Programmierer dieses Treibers das "designed" hat. Dabei gibt es von Seiten Microsofts quasi nur Empfehlungen, wann eine low level routine von selber wieder enden sollte. Bei den meisten Treibern ist es ok, es gibt aber auch schlechte Treiber die eine CPU blockieren. Hinzu kommt, dass Änderungen in der Takt Frequenz (wg Energiesparfunktionen) immer wieder eine gewisse Einschwingzeit erfordern, bis der Takt wieder stabil ist und die Bearbeitung fortgesetz werden kann. Das erzeugt auch Latenzen. Ganz schlimmt sind die PEAKS bei den Kernel Latenzen, wo auf einmal für eine recht lange Zeit das System / die CPU für die Abarbeitung von Prozessen nicht verfügbar ist.
Diese ganzen Latenzen verursacht durch Energiespareinstellungen / Frequenzänderungen des Systemtaktes / durch normale Prozesse, die auch eine gewisse Last und I/O erzeugen, hat das System erstmal eine gewisse Grundlast, mit der es ständig zu kämpfen hat.
An der Stelle sprechen wir NICHT von der AUDIO Latenz. Wir sprechen von der Kernel Latenz. Wie schnell steht die CPU/das System für "sinnvolle" Arbeiten wieder zur Verfügung, damit die WAHRSCHEINLICHKEIT minimiert wird, dass nachher wirklich unter Last kein Audio Paket zu langsam bearbeitet wird, was letzten Endes zu Aussetzern führt.
Die Latenz, die Du meinst ist fest gesetzt durch die Roundtrip Zeit zwischen
Recording Interface, A/D Wandlung BUS (USB,FW,PCIe
DAW prozessing BUS Wandler D/A, Recording Interface Kopfhörer/Monitor
Da kommt es stark auf die Treiberprogrammierung, je nach Treiber erreichst Du Werte zwischen unter 1ms bis ca 20ms. Das aber unabhängig von der Kernel Latenz.
Es ist nur so, dass Du unter Last dafür sorgen mußt, dass Dir die Audio Pakete nicht verloren gehen, die zuverlässig von und zum Recording Interface geliefert werden müssen.
Hast Du Dir schon mal überlegt, warum Du eigentlich bei wachsender Projektgröße und Workload unter Deiner DAW die ASIO Buffersize erhöhen mußt ? Um zu kompensieren dass bei zu kleinem ASIO Buffer der Rechner die Daten nicht mehr schnell genug hin und herschieben kann zwischen Recording Interface und dem DAW prozess. Und das wird um so kritischer je mehr Plugins und VST instrumente von der CPU noch mit berechnet werden müssen.
Wenn dann noch der Rechner lahm ist und humpelt, weil die CPU gerade noch anderweitig beschäftigt ist (DPC Last, Taktänderungen, CPU Core Parking, unnötige Prozesse, hohe Last durch Interrupts und nachfolgender DPC Berarbeitung) dann mußt die mit höheren ASIO Buffer Sizes das ganze kompensieren. Aber wie das immer so ist, buffern puffert Daten, das heißt sie werden erstmal eine kleine Zeit gesammelt und dann in einem Rutsch abgearbeitet, das erzeugt halt zusätzliches delay ... darum ist die AUDIO Latenz (Ende zu Ende) dann höher.
Also wäre es schon wünschenswert, wenn der Rechner möglichst effizient arbeitet, um die ASIO Buffersize
a) bei gegebener Workload X vielleicht doch nicht so schnell hochdrehen zu müssen
b) die Wahrscheinlichkeit für AUDIO Aussetzer bei hoher Workload und gegebener ASIO Buffersize (die ist ja erstmal im Projekt fest gesetzt) gen 0 tendierend zu reduzieren.
Kurzfassung
1. Du tunest die *Kernel Latenz* / das ganze System an für sich, um die Effizienz des Systems in der Abarbeitung von Prozessen zu erhöhen, um die Wahrscheinlichkeit für Audio Aussetzer zu minimieren und ggf mit geringeren ASIO buffersizes bei gegebener Workload eines Projekts auskommen zu können, ehe es zu Aussetzern kommt
2. Die Audio Latenz wird im Wesentlichen durch die Güte des ASIO Treibers plus ein bisschen A/D und D/A Wandlung bestimmt und hat mit der Kernel Latenz nichts zu tun.
Punkt 1) ist schlicht und ergreifend der Wegbereiter für eine non-realtime-system in Richtung schlankes effizientes System, damit Punkt 2) zuverlässig funktioniert.
Wenn man nicht benötigte Hardware in einem System deaktiviert, dann reduziert man idR die Anzahl der Hardware Interrupts auf einem System. Die nach einem Interrupt anstehenden DPCs (in der Ausführung auf der CPU nicht unterbrechbare low level "treiber" routinen) werden dadurch auch reduziert und reduzieren generell die Wahrscheinlichkeit, dass die CPU für eine gewisse Zeit einfach belegt ist. Hohe Netzwerklast erzeugt auch eine Menge Interrupts. Deshalb erklärt es sich von selbst, dass man parallel zum Recording keinen Mega downloads von Daten aus dem Internet started. Die Zeiten sind aber vorbei, dass man einen Recording Rechner am besten gar nicht ans internet anbindet. Ich würde aber trotzdem dafür sorgen, dass kein Programm von sich aus irgendwas in Richtung Netzwerk macht. Darum all die automatischen Updates / Firewall Silent oder Gaming Mode und all die vorgeschlagenen Dinge vom Timo umsetzen. Ich möchte dann auch nicht, dass die Aufgabenplanung die gesammelten Daten an Microsoft übers Internet schickt, wenn ich gerade mit der DAW arbeite, um Interrupts, DPCs, die Wahrscheinlichkeit der erhöhten "nicht verfügbarkeit der CPU für user Prozesse" zu minimieren.
Und diese SUMME aller optimierungen liefern ein *schlankes* System bei dem die WAHRSCHEINLICHKEIT für Audio Aussetzer - vor allem auch unter Last - deutlich geringer ist.
Aber bitte lerne den Unterschied zwischen KERNEL Latenz und AUDIO Latenz.
Hängen zusammen hinsichtlich Aussetzern, aber haben erstmal sonst nichts miteinander zu tun.
