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.
 
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.
Darum geht es doch nur peripher. Niemand hat gesagt, dass nur der Mac mit Coreaudio niedrige Latenzen hinbekommt. Aber es ist sehr viel einfacher das zu realisieren und vor allen Dingen kann Coreaudio soviel mehr. Hast Du Dir überhaupt mal die entsprechenden Posts angesehen?
- 197
- 199
 
Zuletzt bearbeitet:
@kerninger wie lief den der Erstkontakt?
Bisher sehr gut. Bis auf Auspacken, externe Platte vorbereiten und das Gerät an seinen neuen Platz stellen ist noch nicht viel passiert. Hab ihn über Nacht sich jetzt erstmal daran gewöhnen lassen, dass er auf einem Windows PC abgestellt wird - zum Beschnuppern sozusagen. Heute schmeiß ich den M4 dann mal an.

IMG_2464.JPEG
 
Prima Bild. Passen geschätzt 10 Mini rein in das PC Gehäuse.
Allerdings :)
Da wird dann sicher schon mal ein positives Erlebnis. Nach Verbindung zum LAN oder Wlan, eventuell Eingabe der Apple ID dauert es einige Minuten und der Desktop erscheint. Fertig.
Okay. Apple-ID möchte ich erst eingeben, nachdem ich die externe SSD als aktiven Home Folder festgelegt habe. Ansonsten müllt mir iCloud wahrscheinlich zuerst die interne Platte zu.
 
Allerdings :)

Okay. Apple-ID möchte ich erst eingeben, nachdem ich die externe SSD als aktiven Home Folder festgelegt habe. Ansonsten müllt mir iCloud wahrscheinlich zuerst die interne Platte zu.
Ne, das ist zum Glück nicht so. Er fragt Dich nur während der Installation, ob Du die Verzeichnisse Schreibtisch und Dokumente auf das iCloud Drive möchtest. Wenn man das nicht möchte (kann auch nett sein für den Anwendungsfall, dass man vielleicht noch Laptops oder iPad hat und auf dem Schreibtisch eher kleinere temporärere Daten hat…), dann das einfach vereinen. Auf dem Mac ist generell keine Bloatware, Werbung, Trialsoftware und iCloud läuft sehr ressourcenarm und dezent im Hintergrund. Das ist etwas, das ich tatsächlich sehr gut finde.
 
externe SSD als aktiven Home Folder festgelegt habe.

Keine gute Idee. Es gibt jede Menge Pfade auf den Homefolder von Apps, Installationsroutinen usw. Nicht alle kommen mit externen Speichermedien zurecht. Das liegt auch user Library und User System Folder. Schlimmstenfalls verhindert das den Boot Vorgang wenn die externe SSD nicht rechtzeitig da ist.

Besser ist es gezielt Daten Folder wie Musik, Video und gegebenenfalls Dokumente auszulagern. Unbedingt notwendig ist das meines Ermessen nach nicht. Mit nur einer DAW mit Grundinstallation von Komponenten, jeder Menge Plugins und was man sonst so braucht komme ich auf ca. 100GB. Noch reichlich Platz für mehr.
 
Keine gute Idee. Es gibt jede Menge Pfade auf den Homefolder von Apps, Installationsroutinen usw. Nicht alle kommen mit externen Speichermedien zurecht. Das liegt auch user Library und User System Folder. Schlimmstenfalls verhindert das den Boot Vorgang wenn die externe SSD nicht rechtzeitig da ist.

Besser ist es gezielt Daten Folder wie Musik, Video und gegebenenfalls Dokumente auszulagern. Unbedingt notwendig ist das meines Ermessen nach nicht. Mit nur einer DAW mit Grundinstallation von Komponenten, jeder Menge Plugins und was man sonst so braucht komme ich auf ca. 100GB. Noch reichlich Platz für mehr.
Das ist halt die Frage, die sich mir stellt, ob mir die 256 Gig tatsächlich reichen und die Auslagerung von spezifischen Ordnern reicht.
Die Entscheidung sollte ich wohl direkt beim Aufsetzen des Minis treffen von Anfang an.

Ich habe mir dazu ein paar Videos von diesem Herren hier angesehen, der das auch so gemacht hat. Allerdings postet der auch regelmäßig Updatevideos, da mit neuen MacOS Versionen wohl die von dir beschriebenen Probleme auftreten und das Auslagern des ganzen HomeFolders mehr tricky wird.

Beispiel:

View: https://youtu.be/9cdim4v_0Kg?si=sMqXVp0igCWvSURA
 
Keine gute Idee. Es gibt jede Menge Pfade auf den Homefolder von Apps, Installationsroutinen usw. Nicht alle kommen mit externen Speichermedien zurecht. Das liegt auch user Library und User System Folder. Schlimmstenfalls verhindert das den Boot Vorgang wenn die externe SSD nicht rechtzeitig da ist.

Besser ist es gezielt Daten Folder wie Musik, Video und gegebenenfalls Dokumente auszulagern. Unbedingt notwendig ist das meines Ermessen nach nicht. Mit nur einer DAW mit Grundinstallation von Komponenten, jeder Menge Plugins und was man sonst so braucht komme ich auf ca. 100GB. Noch reichlich Platz für mehr.
Mein Sohn hat das bei seinem M4 gemacht und es ist läuft alles sehr smokt. Wenn die Platte nicht drinsteckt, kann er sich einfach nicht anmelden; das wird vom System aber auch gemerkt und es passiert nichts Komisches...
Sobald die Platte dran ist, ist alles wie gewohnt. Er hat allerdings eine Thunderbolt Süd dran. Da merkt man auch geschwindigkeitsmäßig gar nichts...
 

Zurück
Oben