@Aphelon hat das mit den den M2 SSDs schon perfekt beschrieben.
Bei großen Libraries hat man mit schnellen NVMe SSDs unter Kontakt eben den Vorteil dass die Samples schneller vollständig geladen werden. Die Zeit bis Kontakt wieder bedienbereit ist scheint sich hingegen kaum zu verbessern. Natürlich können die Ergebnisse mit anderen Sampleplayern abweichen.
@EachHit das System sieht tw schon ganz ordentlich aus. Die Grafikkarte kannst du dir aber sparen, wenn es rein um die Anwendung als DAW geht. Für Videobearbeitung macht eine GPU im Bereich einer 1050Ti durchaus Sinn, da die meisten Programme wie Premiere davon profitieren.
Unter DPC Latenz-Gesichtspunkten scheinen die Nvidia Treiber auch nicht die besten zu sein.
Nochmal kurz zu Latenzen, weil hier gefragt wurde: Man muss zwischen mehreren Latenzen unterscheiden. Die Latenzen, die ich hier anspreche haben auch nichts mit den CPU-Internen Latenzen wie beispielsweise bei Ryzen zwischen den CCX zu tun.
Da wäre zuerst mal die ASIO Latenz, also die Verzögerung die durch Ein- und Ausgabe der Audiodaten durch den Treiber des Audiointerfaces entsteht. Weder die Betriebssysteme, noch die DAW selber sind dazu in der Lage, die Audiodaten wirklich in Echtzeit zu berechnen. Deswegen erfolgt diese Berechnung in kleinen Zeitabschnitten. Dies sind z.B. 256 Samples, was bei 44.1KHz Samplerate 5,805ms entspricht. Ein Abschnitt wird berechnet und in einem Puffer an den Audiotreiber übergeben. Der Treiber beginnt diesen Abschnitt abzuspielen, Währenddessen berechnet die DAW bereits den nächsten Abschnitt. Genau deswegen entsteht beim Spielen eines VST-Instruments per Midi-Keyboard eine Verzögerung die zwischen der Dauer von 1-2 ASIO Pufferlängen schwankt. Beim Aufnehmen von Signalen, bzw dem Live Durchschleifen kommt das gleich Verfahren zum Einsatz. Der Audiotreiber füllt den Puffer Sample für Sample und übergibt diesen dann an die DAW zur Aufnahme bzw Berechnung. Der Audiotreiber schreibt währendessen direkt in einen zweiten Abschnitt des Puffers weiter. Man nennt dieses Prinzip der Zwischenspeicherung Ringpuffer, bei dem zwei Pufferabschnitte abwechselnd zum Einsatz kommen. Damit die Audioausgabe ohne Unterbrechungen erfolgt, muss die DAW unter allen Umständen das Audiomaterial für 256 Samples innerhalb der 5,805ms berechnen. Verkleinert man den Puffer zB auf 32 Samples, hat die DAW für diese 32 Samples 0,726ms für die Berechnung zur Verfügung. Im Grude bleibt der Aufwand pro berechnetem Sample gleich. Je kleiner die Zeitabschnitte sind, umso größer wird allerdings der Gesamt-Overhead der anteilig bei jedem Wechsel der Abschnitte entsteht: Während der Berechnung eines Abschnittes müssen von der CPU ja nicht nur Daten berechnet werden, sondern auch die Programmcodes der Plugins aus dem RAM oder dem Cache geladen werden und die Verwaltung dafür auf Betriebssystemebene kostet auch Rechenzeit. Dieser Aufwand bleibt gleich, egal ob der Pufferabschnitt 32 Samples lang ist oder 256. Logisch, dass dann die Gesamtbelastung bei einem kleinen Puffer von 32 Samples entsprechend höher ist.
Deswegen läuft ein Projekt mit größerem ASIO Puffer mit geringerer CPU Belastung.
Dann gibt es noch die
DPC-Latenz. Diese Verzögerung entsteht vereinfacht gesagt bei Funktionsaufrufen auf Betriebssystemebene durch Treiber usw, die immer wieder jede Sekunde zigfach stattfinden. Wichtig zu wissen ist, dass dabei ein CPU Thread blockiert ist und keine Berechnungen für die Anwendung vornehmen kann. Die Länge dieser Verzögerung kann man mit dem
Resplendence Latency Monitor messen, der einem dazu auch den Prozess/Treiber der längsten gemessenen Verzögerung anzeigt. Nehmen wir an, dass es irgendwann dazu kommt, dass der von der DAW am stärksten belastete Thread (längste Plugin-Kette) mit dem blockierenden Thread kollidiert, heißt das das für die Berechnung des Audiopuffers nicht mehr die volle Rechenzeit zur verfügung steht. Sondern 'Dauer eines Audiopuffers' minus 'längste gemessene Verzögerung'. Messen wir z.B. eine DPC Latenz von 500us, stehen bei 256 Samples ASIO-Puffer nur noch 5,305ms zeit zur Verfügung diesen zu berechnen, also nur noch 91% der Rechenleistung. Bei 32 Samples wären es bereits nur noch 31%. Man sieht also, wie essentiell wichtig eine geringe DPC Latenz ist, wenn man mit kleinen ASIO Puffern arbeiten möchte und das System noch halbwegs Plugin-Last stemmen soll. Idealerweise erreicht man bei der DPC Latenz Werte von 100-200us, manche Systeme schaffen auch noch etwas weniger. Kurz gesagt, eine niedrige DPC Latenz sorgt dafür dass die DAW die zur Verfügung stehende Rechenleistung der CPU gut ausnutzen kann.
Die dritte Latenz ist diejenige die Plugins selbst erzeugen. Ein linearphasiger EQ benötigt eine bestimmte länge eines Audioabschnitts zur Berechnung die evtl größer ist als der ASIO Puffer. Der EQ speichert dann die Daten zwischen, was eben für dieses Plugin eine spezifische Latenz erzeugt. Genauso muss die Look-Ahead Funktion eines Kompressors das Signal verzögern, weil dieser ja nicht wirklich in die Zukunft schauen kann, wann eine Signalspitze kommt. Die Latenzen der einzelnen Plugins die hintereinander geschaltet sind, summieren sich. Wenn man Wert auf eine niedrige Gesamtlatenz legt muss man Plugins mit wenig bis null Eigenlatenz einsetzen.
Zu beachten ist ausserdem, wenn ich zB. Gitarre durch ein Amp Plugin live spielen will, dass sich hier alle Latenzen summieren. Zuerst einmal hat jeder AD/DA Wandler gewisse Latenzen, tw in Höhe von 1-2ms. Dies tritt also noch im Audiointerface auf, bevor der Audiotreiber überhaupt etwas davon mitbekommt. Dann die Eingangslatenz des Treibers, die Latenz der zum Einsatz kommenden Plugins, dann die Ausgangslatenz des Treibers, wieder die Wandlerlatenz und schließlich noch die Latenz die der Schall auf seinem Weg vom Lautsprecher zum Ohr benötigt (1m entspricht ca. 3ms).
Was die Unterschiede zwischen Mac/PC angeht: Beim Mac lassen sich auch mit den integriereten Soundlösungen geringe Latenzen fahren. Allerdings performt im 1:1 Vergleich zB Cubase bei den niedrigsten Latenzwerten unter Windows etwas besser, solange man gute DPC Latenzen hat. Ab 128 Samples ASIO/Core Audio Puffer herrscht meiner Erfahrung nach Gleichstand. Allerdings laufen meiner Erfahrung nach die Plugins unter MacOS stabiler. Gibt irgendwo Artikel online, wo unter Windows gewisse Limitierungen beschrieben sind, dass nur eine gewisse Anzahl verschiedener Plugins gleichzeitig möglich sind aufgrund der Einbindung per DLL. Stichwort FLS (Fiber Local Storage).
