Extreme Real Time Peaks mit neuem Rechner

Du hast ja auch den record Button deaktiviert. Drück den mal…und dann eventuell willkommen im Club :wink:
Deine Average ist meines Erachtens auch viel zu hoch für ein einziges virtuelles Instrument.

Glaube nicht, dass der Average zu hoch ist. Da spielen über 20 Töne. Und Flux ist schon ziemlich unoptimiert und frisst Einiges :wink:.

Korretktur : mir Rec-Button geht RealtimePeak deutlich hoch. habe ich mich aber nie drüber gewundert :smiley:
Weil das immer auch VST-Abhängig ist

Ohne Record Button ist völlig unerheblich. Denn es geht doch genau um die Situation des “Einspielens”, es sei denn, du erzeugst deine Töne mit der Maus.
Du kannst auch Töne löschen und nur einen Dreiklang spielen.

H.

habe mein Beitrag korrigiert ^^. Sorry für die Verwirrung

Und jetzt schau mal im Task Manager nach deiner CPU, die langweilt sich wahrscheinlich gerade genau so, wie meine, wenn Cubase peakt.
Und das ist genau der Punkt. Cubase bringt die Power nicht zu den Prozessoren.

Die Systemanzeige zeigt ja nicht die Prozessorauslastung an, sondern wie viel Zeit (der maximal möglichen Zeit → abhängig von der Buffereinstellung) verbraucht wird, um die Audiobuffer zu füllen. Wenn mehr Zeit benöigt wird, als die Buffer zulassen, geht die Peakanzeige Rot. Und für die Füllraten spielt halt nicht nur der Prozessor eine Rolle, sondern auch die GeräteSchnittstellen, Interruptverarbeitung usw.

Der Taskmanager ist bei mir auch idle.

Wie auch immer. Die Funktionsweise der Systemanzeige hilft mir nicht beim Erledigen meiner Arrangeur Jobs.
Und das Patch im Flux ist nur ein Beispiel, da es ja ähnlich, katastrophale Ergebnisse bei anderen VI’s gibt.
Nicht bei allen, aber bei vielen, die ich zum Einspielen als Profi nun mal benötige.

Ich bin jetzt einfach mal gespannt, wie es mit meinem Testprojekt bei anderen Foristen aussieht, die ihr eigenes System als performant empfinden.

Ja, bin ich auch

Hi

hab´s getestet mit der geringsten Latenz die ich mit der der Soundkarte einstellen konnte.

Im Prinzip war es egal ob ich gleichzeitig aufnehme oder nicht.


Und das ist genau der Punkt. Cubase bringt die Power nicht zu den Prozessoren.

Das kann man generell nicht sagen. Das ist schon sehr von den eingesetztem Plugins und Anzahl der Stimmen der VSTi´s abhängig.


Gruß Ruby

Hier IMG 0685 - Sendvid mach ich doch gerne :smiley:
Aber ich hab hier ein Trick gemacht besser gesagt 2 du gehst bei Halion Sonic auf Options/Performance und machst erst mal alle Cores an.
Dann Max Voices stellst du von 128 auf 10 runter solange du arbeitest und beim Export stellst es wieder rauf,so kannst du Tonnen davon aufmachen und auch noch einspielen,auf was ich hinaus will man muss sich zu helfen wissen. :wink:
setting war 256 Buffer Asioguard small
Das könnte Steinberg noch einbauen ein Haken mit “Export Max Voices” dann muss man sich darum nicht mehr kümmern.

^^^^^^
Alter, kraaaassss :astonished: :open_mouth: :smiley:

:confused: OK

@ Ruby

Bei dir sieht das ja schon mal besser aus, als bei mir. Wobei die Average auch sehr hoch ist.


@ Wepsta :sunglasses:

Schön, das du einen Trick gefunden hast, in diesem speziellen Fall den Halion Sonic durch Ändern der Einstellungen zu überlisten.
Jetzt muss ich nur noch diverse Omnisphere, NI Kontakt und UVI Patches oder deren Engine umprogrammieren und dann ist ja alles gut. :laughing:

Für mich ist diese Art und Weise zu arbeiten der Killer jeglichen kreativen Flows.

Hi,

aber stabil. Das System läuft auch noch stabil und peakfrei wenn die Last auch > 90% ist. Der Pegel ist/bleibt stabil und nichts peakt bei dieser geringen Latenz.

Für mich ist diese Art und Weise zu arbeiten der Killer jeglichen kreativen Flows.

Muss man denn wirklich bei einer Aufnahmesession gleichzeitig in der Form so kreativ sein, dass die VSTi´s tatsächlich unter Volllast laufen müssen?
Da gibt es sicherlich noch gute Möglichkeiten/Workflows. :wink:

Gruß Ruby

Muss man denn wirklich bei einer Aufnahmesession gleichzeitig in der Form so kreativ sein, dass die VSTi´s tatsächlich unter Volllast laufen müssen

Gruß Ruby
[/quote]

Verstehe ich nicht…

Es ist doch nicht zu viel verlangt, wenn ich ein Instrument einspielen möchte, das nicht peakt.

HI,

Es ist doch nicht zu viel verlangt, wenn ich ein Instrument einspielen möchte, das nicht peakt.

Natürlich nicht. :wink:

Gruß Ruby

Ich werde mal ein neues Topic aufmachen im Hardware & Setup Forum, eine komplette Anleitung für X299 Systeme mit bestimmte Asus Boards.Komponenten,Bios Einstellung,Windows Einstellung usw. wo ich zu 98% sagen kann das es im normalen Fall keine Probleme gibt.
Kann aber noch etwas dauern ich muss mir mal Zeit dafür nehmen. Lg

Sehr gute Idee!

Ich würde mich freuen, wenn du diesen Beitrag gleich hier in diesem Forum posten würdest oder zumindest ein Link oder Hinweis. Bei dem Mist der hier fast täglich erscheint wäre das wirklich mal ein sehr interessanter, hilfreicher und absolut cubasebezogener Beitrag! Da sag ich jetzt schon mal Danke für die Mühe!

Wie versprochen hier die Anleitung
Bitte gern :wink:

Hallo Ihr geplagten Cubase Nutzer,

ich möchte mich traurigerweise einreihen in diese Reihe. Ich habe ein relativ frisch zusammen gebautes System und massiv mit Reak-Time-Peaks zu kämpfen.

Ich poste euch mal den LatencyMon Status hier rein und hoffe sehr auf Hilfe und Tipps wie ich meine System performant bekomme. Vielen Dank schonmal im Voraus


CONCLUSION


Your system appears to be suitable for handling real-time audio and other tasks without dropouts. (das ist halt voll lächerlich, bereits bei ein paar Spuren kommt es zu Peaks
)
LatencyMon has been analyzing your system for 0:14:14 (h:mm:ss) on all processors.

\


SYSTEM INFORMATION


OS version: Windows 10 , 10.0, build: 17763 (x64)
Hardware: ASUSTeK COMPUTER INC., PRIME X470-PRO
CPU: AuthenticAMD AMD Ryzen 7 2700X Eight-Core Processor
Logical processors: 8
Processor groups: 1
RAM: 32688 MB total

\


CPU SPEED


Reported CPU speed: 3693 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.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.


\


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): 134,30
Average measured interrupt to process latency (µs): 4,458661

Highest measured interrupt to DPC latency (µs): 129,80
Average measured interrupt to DPC latency (µs): 1,815477

\


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): 126,950176
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

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

Total time spent in ISRs (%) 0,130371

ISR count (execution time <250 µs): 973770
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µ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): 185,741403
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 430.39 , NVIDIA Corporation

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

Total time spent in DPCs (%) 0,276943

DPC count (execution time <250 µs): 3962420
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 0
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µ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: cubase8.exe

Total number of hard pagefaults 2887
Hard pagefault count of hardest hit process: 2783
Number of processes hit: 4

\


PER CPU DATA


CPU 0 Interrupt cycle time (s): 43,581147
CPU 0 ISR highest execution time (µs): 126,950176
CPU 0 ISR total execution time (s): 8,869713
CPU 0 ISR count: 926983
CPU 0 DPC highest execution time (µs): 185,741403
CPU 0 DPC total execution time (s): 18,794236
CPU 0 DPC count: 3926625


CPU 1 Interrupt cycle time (s): 4,069532
CPU 1 ISR highest execution time (µs): 19,857568
CPU 1 ISR total execution time (s): 0,005202
CPU 1 ISR count: 5892
CPU 1 DPC highest execution time (µs): 120,317628
CPU 1 DPC total execution time (s): 0,015054
CPU 1 DPC count: 5572


CPU 2 Interrupt cycle time (s): 4,325135
CPU 2 ISR highest execution time (µs): 3,937449
CPU 2 ISR total execution time (s): 0,005080
CPU 2 ISR count: 5738
CPU 2 DPC highest execution time (µs): 59,282155
CPU 2 DPC total execution time (s): 0,020238
CPU 2 DPC count: 7069


CPU 3 Interrupt cycle time (s): 4,173688
CPU 3 ISR highest execution time (µs): 3,616843
CPU 3 ISR total execution time (s): 0,003840
CPU 3 ISR count: 4535
CPU 3 DPC highest execution time (µs): 50,325210
CPU 3 DPC total execution time (s): 0,011233
CPU 3 DPC count: 4237


CPU 4 Interrupt cycle time (s): 4,759802
CPU 4 ISR highest execution time (µs): 3,015705
CPU 4 ISR total execution time (s): 0,002402
CPU 4 ISR count: 3053
CPU 4 DPC highest execution time (µs): 43,732738
CPU 4 DPC total execution time (s): 0,009051
CPU 4 DPC count: 2786


CPU 5 Interrupt cycle time (s): 4,645392
CPU 5 ISR highest execution time (µs): 3,636881
CPU 5 ISR total execution time (s): 0,006290
CPU 5 ISR count: 8132
CPU 5 DPC highest execution time (µs): 43,462226
CPU 5 DPC total execution time (s): 0,018901
CPU 5 DPC count: 6521


CPU 6 Interrupt cycle time (s): 4,633894
CPU 6 ISR highest execution time (µs): 6,001354
CPU 6 ISR total execution time (s): 0,005070
CPU 6 ISR count: 6564
CPU 6 DPC highest execution time (µs): 45,656377
CPU 6 DPC total execution time (s): 0,017807
CPU 6 DPC count: 4659


CPU 7 Interrupt cycle time (s): 5,103677
CPU 7 ISR highest execution time (µs): 5,119686
CPU 7 ISR total execution time (s): 0,009336
CPU 7 ISR count: 12873
CPU 7 DPC highest execution time (µs): 58,500677
CPU 7 DPC total execution time (s): 0,034219
CPU 7 DPC count: 4951


Hi, habe die gleichen Probleme mit allen erdenklichen Audio DAWs wie, Reason 11, Bitwig 3.x, Ableton 10. Auch ganz gleich welche Plugins ich lade selbst ohne Last also ohne Plugins springt die CPU wie wild auf hohe Peaks. Mein System ist gleichermaßen schnell i7 Quad Core, 32 GB RAM, SSD, MOTU Ultralite MKIII. Ich denke, dass es ein Windows Problem ist.