Das Problem ist wie bereits erwähnt in der Multimedia Steuerung des Betriebsystem Windows 10 zu orten. Das wird auch von Vertretern von Microsoft nicht bestritten. Der Unten verlinkte User arbeitet für Microsoft u.a. im Bereiche Audio.
https://www.gearslutz.com/board/showpost.php?p=13158114&postcount=5
Der Unterschied zwischen Windows 7/ 8.1 und Version 10 ist die Auslagerung der MMCSS ( Multimedia Class Scheduler service) in den Kernel Mode, wohingegen diese Prozess- Steuerung zuvor im so genannten User mode lief. Das führt nun zu Einschränkungen wofür man eine Lösung suche. Allerdings habe ich bisher nicht mal in der aktuellsten Insider Version eine solche Lösung bemerkt.
Als Nebeneffekt der Auslagerung von MMCSS als Kernel Prozess entstand eine Pro-Prozess-Beschränkung von 32 registrierten Threads. Anwendungen, die eine grosse Anzahl von Threads in einem einzelnen Prozess registrieren, sehen möglicherweise MMCSS-Registrierungen in Windows 10 fehlgeschlagen die unter Umständen in Windows Vista bis Windows 8.1 funktonierten.
Die vorgeschlagenen Zwischen- Lösungen halte ich für wenig praktikabel, vor allem der zweite Vorschlag gefällt mir gar nicht:
"
Seien Sie darauf vorbereitet, dass die MMCSS-Registrierung fehlschlagen kann, da MMCSS-Ressourcen von System zu System und von Zeit zu Zeit variieren können, je nachdem, was andere Anwendungen auf dem System gerade tun"
Ein Programmcode der fehlgeschlagene MMCSS Aufrufe abfängt ist zwar möglich, jedoch können die dazu notwendigen Systemabfragen kein latenzarmes Audio mehr garantieren. Es muss zusammen mit der Prozesserzeugung sicher gestellt werden können dass die erforderlichen Ressourcen auch registriert werden können. Um das sicher zu stellen muss man bis zur Lösung durch Microsoft entweder Windows 7/8.1 benutzen oder dann zum Vorneherein im Programmcode die Anzahl MMCSS -Threads pro Prozess auf max. 32 beschränken.
Bei Steinberg wurde schon bald erkannt das man bei neueren CPU's mit sehr vielen Kernen die maximale Anzahl virtueller Threads einschränken muss unter Windows 10. Dazu müsse man eine Datei mit dem Namen "audioengine.properties" mit folgendem Text erzeugen:
audioengine.threads.max=14
siehe auch hier:
https://helpcenter.steinberg.de/hc/...ws-10-audio-dropouts-on-multi-core-CPU-setups
Diese Datei sei dann in das Programmverzeichnis zu verbringen, z.B. C:\Users\<username>\AppData\Roaming\Steinberg\Cubase 9_64
Einiges Später hat sich an einem anderen Ort bei Microsoft wiederum der Entwickler "Pete Brown" eingeschaltet und auf eine Anfrage hin folgendes geschrieben:
https://answers.microsoft.com/en-us...ads-with/e3a47fc2-9547-4fea-b830-042a552f56a9
"Steinberg arbeitet an einer langfristigen Lösung, die in einer Änderung des Programmcode liegen wird.
Zusätzlich hat Steinberg Zugang zu einem Registry-Work-Around,
was wir (Microsoft) ihnen im letzten Jahr zur Verfügung gestellt haben.
Sie können diese Registry Einträge bei Bedarf mit ihren Kunden teilen. Es ist aber nicht etwas, was wir öffentlich teilen möchten, da es systemweite Auswirkungen auf die Performance gibt, wenn man einfach eine zufällige Zahl für die Prozessobergrenze auswählt."
Offenbar hängt der Eintrag in die Registry von System Hardware wie der CPU Spezifikation ab, dies dürfte aber bei Mehrprozessor Systemen mit denselben CPU zudem nochmals verschieden sein.
Nehmt bei Problemen mit solchen neuen Prozessoren bei denen Probleme auftreten Kontakt zu Steinberg auf und teilt dort genau mit welche CPU ihr habt, zudem wie viel Arbeitsspeicher. Auch Grafikkarte und Audio Interface können wichtig sein um den Eintrag zu bestimmen.
Der schwarze Peter wird also von einem Ort zum Anderen weiter gegeben, aber für mich ist klar Microsoft in der Bringschuld, zumal ich auch gesehen habe dass die Unterlagen für Systementwickler von Windows Programmen im Bereich Audio ungenügend sind. Dies trifft vor allem auf die Online Referenzen zu
![] Peter:H [](/data/avatars/m/85/85803.jpg?1515001432){kind=avatar}
