Windows 11 24H2 mit integriertem ASIO-Treiber für alle USB-Audio-Geräte

[tchibo]

Link: https://devblogs.microsoft.com/windows-music-dev/making-music-on-windows/

Microsoft hat angekündigt, dass im Laufe des Jahres 2025 zuerst Windows on ARM und später auch Windows x64 einen eingebauten, sehr performanten ASIO-Treiber für alle klassenkompatiblen USB-Audiogeräte haben wird.

We’ll have previews of these drivers available at milestones throughout 2025. Our first target for the new driver is Arm64 devices on Windows 11. We will follow-up with x86-64 versions after the Arm64 driver is out and we’re satisfied with the quality. These high-performance drivers will be shipped in-box in Windows so we can provide that plug & play experience where everything just works.

Die Info scheint in all der taumelnden Freude, dass Cubase, Reason und Reaper jetzt auch native auf Windows-ARM zur Verfügung stehen, ziemlich unterzugehen.

Das heißt: Kauf dir ein 9-Euro USB-Headset vom Grabbeltisch, stöpsel es an deinen Windows-ARM-Rechner, und genieße in Audioprogrammen sofort deutlich einstellige Latenzwerte über ASIO. Während die hochklassigen AUDIO-Interfaces mit hunderten Sonderfunktionen sicher auch weiterhin existieren werden, dürfte der Markt für die Unterklasse, die Hobby-Musiker eigentlich nur wegen des verfügbaren ASIO-Treibers erwerben, sich in Luft auflösen.

Gemeint ist hier nicht sowas wie ASIO4ALL (dass sich als Wrapper auf bestehende Treiber draufsetzt, d. h. die Latenzen addieren sich, weswegen ASIO4ALL rein technisch nicht unter 10 ms kommen kann), sondern ASIO auf unterster Treiberebene des Class-Compliant-USB-Treibers. Sozusagen echtes 'Lau Low Latency'.

Ob das 'eingebaute ASIO' später auch für die eingebauten Nicht-USB-Audiogeräte kommen wird, lässt der Microsoftie offen.

 

[Glutamatjunkie]

Mich wunderts, daß Microsoft nach 28 Jahren nach Einführung des Asio Protokolls damit um die Ecke kommt.
Hätten sie es vor 15 oder mehr Jahren getan wären uns viele Schrott Produkte erspart geblieben.

 

[Entone]

Ich hoffe nur, dass es dann keine Probleme mit bestehenden asio Treibern geben wird.

 

[musikertimo]

Mich wunderts, daß Microsoft nach 28 Jahren nach Einführung des Asio Protokolls damit um die Ecke kommt.

Wie heisst es so schön: Gut Ding will Weile haben!
Auf jeden Fall mal eine gute Nachricht für die Windows-Welt.

 

[Glutamatjunkie]

Cubase hat jetzt auch einen eigenen ASIO Treiber, muss nachher gucken was der so kann.

 

[adrachin]

Gut Ding will Weile haben!

Ob das ein gut Ding ist muss sich ja erst noch rausstellen.... (;

 

[ksoa]

1. Gut, könnte wirklich nützlich sein, um auf Budget-Level nicht mal mehr ein billiges Interface zu brauchen um spaß beim live einspielen per keyboard zu haben?
2007 oder so hätte mich das echt begeistert.
2. Nun ist es aber Letztlich ziemlich uninteressant für alle Musiker, die ohnehin (wegen Anschlüssen o.ä.) auf ein Interface angewiesen sind (und schon lange eines besitzen!) noch dazu wenn man Rock solide ASIO Treiber von RME liebt
Aber ja: Budget PC/Laptop user ohne Interface könnten sich freuen, wenn die Latenzen wirklich sehr niedrig sind.

 

[adrachin]

Nun ist es aber Letztlich ziemlich uninteressant für alle Musiker, die ohnehin (wegen Anschlüssen o.ä.) auf ein Interface angewiesen sind (und schon lange eines besitzen!) noch dazu wenn man Rock solide ASIO Treiber von RME liebt

Der Vorteil liegt nicht im Ersatz herkömmlicher ASIO Treiber. Richtig implementiert auf OS Ebene bekommt die ASIO Verarbeitung absolute Priorität vor allen anderen Prozessen im OS. Bisher war das nicht der Fall und konnte auch mit einem 3rd Party Treiber nicht implementiert werden. Notwendig ist das für Audio Verarbeitung da es ein Prozess ist der nahezu Echtzeitverarbeitung verlangt. Bei Video ist das egal. Da gibt es Error Correction. Interessiert ja nicht, wenn eines der Millionen Pixel per Interpolation hergestellt wird bevor es angezeigt wird.

Bei Audio hingegen ist das dann ein Dropout.

 

[ksoa]

Der Vorteil liegt nicht im Ersatz herkömmlicher ASIO Treiber. Richtig implementiert auf OS Ebene bekommt die ASIO Verarbeitung absolute Priorität vor allen anderen Prozessen im OS. Bisher war das nicht der Fall und konnte auch mit einem 3rd Party Treiber nicht implementiert werden. Notwendig ist das für Audio Verarbeitung da es ein Prozess ist der nahezu Echtzeitverarbeitung verlangt. Bei Video ist das egal. Da gibt es Error Correction. Interessiert ja nicht, wenn eines der Millionen Pixel per Interpolation hergestellt wird bevor es angezeigt wird.

Bei Audio hingegen ist das dann ein Dropout.

Ich habe den Artikel wohl nicht ganz richtig gelesen/Verstanden. Und erst jetzt in den Kommentaren auch noch das hier gelesen "But right now, there’s nothing for Arm64 devices. So we tackle them first, and like I said, Intel/AMD x64 afterwards."
Wenn das bedeutet, dass RME Interfaces auch noch stabiler laufen und mit besserer Latenz !? auf meinem nicht-ARM-Intel-i7-Rechner wäre das natürlich großartig.
Auch seit Jahren schon war ich neidisch auf MAC OS, wo es möglich ist, mehrere Treiber-Puffergrößen parallel zu benutzen ->
Diesen folgenden Trick (siehe Video, gleichzeitige Benutzung des RME Interfaces mit zwei verschiedenen Programmen und Puffergrößen!) kann man in Windows nämlich leider nicht anwenden. Ist aber fraglich, ob es jemals der Fall sein wird? Oder steht das auch im Artikel und ich hab's überlesen?

View: https://www.youtube.com/watch?v=PTyPp8vcsP0

 

[djbobo]

Generische ASIO Treiber, na ja.
Das dürfte vor allem für die Onboard Soundchips und interfaces und USB Mixer interessant sein, die keine "echten" ASIO Treiber haben und auch keine akkurate Latenzzeit für Eingang und Ausgang melden.

 

[ksoa]

Generische ASIO Treiber, na ja.
Das dürfte vor allem für die Onboard Soundchips und interfaces und USB Mixer interessant sein, die keine "echten" ASIO Treiber haben und auch keine akkurate Latenzzeit für Eingang und Ausgang melden.

war auch mein Ersteindruck - deswegen frage ich mich, was daran dran ist:

Der Vorteil liegt nicht im Ersatz herkömmlicher ASIO Treiber. Richtig implementiert auf OS Ebene bekommt die ASIO Verarbeitung absolute Priorität vor allen anderen Prozessen im OS. Bisher war das nicht der Fall und konnte auch mit einem 3rd Party Treiber nicht implementiert werden. Notwendig ist das für Audio Verarbeitung da es ein Prozess ist der nahezu Echtzeitverarbeitung verlangt. Bei Video ist das egal. Da gibt es Error Correction. Interessiert ja nicht, wenn eines der Millionen Pixel per Interpolation hergestellt wird bevor es angezeigt wird.

Bei Audio hingegen ist das dann ein Dropout.

 

[tylerhb]

Generische ASIO Treiber, na ja.
Das dürfte vor allem für die Onboard Soundchips und interfaces und USB Mixer interessant sein, die keine "echten" ASIO Treiber haben und auch keine akkurate Latenzzeit für Eingang und Ausgang melden.

Sehe ich auch so. Kenne mich mit Mac nicht aus, aber dort ist wahrscheinlich doch auch so, dass dedizierte Treiber wahrscheinlich deutlich besser performen als der generische Kram für Billig Interfaces.

Generell hat Windows on ARM bislang einfach keine große Rolle gespielt, weil da einfach für zu viele Benutzer zu viele alte x86/64 Zöpfe dran hängen, die man nicht mal eben so abschneiden kann. Sobald das wirklich zur Frage steht und die kritische Masse an Programmen für ARM kompiliert sind werden Intel und AMD alles tun, um den Wechsel auf ARM möglichst schwer zu machen. Ich sehe da im Gegensatz zum Mac eine sehr lang andauernde Parallelexistenz von ARM und X86. VMs bringen hier ja nichts und Emulatoren sind zu langsam. Wahrscheinlich werden Cloud PCs hier zunehmend wichtiger.

 

[adrachin]

Wenn das bedeutet, dass RME Interfaces auch noch stabiler laufen und mit besserer Latenz !?

Auf bessere Latenz würde ich nicht wetten. Eine gewisse Latenz ist technisch bedingt und hängt ab von der Audio Hardware konkret von den ADDA Wandlern und auch der Schnittstelle über welche diese angebunden ist. Hier sollen Latenzen von unter 10ms möglich sein.

Der Vorteil der Implementierung im OS liegt aber auf der Hand.

Sinnbildliche gesehen ist das wie die grüne Welle für Busse in der Stadt.... (;

ARM, na ja, das ist bisher bei Windows eher nichts. Das neue Surface zum Beispiel hat einen Snapdragon Prozessor. Da brauch man erst gar nicht versuchen Pro Audio Software laufen zu lassen. Wobei sich dann die Frage stellt, was wollen die auf den Teilen mit im OS implementiertem ASIO anfangen?

 

[tchibo]

Richtig implementiert auf OS Ebene bekommt die ASIO Verarbeitung absolute Priorität vor allen anderen Prozessen im OS. Bisher war das nicht der Fall und konnte auch mit einem 3rd Party Treiber nicht implementiert werden.

Ich bezweifle dringend, dass Microsoft das tun wird. Sie werden den Class Compliant USB Audio Driver USBAUDIO.sys - wie jeder andere Entwickler eines ASIO-Treibers - um die Möglichkeit des Low-Level-Pufferzugriffs erweitern, und einen ASIO-Treiber mit Hilfe von Steinbergs SDK erstellen. Heraus kommt eine DLL, die unter HKLM/Software/ASIO in der Registry eingetragen wird, eine CLSID mitbringt, und unter der ist die DLL dann registriert.

Dabei ändert sich erstmal gar nix an der reinen Treiber-Implementierung (bis auf den genannten Low-Level-Buffer-Zugriff, der ja eben der Witz bei ASIO ist). Um das Multi-Client-Mixing mit anderen Audioquellen zu ermöglichen wird es einen Safety-Buffer geben, und wir landen dann bei Latenzen, die einen Tick oberhalb von dem liegen, was z. B. ein RME-Treiber ermöglicht. Also bei 48 kHz eine Ausgagslatenz von 2-3 ms bei 64 Samples Puffergröße und 3-4 ms bei 128 Samples Puffergröße, RTL jeweils ca. das Doppelte.

Wenn sie das so hinbekommen, ist schon viel bewegt. Wenn du viel Glück hast, werden Sie den ASIO-Thread dann in den MMCSS-Pfad bewegen (so wie es die RME-Treiber ja auch unterstützen), und Fettich.

 

[adrachin]

Wenn sie das so hinbekommen, ist schon viel bewegt.

Wenn. Aber bei den gebialen Developern von MS habe ich da keine Zweifel. Die haben es ja auch geschafft ein uraltes FS NTFS über Jahrzehnte zu erhalten. Die haben also Erfahrung mit antiker Software..... (;

 

[Tragtop]

Ich bezweifle dringend, dass Microsoft das tun wird

Ich habe da auch meine Zweifel... Die werfen doch viel lieber noch eine unnütze Audioapp auf den Markt an der sie kräftig Kassieren können, statt irgendwelche Lizenzgebühren an Steinberg bzw. Yamaha zu bezahlen.

 

[Dondelinger]

Ich habe da auch meine Zweifel... Die werfen doch viel lieber noch eine unnütze Audioapp auf den Markt an der sie kräftig Kassieren können, statt irgendwelche Lizenzgebühren an Steinberg bzw. Yamaha zu bezahlen.

Wäre mir neu daß man für die Implementierung von ASIO Treibern Lizenzgebühren zahlen muß.

3rd-Party Developers Support & SDKs

We offer other manufacturers the chance to develop VST- and ASIO-based software and hardware for macOS and Windows by offering those technologies.

www.steinberg.net

 

[stereolli]

Nutzt jemand Win 11 und FireWire ?
Ist ja immer das Problem mit den FW Karten.
Nur weil Texas Instruments draufsteht, bedeutet das nicht, dass die erkannt wird.