Ich habe null Ahnung davon, wie sich irgendwas unter Linux verhält, aber Core Audio und ASIO sind schon zwei ziemlich unterschiedliche Paar Schuhe. Bei ASIO handelt es sich um eine Treiberarchitektur, die versucht, die Windows-interne Geschichte (also WDM) zu umgehen, damit kleinste Latenzen möglich sind. Core Audio hingegen ist sozusagen das OSX Equivalent für WDM. Ermöglicht aber von Haus aus, anders als WDM, bereits sehr kleine Latenzen, weshalb viele Interfaces, sofern denn class compliant gehalten, auch komplett ohne zusätzliche Treiber für OSX geliefert werden und dennoch meistens zumindest einigermaßen laufen. Extra Treiber für OSX braucht man nur dann, um nochmals niedrigere Latenzen zu erreichen.
Mal als ganz grobe Hausnummer, von welchen Werten wir hier so reden: Mein Zoom UAC-2 bietet beide Betriebsmodi, class compliant alleine (gut, wenn man das bspw. mit einem älteren Rechner oder einem Tablet benutzen möchte) und per Treiber. Mit Treiber komme ich bei 64 Samples auf 5,9ms RTL, im CC Modus immerhin auch noch auf 8,3ms - ein Wert, der sich unter Windows niemals nur per WDM erreichen lässt (ok, ich glaube, Cakewalk/Sonar hat da mal was versucht, weiß aber nichts genaues...), weshalb man bei CC Interfaces unter Windows meist ASIO4All bemühen muss.
Wie dem auch sei, unter OSX braucht es eben nicht zwingend die Umwege über einen extra Treiber, wenn auch die Performance mit einem gut programmierten Treiber nochmal deutlich besser ist.
Windows hat ja mittlerweile mit WASAPI nachgelegt, also ich denke es macht (heutzutage) mehr Sinn Core Audio und WASAPI (statt WDM) gegenüberzustellen. Ich zumindest bekomme mit WASAPI schon recht brauchbare Latenzen.
so ist es, mit WASAPI ist man bei Windows 10 auf den richtigen Weg gekommen, wobei es genau gesehen zwei verschiedene WASAPI Verbindungen gibt. Es gibt shared und exclusive WASAPI. Das Verhalten der Schnittstellen um im Low Latency Modus zu arbeiten ( < 10ms) muss allerdings von der Anwendung bei den neuen Windows 10 Schnittstellen angefordert werden. Genaueres kann man hier nachlesen:
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
Unabhängig davon konnten die WASAPI Latenzen seit Windows 8.1 auch generell reduziert werden, was ebenfalls im (englischen) Artikel steht:
"Bei allen Anwendungen, die Audio verwenden, wird die Round-Trip-Latenz um 4,5-16 ms verringert, ohne dass Codeänderungen oder Treiberaktualisierungen vorgenommen werden müssen, verglichen mit Windows 8.1. .a) Anwendungen, die Fließkommazahlen verwenden, haben eine niedrigere Latenzzeit von 16 ms. b) Anwendungen, die Ganzzahlen benutzen, haben eine niedrigere Latenz von 4,5 ms.
Vor Windows 10 habe das System alle Audiodaten in einen Buffer mit 10 ms Latenz geschrieben, wobei ein neuer Audiotreiber jetzt niedrigere Buffer anfordern könne bis 1ms. Die 10 ms haben bedeutet dass die CPU alle 10 ms aus dem "Schlaf" aufgeweckt wurde um die Audiodaten im Buffer zu verarbeiten, bei 1 ms wird die CPU alle 1 Millisekunden aus dem Schlaf geweckt (falls sie überhaupt schläft und nicht mit anderen Aufgaben beschäftigt ist). Ursache für die früheren minimalen Latenzen von 10ms seien die Stromsparfunktion, weil tiefe Latenzen mehr Strom benötigen würde und daher die Batterie belaste.
Offensichtlich hatte Microsoft früher jedoch auch an das Festnetz angeschlossene PC immer mit diesem minimalen 10ms Buffer ausgestattet, was mir jetzt die Stromsparfunktion der Batterie als Begründung aus meiner Sicht eher billige Ausrede ist.
Microsoft hatte sich früher (bei seinen eigenen Schnittstellen) schlicht zu wenig um Audio Professionals gekümmert. Auch wird erst mit dem nächsten Funktions-Upgrade von Windows 10 eine andere mühsame Behinderung für unsere DAW's aus dem Wege geräumt, nämlich die Möglichkeit mehr als 120 Plugin einzusetzen (was bereits seit Windows XP, Vista der Fall ist ). Ursache dafür liegt in der programmierten Schnittstelle von Windows um Dll Funktionen aufzurufen.
Auch gibt es noch eine dritte Baustelle mit Windows 10, nämlich die Begrenzung der Multimedia Audio Funktionen auf 12 CPU Kerne (nur unter Windows 10 aber).
Ursache für diese Behinderung von mit Windows Audio arbeitenden Programmen sei die Verlegung der Windows Multimedia Schnittstelle neu in den Kernel Mode des Systems, früher lag diese MMCSS im User Mode des Systems und konnte daher mehr Prozessor- Threads abarbeiten.
Windows 10 ist also aus meiner Sicht noch immer nicht generell besser als seine Vorgänger, leider. Und das notwendige Windows 10 Release um mehr als 120 Plugins gleichzeitig auszuführen könnte sich auch wieder verzögern, da Microsoft offenbar wieder Schwierigkeiten hat um wie geplant das nächste Funktionsupgrade sauber genug hinzukriegen. Das im April geplante Upgrade könnte sich also um 1-2 Monate verzögern. Bei mir auf jeden Fall, denn ich Upgrade meine Systeme generell erst mit 3-4 Monaten Verzögerung.
Auch diese alle 6 Monate stattfindenen Release sind ein gutes Argument gegen Windows 10, jedenfalls für alle jene Personen die wenig Zeit haben um das Betriebssystem neu aufzusetzen und allenfalls bereits registrierte Software wiederholt aktivieren zu müssen.
Schon aus diesem Grund (Langfrisitg sicher laufende registrierte Software ohne Update Druck) wäre für mich ein eigenes Musik Betriebssystem eine echte Erleichterung.
Aus meiner Sicht gibt es beim Betriebssystem Kern Windows seit vielen Jahren keine wirklich notwendigen Neuerungen mehr. Jegliche den Menschen als Neuigkeit erscheinenden Features basieren nicht auf den Kernfunktionen eines Betriebssystems, sondern liegen in neuer Zusatzsoftware bis hin zu den kleinen Apps die mit einem OS nicht viel zu tun haben. Auch das gewandelte Erscheinungsbild von Windows hat wenig mit den notwendigen Kernfunktionen zu tun.
Auch die stetige Weiterentwicklung der Webbrowser haben wenig mit dem Betriebssystem am Hut.
Ein gutes Musik-OS könnte viele Jahre bestehen ohne das man etwas an den Schittstellen ändern müsste, Patches wären zwar auch hier möglich, aber nicht notwendig sie vornehmen zu müssen.
