Die Suche nach dem Flaschenhals - System für Cubase optimieren

[Jabir]

Hi Leute,

ich mache hier mal einen extra Thread auf, um das Thema nochmal genauer aufzurollen. "Mel_Ohne" hat in einem anderen Thread netterweise diesen Video gepostet, welches ich sehr spannend fand:


View: https://youtu.be/GUsLLEkswzE

Ich war schon drauf und dran, mir einen neuen Rechner mit leistungsfähigerer CPU zusammenzustellen. Nun habe ich aus dem Video mitgenommen, dass der Flaschenhals sehr wahrscheinlich nicht die CPU ist. Dennoch tappe ich insgesamt weiter im Dunkeln und suche nach Anhaltspunkten, welche Komponenten dazu führen, dass ich in volleren Projekten mit rechenintensiven Plugins nicht flüssig arbeiten kann.

Mein System:
CPU: AMD Ryzen 5 3600
Mainboard: MSI B450M-A PRO
Arbeitsspeicher: 16GB DDR4
Grafikkarte: Nvidia GeForce GTX 970
Netzteil: 400 Watt be quiet! System Power 9
Festplatten: 1x 1TB Samsung 970 Evo Plus M.2 2280 und 1x 1TB Samsung 860 QVO 2.5"
Interface: Focusrite Clarett 2Pre USB

Auf der 970 Evo Plus Festplatte ist mein Betriebssystem sowie alle Programme (VSTs, Plugins usw.) und Libraries installiert. Auf der 860QVO liegen die ganzen Cubase-Projektordner inkl. der Inhalte.

Ich nutze Cubase 12 Pro in der aktuellsten Version.

Bei Überlastung meines Systems sieht die Performance Anzeige in Cubase übrigens so aus:

Ist das normal? Es wundert mich, dass nur bei Asio Guard etwas angezeigt wird und die Real Time und Peak Belastung quasi auf 0 sein soll.

Ich habe dann probehalber bei zwei sehr rechenintensiven Plugins die Asio Guard Nutzung deaktivert. Dann schaut es zwar besser aus (siehe nachfolgendes Bild), ich habe allerdings trotzdem Dropouts.

Ich bin für jeden Hinweis dankbar. Mein Wunsch ist es, dass ich mich problemlos in Projekten mit sehr vielen Spuren und Plugins bewegen kann. Ich wäre natürlich auch bereit, mein System dafür upzugraden, oder eben ein neues aufzusetzen, aber es muss halt Sinn machen. Einfach nur eine schnellere CPU scheint ja nicht die Lösung zu sein.

Danke vorab und beste Grüße
Jabir

 

[suboptional]

Das Tool mal laufen lassen und berichten:

Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks

LatencyMon: suitability checker for real-time audio and other tasks

www.resplendence.com

 

[muffy]

Genau deswegen und anderen Stunts habe ich dieser DAW den Rücken gekehrt.

 

[Entone]

Nun habe ich aus dem Video mitgenommen, dass der Flaschenhals sehr wahrscheinlich nicht die CPU ist.

Wie kannst Du das genau ausschließen?

 

[Jabir]

Das Tool mal laufen lassen und berichten:

Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks

LatencyMon: suitability checker for real-time audio and other tasks

www.resplendence.com

Mache ich morgen

Genau deswegen und anderen Stunts habe ich dieser DAW den Rücken gekehrt.

Meinst du, das Problem liegt bei Cubase? Auf welche DAW bist du gewechselt?

Wie kannst Du das genau ausschließen?

Ausschließen würde ich es nicht. Aber die Infos aus dem Video deuten daraufhin. Bin nicht sicher, ob ich die Performance Anzige richtig deute, aber er sagt ja mehr oder weniger, dass es bei DAWs häufig nicht um CPU power, sondern um Real Time Performance geht.

Kann denn jemand von euch die Performance Anzeige von Cubase deuten/einordnen? Asio-Guard auf voller Last und Rest auf 0…?

 

[SilentWarrior]

Mein Wunsch ist es, dass ich mich problemlos in Projekten mit sehr vielen Spuren und Plugins bewegen kann.

Dein Wunsch kann sogar die modernste CPU zum schwitzen bringen.

Wenn ich mische dann reduziere ich immer die Spuren. Also wenn ich 16 Backing Vox Tracks habe dann bounce ich mit einem Tastendruck diese zu einem Stereofile.
In Nuendo werden dann die ursprünglichen Tracks deaktiviert und dann blende ich die Spuren aus.

So mache ich das mit allem was nicht einzeln vorliegen muss.

Ich habe ein AMD 5900X, also der hat viel mehr Power als deine CPU.
Aber ich kann auch so arbeiten das ich auf sehr viele Spuren sehr viele Plugins habe bis mein Rechner in die Knie geht.

Aber eines ist fakt: verwendet man die Cubase/Nuendo eigene Plugins dann hat man sehr viel Luft bis die CPU schlapp macht.

Die Frage ist: muss auf jeder Spur ein rechenintensives Plugin sein?
Kann man z.B. zwei Synthesizer auf eine Gruppe routen und diese gemeinsam bearbeiten?

Die meisten Projekte die schlapp machen haben zu viele Plugins auf einer Spur.

Deine CPU ist nicht die stärkste und da können zu viele Plugins mit Oversampling schon deine CPU in die Knie zwingen.
Da hilft dann nur noch Buffer erhöhen, was aber ab 256 aufwärts dann auch keinen Spaß mehr macht
oder eben konsequent nicht unnötige Plugins laden.

Deshalb meine Frage an dich:

ist deine Arbeitsweise effizient oder doch eher so 4-6 Plugins pro Spur und für jede Aufgabe ein Dritthersteller Plugin?


Komischerweise gibt es m.M.n einen Bezug auf schlechte Abhöre und zu viele Plugins auf einer Spur.
Man hört einfach nicht was man hören muss und dann geht es los mit so Reihenfolgen wie EQ, Kompressor, wieder EQ, wieder ein Kompressor, Sättigung..

In so einem Fall statt CPU, bessere Abhöre kaufen das nur noch ein EQ und ein Kompressor auf der Spur liegt.
Je schlechter die Abhöre desto mehr Plugins auf einer Spur.

Also ich möchte dir hier nichts unterstellen, nicht falsch verstehen.
Aber du hast halt sehr wenig darüber geschrieben was für dich viele Spuren und viele Plugins bedeuten.
Der eine meint 2 Plugins pro Spur ist viel und der andere meint 6 pro Spur sind wenig.

 

[TheSarge]

@Jabir
hattest du nicht an anderer Stelle Ozone10-Einsatz erwähnt? das ist, so viel ich weiß, ein CPU-Monster -> ist in deinem Bild von der Auslastung Ozone dabei?
desweiteren ist ASIO-Guard nicht so gestrickt, wie manch andere Dinge, d.h.: Max ist nicht immer die beste Lösung. @tsching hatte da auch mal was zu gemacht, weiß leider nicht mehr, ob in einem Kauf-Tutorial oder auf YT/Forum

 

[ModulationMatrix]

Welches Interface nutzt du? Gute Treiber? Verschiedene Buffer Sizes probiert?

 

[Jabir]

Das Tool mal laufen lassen und berichten:

Resplendence Software - LatencyMon: suitability checker for real-time audio and other tasks

LatencyMon: suitability checker for real-time audio and other tasks

www.resplendence.com

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:07:36 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DESKTOP-6A9KU4E
OS version: Windows 10, 10.0, version 2009, build: 19045 (x64)
Hardware: MS-7C52, Micro-Star International Co., Ltd.
BIOS: 3.50
CPU: AuthenticAMD AMD Ryzen 5 3600 6-Core Processor
Logical processors: 12
Processor groups: 1
Processor group size: 12
RAM: 16337 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed (WMI): 360 MHz
Reported CPU speed (registry): 360 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 660,90
Average measured interrupt to process latency (µs): 4,702169

Highest measured interrupt to DPC latency (µs): 658,60
Average measured interrupt to DPC latency (µs): 1,650245


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 114,090
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,034545
Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%) 0,036889

ISR count (execution time <250 µs): 279465
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 784,230
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 531.41 , NVIDIA Corporation

Highest reported total DPC routine time (%): 0,046119
Driver with highest DPC total execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in DPCs (%) 0,093609

DPC count (execution time <250 µs): 866291
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 70
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: cubase12.exe

Total number of hard pagefaults 184484
Hard pagefault count of hardest hit process: 99155
Number of processes hit: 76


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 11,078717
CPU 0 ISR highest execution time (µs): 114,090
CPU 0 ISR total execution time (s): 1,977443
CPU 0 ISR count: 214247
CPU 0 DPC highest execution time (µs): 784,230
CPU 0 DPC total execution time (s): 4,044668
CPU 0 DPC count: 455507
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 1,160287
CPU 1 ISR highest execution time (µs): 88,450
CPU 1 ISR total execution time (s): 0,014811
CPU 1 ISR count: 4690
CPU 1 DPC highest execution time (µs): 233,190
CPU 1 DPC total execution time (s): 0,143017
CPU 1 DPC count: 28905
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1,359266
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 104,230
CPU 2 DPC total execution time (s): 0,098468
CPU 2 DPC count: 41124
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 1,026189
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 104,550
CPU 3 DPC total execution time (s): 0,022247
CPU 3 DPC count: 8466
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 1,128355
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 67,470
CPU 4 DPC total execution time (s): 0,05140
CPU 4 DPC count: 18444
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 1,157473
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 71,280
CPU 5 DPC total execution time (s): 0,037180
CPU 5 DPC count: 10588
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 4,268412
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 85,040
CPU 6 DPC total execution time (s): 0,375096
CPU 6 DPC count: 147634
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 1,518803
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 93,830
CPU 7 DPC total execution time (s): 0,185590
CPU 7 DPC count: 95779
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 1,223935
CPU 8 ISR highest execution time (µs): 7,60
CPU 8 ISR total execution time (s): 0,022436
CPU 8 ISR count: 52302
CPU 8 DPC highest execution time (µs): 42,140
CPU 8 DPC total execution time (s): 0,066048
CPU 8 DPC count: 27094
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 1,055344
CPU 9 ISR highest execution time (µs): 4,970
CPU 9 ISR total execution time (s): 0,000949
CPU 9 ISR count: 1648
CPU 9 DPC highest execution time (µs): 81,510
CPU 9 DPC total execution time (s): 0,016501
CPU 9 DPC count: 6334
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 1,240858
CPU 10 ISR highest execution time (µs): 12,730
CPU 10 ISR total execution time (s): 0,001768
CPU 10 ISR count: 2945
CPU 10 DPC highest execution time (µs): 102,660
CPU 10 DPC total execution time (s): 0,057458
CPU 10 DPC count: 19727
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 1,149826
CPU 11 ISR highest execution time (µs): 4,920
CPU 11 ISR total execution time (s): 0,002174
CPU 11 ISR count: 3633
CPU 11 DPC highest execution time (µs): 88,240
CPU 11 DPC total execution time (s): 0,027220
CPU 11 DPC count: 6759
_________________________________________________________________________________________________________


Ich hoffe, ich hab richtig gemessen. Hab Latency Mon gestartet und anschließend das betroffene Projekt geöffnet. Dann ein paar Minuten das Projekt inkl. der Dropouts laufen lassen.

 

[Jabir]

Deshalb meine Frage an dich:

ist deine Arbeitsweise effizient oder doch eher so 4-6 Plugins pro Spur und für jede Aufgabe ein Dritthersteller Plugin?

Komischerweise gibt es m.M.n einen Bezug auf schlechte Abhöre und zu viele Plugins auf einer Spur.
Man hört einfach nicht was man hören muss und dann geht es los mit so Reihenfolgen wie EQ, Kompressor, wieder EQ, wieder ein Kompressor, Sättigung..

In so einem Fall statt CPU, bessere Abhöre kaufen das nur noch ein EQ und ein Kompressor auf der Spur liegt.
Je schlechter die Abhöre desto mehr Plugins auf einer Spur.

Also ich möchte dir hier nichts unterstellen, nicht falsch verstehen.
Aber du hast halt sehr wenig darüber geschrieben was für dich viele Spuren und viele Plugins bedeuten.
Der eine meint 2 Plugins pro Spur ist viel und der andere meint 6 pro Spur sind wenig.

CPU Effizient ist meine Arbeit nicht wirklich, da hast du schon recht. Arbeite zu 85-90% mit Drittanbieter Plugins und es passiert mir schon häufiger, dass ich schnell nen neuen EQ reinlade, bevor ich in der Kette nochmal zurückgehe und etwas anpasse. Also da kann ich sicherlich etwas optimieren. Trotzdem hätte ich gerne die Freiheit, mich richtig austoben zu können, sei es nur fürs Gefühl. Ob man es dann wirklich ausnutzt ist dann eine andere Frage

Abhören tue ich über Focal Alpha 65 in einem nicht perfekt, aber doch stark behandelten Raum. Zusätzlich über Kopfhörer Audio Technica ATH-R70x.

In einem meiner Projekte kommt mir das ganze sehr extrem vor. Ich habe auch das Gefühl, dass es schlechter geworden ist. Ich versuche mal ein konkretes Beispiel zu nennen:

1x Beat-Spur: 13 Instanzen/Plugins drauf; Neutron 4 Exciter, 3x Pro Q3 im Zero Latency Mode, Waves RBass, Ozone 10 Exciter, PA Lindel PEX-500, Ozone 10 EQ, Ozone 10 Master Rebalance, Ozone 10 Low End Focus, Ozone 10 Impact, Fresh Air und Virtual Mix Rack ohne Oversampling

1x Main Vocals: 15 Instanzen; 3x Pro Q3 im Natural Phase Mode, Virtual Mix Rack ohne Oversampling, Neutron 4 Exciter, Fresh Air, Maäg EQ4, Waves RVox, MO-TT, Fabfilter MB Comp, Nectar 3, MicroShift, bx Focusrite SC

2x Backing Vocals: je 12 Instanzen; 3x Pro Q3, RVox, FreshAir, Neutron 4 Exciter, Waves CLA 3A, Neutron 4 Gate, RX10 De-Ess, Waves CLA-76, Waves Imager

Dann gibt es im Projekt noch 3 FX Kanäle: 1x Stereo Delay von Cubase, 1x Mono Delay von Cubase und 1x Hall (Stratus von Exponential Audio)

Und zu guter letzt liegt auf dem Master: Bassroom, Mixroom, TDR Kotelnikov, Pro Q3 Natural Phase, BlackBox HG-2, Soothe 2, PA Lindel PEX-500, The God Particle, Ozone 10 Mastering Chain (EQ, Impact, Stabilizer, Imager, Dynamic EQ und Maximizer), Metric A/B und Tonal Balance Control

Die meiner Wahrnehmung nach rechenintensivsten Plugins hiervon sind Ozone 10 Master Rebalance, Ozone 10 Low End Focus, Ozone 10 Maximizier, Soothe 2 und The God Particle.

Trotzdem ist es, was das Routing und die Anzahl der Spuren betrifft (auch wenn sie zugegeben mit Plugins vollgeknallt sind) eigentlich ein Mini Projekt. Dennoch kann ich es in der DAW bei Buffer Size 1024 nicht abspielen.

@Jabir
hattest du nicht an anderer Stelle Ozone10-Einsatz erwähnt? das ist, so viel ich weiß, ein CPU-Monster -> ist in deinem Bild von der Auslastung Ozone dabei?
desweiteren ist ASIO-Guard nicht so gestrickt, wie manch andere Dinge, d.h.: Max ist nicht immer die beste Lösung. @tsching hatte da auch mal was zu gemacht, weiß leider nicht mehr, ob in einem Kauf-Tutorial oder auf YT/Forum

Ja, siehe oben. Hab vorher lange mit Ozone 9 gearbeitet. Soll es bei 10 "schlimmer" geworden sein?
Edit: Kannst du das mit Asio Guard genauer erklären? Was meinst du mit Max ist nicht immer die beste Lösung?

Welches Interface nutzt du? Gute Treiber? Verschiedene Buffer Sizes probiert?

Focusrite Clarett 2Pre USB mit Focusrite Control 3.11.0.1983

 

[hanselmann]

Ich habe seit dem update auf 12 das Problem, daß selbst eine Instanz Avenger, der eine „Sequenz“ abspielt, genau zu dem Erscheinungsbild führt, auf Anschlag und rot.
Lat mon ist sehr im grünen Bereich, extra ne Ati genommen, die besser ist als die nvidia vorher, welche allerdings auch keine Probleme hatte.

Avenger hatte seitdem updates, Cubase 2 mal, keine Besserung. Das hatte ich bei 11 nicht!
Es ist auch bei anderen vstis so, nur nicht ganz so extrem.

Also ich würde schon sagen, das da seit 12 irgendwas im argen ist, auch wenn ich schon oft verlacht wurde deswegen. Ich las auch schon öfter von anderen ähnliches, und andererseits von vielen, die keine Probleme haben.

Dazu - mein Vertrauen in Leute, die „keine Probleme haben“ ist nur teilweise vorhanden, da ich die Erfahrung gemacht habe, das viele es schlicht einfach nicht merken

Und natürlich- klar, jeder PC ist anders.
Aber da ich NICHT der Einzige bin, könnte schon was dran sein.

Eventuell das neue Lizenzsystem, wenn man wegen anderer Sachen noch den eLicencer drin hat oder so.

 

[Marcel_H]

dh wenn ich es richtig lese, hast Du auf einem low/mid PC-System rd 70 teilweise rechenintensive Drittanbieter-Plugin-Instanzen gleichzeitig laufen - finde ich normal dass Dein PC bzw die Asio-Wiedergabe dabei in die Knie geht.

Ich glaube daher nach dem Geschilderten nicht, dass Dein System einen einzelnen „krassen Bottleneck“ hat, den Du nur finden müsstest, um dann zB 140 Plugin-Instanzen problemlos betreiben zu können.

Es sieht mir eher danach aus, dass Du mit effizienterem Arbeiten (zB die Backing Vocals auf 1 Gruppe routen und dort mit Plugins bearbeiten) die Anzahl Instanzen reduzieren kannst und damit Dein System ohne Dropouts betreiben kannst. Und wenn das irgendwann gar nicht mehr geht, dann Dein PC-System als ganzes austauschen

 

[hanselmann]

Du meinst aber nicht mich, oder?

 

[NorthernDecay]

Ich habe seit dem update auf 12 das Problem, daß selbst eine Instanz Avenger, der eine „Sequenz“ abspielt, genau zu dem Erscheinungsbild führt, auf Anschlag und rot.
Lat mon ist sehr im grünen Bereich, extra ne Ati genommen, die besser ist als die nvidia vorher, welche allerdings auch keine Probleme hatte.

Avenger hatte seitdem updates, Cubase 2 mal, keine Besserung. Das hatte ich bei 11 nicht!
Es ist auch bei anderen vstis so, nur nicht ganz so extrem.

Also ich würde schon sagen, das da seit 12 irgendwas im argen ist, auch wenn ich schon oft verlacht wurde deswegen. Ich las auch schon öfter von anderen ähnliches, und andererseits von vielen, die keine Probleme haben.

Dazu - mein Vertrauen in Leute, die „keine Probleme haben“ ist nur teilweise vorhanden, da ich die Erfahrung gemacht habe, das viele es schlicht einfach nicht merken

Und natürlich- klar, jeder PC ist anders.
Aber da ich NICHT der Einzige bin, könnte schon was dran sein.

Eventuell das neue Lizenzsystem, wenn man wegen anderer Sachen noch den eLicencer drin hat oder so.

Das glaube ich auch inzwischen!

https://recording.de/threads/steinberg-treibt-mich-in-den-wahnsinn.254225/post-3214693

 

[SilentWarrior]

Du meinst aber nicht mich, oder?

Nein, er hat deinen nicht gesehen als er seinen schrieb. Du hast 1 Minute vor ihm gepostet.

 

[SilentWarrior]

@Jabir

Deine CPU ist keine Singlethread Bestie.

Du kannst viele Spuren mit wenig Plugins auf einer Spur haben aber nicht viele Plugins auf einer Spur.

Das ist ja der Vorteil der neuen AMD Prozessoren ab der 5000er Serie.

Deine Arbeitsweise packt deine CPU nicht. Ich hatte den 3700X und bin dann zu 5900X gewechselt.

 

[Entone]

Puh. 12-15 Plugins pro Spur. Da stimmt was am Workflow nicht. Ich würde eher daran ansetzen. Und wenn Du am Workflow nichts ändern willst, wird ein Umstieg auf ein besseres System kaum vermeidbar sein.

Je schlechter die Abhöre desto mehr Plugins auf einer Spur.

Entweder das. Oder: Je schlechter das Ausgangsmaterial, desto mehr Plugins auf einer Spur. Man muss ja schließlich reparieren, verschlimmbessern und herummurksen. Ist jetzt kein Vorwurf an den Threadersteller. Aber merkwürdig ist so eine Arbeitsweise schon. Irgendwas stimmt da nicht.

 

[Realist]

Ich bin zur Zeit noch auf Cubase 11, obwohl ich Version 12 besitze.
Abgeschreckt hatten mich damals genau diese Berichte, dass es wohl noch nicht so rund läuft mit dem ASIO Guard in Version 12. Es gibt/gab wohl noch andere Performance Issues.
K.P. ob das mittlerweile gefixt ist. Wenn ich mir hier die Posts so durchlese anscheinend noch nicht.
Hier mal aus dem Steinberg-Forum:

Cubase 12 Upgrade ASIO-Guard Issue

Like so many, I upgraded today to CB12 from CB11. Congratulations on the new release!! My initial first impression - when opening a project created in CB11, CB12 gives me clicks and pops when switching between Kontakt 6 instruments. I have confirmed all my settings are the same (unless I’m...

forums.steinberg.net

Cubase 12.0.10 - performance issues

We have received several reports about performance and stability issues in the initial release of Cubase 12.0.0 from different users. In the past weeks, we invested a lot of time in investigating why, on some systems, Cubase 12 leads to suboptimal performances. We want to thank all users that...

forums.steinberg.net

ASIO Guard ist generell nicht so der Burner und man muss einige EInschränkungen hinnehmen.
Sampler wie Kontakt sollte man nicht mit ASIO Guard betreiben, weil die von Festplatte streamen.
Avenger würde fast auch darunter fallen, weil der ja auch mit Samples arbeitet.
Das Problem ist, man muss das als User selbst ausprobieren, was wenig Anwenderfreundklich ist.
Hier mal etwas zum ASIO Guard um es etwas zu verstehen:

https://helpcenter.steinberg.de/hc/de/articles/206103564-Details-zu-ASIO-Guard-in-Cubase-und-Nuendo

Auf der anderen Seite sind die Pluginketten die Jabir hat schon extrem anspruchsvoll.
Da könnte man schonmal drüber schauen. Ozone und Pro Q im Natural Phase so als Beispiel sind schon nicht ohne.

Ansonsten könnte man auch nochmal im Steinberg-Forum anklopfen und etwas Druck aufbauen.
Dort aber nur im englischen CUbase-Bereich. Dort lesen die Steinis mit. Im deutschen Forum nicht mehr.

 

[Entone]

Wenn das eh alles Drittanbieter-Plugins sind, könnte man doch mal einen Vergleich mit einer anderen DAW wagen. Reaper ist klein, schlank und effizient. Einfach downloaden und mal ein vergleichbares Projekt mit den gleichen Plugins in Reaper anlegen. Dann sieht man schon, ob es an Cubase liegt.

REAPER | Download

 

[miniak2012]

Zwei Sachen die mir auf die schnelle einfallen.
Läuft dein RAM schon auf der maximalen stabilen Taktfrequenz?
Verwendest du den regulären NVidia-Treiber? Eventuell wäre der Studio-Treiber oder sogar eine slimed-down Variante einen Blick wert.

Generell zu Plugins, vor allem in größeren Projekten, ich hab persönlich die Erfahrung in Nuendo gemacht, dass es oft einzelne Plugins bzw. spezielle Modi bei Plugins sind die besonders lange Pufferzeiten brauchen, die die Projektperformance dann killen.

Um da Probleme zu ermitteln hilft die Kanal-Latenz-Übersicht in Cubase/Nuendo enorm.
Da sieht man bei manchen Plugins gleich, das könnte Probleme geben.

Und wenn man Plugins trotzdem weiter nutzen will gibt es dann auch Lösungen.
Bin leider nicht so der Freund vom klassischen Freezen, das killt für mich etwas den Workflow.
Abhilfe schafft da für mich Direct Offline Processing.