Er sagt ja auch : je grösser die Kette auf einer Spur desto mehr Performance wird geschluckt.
EDIT1: ein paar Ergänzungen Turbo Mode, Leistungsdaten CPU, Win7 vs Win10 performance
EDIT2: Ideal eingestelltes und performendes System unter Win7, ein paar LatencyMon screenshots kommentiert
Nein, die entscheidende Aussage von ihm ist, dass in einer Kette von Effekten das Audiosignal nur von einem thread bearbeitet wird. Der einzelne thread hat aber nichts von 28 Kernen, denn er läuft nur auf einem CPU core. Da Audiobearbeitung was mit Echtzeitbearbeitung zu tun hat, müssen die ganzen Berechnungen rechtzeitig fertig werden.
Wer seine Backing tracks mit vielen VSTi's bestreitet und zB selber Gitarre oder Drums über ein VSTi einspielt, der hat zusätzlich noch höhere Anforderungen an das System (Leistung, Agilität), weil man dann mit ASIO Buffersizes arbeiten muss (bei RME im Bereich 32 - 128), um noch unter 10ms RTL (Round Trip Latency) kommen zu können für den Weg von Audio von der Gitarre über das Interface, USB, zum Rechner, zur DAW und zurück bis zum Kopfhörer.
Wovon Du nun im Einzelnen mehr hast, vorn mehr cores oder einem höheren Systemtakt, kommt vor allem auf die Applikationen an. Ob sie mehr von Single Thread Performance oder einer höheren Anzahl von Cores profitieren.
Und bei einer DAW kommt es dann darauf an, wie Du Dein Projekt genau aufsetzt. Ob Du wirklich in alle möglichen Spuren einzelne VSTs als Inserts reinknallst oder versuchst, über Sends mit weniger Reverb Instanzen auszukommen. VSTi (synthetische Instrumente) werden vermutlich auch in einem thread ausgeführt und damit eine hohe Single Thread Performance benötigen.
Dann geht die Sache ja auch noch weiter, wie die CPUen aufgebaut sind und wie der Hauptspeicher an alle Cores angebunden ist. Weswegen bei AMD Threadripper (NUMA Architektur) mit höheren internen Latenzen zu rechnen ist.
Und dann kommt auch das große Thema, wie gut eine Applikation überhaupt viele Cores auslasten kann und in welchen Situationen: eine Recording / Mixing Situation ist was anderes, als wenn Du einen Downmix von Deinem Projekt machst.
Im Grunde genommen müßte man alles ganz genau wissen, tut man aber nicht. Man müsste alle mögliche HW ausprobieren, was für die eigenen Projekte am besten ist, aber die Zeit und das viele Geld hat man auch nicht.
Wenn man nicht so viele tracks oder VSTi's hat und nicht völlig idiotischerweise zu viele Inserts pro Spur verwendet wird idR schon alles gut gehen. Da man also nie nicht genau weiß, was alles kommen wird, kauft man sich am besten eine CPU, die man sich noch leisten kann und bei der die Anzahl der Kerne und der Takt in einem ausgewogenen Verhältnis zueinander stehen.
Ich habe mich damals zu einem Xeon basierenden System entschieden. In diesem Bereich gibt es einen Haufen von CPU Möglichkeiten, die auch jeweils Ihre eigenen Vorzüge haben, es gibt sogar auch CPUen, die durch einen höheren Cache brillieren, weil das möglicherweise im Datenbankbereich etwas mehr Performance bringt..
Da habe ich halt auch überlegen müssen, wo ist denn da eine für mich vernünftige Preis / Leistungsgrenze erreicht. Gamen wollte ich mit dem Setup auch, was auch eher nach mehr Single Thread Performance, sprich höherem CPU Takt schreit.
Ich bin einfach davon ausgegangen, dass ich folgendes benötige:
- einen hohen Mindesttakt von 3.5 GHz Pro CPU core haben möchte (-> hohe single thread performance)
- dass es diesmal mehr als 4 CPU kerne sein sollten
- Preis sollte €600 nicht überschreiten (früher hatte ich immer bei €300-350 die Grenze gesetzt)
Andere Aspekte:
- Mehrkerner werden sehr schnell sehr teuer
- ab einer bestimmten Leistung steigen die Preise überproportional
- an die Abwärme denken
Deshalb ist es vernünftig, die Leistung in Relation zum Preis zu setzen und mit gesundem Augenmaß zu schauen bis zu welchem Preis man eigentlich noch eine gute Leistung bekommt oder ab wann weitere Leistungssteigerungen einfach zu teuer werden.
Dafür hatte ich damals einen umfangreichen Excel Job gemacht und habe für diverse CPUen (Consumer und Xeon), die es 2014 zu kaufen gab, die Benchmark Werte eines gemischten Benchmarks (Passmark) in Relation zum Preis gesetzt.
Gefiltert welche CPUen über 3.5 GHZ Basis Takt und die beste Leistung haben und vom Preis/Leistungsverhältnis noch gut dastehen.
Somit hatte ich dann eine CPU gefunden, die meiner Meinung nach für alles geeignet sein sollte: Office, Gaming, DAW, Videobearbeitung
Ist nachher ein Xeon 6-kerner geworden (das war Stand Oktober ~2014)
Xeon E5-1650v3 mit 6 Cores / 12 threads, 3.5 GHz Basis Takt, 3.8 GHz Turbo für €545.
Aktuelle Leistungsdaten siehe hier
https://www.tonstudio-forum.de/blog...0-10-Performance-Test-400-Audio-Tracks-de-en/
und hier Cubase Vergleich Win7 vs Win10:
https://www.forum.rme-audio.de/viewtopic.php?pid=141931#p141931
Dann gibt es noch weitere Dinge zu beachten:
Der Turbo Takt wird nur unter bestimmten Bedingungen erreicht
- nur für eine gewisse Anzahl von Cores und
- wenn als Ausgleich dafür eine gewisse Anzahl anderer Cores runtergetaktet sind oder durch Windows geparkt sind
CPUen mit mehr kernen haben einen eher bescheidenen Basis Takt und der Turbo Takt liegt dann für einige wenige Cores viel höher als bei meiner CPU. Aber dann muss man das System auch so aufsetzen, dass Turbo erreicht werden kann und Takt Schwankungen erhöhen wieder etwas die internen Latenzen im System, denn eine CPU muss sich auch erstmal auf einen neuen Takt ein bisschen einschwingen, wesentlich längere Zeit braucht es, um aus einem Schlagzustand aufzuwachen, wzB verursacht durch Windows CPU core parking.
Es kommt auch sehr auf die CPU Generation ab und ist im Grunde genommen nichts anderes als ein Wärmeproblem, damit ein gewisser "TDP" Wert nicht überschritten wird.
Zum Thema Turbo takt. Wird meist eh nicht erreicht und man möchte auch keinen schwankenden CPU takt (-> interne Latenzen, zu messen mit LatencyMon)
Das heißt .. in einem System profitieren unter Umständen eh nur sehr wenige cores von der Turbofrequenz.
Cubase und AVX Kommandos: noch besser, Cubase verwendet komplexe Vektorbefehle (AVX instruction set) , damit laufen die CPUen meistens nur auf dem Basis Takt und nicht mehr. Beim Downmix eines Projekts läuft auf jeden Fall die ganze CPU nur auf Basis Takt wegen der Verwendung des AVX instruction sets.
Leider ist das bei Intel nur sehr schlecht dokumentiert wie hoch der Takt bei der Ausführung von AVX instructions ist.
Eine herbe Enttäuschung war die Nachfolgeversion der CPU, der E5-1650
v4.
Die hatte eigentlich einen viel höheren Takt, 3.6 GHz Basis und 4 GHz Turbo.
Im normalen Betrieb erreichte sie einen stabilen Takt von 3.8 GHz.
Sobald Cubase lief, ist dann der Takt wegen der AVX Instruktionen auch auf 3.5 GHz runtergegangen, wie bei der alten v3er CPU. Was für eine Enttäuschung. Neuere CPU, kleinere Stukturen, weniger TDP, aber geht dann noch 100 MHz unter den Basis Takt auf nur 3.5 GHz ?!
Man muss also sehr aufpassen, die spannende Frage ist einfach, welchen Takt bekommt man am Ende des Tages raus, bei der Art und Weise wie das System zum einen eingerichtet ist (CPU core parking aus oder nicht, Turbo im BIOS aus oder nicht, EIST aus oder nicht) und wie die Applikation arbeitet oder ob sie diese AVX Kommandos verwendet.
Damit möchte ich einfach sagen, dass man sich darauf einrichten sollte, dass man meistens eh nur mit dem Basis Takt kalkulieren kann und sich die höheren Turbo Werte unter Umständen erstmal abschminken kann.
Konsequenz: wenn Du Dir also so ein Xeon Monster mit 28 Kernen holst, dann richte Dich darauf ein, dass Du nur den Basis Takt bekommst und die Turbo Frequenz unter umständen nie erreichst.
Taktänderungen, interne Latencen (-> LatencyMon, DPC Latenzen, etc)
Taktänderungen in einem System erzeugen sowieso einige interne Latenzen, die sich bei LatencyMon Messungen etwas bemerkbar machen. Insofern ist ein stabiler Basis Takt, der ständig anliegt, eh die bessere Wahl, vermutlich aber auch nur bei Desktop Systemen realisierbar, denn ein Laptop käme zu schnell in Thermische Probleme.
Bei meiner besagten Xeon E5-1650v3 CPU sieht das dann so aus.
Basis Takt erreiche ich immer: 3.5 GHz
Wenn das System keine AVX Befehle ausführen muss, dann sogar permanent 3.6 GHz.
Den Turbo Takt von 3.8 GHz erreicht mein System nie, weil ich CPU core Parking deaktiviert habe, um die internen System Latenzen zu minimieren. Somit legt sich kein Core schlafen, man muss nicht auf die Wiederauferstehung warten, aber halt kein Turbo.
Schlimm, nö,. dafür agiles System und man kann tendenziell mir geringeren ASIO buffer sizes arbeiten, damit es keine Audio Aussetzer gibt.
Wer sich also den dicken Mäckes da holt, der sollte sich vorher genau überlegen, was er braucht, mehr Kerne oder einen höheren Takt zwecks höherer Single Thread performance.
Und nie vergessen, es kommt auf die Applikationen an, jede DAW könnte für sich betrachtet anders reagieren. Und Cubase steht ja auch in dem Ruf, dass gewisse Dinge in einem Thread passieren müssen und nicht alles auf alle Cores verteilt werden kann so dass es zu einer gleichmäßigen und hohen Auslastung aller Cores kommt.
Was für ne CPU holen ohne eine Wissenschaft draus zu machen ?
Also einfach kucken, dass man in 2019 einfach ne aktuelle Intel CPU für €350 - 600 kauft.
Am besten mit Hyperthreading und größtmöglicher Anzahl Cores bei einem Basis Takt von mindestens 3.5 GHz.
Da wird man dann vermutlich bei einem 8 Kerner landen wzB diesem hier, der Leistungsmäßig oben mitspielt
https://geizhals.de/intel-core-i9-9900k-bx80684i99900k-a1870092.html €487
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i9-9900K+@+3.60GHz&id=3334
Der Rest (Apple etc) ist eigentlich völlig Humpe, die verwendeten Intel Xeons werden ja schliesslich auch in Windows Büchsen verbaut.
Das ganze ist wie auch bei allen anderen Anwendungen ein reines Applikations / Performance Thema und man sollte die Belange seiner Applikation kennen und dann die Hardware Auswahl darauf auslegen.
Wer auf geringe RTL (Round Trip Latencies) angewiesen ist, also kleinere ASIO Buffer sizes braucht, zB durch Einspielen mit VSTi's, der muss auf einige Dinge mehr acht geben (Performance, Hohen Takt für hohe Single Thread Performance, agiles getuntes System) als jemand, der nur ein paar Spuren sicher aufnehmen möchte und eine ASIO buffersize von 1024 oder sogar 2048 dafür einstellen kann.
Ideal eingestelltes und performendes System unter Win7
Gemessen mit LatencyMon 6.7 (Einstellung Kernel Latency Timer), auf einem unbelasteten System (ohne DAW aufgestartet) in etwa so aus ...
Man sieht, der Kernel Latency Timer kommt auf einem unbelasteten System runter bis auf 2 microsekunden. Das zeigt, dass die BIOS und Systemeinstellungen gut sind und die Cores durch nichts ausgebremst / laggy werden, sei es durch ungünstige BIOS oder Windows Einstellungen im Bereich Energy Saving. Jeder CPU core ist sofort da und die CPU kann sofort auf Last reagieren ohne erstmal aus einem Schlafzustand aufwachen oder den Takt ändern zu müssen. Das ist eine sehr notwenige Voraussetzung, wenn man viel mit VSTi's arbeitet und vor allem mit einem virtuellen Instrument etwas einspielen möchte. Dann muss man wie gesagt die ASIO buffersizes was runterdrehen um unter die 10ms RTL zu kommen. Wenn dann irgendwas die CPUs blockiert, schlechter Treiber oder Systemeinstellungen, dann gibt es mit höchster Wahrscheinlichkeit Audio Aussetzer.
Das ist der ganze Sinn und Zweck von ein paar Einstellungs/Tuning Massnahmen, um das zu vermeiden. Für das reine recorden von 30 oder mehr spuren und ASIO Buffersizes von 1024-2048 ist das ziemlich humpe. Es kommt immer drauf an, wie man mit dem System arbeiten will, weil eine DAW load je nach Anwendungszweck und Aufbau des Projektes sehr unterschiedlich sein kann.
Wenn man die Treiberliste nach höchster Ausführungszeit sortiert, sieht man wie effektiv die einzelnen Treiber performen und ob sie im ungünstigsten Fall zu lange die Cores blockieren.
Windows ist kein RealTime Betriebssystem. Eine laufende Treiber / Kernel / Interrupt Routine kann durch den Prozess Scheduler des Betriebssystems nicht unterbrochen werden. Das heißt, der Treiber blockiert den Kern so lange, wie es im Treiber kodiert ist. Wenn der Prozess Scheduler auch einen Audio Prozess auf diesen Kern legt, dann kommt es zu den berüchtigten Audio Aussetzern, die durch schlechte Treiber verursacht werden. Treiber müssen gut programmiert sein, nichts im Betriebssystem kann ihre Laufzeit (mit höchster Prio) aufhalten, das muss die gute Treiber Programmierung (einfache "Konventionen" an die sich Entwickler eigentlich halten sollten) richten .. bei manchen gehts, bei manchen eben nicht.