iZotope Ozone 9 Performance Probleme - Suche nach dem Flaschenhals

[SilentWarrior]

@rkdk Da wir beim Thema sind:

wo könnte man die Grenze in ms setzen? Ist ja von DAW unabhängig. Der Drum Leveler macht ähnlich viel wie der Pro-L von FF.
Dann wären wir schon bei 120-130ms wenn beide auf einer Spur/Gruppe wären.

Bin mir nicht sicher ab wann Bitwig rot aufleuchtet um zu zeigen das die Latenz zu hoch wird.

 

[SilentWarrior]

War das bei Pro Tools nicht bei 4096 Samples oder so ähnlich?

 

[Gast92251]

wo könnte man die Grenze in ms setzen? Ist ja von DAW unabhängig.

Richtig. Ich weiss da auch nur, dass es in Pro Tools diese fixe Obergrenze hierfür gibt, worüber sich viele PT-User rege beklagen: alles was darüber ist, wird nicht mehr latenzkompensiert. Der von dir genannte Obergrenzenwert scheint das Thema dort zu sein.

 

[SilentWarrior]

Richtig. Ich weiss da auch nur, dass es in Pro Tools diese fixe Obergrenze hierfür gibt, worüber sich viele PT-User rege beklagen: alles was darüber ist, wird nicht mehr latenzkompensiert. Der von dir genannte Obergrenzenwert scheint das Thema dort zu sein.

Also ich weiß das irgendein Repair Tool von iZotope RX unglaubliche Latenzen unter Bitwig erzeugt. Da fiel mir dieses Problem überhaupt mal richtig auf.
Kann gut sein das diese Rebalance und Low Focus ähnliche Latenzen verursachen (habe beides nicht). Also mit DAW hat das sicherlich weniger am Hut.

 

[Gast92251]

Repair Tool von iZotope RX unglaubliche Latenzen

absolut!
iZotope musste u.a. mit einem Update nachliefern, damit RX Connect auf Nuendo/Cubase (ich kann als Beispiel nur von dieser DAW berichten) vernünftig auch im dortigen Direct Offline Processing funktionierte.

Interessantes Thema!

 

[rocking.xmas.man]

War das bei Pro Tools nicht bei 4096 Samples oder so ähnlich?

Ney, eher so um 16.000 rum. Und danach kommt die entsprechende bearbeitungsreihe verzögert.
Große Problemkinder diesbezüglich sind rx deplosive und decrackle.

 

[Jabir]

Hm, ich hänge immer noch daran, dass CPU und RAM nicht ausgelastet sind und es dennoch hakt :-/

 

[muffy]

Hm, ich hänge immer noch daran, dass CPU und RAM nicht ausgelastet sind und es dennoch hakt :-/

Es liegt an Cubase.

 

[Sweetsweep]

Wenn du bei hoher Buffersize die Probleme erst später bekommst, dann hast du den Übeltäter doch gefunden. Es ist deine CPU. Deine CPU hat zwar noch Reserven für bestimmte Kerne (Rechenprozesse), aber eben keine mehr für den Rechenprozess, in dem dein iZotope Plugin vorkommt.

Alles was du in einem Kanal am laufen hast, geht zu Lasten von einen Kern. Schlimm wird's dann, wenn der Kanal noch in diverse Sends und Gruppen geht und dort erneut Rechenprozesse statt finden. Das summiert sich. Das 'in Reihe schalten' ist der CPU Killer.

Ich kann beispielsweise parallel ca. 20 IKM Tapes öffnen (absolute CPU Killer) und in den einzelnen Kanälen noch Unmengen (!!!) Plugins nutzen; in Reihe geschaltet gehen maximal 3-4 und ein paar andere Kleinigkeiten, dann ist Feierabend (bei wohlgemerkt 12 Kernen zu je 3,8 - 4 Ghz).

Zum Verständnis:
Ich bin z.B. dazu übergegangen, anstelle eines Romplers, der in 2 Sendkanäle geht, lieber den gleichen Rompler 3 mal zu öffnen und 3 Kanäle zu betreiben, somit ohne Send zu arbeiten, damit sich die Rechenprozesse auf den CPU Kernen aufteilen können. Verkompliziert alles ein wenig, aber es verschafft sehr viel Luft.​

 

[Ethersis]

damit sich die Rechenprozesse auf den CPU Kernen aufteilen können. Verkompliziert alles ein wenig, aber es verschafft sehr viel Luft.

Das muss ich mal testen.

 

[Jabir]

Wenn du bei hoher Buffersize die Probleme erst später bekommst, dann hast du den Übeltäter doch gefunden. Es ist deine CPU. Deine CPU hat zwar noch Reserven für bestimmte Kerne (Rechenprozesse), aber eben keine mehr für den Rechenprozess, in dem dein iZotope Plugin vorkommt.

Alles was du in einem Kanal am laufen hast, geht zu Lasten von einen Kern. Schlimm wird's dann, wenn der Kanal noch in diverse Sends und Gruppen geht und dort erneut Rechenprozesse statt finden. Das summiert sich. Das 'in Reihe schalten' ist der CPU Killer.

Ich kann beispielsweise parallel ca. 20 IKM Tapes öffnen (absolute CPU Killer) und in den einzelnen Kanälen noch Unmengen (!!!) Plugins nutzen; in Reihe geschaltet gehen maximal 3-4 und ein paar andere Kleinigkeiten, dann ist Feierabend (bei wohlgemerkt 12 Kernen zu je 3,8 - 4 Ghz).

Zum Verständnis:
Ich bin z.B. dazu übergegangen, anstelle eines Romplers, der in 2 Sendkanäle geht, lieber den gleichen Rompler 3 mal zu öffnen und 3 Kanäle zu betreiben, somit ohne Send zu arbeiten, damit sich die Rechenprozesse auf den CPU Kernen aufteilen können. Verkompliziert alles ein wenig, aber es verschafft sehr viel Luft.​

Spannend....bisher hörte ich es immer genau anders herum: das der Einsatz eines Sends die CPU Last verringert, da die Plugins nicht gleichzeitig auf mehreren Kanälen laufen...

 

[auron]

Richtig. Ich weiss da auch nur, dass es in Pro Tools diese fixe Obergrenze hierfür gibt, worüber sich viele PT-User rege beklagen: alles was darüber ist, wird nicht mehr latenzkompensiert. Der von dir genannte Obergrenzenwert scheint das Thema dort zu sein.

Also ich weiß das irgendein Repair Tool von iZotope RX unglaubliche Latenzen unter Bitwig erzeugt. Da fiel mir dieses Problem überhaupt mal richtig auf.
Kann gut sein das diese Rebalance und Low Focus ähnliche Latenzen verursachen (habe beides nicht). Also mit DAW hat das sicherlich weniger am Hut.

Ohja , die Izotope Plugins erzeugen teilweise eine unglaubliche Latenz:

Neueste Version installiert. Also da kann man die Schuld wohl nicht auf Cubase oder Rechner schieben Merkwürdig ist dass das bei Izotope öfter vorkommt, ich kann zum Beispiel andere Denoising Tools von anderen Herstellern einfügen ohne dass die solche unglaubliche Latenzen erzeugen.

 

[Gast92251]

So ist es.
Das hat mit Cubase nichts zu tun, viele iZotope Dinger ziehen halt viel CPU und Latenz, weil sie aufwändiger berechnen als andere Plugins.
Im Falle von Cubase nutze ich diese bevorzugt einfach per DOP auf Audio Events - das kostet damit dann keinerlei zusätzliche CPU Power und zieht vor allem keine extra Latenz. DOP ist auch gut einzusetzen für Notebooks oder ältere Rechner mit schwächerer Leistung.

 

[rocking.xmas.man]

Grade der RX Kram ist auch nur teilweise für Echtzeit-Nutzung gedacht. Die Werkzeuge sind ja in erster Linie für Postpro Workflows entwickelt, da ist an vielen Stellen üblich dass Reparaturen per audiosuite eingerechnet werden.

 

[Gast92251]

Zum Verständnis:
Ich bin z.B. dazu übergegangen, anstelle eines Romplers, der in 2 Sendkanäle geht, lieber den gleichen Rompler 3 mal zu öffnen und 3 Kanäle zu betreiben, somit ohne Send zu arbeiten, damit sich die Rechenprozesse auf den CPU Kernen aufteilen können. Verkompliziert alles ein wenig, aber es verschafft sehr viel Luft.

Das ist höchst interessant, danke dir.

 

[Gast92251]

Grade der RX Kram ist auch nur teilweise für Echtzeit-Nutzung gedacht. Die Werkzeuge sind ja in erster Linie für Postpro Workflows entwickelt, da ist an vielen Stellen üblich dass Reparaturen per audiosuite eingerechnet werden.

Korrekt.
Daher stammt übrigens auch DOP, das Direct Offline Processing kam urmals von Nuendo und Post Pro Anwendungen.
Zu iZotope, das betrifft ja auch die Mastering Suite Ozone, diese Plugins wurden eben hierfür entwickelt: beim Mastering spielt Latenz auch keine Rolle.

 

[Loop_Breaker]

Hab jetzt nur kurz überflogen:

Verwende selbst auch Cubase10 und hab mir jetzt die verbilligten Elements Versionen von: Nektar (hab ich idiot mit Neutron verwechselt // quasi fehlkauf, aber für 8€ zu verkraften), Neutron, und Ozone.
Hab Alle 3 getestet, aber nur einen Instanz und mir ist da nichts merkwürdiges aufgefallen.

Hab bei mir Alle iZotope Sachen als VST2 rennen, weil ich einst (vor Jahren als ich mir das CreativeBundle gegönnt habe) festgestellt habe, dass die Automationen nicht zuverlässig funktionieren bzw beim exportieren teilweise ignoriert wurden. Und es gab auf der iZotope website einen Hinweis, dass man VST2 versionen verwenden soll, wenn es Probleme gibt. Hab jetzt nach dieser Seite gesucht, und sie ist offline. Schätze sie werden jetzt mit VST3 einwandfrei funktionieren, werd das iZotope Zeug bei mir auch auf VST3 umstellen...

Der i7 8550u (CPU des TE) ist anscheinend nicht übertaktbar, und hat nur 2,1GHz, daher sehr lahmarschig...
Z.B.: um 400€ bekommt man einen Intel 8 Kerner (welchen man auch noch übertakten kann): https://geizhals.eu/intel-core-i7-9....html?hloc=at&hloc=de&hloc=eu&hloc=pl&hloc=uk
(hab selber für meinen 8Kerner vor ca. 5 Jahren noch einen 1000der hinblättern müssen, und der um 400€ ist sogar noch besser. hab bei mir HyperThreading deaktiviert, was bei kurzen Latenzen meist besser ist, als wenn man es an lässt...)
AMD kenn ich mich nicht aus, aber bei den Preisen auf jeden Fall einen hingucker Wert.

Wenn es an den System liegt, müssten doch auch noch Andere Dinge nicht funktionieren (aber kein Cubase Stock-Plugin braucht annähernd soviel Resourcen wie iZotop Stuff)?


Wie wärs wenn wir Alle eine Testszenario nachbauen, und schauen nach wieviel Instanzen Ozone (je auf einer eigenen Audiospur) der Rechner in die Knie geht?