Nutzung der CPU-Threads in Logic - Peaks eines einzelnen Kerns

  • Ersteller MountainKing
  • Erstellt am
So, ich habe jetzt schon mal zwei "Bösewichte" im Stereo-Bus ausfindig gemacht:

- Varisaturator - hier hatte ich 8x Oversampling eingestellt. Das lässt den 8ten Kern deutlich nach oben springen. Warum das aber nur diesen beansprucht, erschließt sich mir nicht. Euch?

- Ozone 6 - Darin hatte ich den Maximizer verwendet. Ozone 6 raus und stattdessen den Elephanten und es läuft schon viel ruhiger. Der rechte Kern bewegt sich deutlich in der Nähe der anderen Kerne - jedenfalls bei 1024er Einstellung. Aber anscheinend bin ich dann doch schon an einer gewissen Grenze angelangt, was niedriger Latenzen zu Zwecke der INstrumenteinspielung angeht. 64 knackst deutlich (aber immerhin läuft es noch, einspielen wäre also sogar möglich), 128 läuft besser, aber hier sind die Latenzen schon stärker spürbar. Bei 1024 hab ich noch reichlich Reserven in Bezug auf das Mixing. Aber "produzieren" mit ergänzenden Aufnahmen usw. wird schon schwieriger.



Und woher rühren diese Sync-Fehler in Bezug auf Audio-Midi?
 
Mit meiner RME UFX hab ich bei 128 Samples keine merklichen Latenzen.

Mastereffekte würde ich zum Einspielzeitpunkt komplett rausnehmen. Wer macht denn sowas ;)
Das verschärft ja die Sache vollkommen unnötig und erhöht die Latenz, also kein Wunder.
 
Mastereffekte würde ich zum Einspielzeitpunkt komplett rausnehmen.

+1

Unabhängig davon kannst Du das bestimmt mit dem Low-Latency Modus in den Griff kriegen.
Experimentiere mit den Einstellungen - im Mixer siehst Du ja, welche Plugins ausgeblendet werden.

Klingt dann etwas sparsamer, ist es aber auch (für die CPU)
 
> Mastereffekte würde ich zum Einspielzeitpunkt komplett rausnehmen.
+1

Ozone ist ein ziemlicher Resourcenfresser.

> Varisaturator - hier hatte ich 8x Oversampling eingestellt. Das lässt den 8ten Kern
> deutlich nach oben springen. Warum das aber nur diesen beansprucht,
> erschließt sich mir nicht. Euch?

Nicht alle Programme sind multi-threaded geschrieben. Dass ein Betriebssystem Multithreading unterstützt reicht alleine nicht aus. Hier ein paar Infos dazu.
http://www.zdnet.de/39197412/einfuehrung-in-die-multithreading-programmierung/

Und 8-fach oversampling bedeutet, dass das Plugin intern aufwendiger arbeitet und damit mehr Rechenzeit benötigt. Möglicherweise liess sich diese Berechnung nicht gut parallelisieren oder da gibts noch "headroom for improvements".

An der Stelle ein Tip für den CPU Kauf. Hier auch auf die Single thread Performance achten.
Die ist neben anderen Dingen wzB CPU Architektur/Design vor allem aber von der Taktfrequenz abhängig.

Je mehr Kerne man hat (-> Energieverbrauch / Hitze) desto geringer ist die Taktfrequenz.
Es gibt zwar Turbo Boost, aber die höhere Turbo Boost Frequenz erreicht man nicht, weil durch Rechner Tuning für Audio idR a) das Parken von CPU Kernen abgeschaltet wird und b) Energiesparen möglichst deaktiviert wird, manchmal sogar EIST abschalten von Speedstep.

Turbo Boost bedeutet, dass nur wenige Kerne übertaktt werden können (ich glaube ca 25%), hat aber als notwendige Grundvoraussetzung, dass ein paar andere Kerne geparkt (abgeschaltet) werden können. Das möchte man im Audio Bereich nicht, weil es verhältnismäßig lange (zu lange) dauert, bis eine CPU wieder verfügbar ist.

Diese Rechner internen Latenzen (nicht zu verwechseln mit der RTT Latenz zwischen Recording Interface und DAW) sollten nicht zu hoch werden, weil es die Wahrscheinlichkeit für Audio Aussetzer erhöht und höhere ASIO Buffer Sizes erfordert für einen störungsfreien Betrieb.
Die Cubase Optimierung (optimiertes Energieprofil) für höhere Audio Leistung schaltet beispielsweise CPU Core Parking ab, damit ist das Erreichen des angegebenen Turbo Taktes für eine CPU schon mal per se Essig.

Hier in dem Artikel eine Übersicht, welche Rechner internen Latenzen durch verschiedene Sleep States resultieren:
http://www.tonstudio-forum.de/blog/index.php/Entry/52-BIOS-Optimierung-Supermicro-X10SRi-F/

Darum beim CPU Kauf abwägen zwischen vielen Cores und Single thread performance.
Viele Cores haben sicherlich auch Ihren Sinn, weil man mehr vollwertige CPUs bekommt.
Der 2. thread eines Cores ist ja bekanntermassen nicht so leistungsfähig, weil er quasi parallel zum Hauptthread versucht, auf die zur Zeit ungenutzten Restresources eines Cores zuzugreifen, was aber je nach Applikation mal besser und mal schlechter gelingt. Darum gibts ja auch die Emphehlung auch mal im BIOS auszuprobieren, das Multithreading der CPU auszuschalten.
 
Warum ist es dann aber beim Line 6 Gerät ähnlich?
Kann ich morgen bei mir auch mal testen - liegt im Büro.
Ich vermute einen Zusammenhang mit USB-Interfaces.
Hast Du mal den internen Sound versucht? Hat der Mac Mini doch auch, oder?
Hab jetzt gerade mal mein Sonic Port VX dran gehängt - keine Spitze beim 8. Kern.
Das Interface unterstützt aber auch maximal 48 kHz.

Das Projekt mit dem ich es gestern und heute getestet habe besteht übrigens nur aus einer Audio-Spur mit diversen Amp-Simulationen (natürlich nur je eine aktiv). Im Stereo-Bus liegt kein Effekt.
Und Amp-Sims können zwar CPU-hungrig sein, aber sind ja in der Regel für "live"-Betrieb ausgelegt.

Aber im Prinzip ist es ja wirklich egal - solange die Wiedergabe/Aufnahme ohne Probleme läuft, können die Kerne ausgelastet sein oder zappeln wie sie wollen. Hauptsache, ich merke davon nichts.
 
So, vielen Dank für Eure Einschätzungen und Bemühungen in Sachen Over-Sampling, Ausprobieren von Interfaces uswusf. Das hilft.


Mit meiner RME UFX hab ich bei 128 Samples keine merklichen Latenzen.

Mastereffekte würde ich zum Einspielzeitpunkt komplett rausnehmen. Wer macht denn sowas ;)
Das verschärft ja die Sache vollkommen unnötig und erhöht die Latenz, also kein Wunder.


Ja, klar. Das mach ich ja normalerweise auch nicht. Aber ich gehe mittlerweile schon ganz gerne in eine Art Pseudo-Mastering-Kette rein (ja, da gibt es viele Diskussionen, ich weiß), einfach um zu wissen, wie das Stück funktioniert. Brauch' ich natürlich nicht beim Einspielen.

Ich brauche auch bestimmt keinen super-duper-Klang, um ein paar Instrumente zusätzlich einzuspielen, ganz im Gegentum. Ich wäre ja eher froh darüber, wenn es in Logic einen Global-FX-Off -Button gäbe. Auch da wird viel drüber diskutiert. Aber gerade in solchen Situationen - mal eben noch was dazu einspielen - fänd' ich das super. Gibt's leider nicht. Im Mixer zeilenweise über alle Plugins zu ziehen ist keine gängige Option für mich.

Stimmt, ich habe jetzt auch noch mal mit 128 eingespielt. Das funktioniert tatsächlich leidlich gut.






Unabhängig davon kannst Du das bestimmt mit dem Low-Latency Modus in den Griff kriegen.
Experimentiere mit den Einstellungen - im Mixer siehst Du ja, welche Plugins ausgeblendet werden.

Klingt dann etwas sparsamer, ist es aber auch (für die CPU)


OK, damit werd' ich mal rumexperimentieren. Welche diesbezüglichen Einstellungen funktionieren für Euch gut?



Aber nochmal zu synthpark's Bemerkung in Bezug auf die "Unrundheit" des MAC-OSX-Logic-AU-Universums: Es ist für mich doch ziemlich unerfreulich, dass bei zusätzlicher Plugin-Belastung (unabhängig, ob im Stereo-Bus oder auch sonstwo) dieses "Universum" offenbar dazu tendiert, immer diesen einen bekloppten Kern über die Maßen (jedenfalls deutlich mehr als alle anderen Kerne) anzusprechen - mit dem blöden Eregebnis, dass eher mal Dropouts entstehen, obwohl ja das Niveau der anderen Kerne überhaupt noch nicht im Entferntesten ausgelastet wird. (Klar: Dabei ist natürlich richtig, dass letztlich egal ist, wie das CPU-Meter "aussieht". So lange es läuft, läuft's. Aber tendenziell gibt es doch hier offenbar noch großes Optimierungspotenzial.)



Ich frage mich, ob das bei anderen Systemen auf dem MAC (S1, Live, Cubase, ProTools) besser läuft?!? Und auch, welchen Einfluss das verwendete Interface auf diese Performance hat. Das TAC-2R (Thunderbolt) ist jetzt angekommen (hab das für gut 130 EUR vone einem englischen Händler über ebay bekommen - neuwertig als Retoure). Mal sehen, wie sich dieses so schlägt.
 
> Es ist für mich doch ziemlich unerfreulich, dass bei zusätzlicher Plugin-Belastung
> (unabhängig, ob im Stereo-Bus oder auch sonstwo) dieses "Universum" offenbar
> dazu tendiert, immer diesen einen bekloppten Kern über die Maßen
> (jedenfalls deutlich mehr als alle anderen Kerne) anzusprechen -
> mit dem blöden Eregebnis, dass eher mal Dropouts entstehen,
> obwohl ja das Niveau der anderen Kerne überhaupt noch nicht im
> Entferntesten ausgelastet wird

Ich könnte mir vorstellen, dass hier was läuft, was nicht multithreaded ist.
Schaltet doch mal VSTs in allen Spuren Stück für Stück ab und schau, ob
die Last bei dem einen Kern bzw thread auf einmal drastisch runtergeht.
 
> Es ist für mich doch ziemlich unerfreulich, dass bei zusätzlicher Plugin-Belastung
> (unabhängig, ob im Stereo-Bus oder auch sonstwo) dieses "Universum" offenbar
> dazu tendiert, immer diesen einen bekloppten Kern über die Maßen
> (jedenfalls deutlich mehr als alle anderen Kerne) anzusprechen -
> mit dem blöden Eregebnis, dass eher mal Dropouts entstehen,
> obwohl ja das Niveau der anderen Kerne überhaupt noch nicht im
> Entferntesten ausgelastet wird

Ich könnte mir vorstellen, dass hier was läuft, was nicht multithreaded ist.
Schaltet doch mal VSTs in allen Spuren Stück für Stück ab und schau, ob
die Last bei dem einen Kern bzw thread auf einmal drastisch runtergeht.

Ja, danke. Das werd' ich mal machen.
 
Was du hier schilderst klingt schon sehr nach dem Live Input Mode, von dem Clemens ja bereits sprach. Hat man einen virtuellen Klangerzeuger angewählt werden alle Prozesse dieses Kanals auf einem Kern gerechnet, damit man das Instrument über einen MIDI-Controller bedienen kann.

Da hilft eigentlich nur die Last ggf. über Busse aufzuteilen und virtuelle Instrumente nur dann anzuwählen, wenn man auch eine Aufnahme machen will.

Und zu der Fehlermeldung: Hast du evtl. ein Interface dran, dass die von Logic übermittelte SR nicht erkennt? Es gibt nur eine Master Clock, richtig? I/O Buffer sind auf Maximum? Tritt das auch beim Built In Audio auf? Unter Projekteinstellungen>Synchronisation>Audio kannst du mal unter Core Audio zwischen MTC Continuous und der MTC Trigger & Auto Speed Detection wechseln, wieder zurückschalten und schauen ob sich die Fehlermeldung reproduzieren lässt.
 

Ähnliche Themen

stefangeidel
Antworten
17
Aufrufe
4K
clemenserwe
clemenserwe
twinnpeaks
  • Artikel
Testberichte Test: Output Exhale
Antworten
3
Aufrufe
21K
zamorra
zamorra

Oft gelesene Themen

Zurück
Oben