Bei ASIO geht's genau um das Gegenteil: Audiodaten werden *direkt* an die Soundkarte gesendet, unter Umgehung des Betriebssystems, um Latenzen zu minimieren.
Ohne Betriebssystem bewegt sich in einem Computer kein einziges Bit. 
Es gibt allenfalls eine Datenübertragung per DMA-Controller unter Umgehung der CPU. Aber auch das wird vom Betriebssystem gesteuert, welches letztlich nur mit CPU laufen kann.
Ohne Betriebssystem bewegt sich in einem Computer kein einziges Bit.
Naja nicht ganz. Früher konnte man durchaus direkt mit der Hardware arbeiten unter Umgehung des Systems. Glücklicherweise ist so etwas in Modernen Systemen nicht mehr so ohne weiteres möglich und direkten Speicher oder Hardwarezugriff gibt es nicht mehr. Man muss grundsätzlich über eine vom System bereitgestellte Schnittstelle gehen und darf auch nur begrenz im Speicher oder der Hardware kommunizieren. Aber auch nur in bestimmten Systemebenen und dann meist auch nur ganz wenig Spezialfälle wie Treiberentwicklung.
Warum sage ich zum Glück? Ganz einfach weil ein Fehler das gesamte System abschießen kann. Und wenn mehrere Programme im Speicher oder der Hardware rumpfuschen dann kann das nur in einem instabilen System enden. Mal von der Sicherheit des Systems ganz zu schweigen wenn jede Software einfach mal so in jeden Speicherbereich lesen und schreiben könnte.
Und von diesen Punkten abgesehen sind eh nur ganz wenige hoch spezialisierte Entwickler mit Maschinensprache in der Lage so etwas effizient und einigermaßen sicher zu gewährleisten. Daher ist es gut, dass es nicht jedes Stück Software darf und moderne Systeme so etwas komplett unterbinden. Dies ist im Interesse von uns allen, außer wir wünschen uns die Zeiten zurück in der ein System so stabil war wie ein Kartenhaus im Orkan.
Eher unter Umgehung der Soundtreiber des Betriebssystems
Werden bei ASIO nicht die Daten an ein externes Audiointerface gesendet und dort dann ausgegeben? Ich wüsste nicht, dass ASIO dafür konzipiert wurde mit Soundkarten zu arbeiten, sondern nur mit einem geeigneten Audiointerface, dann ist die Soundkarte ohnehin raus aus der Nummer. ASIO4ALL ist als Bestellösung etwas das was zum Audiointerface gehen würde dann eben zum Soundchip im Rechner schleift. Aber selbst dass geht ja nicht ohne Treiber. Es ist eher so, dass dann ein fertiges Signal zum Treiber geht der es nur noch ausspucken muss und ohne weitere Funktionen sind die Chancen ganz gut, dass es auch der schlechteste Treiber schafft einen fertigen Stream ohne anzufassen auch ausgeben kann in einer anständigen Qualität.
Damit die Schnittstelle zur Soundkarte funktioniert, sollte der ASIO-Treiber vom Soundkarten-Hersteller geliefert werden.
Korrekt der ASIO Treiber ist quasi der Treiber für die ASIO Hardware und somit nur nützlich auf Hardware die diese Sprache auch versteht. Eine gewöhnliche OnBoard Soundkarte oder normale Heimanwender Hardware kann das nicht, daher ASIO4ALL damit dieser als Vermittler dazwischen geht und die Funktionen bietet welche die Hardware nicht kann. Aber demzufolge bringt ASIO4ALL keine Vorteile, außer das man es auf nicht kompatibler Hardware nutzen kann ohne nativer ASIO Schnittstelle. Aber das ist in etwa so wie wenn ich einen Porsche hinter einen Eselkarren binde und meine ich wäre nun schneller nur weil ich im Porsche sitze obwohl er weiterhin vom Esel gezogen wird
Oder anders gesagt ein USB1 auf USB3 Adapter wird zwar USB3 Geräte am USB1 Anschluss nutzbar machen, trotzdem ist es nicht schneller als USB1 mit zusätzlichen Overhead
Ich meine schon, dass das Performance gebracht hat. Warum soll ich den sonst installieren?
Die spannende Frage ist ob du tatsächlich eine bessere Latenz hast (extern gemessen) oder es eher ein Placebo ist. Die Sache ist ja wenn deine Hardware kein natives ASIO kann, wo soll dann bessere Leistung herkommen wenn du einen Softwarelayer drüber legst der die Funktionalität nur vorgaukelt und das ganze dann per Software irgendwie hinbiegt damit es funktioniert? Zumindest im Falle von GO wo es ja nur darum geht Midi Signal Rein, Audiosignal raus ist ja nicht wirklich viel wo etwas schneller werden sollte als nativ über die Soundkarte raus und dem Midi Controller rein.
Ausnahme wäre wenn dein Hersteller wirklich miese Treiber liefert die so schlecht sind, dass Umwege noch schneller sind. Leider ist das nicht unüblich.
Naja nicht ganz. Früher konnte man durchaus direkt mit der Hardware arbeiten unter Umgehung des Systems.
Was sollte das sein? Jetzt musst Du aber aufpassen was Du sagst, denn jetzt kommen wir zum Kernthema meines damaligen Studiums als Computeringenieur. 
Wenn ich von Computer spreche bezieht sich das auch nicht nur auf einen PC mit Windows oder Linux.
Nachdem ich lange keine Updates mehr gemacht hatte, habe ich heute Abend meine Linux-Partition aktualisiert. Bei mir läuft nun GO 3.5.0-1 (vor 4 Tagen auf Github veröffentlicht) unter LinuxMint 20.3 und macht bisher keine Probleme. Konnte jetzt auch die originale GO-Zoeblitz ohne Zusatzkniffe laden.
Was sollte das sein? Jetzt musst Du aber aufpassen was Du sagst, denn jetzt kommen wir zum Kernthema meines damaligen Studiums als Computeringenieur.
Naja gerade in der DOS Ära war es ja ganz normal direkt im Speicher zu arbeiten um Leistung zu bekommen. Auch bei den Systemen die noch eine Erweiterung zu MS-DOS waren wie Windows 9x bis ME war das ja durchaus üblich. Alleine schon weil es keine klaren Standards gab. Mit Windows 2000 bzw. genauer mit Windows NT wurde das ja geändert. Wobei NT eher ein Versuchsfeld war. Mit Windows XP hatte man am Anfang ja auch viele Stabilitätsprobleme weil jeder auf einen anderen Weg einen Treiber schrieb. In der weiteren Lebensspanne hat Microsoft dann ja viele Daumenschrauben angezogen und weite Teile abgeschottet und neue Richtlinien gegeben wie ein Treiber funktionieren muss, wie er welche Funktionen nach außen einheitlich abbilden muss. Auch ab den NT Kernels war es ja so, dass Programme ihren Speicherbereich hatte und darüber hinaus nicht mehr irgendwo anders rumpfuschen konnten. Es war damals dann eigentlich normal, dass selbst Hardwarenahe Zugriffe über das System gingen und das System eben die Finger drauf hatte ob dieser Prozess es darf oder nicht. Damit wurden die Systeme eigentlich erst stabil.
Bei Linux stellt sich die Frage eigentlich nicht, da hatte der Kernel ja schon immer die Kontrolle über alles und daran vorbei zuarbeiten war zwar möglich in frühen Versionen aber nicht als Normal angesehen.
Naja gerade in der DOS Ära war es ja ganz normal direkt im Speicher zu arbeiten um Leistung zu bekommen.
Antwort ist leider 
Selbst wenn Du ein Disk Operating System (=DOS) völlig weg lässt, ist immer noch das BIOS (=Basic Input Output System) ein grundlegendes Betriebssystem. Und sogar wenn Du das BIOS weglässt, dann ist das Steuerwerk innerhalb einer CPU quasi als eine Art Betriebssystem anzusehen, ohne das sich kein Datenbit bewegt.
Und sogar wenn Du das BIOS weglässt, dann ist das Steuerwerk innerhalb einer CPU quasi als eine Art Betriebssystem anzusehen, ohne das sich kein Datenbit bewegt.
Ja schon und die Informatiker Sicht ist natürlich komplexer. Aber mich würde eben kein Bios oder Windows 9x davon abhalten z.B eine Speicheradresse im Grafikspeicher beliebig zu verändern oder eine Funktion auf der GPU auszuführen, so lange die Anfrage plausibel ist. Im dümmsten Falle überschreibe ich etwas wichtiges was zu einem totalen Systemausfall führt oder mit anderen Programmen die ähnliches tun kollidieren.
Heutige Programme sind ja kein Maschinencode mehr wie früher, sondern nur eine Art Paket in welchem für das Betriebssystem verständlich erklärt ist was dieses tun soll. Ich weiß nicht ob es in modernen Systemen überhaupt noch möglich ist Programme zu schreiben welche wirklich auf der Hardware ausgeführt werden und nicht nur als ein Unterprogramm des Systems läuft in einer eigenen kleinen Welt.
Dem Konzept von Mikelectric was ein Betriebssystem darstellt muss aber schon entschieden wiedersprechen. DOS hat eben (wie auch MacOS < OSX) kein wirkliches System bereitgestellt das sich zwischen Anwendungsprogramm und Hardware gestellt hat. Sowohl das BIOS als auch DOS haben lediglich aufrufbare/anspringbare Funktionen bereit gestellt um sich mit der Hardware (einigermassen bequem) zu unterhalt. Das konnte, musste man aber nicht nutzen. Selbst in (damals atemberaubend hohen Hochsprachen wie) BASIC konnte man mittels peek/poke direkt Maschinencode in die CPU pumpen. "Richtige" Betriebsssteme (Windows ab NT, Unices und Linux) erlauben das nicht mehr weil alle Adressen durch die MMU (Memory Management Unit) umgewandelt werden - Programme "sehen" nur einen virtuellen Adressraum. Direkter Speicherzugriff ist also nicht. Das ist Funktionalität die die CPU zur Verfügung stellt. Betriebsystem (Kernel) und Anwendungen laufen in unterschiedlichen "Ringen", nur der Betriebssystem-Ring hat Zugriff auf die Harware (Nur zur Info: der Wechsel zwischen den Ringen ist relativ "teuer", wenn Daten über diese Grenze müssen dann kostet das Performance. Das ist gerade im Audiobereich sehr wichtig und (hier kommen wir wieder zum Thema) einer der Gründe für Jack. Dort werden die Audiodatenblöcke eben nicht von Programm A and den Kernel gegeben, nur damit der sie dann an Programm B ausliefert (zwei Grenzübergänge) sondern die Daten werden über "shared memory" (not time to explain 
relativ performant durchgereicht). Bei "richtigem" ASIO werden die Audiodaten an der/den Abstraktionsschichten des OS vorbei direkt an die Soundkarte geliefert.
Was die Definition eines Betriebssystems betrifft, seid ihr beide völlig auf dem Holzweg. Ihr vermischt hier Dinge, die allenfalls aus Sicht eines Anwendungsentwicklers interessant sind. Selbstverständlich ist DOS genauso ein Betriebssystem wie Raspbian, UNIX, VAX VMS, IBM OS2, OSX, Windows xx oder sonstwas. Ohne ein Betriebssystem schreibt keiner auch nur irgendetwas in irgendeine Speicherstelle. Erst ein Betriebssystem erweckt einen Computer zum Leben. Deshalb hat es ja auch den Namen "Betriebssystem". Dass es Betriebssysteme mit unterschiedlichen Eigenschaften gibt und auch Betriebssysteme aus mehreren Ebenen bestehen können, die sich gegenseitig überlagern, ist ein ganz anderes Thema. Da gibt es heute natürlich Strategien, wie die Prozesse geschützt werden und wie verhindert wird, dass der Anwender Schaden am System anrichtet.
Ein BIOS ist grundlegender Teil eines PC Betriebssystems. Darauf aufbauend kann z. B. DOS, Windows, Linux oder anderes verwendet werden, das die Funktionalität des BIOS in irgendeiner Weise nutzt und dieses somit überlagert.
Grundsätzlich kann jeder Prozessor in Maschinensprache programmiert werden, denn es ist das Einzige, was ein Prozessor wirklich versteht. Wenn ein übergeordnetes Betriebssystem das verhindert, ist das ein anderes Problem. Die nächsthöhere Ebene in der Programmierung ist Assembler. Hier werden Maschinenbefehle mit lesbaren Codes programmiert und anschließend zu Maschinencode assembliert. Erst in den Hochsprachen wie Pascal, Cobol, Fortran, C, C++ usw. wurden die Befehle immer weiter vom Maschinencode abstrahiert. Letztlich wird aber beim Compilieren wieder Maschinencode erzeugt, mit dem der Prozessor etwas anfangen kann.
Letztlich wird aber beim Compilieren wieder Maschinencode erzeugt, mit dem der Prozessor etwas anfangen kann.
Ein Compiler erzeugt doch im Grunde nur noch einen Code der vom Betriebssystem ausgeführt werden kann. Ein modernes Betriebssystem ist quasi der Interpret des Ergebnisses. Natürlich werden gewisse Funktionen an die cpu weitergegeben, aber das meiste sind ja nur Funktionen des Systems für die dieses Programm compiliert wurde.
Diese Lowlevel Programmierung macht ja in der Praxis ein normaler Programmierer nicht mehr und selbst Assembler Code der sehr nahe an der Hardware ist läuft ja überwiegend in virtuellen Container die das Betriebssystem kontrolliert. Jede cpu der letzten zehn Jahre führt vielen Code nur virtualisiert aus.
Übrigens ein komplettes Betriebssystem schreiben ist recht simpel. Da gibt es viele Beispiele, die können nur nicht viel und jede Anwendung muss sich zum alles selber kümmern. So was braucht man heute aber außer in speziellen Szenarien nicht mehr.
Compiliert wird immer zu Maschinencode. Es gibt außerhalb der Compiler-Sprachen noch andere Ebenen der Programmierung, wie die Interpreter-Sprachen, z. B. klassischerweise BASIC (gibt es aber auch als Compiler) oder CNC für Maschinensteuerungen. Der Interpreter übersetzt das Programm erst zur Laufzeit in Maschinencode. Darüberhinaus natürlich alle möglichen Arten von Anwendungen die auch "programmiert" werden wollen um bestimmte Funktionen auszuführen. Es handelt sich dabei mehr um "Parametrieren" als um "Programmieren". Hierzu würde ich z. B. auch GrandOrgue ODF zählen.
Je weiter man sich in den Schichten um den Betriebssystemkern nach außen bewegt, um so länger der Weg bis zum ausführbaren Maschinenbefehl. Umso langsamer läuft ein Programm.
Fakt ist aber: NICHTS geht ohne Betriebssystem!
Bezogen auf einen Soundtreiber, der nichts anderes als ein Programm darstellt, das eine Schnittstelle zwischen Anwendung und D/A- und A/D-Wandler zur Verfügung stellt, kann dieser Soundtreiber auf unterschiedliche Art programmiert worden sein. Viele Hersteller geben sich wenig Mühe und programmieren einen Treiber, der durch mehrere Schichten hindurch arbeitet und dementsprechend langsam ist, d. h. zu hoher Latenz führt. Für einfache Anwendungen wie Musikhören oder Computerpiele reicht das auch aus und die Latenz stört nicht.
Ein ASIO konformer Treiber bietet zum einen einen Schnittstellenstandard für Anwendungen im Musikbereich und gleichzeitig eine optimierte Programmierung, die zu möglichst geringer Latenz führt. Das erfordert mehr Gehirnschmalz bei der Programmierung des Treibers. Wird deshalb eher nur von Anbietern teurerer Audiohardware gemacht und speziell auf deren spezifische Hardware zugeschnitten.
Der Asio4all-Treiber ist nichts anderes als ein optimierter Treiber nach ASIO Standard, der entwickelt wurde, um die gängigen Soundchips, die meistens auf den Mainboards eingesetzt werden, mit einem latenzarmen Treiber für Musikanwendung nutzen zu können. Die Leistungssteigerung, bzw. Latenzverringerung ist oft als erheblich einzustufen, gegenüber den einfachen, mitgelieferten Soundtreibern!
Wo der Soundchip physikalisch sitzt, ob direkt auf dem Mainboard, auf einer eingesteckten Soundkarte, oder entfernt in einem Soundmodul über USB oder Firewire angeschlossen, spielt im Prinzip keine Rolle.
ASIO ist der Soundtreiber und nicht ein langsamer Soundtreiber von Windows oder der Soundkarte. Damit die Schnittstelle zur Soundkarte funktioniert, sollte der ASIO-Treiber vom Soundkarten-Hersteller geliefert werden. Was ASIO4ALL unter der Haube treibt, weiß ich nicht. Den hatte ich mit Onboard-Sound verwendet, ging ganz gut, bis es aus unerfindlichen Gründen nicht mehr funktionierte.
Das war dann der Ich-hab-die-Schnauze-Voll-Wechsel zu RME. Seitdem läuft alles rund mit dem hervorragenden RME-ASIO-Treiber.
Habe auch ein RME Digiface, mit welchem Soundtreiber läuft das in GO am besten?
B) Building on OS X
===================
1. Prequisites:
- OS X >= 10.11
- Xcode >= 7.3
- homebrew
an VPO-organist: Xcode habe ich über terminal installiert, aber bei homebrew ist mir das nicht gelungen. Ich bin der Anleitung in
https://geekflare.com/de/homebrew-intro-installing/
gefolgt. Nach der Eingabe des Befehls
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
kommt die Abfrage des Admin-Passors, das sich aber nicht eingeben lsst, weil an der Eingabe stelle ein Schlüsselzeichen auftaucht, was Schreibvorgänge verhindert (siehe Screenshot. Was mache ich falsch?Ich denke das kommt daher, dass du das Passwort zuvor drei Mal falsch eingegeben hast, wie man auf dem Screenshot sieht.
Hast du vielleicht nicht das richtige Passwort (Admin?) verwendet?
Könnte man das von euch gebaute Paket nicht hier teilen?
Das "Schlüsselzeichen" benutzt MacOS um das eig. Passwort nicht anzuzeigen (das machen Webbrowser auch - nur eben meistens mit Punkten oder Sternen).
Wenn Du mir verrätst, wie man ein Paket baut?
Nö, aus Prinzip nicht... Na gut, wenn ich ehrlich bin, ich habe keine Ahnung vom Mac und wie man dort Pakete erstellt 
Sollte aber theoretisch machbar sein.
