Cubase Grundauslastung bei 10-15% normal??

[stereolli]

Mal was völlig irres :
Mein Cubase Sx3.1 läuft mit eingeschaltetem Multiproz Unterstützung trotz Quadcore hakelig und mit hoher Cpu Last. Stelle ich die MultiprozUnterstützung aus, schnurrt er, wie er soll. Das soll man erstmal verstehen....

 

[Loop_Breaker]

Ich hab nun mal Screens vom Performance-Meter mit Cubase 7.5, 9,5 und 10 gemacht.
Hier mal die Auslastung in einem leeren Projekt.

Anhang anzeigen 73243 8.5
Anhang anzeigen 73244 9.5
Anhang anzeigen 73245 10

Die größten Schwankungen habe ich unter Cubase 10, sowohl bei average load wie auch beim peak. Hier gehen die Anzeigen zumindest gelegentlich bis auf 25% hoch.

Danke!

Kann bitte Jemand, der die Möglichkeit hat, diesen Test,
(Cubase mit keinen Projekt offen, und die Leistungs-Anzeige, z.B. mit LICEcap ab Screenshotten/Filmen)
mit C9,5; C10 und C10.5 machen?
(Und der ASIO-Puffer wär nicht schlecht, mit den der Test gemacht worden ist, anzugeben // der wirkt sich Maßgeblich auf das Ergebnis aus)


Lg

 

[Gast92251]

Mal was völlig irres :
Mein Cubase Sx3.1 läuft mit eingeschaltetem Multiproz Unterstützung trotz Quadcore hakelig und mit hoher Cpu Last. Stelle ich die MultiprozUnterstützung aus, schnurrt er, wie er soll. Das soll man erstmal verstehen....

Nicht irre Antwort: das uralte SX3 hat Multiproz noch nicht vollumfänglich unterstützt. Damals gab es zudem auch andere Rechnerhardware. So einfach ist das.

 

[stereolli]

Mal was völlig irres :
Mein Cubase Sx3.1 läuft mit eingeschaltetem Multiproz Unterstützung trotz Quadcore hakelig und mit hoher Cpu Last. Stelle ich die MultiprozUnterstützung aus, schnurrt er, wie er soll. Das soll man erstmal verstehen....

Nicht irre Antwort: das uralte SX3 hat Multiproz noch nicht vollumfänglich unterstützt. Damals gab es zudem auch andere Rechnerhardware. So einfach ist das.

Ab 3.1.944 soll laut Steinberg Multi richtig unterstützt werden. So zumindest auch die Berichte einiger QuadUser unter Sx3 die im Netz zu finden sind.

 

[PlanNine]

...Warum in aller Welt soll denn beim Rendern NICHT die ganze CPU Power genutzt werden, das ist doch totaler Mumpitz....

Bsp:

Ein Project:
AudioSpur> VST Slot1 > VST Slot2 > VST Slot3 > VST Slot4 > VST Slot 5 ... > Dithering Plugin > Out.
(Also ein Kanal, Alles in Serie geschalten)

Soll das gerendert werden, MUSS jedes VST, auf das Ergebnis des Vorherigen warten, damit es was tun kann, (weil ja Alles in Serie hängt).

Da ist nur die Frage wie das warten auf das Ergebnis realisiert ist. Wenn Sampleweise gewartet wird dann geht es schnell. Wenn Bufferweise gewartet wird dann benötigt es natürlich mehr Zeit. Ich weiß nicht wie das intern realisiert ist.

Edit: Ich war noch im Kontext. Jedes Plugin in einer Kette erhöht die Latenz.

 

[Gast92251]

Ab 3.1.944 soll laut Steinberg Multi richtig unterstützt werden. So zumindest auch die Berichte einiger QuadUser unter Sx3 die im Netz zu finden sind.

tat SX 3 aber vor ca. 15 Jahren nie wirklich. Ich weiss das sogar ziemlich genau, weil ich das alles durch hatte. Was hat das uralte SX3 hier im Thread zu suchen, frage ich mich ferner gerade.

 

[Sascha Franck]

Jedes Plugin in einer Kette erhöht die Latenz.

Nur bei denen zutreffend, bei denen es zutrifft. Es gibt etliche Plugins ohne eigene Zusatzlatenz. Sind allerdings oft einfachere oder welche, die dann wirklich auf die Rechnerlast drücken, weil eben alles innerhalb der vorgegebenen Puffergröße erledigt werden muss.

 

[Loop_Breaker]

wenn die Plugins ohne latenz, in serie geschalten sind,
und jedes Plugin nur einen thread nutzt, muss trotzdem jedes Plugin in serie, auf das ergebnis des vorherigen plugins warten.
und es kann immer nur ein thread (core) gleichzeitig genutz werden.

einfach vom der signalfluss logik her. 0 it-wissen, für diese erkenntnis erforderlich...

 

[SilentWarrior]

 

[Sascha Franck]

wenn die Plugins ohne latenz, in serie geschalten sind,
und jedes Plugin nur einen thread nutzt, muss trotzdem jedes Plugin in serie, auf das ergebnis des vorherigen plugins warten.
und es kann immer nur ein thread (core) gleichzeitig genutz werden.

einfach vom der signalfluss logik her. 0 it-wissen, für diese erkenntnis erforderlich...

Mir ist nicht ganz klar, ob das wirklich bei Offline-Prozessen zwingend so ist. Wenn ich das recht in Erinnerung habe, wird in Video-Rendering-Farmen auch parallel gearbeitet. Da bekommt dann eben ein Rechner die Frames 10.000-19.999 zum abarbeiten und der andere 20.000-29.999, danach wird das im Masterrechner zusammengesetzt. Keine Ahnung, ob das wirklich so ist, hat mir halt mal ein Videofuzzi grob erzählt. Und das müsste dann doch eigentlich auch im Audiobereich so gehen - wobei ich absolut keine Ahnung habe, wie das vonstatten geht.

 

[Gast92251]

wenn die Plugins ohne latenz, in serie geschalten sind,
und jedes Plugin nur einen thread nutzt, muss trotzdem jedes Plugin in serie, auf das ergebnis des vorherigen plugins warten.
und es kann immer nur ein thread (core) gleichzeitig genutz werden.

einfach vom der signalfluss logik her. 0 it-wissen, für diese erkenntnis erforderlich...

Völlig richtig. Es gibt und kann daher auch keine Null-Latenz in digitalen Systemen geben.

 

[Sascha Franck]

Völlig richtig. Es gibt und kann daher auch keine Null-Latenz in digitalen Systemen geben.

Die gibt es, wenn man es streng nimmt, auch in analogen Systemen nicht.

 

[Froschkapitaen]

Wenn die Summe der Latenzen von in Serie geschalteten Plugins kürzer als die Samplefrequenz ist, kann man doch von "quasi Latenzfrei" sprechen, oder?

 

[Sascha Franck]

Wenn die Summe der Latenzen von in Serie geschalteten Plugins kürzer als die Samplefrequenz ist, kann man doch von "quasi Latenzfrei" sprechen, oder?

Wie meinen?

 

[Loop_Breaker]

Kann schon Jemand von Erfahrungen berichten mit "Gapeless Audio"?

wenn die Plugins ohne latenz, in serie geschalten sind,
und jedes Plugin nur einen thread nutzt, muss trotzdem jedes Plugin in serie, auf das ergebnis des vorherigen plugins warten.
und es kann immer nur ein thread (core) gleichzeitig genutz werden.

einfach vom der signalfluss logik her. 0 it-wissen, für diese erkenntnis erforderlich...

Mir ist nicht ganz klar, ob das wirklich bei Offline-Prozessen zwingend so ist. Wenn ich das recht in Erinnerung habe, wird in Video-Rendering-Farmen auch parallel gearbeitet. Da bekommt dann eben ein Rechner die Frames 10.000-19.999 zum abarbeiten und der andere 20.000-29.999, danach wird das im Masterrechner zusammengesetzt. Keine Ahnung, ob das wirklich so ist, hat mir halt mal ein Videofuzzi grob erzählt. Und das müsste dann doch eigentlich auch im Audiobereich so gehen - wobei ich absolut keine Ahnung habe, wie das vonstatten geht.

Ich hab erst später gemerkt, dass wir teilweise aneinander vorbei schreiben:

- Ja Digital ist immer Latenz behaftet.
- wenn man 100 Plugins welche KEINE Latenz erzeugen in Serie hat, hat man keine zusätzliche Latenz zum ASIO Puffer.
- wenn ein Plugin Latenz verursacht, schiebt es alle davon abhängigen Plugins (gleicher Kanal, Sends, Gruppen, Sidechains) zeitlich nach hinten.

- beim Video-rendern, muss nicht alles von einander abhängig sein, (meist überlenden nur 2 Video-Spuren oder so i.d.R. schätze ich) man kann unter umständen das Bild zum Bsp. in 2 hälften Teilen, und unabhängig voneinander rendern, b.z.w. an verschiedenen stellen gleichzeitig rendern und zusammenführen.
Aber bei einer DAW, kann es ja sein, dass irgendein Signal, auf Ereignisse welche erst eine Minute später stattfinden Einfluss hat...

 

[Sascha Franck]

- Ja Digital ist immer Latenz behaftet.
- ( ich glaube) wenn man 100 Plugins welche KEINE Latenz erzeugen in Serie hat, hat man keine zusätzliche Latenz zum ASIO Puffer.
- wenn ein Plugin Latenz verursacht, schiebt es alle davon abhängigen Plugins (gleicher Kanal, Sends, Gruppen, Sidechains) nach hinten.

Schon klar.

Aber bei einer DAW, kann es ja sein, dass irgendein Signal, auf Ereignisse welche erst eine Minute später stattfinden Einfluss hat...

Ich habe mir das eben auch nochmal durch den Kopf gehen lassen - und kann mir tatsächlich ebenfalls nicht vorstellen, wie das gehen sollte. Allein schon, wenn da sowas ganz schnödes wie eine Hallfahne in's Spiel kommt, würde das ja nicht mehr funktionieren - die Entsprechung dafür gibt's bei Video wohl kaum.

 

[Loop_Breaker]

voll.
Hab mich vorhin schlecht ausgedrückt, mit "wir teilweise aneinander vorbeischreiben" meinte ich Alle hier, nicht explizit Sascha Franck...


Ein Frage:
Egal welcher ASIO-Puffer eingestellt ist, (auch wenn er größer als die Plugin-Latenz ist), erzeugt ein Plugin, welches Latenz verursacht, zusätzlich zum ASIO-Puffer Latenz?
Ich glaube das es so ist, hab's aber noch nie überprüft...
(Könnte ja sein, dass, wenn die Plugin-Latenz unterhalb der ASIO-Puffer-Latenz ist, die Plugin-Latenz "verschwindet)

 

[Sascha Franck]

Ein Frage:
Egal welcher ASIO-Puffer eingestellt ist, (auch wenn er größer als die Plugin-Latenz ist), erzeugt ein Plugin, welches Latenz verursacht, zusätzlich zum ASIO-Puffer Latenz?
Ich glaube das es so ist, hab's aber noch nie überprüft...
(Könnte ja sein, dass, wenn die Plugin-Latenz unterhalb der ASIO-Puffer-Latenz ist, die Plugin-Latenz "verschwindet)

Hah! Ich hatte genau das auch mal überlegt - und es getestet. Macht keinen Unterschied. Da müsste ja in jedes Plugin etwas eigebaut sein, dass dann die Puffergröße erkennt, damit es sagen kann "Hey, das sind genug Puffersamples, jetzt kann ich meinen eigenen Puffer abschalten". Vielleicht geht sowas technisch ja sogar, aber da müsste das Plugin auch noch die Daten vom Treibermenü des Hosts auslesen können - denke mal, das wäre zu viel Aufwand. Die Plugins, mit denen ich das mal ausprobiert hatte, haben's jedenfalls nicht gemacht.

 

[Loop_Breaker]

Wenn die Summe der Latenzen von in Serie geschalteten Plugins kürzer als die Samplefrequenz ist, kann man doch von "quasi Latenzfrei" sprechen, oder?

Die Frage ist, rein technisch gesehen, ungünstig Formuliert:

Die Samplefrequenz muss man erst umrechnen in eine Zeit, zB: 1sek : 44,1khz = 1 Sample (0,022675736961 ms).


Wenn wir Wandler-Latenzen e.t.c. Unterschlagen, und uns nur auf ASIO-Puffer- u. Plugin-Latenz konzentrieren:

32 Samples (0,79ms) ASIO-Eingangspuffer
+ Plugin Latenz (sagen wir mal 0ms)
+ 32 Samples (0,79ms) ASIO-Ausgangspuffer = 1,587ms Latenz. (ohne Wanlder und Andere Komponenten welche noch dazuwischen hängen)

Steinberg gibt in der Cubase-Anleitung zum Thema Control-Room an, dass man maximal 64Samples @ 44,1khz Einstellen soll, damit es "realtime'ig" ist. Das wären dann in unseren Bsp. (Ohne Wandler e.t.c. und Plugin verursachte Latenzen) = 3,1746ms

 

[KDthe2nd]

Meine Güte Cubase kann es einfach nicht. Jetzt habe ich mal eine CPU intensive Spur mit Render in place gerendert. Und Cubase braucht wieder relativ lange . Ich habe auch Multicore angehakt in den Global Einstellung in Cubase , kein Echtzeit angehakt (geht bei Render in place auch z.B. nicht und beim mp3 Export mach ich das eh nicht...) Energie Höchstleistung unter Windows, Audiopriorität Boost (Cubase) und mache den Windows Taskmanager an und Cubase dümpelt dort wieder bei 10 % rum . Warum in aller Welt soll denn beim Rendern NICHT die ganze CPU Power genutzt werden, das ist doch totaler Mumpitz. Sorry das ich mich aufrege aber jetzt alles aufgerüstet auf Windows 10, Ryzen 8 Kern und Cubase 10 Pro und dann kommt hier so ein unprofessioneller Mist.

Vielleicht könnt ihr das mal testen ob Cubase 10 überhaupt beim Mixdown, Render in place einen Multicore Prozessor mit 90% belastet. Da könnte man sich einen Threadripper für 2000 Dollar holen und bringt herzlich wenig. Oder dürfen wir jetzt bis Cubase 10.5 warten bis sich da mal was tut?

Gerade mal aus reiner Neugier getestet...

Win 10 Pro
Intel i5 8600k / 3.60 GHz Basistakt (automatisches Overclocking [medium] im BIOS - ASUS Mainboard aktiviert.
16 Gig RAM - M2. NVMe Systemplatte etc.pp.

Windows Energiesparplan: ausbalanciert (nicht auf Höchstleistung)
Turbo Boost aktiviert.

Cubase Einstellungen, siehe Screenshot >




war ein kleineres Projekt bei Render In Place

Alle Kerne am werkeln