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.