[Gelöst] 7.0.5: Performance-Meter am Anschlag

Ich hab mich überwunden, mal einen Mix in C7 zu probieren … scheint keine sehr gute Entscheidung gewesen zu sein, denn ich stoße auf echte Probleme.

Ich habe ne ganze Menge aber ausschließlich Audiospuren im Projekt (und klar, ne ganze Menge Insert-Plugins) und nach einiger Zeit - mal nach 10 Minuten, mal nach 20, wie er gerade Lust hat - entstehen immer mehr Peaks und der Sound “zerbröselt” langsam. Zum Schluss steht die Auslastung dann auf 100% und nix geht mehr. Muss den Song neu laden, dann geht alles wieder von vorne los.

Einzige Besonderheit des Projekts: es hat eine Tempospur. Darüber gibt´s einen Thread im engl. Forum:
http://www.steinberg.net/forum/viewtopic.php?f=184&t=45885
Es ist mir aber zu anstrengend mit dem englisch :wink:, deshalb hier mal die Frage, ob jemand ebenfalls auf ein ähnliches Problem gestoßen ist.

Was ich versucht habe:

  1. Alle Präferenzen gelöscht - kein Unterschied (außer vertane Zeit)
  2. Buffer von 512 auf 1024 erhöht. Das hat ein bisschen gebracht - dauert ein wenig länger, bis er abk…ckt.
  3. Alle anderen Einstellungen scheinen nix zu verändern (ASIO-Guard etc).
  4. Die Aktivierung der Option für die “besondere Steinberg-Optimierung” (hab gerade vergessen, wie sie genau heißt), bewirkte gestern das komplette Einfrieren des Rechners - so was hab ich noch nie gehabt.

Unter 5.5. und 6.5 sind mir diese Probleme nie untergekommen - schon gar nicht in einem Mix mit Audio-only!
overload.PNG

Ich kann dies bestätigen, auch als Bugreport bei Steinberg eingereicht, mittels TeamView Session nachprüfen lassen.

Aussage bis dato: “Third Party Plugins sind das Problem”.


Je mehr ich jedoch davon lese, desto mehr denke ich, dass es ein viel größeres Problem ist. Besonders wenn es so viele Steinberg User haben. Zeigt mir, dass ich nicht verrückt bin und mir was einbilde.

BTW: Ich benutze eine RME HDSPe/Digiface Kombo, ich bin sogar soweit gegangen, sämtliche Hardware Firmware Seitig zu aktualisieren, den Rechner zu plätten und sogar zu Übertakten(!) um den Problem einermaßen Herr zu werden.


Steinberg… sagt uns bitte das da was Faul ist und das dies umgehend behoben wird. Das kann keine Einbildung mehr sein.

Danke für die Rückmeldung. Diese Steinberg-Aussage ist ja wahnsinnig konkret - und ich glaube nicht dran.

Bei so vielen Usern wie ich sehe, die genau das gleiche Problem posten… ich auch nicht mehr.

Also, ich kann das Projekt ja (gottseidank) auch in 6.5 öffnen - und da hab ich nicht ein einziges Mal einen CPU-Peak, auch nicht nach längerer Zeit.

Und nebenbei fällt mir gerade wieder auf, wieviel übersichtlicher die Inserts sind: Einmal ist die Beschriftung viel besser lesbar und zweitens fiel mir sofort ins Auge, dass ich im C7-Mixer viele Plugins nur deaktiviert, aber nicht ausgeschaltet hatte (was ja zu einem erheblichen Performance-Killer werden kann) - eben weil´s dort a) nicht wirklich auffällt und b) weil ja sowieso der Deaktivierungsschalter fehlt.

Außer dem, wie hier im Forum anderswo schon angemerkt wurde, ist die Kanaltrennung 10mal besser gelöst.

Ich glaub, ich muss Abbitte tun: Nach längerem Geteste hab ich´s rausgefunden: der Buhmann ist tatsächlich nicht Cubase, sondern:

ROB PAPEN RP-DELAY

Das Teil macht irgendwann Zicken - nicht immer, aber immer öfter. Und zwar in der Regel, wenn man in Teilen loopt, die Tempo-Änderungen beinhalten.

Schade, dass Steinberg keine “richtige” Knowledge Base hat. Dann könnten sie das nämlich darin aufnehmen und sich so sehr schnell vom Vorwurf eigener fehlerhafter Software befreien. Aber bitte …

Ach bitte… ein weiteres Plugin das “angeblich” Denormal Issues hat (was eindeutig danach aussieht)?

Wie viele 3rd Party Developer, besonders solche wie Rob Papen die bei Steinberg gefeatured sind, sollen das bitte haben seit Cubase 7?

Sorry, aber da stimmt was nicht. Und zwar unter Garantie.
Könnte es nicht doch mit der neuen ASIO Version und VST3.5 zu tun haben, welches Cubsase 7 benutzt?


Ich lese (und habe selbst) so viele Probleme mit Cubase 7 in diesem Zusammenhang, und immer sollen es die 3rd Party Developer sein? Bitte… :unamused:

Nein. Ich würde auch stark behaupten, dass gerade Dritthersteller-Plugins sehr viel Ärger machen (können!) in Cubase. (C7 scheint gar etwas anfälliger?)
Ich habe diese o.g. Sache auf mehreren Rechnern (Win7, OSX, 32/64 Bit getestet), mit > internen Plugins gab es hier jedenfalls so keinerlei Fehler, alles lief (zumindest in dieser Konfiguration) sehr smooth und korrekt, wie es sein soll. Es waren große Test-Projekte mit vielen Audio- und Vsti- Sachen und Effekten ferner Automationswirrwarr. Denke daher, wir haben in C7 andere Dinge, die uns Sorgen bereiten, aber das würde ich so jetzt mal ausschließen.

Könnte es nicht doch mit der neuen ASIO Version und VST3.5 zu tun haben, welches Cubsase 7 benutzt?
Ich lese (und habe selbst) so viele Probleme mit Cubase 7 in diesem Zusammenhang, und immer sollen es die 3rd Party Developer sein?

@Studiopontifex: Durchaus, ja! Zumal es ja auch kaum (keine!) VST 3.5er Plugins von Drittherstellern gibt, aktuell (!)

Zum allg. Asio-Handling/Asio-Guard gibt es hier weitere interessante Infos:
https://www.steinberg.net/de/support/knowledgebase_new/show_details/kb_show/details-on-asio-guard-in-cubase-and-nuendo.html

Da würde ich eher den Übeltäter einkreisen. Und wenn es letztendlich der User ist. Kann ja auch mal sein.
:wink:

Das Problem mit dem ASIO Guard ist einfach, das dieser nur sehr eingeschränkt funktioniert. Ein weiteres Beispiel (was in der Cubase Help Datei steht), dass der Guard mit Plugins nur funktioniert, wenn die Plugins die gleiche Bit Variante wie das Betriebssystem und auch der Host haben.

32bit Plugins in einem 32bit Host, aber auf einem 64bit OS werden niemals von dem ASIO Guard profitieren können. 32bit Plugins gebridged in einem x64 Host auch nicht. Das schon mal zum einen.


Was mich aber so maßlos stört, und das habe ich bereits mehrmals deutlich gegenüber dem Support geäußert, ist die Aussage das “Steinberg keine Probleme hat”, und es immer an den 3rd Party Developern liegt. Nun ist es aber so, das 99% der Steinberg User einfach mal 3rd Party Plugins benutzen. Und das seit Jahren/Jahrzehnten.

Seit Cubase 7 scheint es jedoch Sand im Getriebe, oder einen Schraubenschlüssel in selbigen zu geben. Warum, weiß nur der Spaghetti Gott. Aber ich bin z.B. Beta Tester für diverse Firmen. Und ich höre nur negative Kommentare wenn es um integration mit Steinberg Produkten geht. Und ja, die Programmierer sind durch die Bank mittlerweile alle auf dem VST3.5 SDK.



Um dieser ganzen Problematik gegen zu steuern, habe ich mittlerweile meinen Rechner um mehrre 100MHz übertaktet, mein Betriebssystem geplättet und neu aufgezogen (auf Wunsch vom Steinberg Support), bin im Moment dabei komplett(!) auf x64 um zu steigen (was bei manchen Plugins nicht möglich ist), benutze höhere ASIO Puffer (1024? hallo?! RME, eine der besten ASIO Karten! Warum?) und bin in permanenten Kontakt mit den Firmen für die ich Beta-Teste, oder von denen ich hoffe, irgendwann mal x64 Plugins zu sehen.

Das Endresultat ist noch immer… Performance-Meter am Anschlag (und das mit teiweise sehr wenigen Tools). Und die einzigen Aussagen die ich bekomme vom Support, und das ist kein Geheimnis, ist: “an uns liegt es nicht, wir können dies auch nicht nachvollziehen”.

Eine Menge anderer User kann dies aber. Besonders im Direktvergleich mit einer Vorgängerversion (Beispiel Cubase 6.0/6.5 auf Cubase 7). Ein Abstellen des ASIO Guards macht es teilweise sogar noch schlimmer.


Auch die Aussage, dass der neue Channel Strip in der MixConsole einfach mal mehr Rechenpower braucht, kann ich pertou nicht nachvollziehen. Wenn ich KEINES dieser Plugins oder Modi benutze, sollte keine Last angezeigt oder gar benutzt werden. Deswegen z.B. auch mein FR im Englischen Board, dass man den EQ FFT endlich abstellen kann!



Ich bin immer noch der Meinung, das neue ASIO System und das VST3.5 Modul hat massive Probleme. Und die werden schlichtweg seit den Bug Reports mit C7.0 ignoriert - oder Steinberg hat den Fehler noch nicht gefunden um dies ab zu stellen.

Ich hoffe jedoch nicht, dass dies zu 7.5 (bezahlt!) geschehen wird. Denn nicht nur müssen wir dann für einen Bugfix bezahlen, der seit Anfang an hätte behoben werden können (Cubase 7 ist seit Ende letzten/anfang diesen Jarhes raus, wir haben mittlerweile August!). Nein, vereinzelt sind auch einige von uns dazu gezwungen(!) Hardware Seitig auf zu rüsten - eben um dieses Problem zu kaschieren.



Wie gesagt, ich glaube nicht mehr daran, dass es immer an den Drittanbietern liegt. Und ich habe mir Cubase nicht gekauft (auch schon damals nicht), damit ich “nur” Cubase interne Tools benutze.

Finde ich echt nicht okay so.



EDIT:
StudioPontifex - interessanter Name. “Brückenbau Studio” (pons („Brücke“) / facere („machen“) )
Vielleicht ändere ich doch noch meinen Studio Namen, irgendwie gefällt der mir. :mrgreen:

Fox, ich kann deinen Ärger schon verstehen. Wir wollen ja alle nur Musik machen und nicht Beta-testen. Bei solchen Problemen geht haufenweise Zeit verloren und man kommt überhaupt nicht zu dem, was man eigentlich will - besonders, wenn man versucht, die Sache nachvollziehbar zu dokumentieren. Und irgendwie hat man den Eindruck. dass man dann von Steinberg grundsätzlich abgebügelt wird, dabei sollten sie doch froh sein, dass man sich diese Mühe macht.

“Sand im Getriebe” ist bei C7 in jedem Fall und deshalb werde ich für die Hauptarbeit auch bis auf Weiteres bei 6.5 bleiben. Da hatte ich aber übrigens bei Songs mit Tempowechseln ebenfalls seltsame Phänomene mit Delays, nur nicht in diesem Ausmaß.

:wink:
@Studio:
Freut mich sehr, dass du Humor hast, und es verstanden hast. :slight_smile:
Nun, ich sehe vieles leider deutlich positiver als du - das muss ich zugeben.
Auch wenn ich einige deiner angesprochenen Punkte teile, keine Frage.

Zwar offtopic, aber fällt mir gerade ein: die Suchfunktionen in der MixConsole sind einfach geil. Sowohl für Spuren als auch für Plugins, das ist echt ein Bringer für mich.

  • 1 !
    Und würde man die gesamte Zeit eines herkömmlichen DAW-Gesuches (nach Spuren, Kanäle, Presets usw.) zusammen mal addieren, da würde schon echt was Ungeheuerliches bei rauskommen…
    Ergo: die neuen Suchfunktionen in Cubase 7.x sind echte Workflow-Verbesserungen!
    (will ich auch nicht mehr missen!)
    :slight_smile:

Und auch die einzig gute “Verbesserung” was VST3 Plugin Handling anbelangt. Wobei ich das Sortier-Verhalten von Wavelab 8 in Cubase 7 sehr gerne sehen würde.


Aber zurück zum Topic:
Ich hab noch mal im US Forum herum gestöbert. Das Problem ist nicht nur bei VSTi, das ist auch bei VST. Es wurde mehrmals angesprochen. Viele User haben (auf Bitte!) ihre Hardware aktualisiert (Firmware), ihre Rechner geplättet und neu Installiert (das war auch ein Kriterium bei mir um Support zu bekommen!), Hardware seitig aufgerüstet, Tagelang Testreihen gestartet und an Einstellungen herum gebastelt.

Endresultat: immer noch diese Probleme.


Wo(?!) ist der Schraubenschlüssel im Getriebe?
Wie viele(?!!!) User müssen noch schreiben mit dem gleichen Fehlerbild?

Es kann doch echt nicht nur an uns Usern und unseren Plugins liegen.

Mann, das hört sich ja gräuslich an. Ich mag jetzt gar nicht mehr was probieren mit VSTi´s …

Also. Moment!
ich würd mal zuallererst mal nicht gleich in Panik verfallen - das klingt hier nämlich langsam nach forcierter Panikmache… :unamused:

@Uni: ich dachte, bei dir ist wieder alles ok? was ist los?

Das ist leider keine “forcierte” Panikmache, das ist trauriger Fakt.

In meinem Fall habe ich Probleme mit VST Plugins, wie oben geschildert. Nur bei mir ist es nicht Rob Papen, bei mir ist es mit Slate Digital, Variety of Sound, IKMultimedia und noch ein zwei anderen Developern. Bei VST2 scheint es immer in einen sogenannten “Denormal Bug” zu resultieren (was ein Dev bestätigen konnte, andere nicht), bei VST3 in unkontrolliert hohen ASIO Lasten (obwohl kein Oversampling vorhanden ist).

Der Support bat mich damals erst alle Treiber zu aktualisieren, dann Firmeware updates zu fahren, letztendlich (weil ich so viele Probleme auf einmal hatte) meinen Rechner zu plätten. Dann machten wir noch eine TeamView Session und fanden heraus “das ist das Problem von Drittanbietern”. Und ich bin nicht der einzige, dem das so erging.

Meine einzige Lösung im Moment (und ich habe ein Equivalent zu einem iMac 11.3!!!), ist meine CPU zu übertakten, damit ich nicht so schnell in die bekannten Probleme gerate. Aber mit einem Puffer von 1024 Samples, bei einer RME HDSPe?! Ich bitte euch, mein Stamm-Pufer ist 256 Samples, andere RME User fahren sogar mit 64 samples auf einem i7 (älter Sandy/Ivy Bridge und Haswell). Ich bin auf kurz oder lang gezwungen Hardwareseitig auf zu rüsten.


Dieses Problem mit ASIO Meter am Anschlag, oder CPU Glitches, das VSTi nicht mehr funktionieren, etc… das dreht sich meiner Meinung nach alles um das ASIO Modul, oder dem VST3 SDK - vielleicht sogar beidem! Dies hier ist nur ein Thread, der die Thematik anspricht. Und was soll die ultimative Lösung sein? Plugin nicht benutzen, oder auf Updates warten vom Drittanbieter (was wenn aber der Fehler nicht bei diesem liegt?), alternativ hardwareseitig Aufrüsten oder auf C6.5 zurück?

Das kann so nicht sein. Das soll so nicht sein.


Nur mal ein kleiner Querschnitt an Problemen die sich überschneiden (im dt. Subforum finde ich leider nichts mehr, nur noch im US):
http://www.steinberg.net/forum/viewtopic.php?f=184&t=44388 (hier wurde auch das OS geplättet, sogar bei HDDs die Firmware aktualisiert)
http://www.steinberg.net/forum/viewtopic.php?f=184&t=45885 (hier wird von bugs mit der Timeline gesprochen, was Einfluss auf die ASIO Last hat)
http://www.steinberg.net/forum/viewtopic.php?f=184&t=45991 (hier spricht ein User von massiven ASIO Problemen, er verfolgt dies seit C7.0)
http://www.steinberg.net/forum/viewtopic.php?f=184&t=44986 (MIDI Probleme, die mit dem ASIO Guard zu tun haben)
http://www.steinberg.net/forum/viewtopic.php?f=196&t=46164&p=280163#p280163 (Probleme mit VSTi/Samplern - auf KVR wurde hier auch die Vermutung geäußert, dass das mit dem ASIO System zu tun hat, ASIO Guard ein/aus brachte keine Änderung)
http://www.steinberg.net/forum/viewtopic.php?f=181&t=38560 (auch dieses Problem beschreibt eine höhere ASIO Last im Vergleich zu älteren Cubase Versionen)


Dann gibt es noch reihenweise Posts auf KVR Audio und GearSlutz, die sehr gerne von Steinberg Mitarbeitern herunter gespielt wurden.


Es ist also keine Panikmache, da scheint irgendwo was gewaltig faul zu sein. Und bei so vielen Berichten (wie gesagt, das ist nur ein Querschnitt, ich kann nicht sagen wie viele Bug Reports beim Support eingehen, oder was in Fremd-Foren noch geschrieben wird), kann die Hauptaussage nicht sein:

“Updated eure Treiber/Firmware”, “Plättet eure PC’s”
oder aber
“das liegt nicht an uns, das liegt an den Drittanbietern”.

Ich verstehe irgendwo das Steinberg sich absichert und sagt “auf unseren System geht alles”, besonders wenn nur Cubase internes Material benutzt wird. Aber… wie bereits erwähnt, wir User benutzen UADs, PowerCore’s, Drittanbieter Plugins und Instrumente, Hardware(!). Cubase ist unsere Workstation, unsere Bandmaschine, unser Editor, der “Plugin-Chainer”. Die 3rd Party Devs sind darauf erpicht ihre Softwae immer auf dem laufenden Stand zu halten.

Doch wenn selbst danach noch die Probleme auftreten, und weiterhin der Finger auf jemand anderen gezeigt wird - dann stimmt da was nicht. Und bis dato sind diese Probleme auch nicht anerkannt worden seitens Steinberg.


Panikmache oder nicht - geht so einfach nicht. Sorry.

Also mir geht es wie Uni, ich habe genau dieses Verhalten, dass die ASIO Last einfach zu wacklig und wenig vorhersagbar ist. Heute läuft das Projekt stabil auf ca. 50%, morgen schaukelt es sich schnell auf 90% oder auch 100% hoch. Irgendwie ist da eine Zufalls-Komponente dabei. Ich konnte bisher Waldorf D-Pole und Kuassa Amplifikation One als problematische Plugins ausmachen. Diese bringen die ASIO Load häufig auf 90-100%.

Ich mag diese Zufallskomponente überhaupt nicht, und dieses Aufschaukeln. Die ASIO Last sollte stabil und reproduzierbar sein.

Wenn es wirklich so viele 3rd party Plugins mit Problemen gibt sollte man eine Code-Prüfung wie in den App-Stores von Google und Apple einführen. Steinberg prüft die Konformität der Plugins, so dass böse Überraschungen beim Kunden ausgeschlossen sind.

Nochmal zum Thema Denormal. Es gibt Gnormal (http://www.gvst.co.uk/gnormal.htm), damit kann man ein Signal einführen was Denormal verhindern soll. Hat bei Amplifikation One leider nix gebracht. Heisst das nun dass es KEIN Denormal Problem ist?

“Denormal” - immer mal was Neues, hab ich noch nie gehört. Hab dazu dies gefunden und werde es mal testweise dazwischenschalten: http://www.digitalfishphones.com/main.php?item=2&subItem=6
Wenn ich´s richtig verstehe, müsste man damit ja verifizieren können, ob RP-Delay diesen Bug hat.

@Cent: Ich hab noch nix “Größeres” mit C7 angefangen und die Aussagen hier machen mir echt Angst. Wie user123 schreibt, man will sich ja drauf verlassen können, auch mal voranzukommen und nicht wieder wie damals ständig mit irgendwelchen Problemen kämpfen. Ich erinnere mich noch an C4, als ich noch nen alten P4 hatte, der nach Steinbergs Aussagen angeblich ausreichen sollte … von wegen, das war einfach nur grausam alles.

Deswegen sage ich ja… wir User sind gezwungen hardwareseitig Aufzurüsten.

Wenn das aber auch auf Sandy und Ivy Bridge Rechnern passiert, nicht nur auf Bloomfield… dann wirds Kritisch und es ist mächtig was faul.

Und, es ist schon komisch das so viele Plugins auf einmal Denormal Issues (das unkontrollierte CPU/ASIO Verhalten) haben sollen.


Übrigens spreche ich mich gegen(!) ein Kontrol-Schemata wie bei dem Apple Store aus. Steinberg könnte somit dem Markt kontrollieren. Auch bei den guten Programmierern. Ich weise nur auf das momentane iLok/AVID Desaster hin, und warum AAX Plugins im Moment so verhasst bei Programmierern sind.