Mac Mini Desktop M4 für 555 Euro bei Amazon (Prime)

Mensch Leute, versucht doch wenigsten das zu verstehen. ASIO ist ein zusätzlicher Treiber für Windows. Der hat keinen Zugang zu Windows System Prozessen. Core audio IST ein Systemprozess und unterliegt zu 100% der Kontrolle des OS.

So kompliziert kann das doch nicht zu verstehen sein. Oder doch?

ASIO braucht keinen Zugang zu Systemprozesse, weil es die Windows API komplett umgeht bzw. WDM, Directsound, WASAPI, und direkt mit der Hardware kommuniziert, desewegen auch die niedrige LAtenz. Wohingegen Core Audio wie schon geschrieben zusätzliche Overheads verursachen kann. In der Praxis ist ASIO sogar schneller als Core Audio, wohingegen Core Audio etwas stabiler ist, wenn mehrere Anwendungen unterschiedliche Sampelraten verwenden.

Für reine Latenz und DAW Leistunf ist ASIO überlegen.
Also ja, wenn du die DAW offen hast und gleichzeitig zum mixen no Spotify hörst, dann ist core Audio 1-2 Millisekunden schneller, ABER jedes zusätzliche Layer gibt Latenz in der DAW

Also Core Audio ist auf jeden Fal benutzerfreundlicher wenn du 100 Sachen am laufen hast + deine DAW (trotz zusätzlicher LAtenz, weil Core Audio eben wie gheschrieben nicht das OS umgehen kann)
 
Zuletzt bearbeitet:
Ich habe den Text geändert.

Die Aussage ist grundsätzlich nicht falsch, aber sie braucht Differenzierung, damit sie nicht in Mythen abgleitet. Hier die technischen Fakten zum Thema „Echtzeitverhalten von ASIO unter Windows“ – speziell bei RME:


✅

  1. ASIO-Treiber wie die von RME sind sehr effizient
    RME-Treiber sind bekannt dafür, mit minimaler Latenz und hoher Stabilität zu arbeiten. Das liegt an:
    • sehr gutem Ringpuffer-Management,
    • optimierter Interrupt-Steuerung,
    • effizienter Nutzung von DMA (Direct Memory Access).
  2. NT-Kernel erlaubt Priorisierung
    Windows (ab NT) hat sehr wohl Mechanismen zur Priorisierung von Threads, etwa durch:
    • Thread Priorities (REALTIME_PRIORITY_CLASS, TIME_CRITICAL)
    • Multimedia Class Scheduler Service (MMCSS) für Audio-Optimierung seit Vista.
  3. ASIO erlaubt direkten Zugriff auf den Hardwarebuffer
    Der Vorteil von ASIO gegenüber WDM/DirectSound ist der Bypass des Windows-Audiostacks (kein Mixer, keine Resampler etc.).
    → Das reduziert Latenz, aber ist nicht gleichbedeutend mit „Kernel Mode Access“ im Sinne eines Treibers, der sich direkt ins Scheduling einhängt.

❌

  1. ASIO ist nicht gleich Kernel-Thread mit Echtzeitgarantie
    ASIO-Treiber laufen nicht automatisch mit „hard real-time“ Priorität. Windows ist kein echtes Echtzeitbetriebssystem. Es gibt keine Garantie, dass ein Thread genau zu einem bestimmten Zeitpunkt ausgeführt wird – es gibt nur Wahrscheinlichkeiten durch Priorisierung.
  2. RME hat keinen Zugriff auf Kernel Scheduling
    Ein Audio-Treiber (auch RME) kann zwar einen Kernelmode-Treiber-Teil haben (.sys), aber das bedeutet nicht, dass er das OS „zwingen“ kann, andere Prozesse zu unterbrechen.
    → Er kann Interrupts sehr effizient nutzen, aber nicht zentrale Kernelzeitpläne manipulieren.
  3. "Direct to hardware" ≠ Echtzeitprivileg
    Der Zugriff auf den Hardwarebuffer (z. B. über PCIe oder USB) bedeutet nicht, dass ein Prozess Vorrang vor anderen bekommt – das ist Sache des Schedulers.

🧠 Fazit​

RME nutzt die gegebenen Möglichkeiten von Windows extrem gut aus. Das führt in der Praxis zu einem „quasi-echtzeitfähigen“ Verhalten – aber eben innerhalb der Schranken des NT-Systems.

Der Unterschied zu Core Audio (macOS) liegt eher im Systemdesign:

  • macOS hat Core Audio als Teil des Betriebssystems, tightly integriert in den Scheduling-Loop.
  • Windows hat ASIO als Drittlösung, die auf Optimierung und Effizienz setzt, aber außerhalb der OS-Kontrolle läuft.
Beides kann zu sehr guten Ergebnissen führen – aber nur unter bestimmten Voraussetzungen.

Wenn Du magst, kann ich Dir mal zeigen, wie man in Windows Prozesse und Threads mit Realtime-Priorität ausliest – inklusive ASIO-Prozesse.

Jetzt ist dann aber auch gut mit den Innereien von Treibern und OS.
 
Ich habe den Text geändert.

Die Aussage ist grundsätzlich nicht falsch, aber sie braucht Differenzierung, damit sie nicht in Mythen abgleitet. Hier die technischen Fakten zum Thema „Echtzeitverhalten von ASIO unter Windows“ – speziell bei RME:


✅

  1. ASIO-Treiber wie die von RME sind sehr effizient
    RME-Treiber sind bekannt dafür, mit minimaler Latenz und hoher Stabilität zu arbeiten. Das liegt an:
    • sehr gutem Ringpuffer-Management,
    • optimierter Interrupt-Steuerung,
    • effizienter Nutzung von DMA (Direct Memory Access).
  2. NT-Kernel erlaubt Priorisierung
    Windows (ab NT) hat sehr wohl Mechanismen zur Priorisierung von Threads, etwa durch:
    • Thread Priorities (REALTIME_PRIORITY_CLASS, TIME_CRITICAL)
    • Multimedia Class Scheduler Service (MMCSS) für Audio-Optimierung seit Vista.
  3. ASIO erlaubt direkten Zugriff auf den Hardwarebuffer
    Der Vorteil von ASIO gegenüber WDM/DirectSound ist der Bypass des Windows-Audiostacks (kein Mixer, keine Resampler etc.).
    → Das reduziert Latenz, aber ist nicht gleichbedeutend mit „Kernel Mode Access“ im Sinne eines Treibers, der sich direkt ins Scheduling einhängt.

❌

  1. ASIO ist nicht gleich Kernel-Thread mit Echtzeitgarantie
    ASIO-Treiber laufen nicht automatisch mit „hard real-time“ Priorität. Windows ist kein echtes Echtzeitbetriebssystem. Es gibt keine Garantie, dass ein Thread genau zu einem bestimmten Zeitpunkt ausgeführt wird – es gibt nur Wahrscheinlichkeiten durch Priorisierung.
  2. RME hat keinen Zugriff auf Kernel Scheduling
    Ein Audio-Treiber (auch RME) kann zwar einen Kernelmode-Treiber-Teil haben (.sys), aber das bedeutet nicht, dass er das OS „zwingen“ kann, andere Prozesse zu unterbrechen.
    → Er kann Interrupts sehr effizient nutzen, aber nicht zentrale Kernelzeitpläne manipulieren.
  3. "Direct to hardware" ≠ Echtzeitprivileg
    Der Zugriff auf den Hardwarebuffer (z. B. über PCIe oder USB) bedeutet nicht, dass ein Prozess Vorrang vor anderen bekommt – das ist Sache des Schedulers.

🧠 Fazit​

RME nutzt die gegebenen Möglichkeiten von Windows extrem gut aus. Das führt in der Praxis zu einem „quasi-echtzeitfähigen“ Verhalten – aber eben innerhalb der Schranken des NT-Systems.

Der Unterschied zu Core Audio (macOS) liegt eher im Systemdesign:

  • macOS hat Core Audio als Teil des Betriebssystems, tightly integriert in den Scheduling-Loop.
  • Windows hat ASIO als Drittlösung, die auf Optimierung und Effizienz setzt, aber außerhalb der OS-Kontrolle läuft.
Beides kann zu sehr guten Ergebnissen führen – aber nur unter bestimmten Voraussetzungen.

Wenn Du magst, kann ich Dir mal zeigen, wie man in Windows Prozesse und Threads mit Realtime-Priorität ausliest – inklusive ASIO-Prozesse.

Jetzt ist dann aber auch gut mit den Innereien von Treibern und OS.

Sage ich ja, beides ist gut, es sind ein paar Millisekunden Unterschied. Und ihr tut hier so als Mac der heilige Gral wäre- Obwohl MEssungen zeigen das die reine DAW Performance ASIO vorne ist - ABER EGAL, IGNORIEREN, wirklich. mal so mal so. Setup etc..ö. Wen juckts?

Aber dieses Getue, nur Mac kann etwas richtig gut und umgekehrt, das ist alles bullshit. Völlig unnötige Diskussion.



Also nochmal, einfach das nehmen womit man am wohlsten ist, beides ist gut. Beides hat minimale, winzige Vorteile und Nachteile.
 

Neue Antworten


Zurück
Oben