Latenz beim Abspielen.

[Shino]

Hallo!

Ich hab mal wieder ein seltsames Latenzproblem (Focusrite Saffire Pro 40) und zwar sogar dann, wenn ich auf die Leertaste (play) drücke, dann spielt die DAW (Cakewalk) erst nach ein paar Sekunden ab.
Das Gleiche passiert dann auch beim MIDI-Keyboard.

Die Einstellungen passen eigentlich alle.
Das einzige, was mich wundert (was allerdings nicht unbedingt mit dem Problem zu tun hat), dass ich die "Firewire Driver Latency" nur auf Medium und nicht auf Short stellen kann. Denn dann kommt beim Abspielen ein Knacksen.
Wenn ich auf Medium stelle, dann geht aber ASIO Buffer Size von 32 nicht, nur ca. 128.
Theoretisch dürfte es aber mit 32 auch gehen, da die CPU nur auf ca 40% ausgelastet ist.

Aber jetzt zurück zum Abspielproblem.
Das Einzige, was mir als Idee kommt ist... ich habe mal kurzzeitig versucht den Treiber für MixPre zu installieren (gleichzeitig mit dem Treiber für Saffire Pro 40), dann habe ich es wieder deinstalliert und für den Focusrite neu installiert.
Ich vermute fast, dass dort etwas unsauber gelaufen ist. Komme aber nicht drauf, ob es daran liegt und wie ichs beheben soll, ohne das ganze System neu aufzusetzen.

Jemand Ideen?

 

[Shino]

Ich kam inzwischen etwas weiter.
Es liegt an den ganzen EQs und ein paar Multibandkompressoren, die in den Spuren hängen.
Wenn ich sie ausmache, ist auch bei "short latency" und 32 Buffer keine Knacken und sofortiges Abpielen.

Der PC wird also in irgendeinem Sinne überlastet. Doch es ist mir nirgendwo ersichtlich.
Die CPU zeigt in Cakewalk höchstens 25% Belastung. Windows zeigt insgesamt höchstens 35% Belastung an.
RAM wird nur insgesamt zu 18% benutzt.

Also was kann da eine derartige Verzögerung und Knacksen hervorrufen, wenn es gar nicht angezeigt wird??

#Edit:
wenn ich den Driver auf medium latency setze und den Buffer bei 32 belasse, dann habe ich zwar eine heftige Verzögerung von ca. 2 Sek. bei play oder stop, aber auch bei MIDI. Latenz wird in den Einstellungen aber bei 5.3ms angezeigt. So ein Problem habe ich noch nie gehabt (aber ich habe auch noch nie so viel mit den EQs rumexperimentiert).

 

[Signalschwarz]

Die Verzögerung wird durch Plugin Delay Compensation bedingt sein.

Die Auslastung deines Systems bzw. dessen Nadelöhr wird wie so häufig das Bussystem sein.

 

[exoslime]

hi shino

beschäftige dich ein wenig mit Asio und der Buffergrösse, die spielt nur indirekt mit der CPU Auslastung zusammen

grob gesaagt: Die Buffer Zeit ist die Zeit, die du deinem System gibst um die Audioprozesse komplett zu berechnen, dh. je kürzer die Zeit, desto herausfordender für dein GesamtSystem, daher kann es durchaus vorkommen das deine GesamtCPU Auslastung recht gering ist, aber die ASIO Auslastung an die Decke schlägt (hat Cakewalk einen Asio Performance Meter eingebaut ?-> der wäre als Indikator für dich interessant) und gewisse Plugins benötigen einfach mehr Zeit um ihre Rechenaufgabe zu erledigen als andere, daher kommt auch eine Verzögerung zustande, das ist völlig normal, hier gilt es für dich zu identifizieren welche Plugins das sind und diese dann auszuschalten was du ja bereits gemacht hast. und Denn wie @Signalschwarz treffend schreibt, der Gesamtlatenzausgleich deiner DAW dadurch alles verzögert.
Welches mMn unabhängig von der gewählten Audio Interface einstellung laufen wird, die kommt dann noch dazu.

Optimieren kannst du das, indem du Plugins verwendest die weniger Latenz verursachen, versuche vielleicht andere EQs oder Multibandkompressoren, die könnten ggf besser funktionieren (ich habe hervorragende Erfahrungen mit denen von Fabfilter gemacht, und die haben zb auch einen Zero-Latency Mode) als die momentan verwendeten

lg
exoslime

 

[Shino]

danke euch! Ja, das ist so eine Sache mt den Plugins. Dieser EQ (LP EQ von Cakewalk) visualisiert die Frequenzen und frisst wohl Unmengen von "ASIO-Breite", wenn ichs jetzt recht verstanden habe.

Inwiefern hängt das mit dem Bussystem zusammen?
Ich habe gerade festgestellt (noch mit Vorsicht zu beurteilen), dass die Hauptbelastung der Mix-Bus und Master-Bus verursachen, bzw. die dortigen EQs. Die EQs auf den Instrumenten-Bus (git-lead, drums etc.) verursachen nicht so viel Belastung, wie die bei Mix und Master. Hat wohl damit zu tun, dass all die anderen Busse dann auf Mix verlinkt sind und Mix auf Master.

Praktisch hieße es dann (mal abgesehen von Benutzung anderer VSTs), wenn ich noch MIDI dazu aufnehmen will, dann alle EQs (in meinem Fall) aus, aufnehmen und danach wieder an und mixen.

Deswegen trennt mal wohl so strickt zwischen Recording, Mixing und Mastering, richtig?
Das habe ich früher nie verstanden.

 

[Telefunky]

nein, das trennt man weil die die Schritte aufeinander aufbauen und man sich nicht auf 3 verschiedene Finge gleichzeitig und gleich gut konzentrieren kann.
Wurde schlecht aufgenommen, macht der Mix Probleme - ist der Mix schlecht, macht Mastern wenig Sinn

Der EQ mit der Grafikanzeige macht vermutlich eine Echtzeitanalyse des Signals.
Die dazu (häufig) genutzte FFT Funktion arbeitet mit sehr grossem Puffer, der erst mal gefüllt sein will, bevor es losgeht. Daher die Verzögerung.

Bei der Anzeige der CPU Last ist Vorsicht geboten: bei einem Dual-Core bedeutet 50%, das 1 Kern komplett ausgelastet ist, bei einem Quadcore entsprechend 25%.
Eine DAW samt Plugins lässt sich aber (technisch) nicht beliegig auf freie (oder wenig genutzte) Kerne skalieren. Deswegen kommt es auch weit unter 100% schon zu Fehlern.

 

[Shino]

hmm... ja, es ist bestimmt eine Echtzeitanalyse. Die muss man also mit genug Puffer füttern, wenn ichs recht verstehe.
Ich hab einen Quadcore... meinst du, dass die DAW nicht alle 4 Kerne gleichzeitig nutzen kann?

 

[Novik]

Inwiefern hängt das mit dem Bussystem zusammen?

Du hast das mit dem Bus falsch verstanden
Signalschwarz redet nicht von deinem Mixbus in Cakewalk sondern vom System Bus deines Rechners. Die Schnittstelle, über die deine Hardware kommuniziert. Firewire ist besonders "picky" was den reibungslosen Betrieb mit Interfaces angeht.
Davon abgesehen sind 32 Samples Puffergröße schon arg klein. Dafür muss das System optimal eingerichtet sein

Deine DAW wird alle 4 Kerne nutzen. Wie gut das aber skaliert wird, hängt von der jeweiligen DAW ab. Im grunde ist es so, das es besser ist, weniger Kerne mit höherem Takt zu benutzen, als viele Kerne mit kleinerem Takt. Je weniger Kerne involviert sind, desto weniger Fehler passieren beim "Zusammensetzen" des Audiostreams in den Main Out.

 

[Shino]

ich dachte schon... um den Stadtbus gings aber sicher nicht, dachte ich mir..

Hmm... also ist ein Audiorechner besser mit wenigen, aber dafür um so heftigeren Cores

Ok... aber ich hab jetzt mal ne Lösung gefunden... ich darf nicht vergessen, die EQs auszumachen, um eine zusätzliche Aufnahme zwischen drin zu machen.
Ja... 32 war auch arg klein (vor allem für ein MIDI-Keyboard), habe es auf 128 gesetzt.

 

[Signalschwarz]

Das "LP" in der Bezeichnung des von dir verwendeten EQs steht sehr wahrscheinlich für "Linear Phase", das ist ein Modus bei EQs der häufig zu hohen Verzögerungen in einem Plugin führt. Dazu dann noch die Analyse-Funktion. Da kommt es dann sehr auf die Qualität der Programmierung des Plugins an. Ich nutze den iZotope Ozone-EQ und den FabFilter ProQ2 meist für technisches EQing und dann in der Regel auch im LP-Modus, CPU-Last und Plugin Delay ist vernachlässigbar.

Dynamikprozessoren haben meistens ein Plugin Delay, um die Lookahead-Funktion auf dem (internen) Detektorweg realisieren zu können.

Das Bussystem meint bei mir, den Signalweg von Festplatte zu CPU zu Audio-Hardware. Ein Signal geht häufig mehrfach hin und her, je komplexer das Routing/die Signalführung innerhalb der DAW-Software, desto aufwändiger auch der Transport der Daten auf, vereinfacht gesagt, dem Motherboard. Deswegen ist es wichtig bei der Konfiguration der DAW-Hardware nicht nur auf CPU und RAM zu schielen, sondern ein leistungsfähiges Motherboard bzw. den darauf verbauten Bus Controller zu wählen.

Ich nutze eine wohl recht ungewöhnliche und aufwändige (dafür aber auch sehr flexible) Mixing-Methode was Gruppen/Busse angeht, da erzeugt das Routing für sich genommen schon eine gewisse Grundlast beim System, aber der Rechner kam bisher noch nicht an seine Leistunggrenze bei Spuren und Bussen im unteren dreistelligen Bereich. Ich hatte mich vor der Zusammenstellung der Hardware aber auch bei Kollegen informiert was bei denen gut funktioniert, Glück spielt wie so häufig aber auch eine Rolle.

 

[Shino]

ok, danke für die Erklärung!
Ich hab, so viel ich weiß das Z170 HD3P von Gigabyte als Mainboard.
CPU ist i7 6700K
und SSDs als Platten

Hätte jetzt aber nicht so viel Lust das Mainboard zu wechseln

 

[Signalschwarz]

Über den Chipsatz auf dem von dir verwendeten Motherboard kann ich dir leider nichts sagen, ich bin schon immer auf AMD-basierten Systemen unterwegs.

 

[Shino]

ok, aber ich kann mir nicht vorstellen, dass er besonders schlecht ist.
Aber ich werd mich mal auf den aktuellen Stand bringen, was Hardware angeht (zumindest theoretisch erstmal), ist schon eine Weile her, als ich die Kiste zusammengestellt habe.
Ich hab mir ja mal überlegt beim nächsten Update einen leistungsfähigen Laptop anzuschaffen, aber das ist glaub nicht sonderlich realistisch (da ich noch Videobearbeitung mache), ohne im Bereich von ein paar Tausend Euro zu rutschen.

 

[Signalschwarz]

"Besonders schlecht" sehr wahrscheinlich nicht, es geht um kleine Details, z.B. welche Schnittstellen und Onboard-Funktionen sich Ressourcen teilen.

 

[Shino]

ok, da muss ich bei Gelegenheit mich mehr informieren, aber danke.