Recording-Stammtisch

  • Ersteller livebox
  • Erstellt am
Das ist strange - wobei die angezeigte CPU Last unter S1 auch nicht einfach nur die CPU beschreibt

Das zeigt die Last der internen Audio Engine an. Das hat keinen direkten Bezug zur CPU. Process Lasso ist da in der Tat nützlich um weitere Informationen zu erlangen. Manchmal ist das ein Plugin, das einen Core komplett belegt und den auf nahezu 100% auslastet. Das führt in S1 zu Audio Engine Last fast 100%. Die CPU als solche hat aber noch jede Menge Luft. Das kann man auch nicht manuell auf mehrere Core verteilen. Das ist so programmiert und das ist dann halt so.

Zur Last Ermittlung nehme ich ein Demo Projekt, das ich mit für jede DAW angelegt habe. Das ist einfach ein Audio File mit Plugins drin. Das ist SDDR und MJUC von Klanghelm, dazu Satin von U-he und noch zwei andere die ich gerade nicht mehr erinnere. Das ganze dann dupliziert bis ca. 200 Spuren. Und dann die Plugin Blöcke nach und nach abschalten. Da kommen alle DAW auf einen Plugin count von um die 190 auf einem i7 6700k. Einziger Unterschied ist die minimale Latenz. Da gibt es erhebliche Unterschiede. Bei Puffer = max ist da kaum mehr ein Unterschied. Es gibt auch einen DAW Benchmark:

http://www.dawbench.com/

kann man auch nehmen.

Zu S1, da gab es ja ein Update im Dezember. Performance eher mau. Und dann kam noch mal so ein mini Update und das hat offensichtlich den Bremsklotz weggezogen. Seither läuft das prima und Projekte die vorher so um die 85% mit Peaks über 100% zeigten spielen jetzt mot 60 - 75% klaglos durch. Irgendwas haben sie gemacht, die Schlingel....... (;
 
Im grunde habe ich 2 Schwergewichte bein den Plugins. Das eine ist das Slate FG-X und das andere sind die Aqua Plugins von Acustica Audio.
Bei S1 geht die Last beim Verwenden dieser direkt krass hoch. Bei Reaper hat sich da kaum was getan. Ich werde das für mich alles noch verifizieren müssen.
 
Bei S1 geht die Last beim Verwenden dieser direkt krass hoch. Bei Reaper hat sich da kaum was getan

Gleiches Projekt? Das kann man nur vergleichen wenn man nahezu das selbe Setup hat. Einfach nur Plugin reinsetzen in eine Spur und sonst ist da nichts anderes ist nicht sehr aussagekräftig.

Hier mal Audio Engine Last am lebenden Projekt:

cpu last.png


Slate Limiter gehört da eher zu den genügsamen Kandidaten. Ozone zum Beispiel braucht auch nicht viel weniger. Allerdings kann man da ja eine ganze Reihe Plugins drin haben. Aqua braucht einiges. Stimmt. Habe ich zwar nicht aber N4 im Bild ist Nebula 4. In der Auslastung wird das kein grosser Unterschied sein zu Aqua. Gleiche Technologie.

Was hast Du denn für eine CPU?
 
Jetzt weis ich, dass ich mir niemals "Morph vst" holen darf :D ... wie gesagt, mus sich das nochmal vernünftig verifzieren.
Der bisherige Vergleich war nicht am selben Projekt sondern es ist mir nur bei der Arbeit aufgefallen, dass eine normale Session wie jetz unter Reaper noch super easy läuft während das unter S1 erfahrungsgemäß da eng wird.
 
200 Instanzen MJUC ist schon eine Ansage. Müsste ich mal probieren, was mein i5 4690 hergibt. :gruebel:
 
Ich habe mal Reaper angetestet und bin übberascht, dass eine vergleichbare Serssion unter Reaper auf den ersten Blick viel weniger Last verursacht als unter S1.

Das ist auch ein immer wiederkehrendes Thema (nicht nur) im offiziellen Studio One-Forum.

Einige Kollegen hier haben ja schon viel Richtiges dazu geschrieben.
Zusammenfassend kann man sagen, dass die CPU Anzeige in S1 und Reaper definitiv verschiedene Dinge anzeigen.
Ob jetzt die eine oder andere DAW ressourcenschonender ist, ist eine andere Frage - wobei Reaper da laut Berichten in diesem Punkt trotzdem die Nase vor den meisten anderen DAWs zu haben scheint.

Als Tipp für Studio One-Nutzer kann ich hier hinterlassen: Ein Kanal in Studio One kann immer nur einen Kern eines Prozessors nutzen.
Es nützt also nichts wenn man 8 Kerne hat, wenn man viele CPU-intensive Plug-ins auf einem Kanal liegen hat.
Man kann sich also in Notsituation so behelfen, dass man die Last auf mehrere Kanäle verteilt, indem man z.B. die Hälfte der Inserts auf einen Bus verschiebt, und dann denn Kanal dorthin routet. Das wird die CPU-Anzeige in S1 deutlich nach unten bringen. An dem Beispiel sieht man auch sofort, dass die Anzeige in S1 nicht die absolute CPU-Last anzeigt.

Bei mir war das in der Praxis allerdings noch nie nötig, trotz einer nicht mehr so aktuellen CPU (i7 2600K).
Ich verwende aber auch nicht MORPH oder ADAPTIVERB :D

Übrigens, wie kommt es zu 255 ms Latenz bei einem Hall Plug-in, @adrachin?
 
Ein Kanal in Studio One kann immer nur einen Kern eines Prozessors nutzen

Wer sagt das?

Ich habe eben mal in einen Kanal 64 Plugins eingesetzt. In der Tat wird da Core 1 mit ca. 65 % belastet. Alle anderen Core so um die 5 - 10. Dann habe ich den Track dupliziert. Wenn die Theorie stimmt, sollte ja dann ein zweiter Core um die 65 % belastet sein. Ist aber nicht. Die durchschnittliche Auslastung der anderen ist hoch gegangen, Core eins immer noch so um die 65 - 75.

Also das kann so nicht ganz stimmen. Wäre ja auch irgendwie unlogisch. Warum sollte S1 Cores einem Kanal zuordnen? Macht irgendwie nicht viel Sinn.

Ich verwende aber auch nicht MORPH oder ADAPTIVERB

Tja. Aber das sind ja nun auch nicht die einzigen Plugins, welche hohe Rechenleistung fordern. Insgesamt kann man schon einen Trend zu mehr benötigter Rechenleistung feststellen bei den Plugin Veröffentlichungen in den letzten Jahren. Bei einem Neutron mit allen Plugins aktiv und noch einigen dynamischen EQ landet man da schon auch mal bei 15 - 20% in der S1 Anzeige. Oder oben im Bild der Mautodynamic 20 mit 11%. Wobei es bei Dynamik EQ noch drauf ankommt. Sind die mit Sidechain belegt geht die Last noch mal einen guten Zacken hoch.

Selbst sowas eher simples wie Kush Omega N gönnt sich mal kurz 5%.

Oder ein bx_X2. Landet auch schon bei 10 oder so.

Jedenfalls habe ich die letzten Wochen immer abwechselnd und nach Lust und Laune mal mit Cubase, dann Pro Tools und dann wieder S1 gemischt. Für mich irgendwie kein grosses Problem die auszulasten. Das schaffe ich zuverlässig bei jeder DAW und jeder Mischung. Und da ist kein grosser Unterschied. Ich habe sogar Mischung, bei der ich in der einen DAW an die Grenze gestossen bin in anderen nachgebaut und da kam ich dann ebenfalls an die Grenzen. Vor dem letzen Update war da nur S1 die Ausnahme mit schlechterer Leistung. Aber jetzt nicht mehr.

So fette Dinger wie Adaptiverb oder oder Morph rendere ich vor dem finalen Mix. Aber die sind auf jeden Fall so lange wie möglich in Echtzeit mit drin. Gerade bi solchen Dingern macht es einen großen Unterschied, wenn man da noch mal an den Stellschrauben dreht. Das verändert das ganze Klangbild. Also so spät wie möglich rendern.

Irgendwann ist das aber auf jeden Fall nötig. Auch Automation oder viele Sidechain belasten die Audio Engine. Also ist der Zeitpunkt der Wahl für das Rendern von Effekten vor der eigentlichen Mischung wo dann die ganze Mischautomation dazukommt. So ungefähr. Oder so.

Übrigens, wie kommt es zu 255 ms Latenz bei einem Hall Plug-in

Das ist einfach die Latenz dieses Plugins. Gibt auch noch andere mit hoher Latenz. VSTi zum Beispiel. Oder UAD Plugins. Da gibt es einige die über 150 ms haben. Ozon kann auch Latenzen bis über 150 haben. Das addiert sich ja auch auf und kann dann zum Problem werden. Pro Tools kann nicht mehr als 850 ms Latenzausgleich. Wenn ich mich recht entsinne. Da muss man dann Maßnahmen ergreifen.Ich hatte schon Mischungen mit absurd hohen Latenzen von über 1500 ms. Da hinken dann die Pegelanzeigen so weit hinterher da wird einem ganz Schwindelig. Die haben zumindest in S1 keinen Latenzausgleich.

Wie auch immer, will man tatsächlich echtes in the Box Mixing betreiben, dann sollte man auf jeden Fall einen entsprechenden Rechner haben. Sonst gibt das immer wieder Render Orgien ohne gleichen. Und da weiß man dann nicht, was man vielleicht anders gemacht hätte, wäre es möglich gewesen, das bis zu Ende in Echtzeit abzuspielen.......
 
Wenn die Plugins in einem Kanal in Serie geschaltet sind, lässt sich da nix parallelisieren, denn jedes Plugin braucht ja das Resultat des vorigen. Ähnliches gilt für die Busse, die an den Kanälen dranhängen, die können erst berechnet werden, wenn alle Kanäle, die drauf gehen, ausgerechnet wurden.

Der kritische Pfad ist die rechenintensivste Kette Kanalplugins -> Bus mit Plugins -> Mastersektion samt Plugins.

Die einzig sinnvolle %-Angabe ist die Rechenzeit für alle Samples eines Puffers bezogen auf das ASIO-Intervall, also Puffergröße geteilt durch Samplerate.

Wenn alle Plugin komplett in Serie wären (ein Kanal mit alles Plugins) , kann das einen Kern komplett auslasten, während die anderen pennen, bei 8 logischen Kernen sind das dann grad mal 12,5% Auslastung der CPU, aber wenn man Pech hat, schafft die DAW das trotzdem nicht, bis der nächste ASIO-Puffer ansteht, dann knackt es.

Drum sagt die CPU-Last lt. Taskmanager nicht allzuviel über die DAW-Performance. Und die Möglichkeiten der Programmierer die Last gut auf die Kerne zu verteilen, sind begrenzt.

Banjo
 
Mal was ganz anderes, eben auf WDR gesehen:

Annemie Hülchrath und Ute Lemper machen einen Abstecher in das Studio, wo Ute L. schonmal aufgenommen hat.
Ein Mikrofonpark für die Membran-Fetischisten wird auch geboten... :prost:


Kann man das Video aus der Mediathek mal als Werbung gegen die Rapper-Hamster-Käfige nehmen?? :confused:
(In Anbetracht der Raumdimensionen)

Los geht der Studio-Besuch ab 10:10 Min.

http://www1.wdr.de/mediathek/video/sendungen/comedy/video-annemie-huelchrath--ute-lemper-100.html
 
Zuletzt bearbeitet:
Wenn die Plugins in einem Kanal in Serie geschaltet sind, lässt sich da nix parallelisieren, denn jedes Plugin braucht ja das Resultat des vorigen. Ähnliches gilt für die Busse, die an den Kanälen dranhängen, die können erst berechnet werden, wenn alle Kanäle, die drauf gehen, ausgerechnet wurden.

Das stimmt zwar, aber das führt noch lange nicht zu dieser Schlussfolgerung:

Wenn die Plugins in einem Kanal in Serie geschaltet sind, lässt sich da nix parallelisieren

Wieso nicht? Der DAW kann das doch völlig schnurz pip egal sein wo und wie das berechnet wird, Hauptsache das Ergebnis wird zurückgeliefert. Werfe ich alle Plugin Alliance Plugins in einen Kanal sehe ich das in der CPU Auslastung:

cpu plugin alliance.PNG


nehme ich die Hälfte und lege die in einen zweiten Kanal dann sieht es so aus:

cpu plugin alliance 2.PNG


also kein riesiger Unterschied. Zwei Audio Kanäle, die in einen gemeinsamen Master gehen. Laut Deiner Theorie könnte dann ja der eine Kanal auf einem Core berechnet werden, der andere auf einem anderen. Denn die Kanäle sind ja parallel.

Das ist dem Rechner aber völlig schnuppe. Im Leerlauf hat in dem Test S1 18 aktive Threats geöffnet. Sind die Plugins drin, dann sind es 256. Und in diesen 256 Threats wird gerechnet. Wo entscheidet das OS. Nicht die DAW.

Bestenfalls kann es Plugins geben, die nur einen Threat öffnen. Und die verbleiben dann in der Regel auf einem Core. Was aber noch lange nicht heißen muss dass wenn ich 10 davon einsetze, die alle auf dem gleichen Core berechnet werden muss.

Eigentlich kann einem das als Anwender auch völlig egal sein. Hauptsache es spielt....... :evil:
 

Die Entwickler von Studio One.

https://forums.presonus.com/viewtopic.php?p=124931#p124931

(siehe auch die weiteren Posts von Ari im selben Thread)

Also das kann so nicht ganz stimmen. Wäre ja auch irgendwie unlogisch. Warum sollte S1 Cores einem Kanal zuordnen? Macht irgendwie nicht viel Sinn.

Nicht ein Core wird einem Kanal zugeordnet, sondern ein Kanal einem Core. Natürlich kann ein Core mehrere Kanäle berechnen, sonst wäre die maximale Spurenanzahl in S1 = der Anzahl der Cores der CPU :ugly:

Das ist einfach die Latenz dieses Plugins. Gibt auch noch andere mit hoher Latenz.

Das ist mir schon klar, dass es Plug-ins mit hoher Latenz gibt - nur bei einem Hall Plug-in ist mir solches noch nie begegnet.

Wenn alle Plugin komplett in Serie wären (ein Kanal mit alles Plugins) , kann das einen Kern komplett auslasten, während die anderen pennen, bei 8 logischen Kernen sind das dann grad mal 12,5% Auslastung der CPU, aber wenn man Pech hat, schafft die DAW das trotzdem nicht, bis der nächste ASIO-Puffer ansteht, dann knackt es.

Genau so ist es.
Dieses Szenario würde dann die CPU-Anzeige in Studio One mit Vollauslastung zeigen - und trotzdem könnte man noch weitere Plug-ins laden, aber eben auf anderen Kanälen.
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Wenn die Plugins in einem Kanal in Serie geschaltet sind, lässt sich da nix parallelisieren

Wieso nicht? Der DAW kann das doch völlig schnurz pip egal sein wo und wie das berechnet wird

Das Wie und Wo ja, das Wann aber nicht. Ich kann schlicht keinen Kompressor berechnen, wenn ich nicht weiß, was aus dem davor geschalteten EQ rauskommt. Deshalb kann ich das nicht gleichzeitig in zwei Threads berechnen, sondern nur nacheinander.

Man muss aber zwischen Threads und Kernen unterscheiden. Wenn ich einen Thread voll ausgelastet laufen lasse, lässt Windows diesen normalerweise auch mal auf diesem Kern, mal auf jenem laufen, der Thread springt von Kern zu Kern und ich sehe im Taskmanagergemittelt ein wenig Last auf mehreren Kernen.

Ich kann als Programmierer aber auch erzwingen, das er auf einem bestimmten Kern bleibt, dann sieht das so aus wie in Deinem ersten Bild. Das kann Sinn ergeben, weil zum Beispiel mit Turbo Boost ein einzelner aktiver Kern höhet getaktet wrrden kann als wenn auf allen Kernen etwas los ist.

Es liegt also an den DAW-Programmieren, inwieweit sie das Windows überlassen, welcher Thread wo rennt oder es selbst in die Hand nehmen. Da gibt es wohl Unterschiede zwischen den DAWs.


Banjo
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Das ist mir schon klar, dass es Plug-ins mit hoher Latenz gibt - nur bei einem Hall Plug-in ist mir solches noch nie begegnet.
Gerade Halls die Räume berechnen, brauchen viel Berechnungszeit. Altiverb beispielsweise möchte gern 512 Samples haben.
--- Beiträge wurden zusammengefasst ---
@Banjo Wie machen das andere DAWs? Verteilen die ihre Instanzen auch so? Mir scheint, einige machen das besser als andere. Logics Audioengine scheint wie die von S1 zu arbeiten, da gab es auch den "Hack" mit den Bussen, um die CPU zu entlasten.
 
@Banjo Wie machen das andere DAWs? Verteilen die ihre Instanzen auch so? Mir scheint, einige machen das besser als andere. Logics Audioengine scheint wie die von S1 zu arbeiten, da gab es auch den "Hack" mit den Bussen, um die CPU zu entlasten.

Es dürfte gar nicht so einfach sein, da die richtige Strategie für alle denkbaren Signalflüsse in einem Projekt zu finden. Zudem unterscheiden sich verschiedene CPUs auch noch im Verhalten.

Ich hab mir vor kurzem ein CPU-Meter geschrieben, das neben der Last auch die Takte der einzelnen Kerne anzeigt, um das besser zu verstehen. Bei manchen i7s taktet Windows auch alle anderen Kerne relativ weit hoch, wenn einer Volllast hat, auf anderen andere laufen die anderen Kerne weiter langsam. Dann gibt es Turbo Boost 3.0, der entsprechende Windowstreiber legt ausgelastete Threads automatisch auf den besten Kern des Chips und übertaktet diesen noch etwas mehr als bei normalem Turboboost. Da wäre es wieder kontraproduktiv, wenn die DAW den Thread selber auf irgendeinem Kern festnagelt.

Die neuesten i7 haben Speedshift, wo die CPU das Rauf- und Runtertakten selber übernimmt und schneller auf verschiedene Lasten reagieren kann als Windows.

Da für jede Hardware und Projektkonfiguration die optimale Strategie zu finden, ist schwer. Drum kann ich mir auch vorstellen, dass die eine DAW in einem Fall die Nase vorn hat, in einem anderen Szenario eine andere.

Wie das bei diversen DAWs gelöst ist, weiß ich nicht. Protools unter Windows kann man sagen, wieviele Kerne es nehmen soll, drum gehe ich davon aus, dass es da relativ viel selber eingreift.

Banjo
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Ich habe da nicht gefunden, was die These stützt.

Wie wäre es mit dem Link, den ich dir vor die Nase gesetzt habe?

Wie das bei diversen DAWs gelöst ist, weiß ich nicht. Protools unter Windows kann man sagen, wieviele Kerne es nehmen soll, drum gehe ich davon aus, dass es da relativ viel selber eingreift.

Das kann man in Studio One ebenfalls festlegen.

fherhhdnx55.jpg
 
Sorry, das sinnerfassende Lesen kann ich dir nicht abnehmen.
 
Es geht nicht um Sinn. Es geht um klare, eindeutige Aussagen zu genau dem besprochenen Thema. Und da steht nichts dazu geschrieben. Vermutungen sind nun mal nicht hilfreich wenn es um technische Dinge geht.

Und jetzt ist von meiner Seite auch gut. Du hast Recht und ich meine Ruhe.
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Sorry Reflex, in der Sache sind wir uns glaub ich einig, aber in dem verlinkten Beitrag hab ich auch nix Eindeutiges gefunden. Du hast ja auch auf andere Posts in dem Thread verwiesen, gäbs da nicht einen mit einer knackigen Aussage, die man hier zitieren/verlinken könnte? Ich will jetzt nicht unbedingt den ganzen Thread dort rückwärts durchackern. Oder hast Du den falschen Post aus dem Thread verlinkt?

Banjo
 

Ähnliche Themen


Unser weiteres Online-Angebot:
Bassic.de · Deejayforum.de · Sequencer.de · Clavio.de · Guitarworld.de · Recording.de

Musiker-Board Logo
Zurück
Oben