ASIO Überlast

[TinDD]

ASIO Last auf Anschlag => Dropouts. Obwohl RAM/CPU noch gar nicht ausgelastet sind.

Habe schon viel gegoogelt aber leider werde ich nicht schlau. Die ganzen Freds zu diesem Thema sind leider auch immer sowas von überfüllt mit Standardratschlägen (installier mal die neuesten Treiber des Audio-Interfaces, optimiere mal den Rechner für DAW Betrieb, usw.) Hab ich alles schon gemacht. Also ihr dürft davon ausgehen dass mein Rechner bereits bestmöglich optimiert ist. Aber wenn man immer noch einen Effekt oder ein Instrument obendrauf knallt kriegt man irgendwann jeden Rechner in die Knie so scheint es.

Die Frage ist nun, wie kann ich die ASIO Last senken? RAM und CPU sind nicht ausgelastet, also hilft Rechner aufrüsten nichts? Finde das total komisch, eigentlich muss doch ein schneller Rechner auch mehr Plugins schaffen?

Die Latenz des AudioInterfaces scheint relativ egal zu sein, habe viele verschiedene Werte ausprobiert, das ändert kaum was.

 

[Soundkraft]

Irgendwie zu wenig Infos...welches Interface...ab wieviel Spuren bzw mit welchen Plugins beginnt das Problem?
Generell könnte eine niedrigere Auflösung bzw Bitrate helfen...es sei denn natürlich du bist da eh schon tief angesiedelt.
Dann hilft vllt ein besseres (schnelleres) Interface...naja...Weiss man ja jetzt nicht weil du nixdazu geschrieben hast

Was die CPU leistet ist für ASIO doch ziemlich egal..solange sie halt nicht überlastet ist und somit der Treiber, der ja auch nur Sotware ist ins straucheln kommt. FInde ich eh schwierig in Mehrkernsystemen noch genau sagen zu können wo da welcher Kern da jetzt grade überlastet ist und wo dann ein weiterer dazugenommen wird. Kurze Spitzen kannst du im Taskmanager auch nicht unbedingt erkennen.

 

[TheRemix]

Moin!

Hier noch ein Standardratschlag: Hast Du schon mal den DPC Latency Checker laufen lassen? Der wird oft empfohlen, wenn es um ASIO Peaks geht.
Der kann dir zeigen wo es hakt.
Auf der Homepage gibt's noch die Erklärung, wie man Probleme erkennt und analysieren kann.

Das hilft jetzt nicht die ASIO-Last zu reduzieren, aber vielleicht läuft im Hintergrund ja noch irgendein Prozess, der Peaks im Datenstrom erzeugt und so Deine ASIO Anzeige in die Höhe treibt.

Gruß, TheRemix

 

[TinDD]

Also ich habe fast alles gemacht was in diesem Dokument steht:

http://www.native-instruments.com/k...mIzc3NjtyIGRpZSBBdWRpb3ZlcmFyYmVpdHVuZy5wZGY=

Also u.a. auch den DPC Check, der bei mir wunderbare grüne Ergebnisse liefert

Ich arbeite bei 24bit 96kHz, da möchte ich auch eigentlich bei bleiben. Obwohl sich vielleicht bei 48kHz die Situtation schon wieder entspannen würde?

Das Problem tritt auf wenn ich viel Zeug verwende

Also ich habe ein Projekt mit einer Instanz Philharmonik (>10 Instrumente), eine Instanz Independence Pro (10 Instrumente), einen externen Virus, dazu ein paar Audiospuren und noch einige Plugins auf den Kanälen.

Wenn ich die drei Plugins nacheinander einschalte geht die ASIO Last schrittweise von fast null auf fast voll. Die fressen also je ungefähr ein Drittel.

Wenn wenig los ist im Track ist die Wiedergabe noch ok. Aber an Stellen an denen viele viele Midinoten/Controllerdaten/Automation gespielt werden kommen dann massive Aussetzer / Stottern der Wiedergabe.

Wenn ich dann noch den Waves Maserati GRP auf der Summe einschalte wirds noch extremer. Dann klingts wie ein Trancegate, jeder zweite Buffer geht flöten

 

[TinDD]

PS: Interface ist MAudio FastTrackUltra8R, die Performance ist eigentlich extrem stabil und schnell.

 

[djbobo]

Je niedriger die Latenzzeit des Interface desto wahrscheinlicher ist ein Puffer-Unterlauf und das Ergebnis sind Aussetzer und Kratzgeräusche oder eben ein Overload.
Also entweder Load verringern oder Puffer vergrößern.

 

[TinDD]

Schrieb ich ja schon im Startpost, größere Buffersizes helfen nicht. Bin von 256 Samples auf 4096 Samples hochgegangen, hat nix genutzt. Unterhalb von 256 Samples wirds noch schlimmer, habe auch 128 und 64 probiert, aber 256 scheint hier der Optimalwert zu sein.

 

[Lacunaflow]

ASIO Last auf Anschlag => Dropouts. Obwohl RAM/CPU noch gar nicht ausgelastet sind.

Was zeigt das ASIO Meter an?
https://recording.de/Community/Userblogs/View/960/blog.html

 

[TinDD]

Sehr informativ, danke!

Aber wie ich jetzt mehr Leistung kriege weiss ich immer noch nicht.

"Wird mehr Zeit benötigt als, durch die Größe des ASIO Puffers bestimmt, benötigt werden darf, gibt es einen Dropout und es meldet sich dann die ASIO Meter Peak LED."

Heisst ja eigentlich, ich muss dafür sorgen dass die ganzen Plugins ihre Buffer schneller berechnen. Also bessere CPU. Oder?

Es ist halt komisch, die Festplatte ist idle, RAM und CPU sind nicht ausgelastet, und trotzdem werden die Puffer nicht schnell genug berechnet.

 

[Soundkraft]

"Wird mehr Zeit benötigt als, durch die Größe des ASIO Puffers bestimmt, benötigt werden darf, gibt es einen Dropout und es meldet sich dann die ASIO Meter Peak LED."



Heisst ja eigentlich, ich muss dafür sorgen dass die ganzen Plugins ihre Buffer schneller berechnen. Also bessere CPU. Oder?

Kann so ja nicht ganz stimmen, denn dann hinge die ASIO-Performance ja völlig von der CPU ab.Ausserdem würde dann ja eine Erhöhung des Buffersizes Abhilfe schaffen.
Vllt versuchst dus einfach mal mit 44.1 khz und schaust mal ob sich dadurch was ändert...wäre dann ja schon mal ein weiterer Ansatzpunkt.
Wichtig ist ja nicht allein dass die CPU wenig ausgelastet ist sondern dass der oder die Threads die mit dem Treiber zu tun haben genug Zeit bekommen.Bei WIndows gibts ne Option auf Hintergundprogramme (also auch Treiber) zu optimieren statt auf Anwenderprogramme...vllt hilfts ja was..ich stell mir das so vor ,dass in dem Multitaskingsystem die Zeitscheibe die der Treiber erhält irgendwie grösser werden musss...das kann man dadruch vllt erreichen. Vllt auch indem man Threadprioritäten erhöht...was aber dann schon eher theoretischer Natur ist,,,wer stellt schon dauernd an den Threadprioritäten rum.
Eine ander Idee: Feste ECHTE Kerne an die DAW bzw noch besser den Treiber zuweisen, um ein switchen in einen anderen Thread zu verhindern...im VIdeobereich hab ich damit schon gute Erfahrungen gemacht.
Es könnte auch sein, denke ich, dass du vllt auch etwas zuviel von deinem Rechner bzw Interface erwartest ...Independence mit Origami is glaub ich auch nicht grade resourcenschonend

Ps: Wie misst du eigentlich CPU- und Festplattenlast?

 

[TinDD]

Auf Hintergrunddienste optimiert habe ich auch schon.


Aber ich habe gerade mal einen Test gemacht, da kann irgendwas nicht stimmen. Ich mache Cubase auf, neues komplett leeres Projekt, PadShop laden, Sound "Daydream" laden, SustainPedal drücken und einmal über die Tastatur gewischt bis alle 16 Stimmen erreicht sind, und was passiert? ASIO Überlast! Das kann doch nicht sein? Mit einem einzigen Plugin? Hab mal ein Video davon gemacht, leider ohne Ton:

http://dl.dropbox.com/u/33470365/Video1.avi

 

[Soundkraft]

Das müsste mal jemand der auch CUbase und padshop hat rekonstruieren....ich vermute aber dass jede Note die ganze Zeit ja berechnte werden muss (ich entnehme dem Pluginnamen dass da reichlich prozessorintensive Pads laufen.) Das dürfte im Endeffekt auch nicht anders sein als 16 Instanzen mit Einzelnoten gleichzeitig.

 

[TinDD]

Ja das wär cool wenn das mal jemand testen könnte....

Ansonsten muss ich mir halt n neuen Rechner holen für mehr Power. Da würde mich weniger das Geld stören als dass dann wieder die ganze Installiererei und Aktiviererei und Lizensiererei losgeht.

 

[Soundkraft]

Da würde mich weniger das Geld stören als dass dann wieder die ganze Installiererei und Aktiviererei und Lizensiererei losgeht.

Weisst Bescheid ? ...Ich hoffe ja dass mein Rechner noch ne Weile mitmacht...der ist schon 3 Jahre alt...als ich noch gezockt habe war jedes Jahr ein neuer fällig....aber das kann man sich bei den Softwarepreisen ja nicht mehr leisten

Welche CPU hast du eigentlich? Ich mein...eben wasrt du doch noch überzeugt dass die nicht mal annähernd ausgelastet ist
Und andere Techniken (Freezen, Bouncen) kommen für dich nicht in betracht?Ich mein wenn du da 30 Spuren hast dann werden doch da wenigstens 10 oder so auch soweit fertig sein, dass du da nicht mehr gross dran musst.

Ich hatte ja auch mal so ein ähnliches Problem mit Reaper...aber viel extremer...neuinstallieren hat geholfen...kommt davon wenn man in den Einstellungen rumfummelt und sich nicht merkt wo

 

[TinDD]

Die CPU ist nicht bei 100%, aber ein schnellerer Rechner MUSS einfach mehr VST Zeug schaffen!

Das Ding ist zwei Jahre alt, ein AMD Athlon II X4 640 @ 3GHz.

Bouncen nervt mich, weil es dauert immer, und natürlich will ich dann später gerade an den Spuren wieder was ändern die ich vor 2 Minuten gebounct habe

[Edit: Ich habe noch eine Tonne sonstige Software auf dem Rechner, vielleicht ist das auch ein Problem. Keine Ahnung.]

 

[Soundkraft]

AMD Athlon II X4 640

http://www.cpubenchmark.net/cpu_lookup.php?cpu=AMD+Athlon+II+X4+640

Ich hätte gleich danach fragen sollen. OB das jetzt dein spezielles Probem lösen würde wenn du aufrüstest kann ich zwar nicht so ohne weiteres behaupten, aber wenn ich mir das Performanceranking da mal angucke wäre ganz generell eine Aufrüstung mal fällig
Und falls ja und wenn Geld nicht so ganz knapp ist , dann auch lieber was sehr schnelles, dass auch 3-5 JAhre halbwegs mithalten kann. ICh steh mit meinem 3 Jahre alten i 7 860 noch immer ganz gut da...mit Übertaktung wirds auch noch 2 weitere Jahre mitgehen

Ich nutze meine Rechner auch für alles mögliche...daher hab ich auch noch ne SOundblaster ( neben dem Focusrite VRM) als Standardaudiodevice...unter 256 Samples BUffer läuft da gar nix
DAs Focusrite spielt aber dasselbe mit 64 Samples Buffersize ab....daher mag ich nicht an die CPU als alleinverantworltliche glauben.

 

[TinDD]

Ach du liebe Güte, da muss ich wirklich über nen Rechnerkauf nachdenken glaube ich.

Das FastTrack ist aber nicht schuld denke ich. Wenn ich reine Audiospuren-Projekte habe läuft das FastTrack auch locker und geschmeidig mit 64 Samples.

Denke eher das Gespann Mainboard / CPU / GPU ist einfach noch mit dem sonstigen System-Gedöns beschäftigt so dass für Audio nicht mehr viel Performance bleibt? Keine Ahnung. Dass die CPU nicht bei 100% ist ist und bleibt merkwürdig.

 

[Soundkraft]

Keine Ahnung. Dass die CPU nicht bei 100% ist ist und bleibt merkwürdig.

Naja..wie oft wird die Lastanzeige aktualisiert? 2 mal pro Sekunde? Das ist kein aussagekräftiger Wert, wenn der Prozessor ein paar Millonen Befehle in der Sekunde abarbeitet
Wichtig ist ja nur der Kern (oder die Kerne) die grade mit dem Treiber beschaftigt sind...wenn da 2 zu 100% ausgelastet sind und der Rest nix tut haste ne Gesamtauslastung von 50%...wichtig sind aber nur die Kerne die grad mit deiner Audioanwendung beschäftigt sind. Ausserdem gibts ja evtl noch das eine oder andere Plugin dass nicht multitaskingtauglich ist und daher einen Kern komplett benötigt...ich nehme mal an du hast in Independence die Mehrkernnutzung auch eingeschaltet?

Schau mal im Taskmanager von Windos wie gleichmässig deine Kerne eigentlich ausgelastet sind während du dein Zeug abspielst.

Normalerweise würde ich auch die Festplatte in Betracht ziehen , weil das ja viele Samples gestreamt werden müssen...der Versuch mit Padshop spricht aber dagegen...oder ist das auch samplebasiert?

Wie gesagt..mein Rechner ist eigentlich von Hause aus ein Spielerechner und Virenscanner und "Gedöns" läuft auch bei mir ohne Probleme...nur Speedstep und EIST sind im Bios abgeschaltet....so wie bei dir hoffentlich Cool 'n Quiet.

Netzwerk soll ja auch Probleme machen können. DIe Sache ist: so ganz genau wirst du das erst wissen, wenn du den Rechner neu aufsetzt...da dir die Neuaktivierung der Software ein Graus ist könntest du dir aber ja auch gleich nen neuen Rechner zulegen und den von vornherein dann auch mal "sauber halten " und als reine Arbeitsmaschine für deine DAW betrachten.

Den jetzigen Rechner dann halt behalten für die alltäglichen Sachen....dafür isser wohl noch schnell genug

 

[TinDD]

Streaming findet kaum statt, die Samples passen alle ins RAM. Die Festplatte macht eigentlich nix während des Playbacks.

CoolNQuiet hatte ich testweise ausgeschaltet, bringt nichts, habe ich daher wieder eingeschaltet.

Multicore bei Indy ist auch aktiviert selbstverständlich.

Wichtig ist ja nur der Kern (oder die Kerne) die grade mit dem Treiber beschaftigt sind...wenn da 2 zu 100% ausgelastet sind und der Rest nix tut haste ne Gesamtauslastung von 50%...wichtig sind aber nur die Kerne die grad mit deiner Audioanwendung beschäftigt sind.

Das ist des Pudels Kern! Im Windows-Taskmanager kriege ich zwar vier Core Plots zu sehen, die zeigen aber alle das gleiche an, nämlich einen Mittelwert über alle 4 Cores. Und ich habe es jetzt mal getestet, ich kann Independence mit einem Piano und ordenlich SustainPedal gedrückt halten ebenfalls zur Überlast kriegen. Ich denke pro Instrument nimmt Indy nur einen Core und der ist irgendwann platt. Beim Padshop ist das genauso. Wenn ich die Spur freeze ist während des Bouncens die CPU bei etwas über 25%. Das heisst er nimmt genau einen Core um den PadShop zu berechnen.

Wenn ich also das volle Projekt abspiele und die CPU Last liegt bei 80%, dann ist das nur der Mittelwert, einer der Cores ist schon überlastet.

Endlich habe ich eine plausible Erklärung gefunden *freu*

 

[Soundkraft]

Endlich habe ich eine plausible Erklärung gefunden

dann könnte es ja was bringen, wenn du eher mehr Instanzen mit jeweils weniger Instrumenten beutzt und dann hoffen,, dass die Daw das intelligenter verteilt als die Plugins Ram ist ja anscheinend nicht so das Problem bei dir....achja...BS ist doch Windows 7 bei dir, oder? Falls du noch XP benutzt lässt sich auch von daher evtl noch ne Kleinigkeit rausholen, da Windows 7 schon intelligenter bei der Verteilung der Aufgaben ist...
Also mehr Kerne + mehr Takt würden dir auf jedenfall helfen...oder halt mehr Instanzen der Plugins in der DAW und hoffen dass das der Aufgabenverteilung zugute kommt..

Ps: wie ist das wenn du Independence standalone betreibst...bekommste dann ne bessere Performance als wenn du es als VSTI einbindest? Ich meine wenn die Multicoreoption wirklich ernst gemeint ist sollte es so sein und nur im Pluginbetrieb verhindert vllt die DAW, dass die Kerne gleichmässig benutzt werden,