ASIO Crackles und CPU Hunger in CUBASE 6

Hallo,


In diesen Fall ist Cubase sehr wahrscheinlich nicht Schuldich.

System läuft auf 4400 Mhz ? Soweit ich weis laufen die normalerweise auf 3,4 Ghz mit noch einen Turbo bis 2,8 Ghz. Hast Du deinen FSB geändert ? Bitte nicht vergessen dass dann sämtliche andere Teilen wie z.B. PCI Anschluss dann auch hochgetacktet werden.

Des Weiteren hat der CPU Auslastung nichts mit die ASIO Auslastung zu tun:

Was zeigt das ASIO Meter an?

Das ASIO Meter zeigt an, wie viel Zeit verbraucht wurde, einen ASIO Puffer (Block) zu verarbeiten, der dann zur Ausgabe an die Audiohardware bzw. dessen Treiber weitergeleitet wird. Das ASIO Meter spiegelt NICHT 1:1 die CPU Auslastung wieder, denn das einzige zu erfüllende Kriterium ist die Sicherstellung, dass das „Audioprocessing“ des gerade bearbeiteten Blocks rechtzeitig stattgefunden hat, genauer gesagt beendet wurde, um den berechneten Block dann zur Ausgabe dem Audiohardwaretreiber zuzuführen. Das Meter zeigt das Verhältnis der verbrauchten Zeit gegenüber der maximal zur Verfügung stehenden Zeit an. Mit steigenden Anforderungen an das System durch mehr Spuren, Plugins, VST-Instrumente und komplexeren Routings, steigt natürlich auch die CPU Last, was sich dann im ASIO Meter dahingehend niederschlägt, das mehr Zeit zum “processen” verbraucht wird, die Anzeige im Meter also steigt. 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.

Welche Faktoren haben konkret Einfluss auf das ASIO Meter?

Es ist das Zusammenspiel der benutzen Computer-Hardware und dessen Leistung im Allgemeinen auf der einen Seite und auf der anderen Seite der Aufbau eines Projektes in Cubase bzw. Nuendo. Den größten Posten nehmen VST-Instrumente und VST Plugins ein, deren Anzahl macht sich am ehesten im ASIO Meter bemerkbar. Aber auch die Anzahl an Spuren und Bussen sowie deren Routings untereinander (z.B. über Gruppen und FX Kanäle oder auch Sidechains) erfordert zusätzliche Leistung. Programmfunktionen, die einen Teil mehr Grundlast erzeugen, sind der Control Room (je nach Komplexität der Einrichtung und Nutzung des Control Rooms sind hier sehr komplexe Routings möglich) sowie die Verwendung von ReWire.

Was zeigt die rote ASIO Meter Peak Anzeige?

Diese Anzeige informiert den User darüber, dass die Hostapplikation mehr Zeit zum Berechnen eines ASIO Puffers benötigte als, durch die Puffergröße bestimmt, Zeit gewesen wäre und der Puffer somit nicht an den Audiotreiber zur Ausgabe weiter gegeben werden konnte (klassischer Dropout) bzw. meldet der Treiber selbst der Hostapplikation, keine Daten bekommen zu haben. Ebenso kann die ASIO Meter Peak Anzeige aufleuchten, wenn ein Treiber signalisiert, nicht genug Zeit bekommen zu haben um Eingangsdaten (z.B. bei Audioaufnahmen) an die Applikation schicken zu können, bzw. die Applikation noch nicht bereit war, Daten zu empfangen. Diese Art der Dropout-Erkennung ist Teil vom Mac OS X Core Audio System und dessen eingebautem Audiocontroller.

Diese Dropouts müssen nicht immer hörbar sein, bzw. hängt es sehr vom Soundmaterial selbst ab, ob der Dropout hörbar war oder nicht. Einige Audiokarten/Treiber besitzen einen eigenen Sicherheitsbuffer um ASIO-Pufferverlust zu kompensieren, andere wiederum geben nötigenfalls den zuletzt empfangenen Puffer einfach noch mal aus. Auf der PC Windows Seite gibt es seitens des Treibers übrigens keine Methode, der Hostapplikation Pufferverlust mitzuteilen, daher wird dort diese Erkennung rein Host-seitig vorgenommen. Eine 100% sichere Erkennung ist dabei allerdings nicht zu erreichen. Dropouts kann mit dem Erhöhen der Latenz der Audiohardware entgegengewirkt werden.

Wie sieht es mit dem Verhältnis von Latenz, bestimmt durch die Puffergröße, zur Rechenleistung aus, auch im Hinblick auf die zunehmende Verbreitung von Mehrkern-Systemen?

Je kleiner die Latenz, desto weniger Zeit steht für die Berechnung eines Blockes zur Verfügung. Das ist keine neue Erkenntnis, sondern gültig seit es natives Processing gibt. Gelegentlich trifft man auf falsche Annahme, dass kleine Latenzen das System stärker belasten und es wird daraus der Umkehrschluss gemacht, dass mehr Rechenleistung (durch Verwendung von immer mehr Kernen) die Möglichkeit ergibt, mit immer kleineren Latenzen arbeiten zu können. Das stimmt so nicht!

Es kommt hinzu, das es bei der momentan vorherrschenden Mehrkernarchitektur nicht so ist, dass eine Verdoppelung der Kerne automatisch eine Verdoppelung der verfügbaren Rechenleistung bedeutet, bzw. dazu benutzt werden könnte, mit nur noch z.B. halbierten Latenzzeiten zu arbeiten. Die Leistungskurve steigt mit jeder Kernverdoppelung nicht linear sondern flacht zunehmend ab und kann bei sehr kleinen Latenzen sogar wieder fallen. Das hängt unter anderem damit zusammen, dass das Synchronisieren der einzelnen Kerne zum Abarbeiten der verschiedenen, gleichzeitig laufenden Threads in einem Programm „Overheads“ erzeugt, also zusätzliche Rechenleistung beansprucht. Je mehr Kerne im Spiel sind, desto mehr Abstimmung unter den Kernen ist notwendig, damit am Ende z.B. ein ASIO Block fertig berechnet und „rechtzeitig“ an den Audiotreiber zur Ausgabe übergegeben werden kann.