Cubase = schlechtere ASIO Performance als Ableton und Bitwig

[CFR]

Das Alter von Programmteilen sagt erstmal gar nichts aus.

Bei einem Reverb aus dem Jahre 2003 vielleicht nicht.
Inzwischen sind aber doch ganz andere Prozessoren, RAM und Mainboards im Einsatz.
Und dahingehend hat Steinberg sich angepasst.
Alter.

 

[Nachhall]

Nein, sicher nicht, aber es würde besser gehen... Wenn man wollte...

Naja Quicksort ist halt auch nach 63 Jahren noch Quicksort.

 

[Nachhall]

Inzwischen sind aber doch ganz andere Prozessoren, RAM und Mainboards im Einsatz.
Und dahingehend hat Steinberg sich angepasst.

Auch wenn pwrusr sonst nur Müll schreibt, sind die Kernfunktionen in Cubase schon noch dieselben wie in Versionen von vor 20 Jahren.

Und in Maschinensprache programmieren die ja nun seit Amigazeiten auch nicht mehr, so dass die Architektur darunter eher egal ist.

 

[CFR]

Auch wenn pwrusr sonst nur Müll schreibt, sind die Kernfunktionen in Cubase schon noch dieselben wie in Versionen von vor 20 Jahren.

Betriebsysteme ändern sich doch auch über die Jahre.
Da gabs doch auch immer wieder trara.
Aber im Grunde sollte sich bei einer Sound Engine tatsächlich , im Kern, wenig ändern.

 

[synthpark]

Auch wenn pwrusr sonst nur Müll schreibt, sind die Kernfunktionen in Cubase schon noch dieselben wie in Versionen von vor 20 Jahren.

Und in Maschinensprache programmieren die ja nun seit Amigazeiten auch nicht mehr, so dass die Architektur darunter eher egal ist.

Es macht aber z.B. schon einen Unterschied, ob man in C relativ maschinennah und absturzgefährdet (nur bei Bugs) oder in C++ mit Smartpointern programmiert, weil man keine Eier in der Hose hat.

 

[Nachhall]

Betriebsysteme ändern doch auch über die Jahre.
Da gabs doch auch immer wieder trara.

Der Befehl zum öffnen einer Datei in Windows ist zum Beispiel seit Windows 3.1 derselbe. Es ändert sich nur das dahinter liegende Dialogfenster, aber das wird eben nur vom eigenen Programm aufgerufen und nicht selber programmiert.

Natürlich gibt es auch viele Dinge die komplett neu gemacht wurden, aber vieles ist halt auch noch nach 20 Jahren identischer Quellcode.

 

[Nachhall]

Es macht aber z.B. schon einen Unterschied, ob man in C relativ maschinennah und absturzgefährdet (nur bei Bugs) oder in C++ mit Smartpointern programmiert, weil man keine Eier in der Hose hat.

Wer programmiert denn noch in C? Und C++ gibts auch schon länger als Cubase.
1978...sie es ein, du wirst zu alt für den Scheiss. Unsere Zeit ist um

 

[CFR]

Habe einfach mal gegoogled.
Da hat sich doch was abgespielt:

An optional 64-bit floating-point mixing engine was added in Cubase 9.5. PG, the main developer of Wavelab, listed the pros and cons in this post:
https://forums.steinberg.net/t/32-bit-or-64-bit/98651/23 14
The effect of this is extremely subtle, so it’s mostly for peace of mind and for a possible small performance increase.
Cubase 10 introduced the ability to handle and record audio files in 32-bit integer and 64-bit float. This is useful if you’re using an interface that supports 32-bit audio such as Steinberg’s UR24C.
There have been other changes that aren’t directly part of the “engine”, if you want to be technical, but may affect your end results. For example, Cubase now has some of the best sample rate conversion in the DAW market (great if you’re using imported samples and loops), and the Sampler Track now lets you increase the quality of its pitch shifting algorithm. Furthermore, the AudioWarp tools and VariAudio are constantly being improved upon.

What is Cubase 12 Sound Engine

Well they do change it over time as new technology & capabilities become available. Kind of like saying this years Honda has better acceleration than last years.

forums.steinberg.net

 

[synthpark]

Wer programmiert denn noch in C? Und C++ gibts auch schon länger als Cubase.
1978...sie es ein, du wirst zu alt für den Scheiss. Unsere Zeit ist um

Genug Leute, wenn es um Echtzeitperformance geht. Im Embedded-Bereich sowieso.

Dann gibts natürlich Leute, die schreiben gern plattformübergreifenden Qt Schwuchtelcode, zum Beispiel für ein Display, wo die Ausgabe nachher bis zum Erbrechen lahm wird. Wär mit C und direkter Hardware-Ansteuerung nicht passiert. Jedem das seine.

 

[CFR]

Wer programmiert denn noch in C?

Ist eben immer noch sehr effektiv, da näher an Maschinencode.

 

[Kwaku]

Laut den Kommentaren eines Ex-Mitglieds dieses Forums (ihr wisst schon wen ich meine, fängt mit rk an) wurde sie gesamte Audio Engine vor einigen Jahren grundüberholt bzw neu programmiert.
Der Typ kannte sich extrem gut mit CB und Nuendo aus.

Er kannte sich aus? Ich bin hier noch nicht so lange angemeldet aber ich habe ihn mehr als einen mittel autoritären Cubasegroupie empfunden. Aber wenn er Recht hatte, dann freue ich mich selbstverständlich, dass Steinberg sich diese Mühe macht grundlegendes zu erneuern, anstatt immer nur neue Features drauf zu klatschen, bis es zu einem Code Monstrum angewachsen ist. Die nächste Frage wäre dann, woher hat er diese Information? Ist es aus einer offiziellen Quelle oder Insider Info? Arbeitet er bei Steinberg? Hat er Einsicht auf den Cubase Code? Im Steinberg Forum lese ich nie. Wenn dann nur auf der Steinberg Website unter "neue Features"

 

[CFR]

Er kannte sich aus?

Mit CB und Nuendo, ja.

Die nächste Frage wäre dann, woher hat er diese Information?

Offizielle Quelle.

Arbeitet er bei Steinberg?

Hat er mehrfach glaubhaft verneint.

Im Steinberg Forum lese ich nie.

@Kwaku​

Ich hoffe, dass ich in unserem Forum nie wieder was von dir lesen muss.

 

[Gelöschtes Mitglied 92547]

Genug Leute, wenn es um Echtzeitperformance geht. Im Embedded-Bereich sowieso.

Dann gibts natürlich Leute, die schreiben gern plattformübergreifenden Qt Schwuchtelcode, zum Beispiel für ein Display, wo die Ausgabe nachher bis zum Erbrechen lahm wird. Wär mit C und direkter Hardware-Ansteuerung nicht passiert. Jedem das seine.

Nicht dass ich mich da wirklich auf eine Diskussion drüber einlassen will, aber du weisst schon dass qT ein UI Framework ist? Und der ist eigentlich recht performant. Wenn da dann was lahmt hat der Entwickler was falsch verkabelt. C und direkte Hardwareansteuerung ist eine komplett andere Baustelle, und hat mit der UI erst mal überhaupt nichts zu tun. Zumindest nicht wenn man UI Code vom Core Code trennt wie es sich gehört. Die UI sind die Knöppken auf die man drückt damit das Zeug unter der Haube das Arbeiten anfängt.

 

[Kwaku]

CFR = Zweitaccount von rd2k

Petze-Button wird ausgelöst in 3, 2, 1

 

[BodoH]

Ich bin hier noch nicht so lange angemeldet aber ich habe ihn mehr als einen mittel autoritären Cubasegroupie empfunden.

Mit Wahnvorstellungen. Was hat der mich nicht genervt, ich sei ein anderer User, ein Gesperrter.
Und dazu sein autoritäres DAW Bashing, nur Cubase sei das Beste, so als hätte er den Programmcode persönlich geschrieben.
Ob der nun Ahnung hatte, oder nicht, rein menschlich war er ein Totalausfall. Überall und zu allem musste der seinen Senf dazugeben und tat immer so, als seien seine geistigen Ausfälle irgendwie lustig. Zum Glück sahen das wohl die Admins ähnlich und haben ihn gesperrt. Jetzt empfinde ich es hier im Forum deutlich angenehmer!

 

[John_Lennon]

Auf die Gefahr hin, dass ich mich wiederhole und lächerlich mache:
Steinberg rät dringend das System (Win) auf Priorität "Hintergrunddienste" zu betreiben.
Hat bei mir einen grossen Performance-Schub erzeugt:

https://recording.de/threads/ich-werde-wahnsinnig-wegen-meinem-laptop.250895/#post-3122465

Probierts mal aus, wenn noch nicht geschehen.

Was auch immer deine Probleme gelöst hat, diese Einstellung war es sicher nicht.

Jener Tipp wurde von Pete Brown (einem Microsoft Entwickler) schon entsprechend kommentiert. Pete hat auf sehr höfliche Art die Aussagen als Bullshit einsortiert.

Alles, wirklich alles, was auf deinem Rechner mit Audio und MIDI zu tun hat, ist ein Vordergrundprozess, auch der Audio-/ASIO-Prozess. Wenn du die Task-Scheduler-Priorität auf "Hintergrunddienste" setzt, machst du genau das Gegenteil von dem, was du erreichen wolltest.

Hintergrunddienste wären z.B. Datenbank- oder Webserver. Wenn Du einen Mediaserver auf deinem Rechner laufen hast, der Smartphones, Tablets oder TV-Streaming in deiner Wohnung versorgt, dann wäre das so etwas. Und mit deiner Einstellung verlagerst du die Priorität darauf und von Cubase WEG.

Hat man sowas nicht, dann macht diese Einstellung schlicht gar nichts, denn die Ressourcenverlagerung ist dann eher theoretisch. Wenn kein Hintergrundtask da ist, kann auch nix priorisiert werden, aber dann macht die Einstellung halt einfach nichts.

Das war mal eine sinnvolle Optimierung unter Windows XP, weil da der Scheduler und das Klassenmodell noch anders war. Da war der Audiothread tatsächlich ein Hintergrund-Thread und da konnte das ein bisschen Perfromance bringen. Aber das ist über 20 Jahre her.

Hier mal Petes Liste mit Dingen, die man NICHT optimieren sollte und die ist deutlich länger als die Liste der tatsächlich hilfreichen Maßnahmen:

https://devblogs.microsoft.com/wind...dio-workstation-build-and-tweak-guide-part-3/

Steinberg empfiehlt an anderer Stelle auch, die E-Cores zu deaktivieren, mit dem Argument, der Audio-Thread würde als "Hintergrund-Thread" sonst am Ende dort landen. Für Windows 10, dessen Task-Scheduler noch nichts von der P-/E-Core-Architektur von Intel weiß, mag das sogar einen gewissen Sinn haben. Bei Windows 11 ist das aber auch auch Bullshit, denn der Audio-Thread ist eben KEIN Hintergrund-Thread und als Vordergrund Task mit hoher Priority landet der IMMER auf einem P-Core. Unter Windows 11 die E-Cores zu deaktivieren bringt nur Einbußen, weil man einen großen Teil der CPU-Ressourcen schlicht lahmlegt.

 

[synthpark]

Nicht dass ich mich da wirklich auf eine Diskussion drüber einlassen will, aber du weisst schon dass qT ein UI Framework ist? Und der ist eigentlich recht performant. Wenn da dann was lahmt hat der Entwickler was falsch verkabelt. C und direkte Hardwareansteuerung ist eine komplett andere Baustelle, und hat mit der UI erst mal überhaupt nichts zu tun. Zumindest nicht wenn man UI Code vom Core Code trennt wie es sich gehört. Die UI sind die Knöppken auf die man drückt damit das Zeug unter der Haube das Arbeiten anfängt.

Wenn ein Team einen Display Driver mit Qt/Linux implementiert und alles läuft verzögert, wer ist dann Schuld?
C und direkte Ansteuerung der Hadrwarecomponenten ist der steinige Weg, aber mit Sicherheit mit dem schnelleren Endresultat.

 

[Gelöschtes Mitglied 92547]

Wenn ein Team einen Display Driver mit Qt/Linux implementiert und alles läuft verzögert, wer ist dann Schuld?
C und direkte Ansteuerung der Hadrwarecomponenten ist der steinige Weg, aber mit Sicherheit mit dem schnelleren Endresultat.

Du mischst hier Äpfel mit Birnen. qT ist ein Framework, C eine Sprache. Und Linux ist wieder eine andere Baustelle. Das ist ein OS, keine Programmiersprache.

Aber ich will hier nicht klugscheissen, und wie gesagt will ich da nicht wirklich drüber diskutieren. Wie die das implementiert haben weiss ich eh nicht. Ich merke nur an

 

[ranzman]

wenn ich @John_Lennon & Pete Brown richtig verstehe, ist es für Win10 und älter doch zumindest mal testenswert, ob diese Hintergrundeinstellung etwas bringt.

Ansonsten kann ich nach Lektüre der Beiträge nur empfehlen: schneller arbeiten und das Material effekttiver nutzen.

 

[synthpark]

Du mischst hier Äpfel mit Birnen. qT ist ein Framework, C eine Sprache. Und Linux ist wieder eine andere Baustelle. Das ist ein OS, keine Programmiersprache.

Nee ist das wirklich so?!
Es geht um das Zusammenspiel, und Qt ist für C++ausgelegt. Es sind moderne Programmiererkonventionen, und Linux kommt im Embeddedbereich regelmäßig zum Einsatz. Die benutzen den Qt/Linux-Ansatz, weil gewisse Treiber schon mit an Bord sind, die sie dann selbst nicht machen müssen.