Extreme Real Time Peaks mit neuem Skylake I7 8Kern

[whitealbum]

In Sachen Threads siehe hier:

https://helpcenter.steinberg.de/hc/...ws-10-Audio-Aussetzer-auf-Mehrkern-CPU-Setups

Der entsprechende Patch ist seitens des Users bereits eingespielt.

 

[Realist]

vermutlich https://www.da-x.de ?
Wenn nicht, dann ruhig die "Anderen" nennen, ich finde auch, dass die so nen Rechner mit der Wunsch DAW prüfen hätten MÜSSEN.

Jetzt Mutmassungen zu tätigen und Gerüchte zu streuen ist ziemlich daneben, finde ich.

 

[whitealbum]

Lassen wir mal den TE zu Wort kommen.
Wie siehts aus @hitproduzent ?

- Konntest Du das mit Firewire schon testen? (s. mein Post)

 

[Realist]

In Sachen Threads siehe hier:

https://helpcenter.steinberg.de/hc/...ws-10-Audio-Aussetzer-auf-Mehrkern-CPU-Setups

Der entsprechende Patch ist seitens des Users bereits eingespielt.

Bez. MMCSS bin auch gerade am Testen. Verstehe nur noch nicht so ganz den Sinn dahinter.
RME hat ja die Option wieder in die Treibern "eingebaut", nachdem sie kurzzeitig verschwunden war.
Ab Cubase 7, kann wohl Cubase auch damit umgehen.
https://www.forum.rme-audio.de/viewtopic.php?id=18255

 

[bluebell]

Sorry Leute aber jetzt mal ganz ehrlich .. selbst wenn der Laden "nur" die genannten Komponenten zusammengesteckt hätte (ich frag mich was die auch sonst machen sollten, aber gut) sollte es mit einer frischen Windows- und Cubaseinstallation trotzdem problemfrei laufen. Das ist ja richtig gute Hardware. Und vor allem: Mit Reaper klappt es doch einwandfrei ? Dann kann doch die Hardware nicht kaputt sein. Ich glaub eher es liegt an Cubase. Vielleicht kommt es mit so vielen Threads oder so viel (Quad-Channel-)Ram nicht zurecht ? Der i7 hat immerhin 16 Threads .. Wäre jedenfalls nicht das erste mal, dass Cubase bei einem normal funktionierenden System rumzickt, während andere DAWs keine Probleme haben ..

Ich kenne mich auf Windows nicht so aus, aber auf Linux würde ich eine Betriebssysteminstanz als VM starten und der weniger RAM und eine alte CPU vorspielen, um zu sehen, wie die DAW reagiert. Wenn man so nachstellen könnte, dass sie mit bestimmten Einstellungen sauber funktioniert und mit anderen nicht, wäre der Hersteller der DAW die erste Adresse für eine Nachfrage.

EDIT: Hat sich ja geklärt. Microsoft hat rumgebastelt und das System verkrüppelt, vermutlich um irgendwann eine Pro-Ultra-Super-Version von Windows10 ohne diese Beschränkung verkaufen zu können. Das Verkrüppeln hat eine lange Tradition. Ich erinnere mich noch an die künstliche Beschränkung der Anzahl gleichzeitiger TCP-Verbindungen zu Laufwerksfreigaben in den Nicht-Serverversionen von Windows NT.

 

[whitealbum]

@Realist
Ich tue mir auch schwer, laut Steinberg wurde die Anzahl der Echtzeit-Threads wohl unter Win 10 reduziert -->

..Zitat:
Mit Windows 10 wurde die Anzahl der Echtzeit-Threads mit Multimedia Class Scheduler Service (MMCSS) Priorität auf 32 pro Prozess limitiert. Vier davon sind zudem bereits durch laufende Nicht-Audio-Threads belegt.


Dies führt dazu, dass Systeme Threads ggf. ohne Echtzeit-Priorität ausführen (vergleichbar mit User Interface Threads), wenn eine CPU mit mehr als 14 logischen Kernen* zum Einsatz kommt. Dadurch können Performance-Probleme und Aussetzer bei der Wiedergabe auftreten.

Im englischen Steinberg Forum gibt es einen Sticky-Thread dazu, was aber auch eher ne Diskussion ist, als Lösungen anbietet.
Es wurde wohl mit WIN 10 auch ne neue Methode "CPU Sets" eingeführt, dafür wohl ne alte (Threads) beschnitten.
Bin auch kein Fachmann, aber sowas ist natürlich auch bitter.
Ehrlich, da bin ich froh noch auf Win 7 zu sein, und wenn sich da nichts ändert, ist der nächste Schritt erstmal Win 8.1 Pro.

 

[DrownedInTrance]

Ich kenne mich auf Windows nicht so aus, aber auf Linux würde ich eine Betriebssysteminstanz als VM starten und der weniger RAM und eine alte CPU vorspielen, um zu sehen, wie die DAW reagiert. Wenn man so nachstellen könnte, dass sie mit bestimmten Einstellungen sauber funktioniert und mit anderen nicht, wäre der Hersteller der DAW die erste Adresse für eine Nachfrage.

Wenn ich mir den weiter oben verlinkten Steinberg-Artikel so anschaue, scheint es ja wirklich mit der Anzahl der Threads zusammen zu hängen. Lustig finde ich die Aussage dort: "[...] Solange dies nicht im Betriebssystem behoben wird [...]" <- warum kommt dann Reaper offenbar damit zurecht, wenn es die Schuld von Microsoft sein soll ? Naja, wie dem auch sei. Vielleicht hat der TE bei der Befolgung der Anleitung etwas falsch gemacht ?

 

[Tonminister_V2]

Lustig finde ich die Aussage dort: "[...] Solange dies nicht im Betriebssystem behoben wird [...]" <- warum kommt dann Reaper offenbar damit zurecht, wenn es die Schuld von Microsoft sein soll ? Naja, wie dem auch sei.

Es sind halt immer die Anderen schuld.

 

[synthpark]

@Realist
Ich tue mir auch schwer, laut Steinberg wurde die Anzahl der Echtzeit-Threads wohl unter Win 10 reduziert -->

..Zitat:
Mit Windows 10 wurde die Anzahl der Echtzeit-Threads mit Multimedia Class Scheduler Service (MMCSS) Priorität auf 32 pro Prozess limitiert. Vier davon sind zudem bereits durch laufende Nicht-Audio-Threads belegt.


Dies führt dazu, dass Systeme Threads ggf. ohne Echtzeit-Priorität ausführen (vergleichbar mit User Interface Threads), wenn eine CPU mit mehr als 14 logischen Kernen* zum Einsatz kommt. Dadurch können Performance-Probleme und Aussetzer bei der Wiedergabe auftreten.

Im englischen Steinberg Forum gibt es einen Sticky-Thread dazu, was aber auch eher ne Diskussion ist, als Lösungen anbietet.
Es wurde wohl mit WIN 10 auch ne neue Methode "CPU Sets" eingeführt, dafür wohl ne alte (Threads) beschnitten.
Bin auch kein Fachmann, aber sowas ist natürlich auch bitter.
Ehrlich, da bin ich froh noch auf Win 7 zu sein, und wenn sich da nichts ändert, ist der nächste Schritt erstmal Win 8.1 Pro.

Ich hab versucht, das Problem zu googlen, ohne Erfolg. Nirgendwo steht irgendwas von Limitierungen, außer auf der Steinbergseite.

 

[whitealbum]

@synthpark
Wenn man tiefer gräbt, findet man ggf. was (nicht über Limitation suchen...)
Wenn nicht, dann würde das aber auch nicht im Umkehrschluss heißen, Steinberg hätte nicht recht mir ihrer Aussage.

Steinberg nutzt ja seit ein paar Jahren MMCSS, wenn dies durch Win 10 beschnitten ist, dann ist es halt so.
Andere DAW-Hersteller nutzen ggf. MMCSS gar nicht, somit haben sie was das betrifft auch kein Problem.
Ich schrieb ja oben das es da auch andere und neue Methoden seitens WIN 10 gibt.


Im Grunde ist das auch eine Hätte/wäre/wenn/Vermutungsarie.
Im Endeffekt funktioniert es beim TE im Zusammenhang mit Cubase nicht, obwohl es sollte, da weder HT aus, noch der Patch (voraussgesetzt er ist im richtigen Pfad), ihm etwas gebracht hat.

Ich sehe es so, wenn Firewire deaktivieren und/oder Firewire Karte ausbauen, kein Fortschritt bringt, ist das Thema im Grunde durch.
Der Audio-PC Hersteller sollte in der Lage sein, ihm ein entsprechenden Rechner funktionierend mit Cubase 9 zusammezustellen.

 

[Realist]

warum kommt dann Reaper offenbar damit zurecht, wenn es die Schuld von Microsoft sein soll ? Naja, wie dem auch sei. Vielleicht hat der TE bei der Befolgung der Anleitung etwas falsch gemacht ?

So wie ich das in diversen Foren gelesen habe ist das vom Sequenzer, der Audio-Engine und den Treiber der Interfaces abhängig und wie diese mit MMCSS umgeht.
Bei Reaper ist das irgendwie schon implentiert. Bei Cubase sollte man in den RME-Treibern z.B. die Funktion MMCSS aktivieren. Bei Reaper brauch man das wohl nicht.
Desweiteren war das nur früher bis Vista akut, deshalb hat RME die Option auch irgendwann rausgenommen.
Jetzt mit Windows 10 ist wohl wieder aktuell.

Ich hab versucht, das Problem zu googlen, ohne Erfolg. Nirgendwo steht irgendwas von Limitierungen, außer auf der Steinbergseite.

Du findest ne menge Sachen in Verbindung mit Windows 10 und MMCSS im Internet, selbst bei microsoft.
Das Multimediaklassen-Gedöhns ist auch kein Dienst (läuft über den Dienst Windows-Audio), sondern Du kannst Änderungen in der Registry durchführen und Prioritäten setzen.
Das Problem ist nur, dass es diesbezüglich widersprüchliche Aussagen in den Foren gibt und keine so recht weiß, was man da einstellen soll.
Deshalb lasse ich da auch erstmal die Finger von.
Wie schon geschrieben, gibt es ne Menge Berichte darüber, auch im Gaming-Bereich. Es geht bei dem MMCSS ja generell um Multimediaanwendungen und nicht nur Audio-Sequenzer.
Hier mal zwei Links, aber halt ohne sicheren Informatiosgehalt:
http://forum.cakewalk.com/Sonar-Optimize-Win-10-MMCSS-m3622091.aspx
https://www.forum.rme-audio.de/viewtopic.php?id=25743
Gib noch unzählige weitere Diskussionen zu dem Thema aber ohne echte lösung.

 

[synthpark]

Hier mal zwei Links, aber halt ohne sicheren Informatiosgehalt:
http://forum.cakewalk.com/Sonar-Optimize-Win-10-MMCSS-m3622091.aspx
https://www.forum.rme-audio.de/viewtopic.php?id=25743
Gib noch unzählige weitere Diskussionen zu dem Thema aber ohne echte lösung.

Ja und wenn ich mich nicht verguckt habe, taucht nirgendwo eine Limitierung in Sachen maximale Threadanzahl auf . Da gehts vorwiegend um die Priorisierungsnummer.

 

[Realist]

Hier auch nochmal aus dem oben verlinkten RME-Thread:
"Check the audio thread priorities via Process Explorer (Sysinternals). Usually they are 24-26, Reaper also uses 22 on at least one thread. Then run Prime95 at 100% load, which uses Priority 1. The MMCSS threads will drop to priority 0 (unless that part was changed in W10) for 10-20% of the time in order to make room for the Prime95 threads.

Keep in mind that some DAWs handle this themselves, some DAWs don't handle it at all and Ableton Live actively suppresses MMCSS (last time I checked). You can also activate/deactivate it in the RME driver, which depending on the DAW you should do or should not do.

This is what I posted last week in the Sonar forum:

Turn off RME MMCSS for Sonar, Sonar will activate it on its own.
Turn off RME MMCSS for Live, Live would deactivate it anyway (unless it's bugged again).
Turn on RME MMCSS for Cubase, Steinberg expect this to be handled by the driver instead of the DAW (and wants all DAWs and drivers to work that way)."

 

[Realist]

Ja und wenn ich mich nicht verguckt habe, taucht nirgendwo eine Limitierung in Sachen maximale Threadanzahl auf

Ich glaube das geht dann über die Registry und ich denke nichts anderes macht das Tool von Steinberg.

 

[whitealbum]

[Vermutung = ON]
Schau mal unter GPU Priority https://msdn.microsoft.com/de-de/library/windows/desktop/ms684247(v=vs.85).aspx

gpu priority = 0-31

Ob das jetzt die Stelle ist, wer weiß...da taucht zumidestens was mit "32" auf.

[Vermutung = OFF]

 

[synthpark]

[Naivmodus=100%]

Es geht um die geheimnisvolle Zahl 32 = 2 hoch 5.

Diese taucht nur im Zusammenhang mit der Priorisierung auf, also Prioritäten von 0 bis 31, nicht im Zusammenhang mit der Anzahl der Threads. Hört sich für mich an wie ne dumme Ausrede von Steinberg, aber ich bin da böse veranlagt.

[Naivmodus=50%]

Steht irgendwo, daß eine Priorität etwa nur einmal vergeben werden darf? In dem Fall hätte man ein Problem, sonst vielleicht nicht.

Weitermachen

 

[Realist]

[Vermutung = ON]
Schau mal unter GPU Priority https://msdn.microsoft.com/de-de/library/windows/desktop/ms684247(v=vs.85).aspx

gpu priority = 0-31

Ob das jetzt die Stelle ist, wer weiß...da taucht zumidestens was mit "32" auf.

[Vermutung = OFF]

Für mich sind das ehrlich gesagt böhmische Dörfer.
Weiter unten auf der Seite findet man unter Thread Priorities eine Tabelle mit dem Reiter High.
Da steht was von 23-26 und:
These threads run at a thread priority that is lower than only certain system-level tasks. This category is designed for Pro Audio tasks.

 

[Realist]

Hört sich für mich an wie ne dumme Ausrede von Steinberg, aber ich bin da böse veranlagt.

Für mich hört sich das ehrlich gesagt auch so an.

 

[bluebell]

Ich kenne mich auf Windows nicht so aus, aber auf Linux würde ich eine Betriebssysteminstanz als VM starten und der weniger RAM und eine alte CPU vorspielen, um zu sehen, wie die DAW reagiert. Wenn man so nachstellen könnte, dass sie mit bestimmten Einstellungen sauber funktioniert und mit anderen nicht, wäre der Hersteller der DAW die erste Adresse für eine Nachfrage.

Wenn ich mir den weiter oben verlinkten Steinberg-Artikel so anschaue, scheint es ja wirklich mit der Anzahl der Threads zusammen zu hängen. Lustig finde ich die Aussage dort: "[...] Solange dies nicht im Betriebssystem behoben wird [...]" <- warum kommt dann Reaper offenbar damit zurecht, wenn es die Schuld von Microsoft sein soll ? Naja, wie dem auch sei. Vielleicht hat der TE bei der Befolgung der Anleitung etwas falsch gemacht ?

Ohne Details ist das schwer zu sagen. Vielleicht haben sie wirklich besser programmiert und die Prozesse, die nicht realtime sein müssen (GUI), irgendwoanders reingehängt. Oder Reaper hat ein hartes Limit drin und verteilt schlechter. Unterm Strich scheinen sie aber für den Endnutzer den geschickteren Weg gegangen zu sein.

 

[Tonminister_V2]

Hört sich für mich an wie ne dumme Ausrede von Steinberg, aber ich bin da böse veranlagt.

Für mich hört sich das ehrlich gesagt auch so an.

Scheint so, leider.