Echtzeit Betriebssysteme.

  • Ersteller Loop_Breaker
  • Erstellt am
Okay dann fasse ich das für mich mal so zuzammen das asio und coreaudio sich verhalten wie alsa + soundserver unter Linux.

Ich habe null Ahnung davon, wie sich irgendwas unter Linux verhält, aber Core Audio und ASIO sind schon zwei ziemlich unterschiedliche Paar Schuhe. Bei ASIO handelt es sich um eine Treiberarchitektur, die versucht, die Windows-interne Geschichte (also WDM) zu umgehen, damit kleinste Latenzen möglich sind. Core Audio hingegen ist sozusagen das OSX Equivalent für WDM. Ermöglicht aber von Haus aus, anders als WDM, bereits sehr kleine Latenzen, weshalb viele Interfaces, sofern denn class compliant gehalten, auch komplett ohne zusätzliche Treiber für OSX geliefert werden und dennoch meistens zumindest einigermaßen laufen. Extra Treiber für OSX braucht man nur dann, um nochmals niedrigere Latenzen zu erreichen.
Mal als ganz grobe Hausnummer, von welchen Werten wir hier so reden: Mein Zoom UAC-2 bietet beide Betriebsmodi, class compliant alleine (gut, wenn man das bspw. mit einem älteren Rechner oder einem Tablet benutzen möchte) und per Treiber. Mit Treiber komme ich bei 64 Samples auf 5,9ms RTL, im CC Modus immerhin auch noch auf 8,3ms - ein Wert, der sich unter Windows niemals nur per WDM erreichen lässt (ok, ich glaube, Cakewalk/Sonar hat da mal was versucht, weiß aber nichts genaues...), weshalb man bei CC Interfaces unter Windows meist ASIO4All bemühen muss.

Wie dem auch sei, unter OSX braucht es eben nicht zwingend die Umwege über einen extra Treiber, wenn auch die Performance mit einem gut programmierten Treiber nochmal deutlich besser ist.
 
Mal eine Frage: sowas wie diese Soundgrid-Server von Waves oder UAD-Karten: gehts um sowas, nur diesmal für alle Plugins statt nur hauseigene? Oder ist das was völlig anderes?

Ich verstehe es so, dass es eigentlich genau darum gehen soll, die Hersteller, welche bisher aber auf den ELK-Zug aufgesprungen sind, doch lieber wieder nur ihr eigenes Süppchen kochen wollen.
 
Also ehrlich gesagt, verstehe ich bei eurer Diskussion nur Bahnhof. :eek:
Ich bin auch eher von der Plug´n Play-Fraktion - mir ist egal, wie es funktioniert.

Allerdings interessiert mich so eine PC-Erweiterung-DSP-"Ich-berechne-dir-alles-mit-wenig-Latenz-und-ohne-deine-CPU-zu-belasten"-Option natürlich auch.
Mal eine Frage: sowas wie diese Soundgrid-Server von Waves oder UAD-Karten: gehts um sowas, nur diesmal für alle Plugins statt nur hauseigene? Oder ist das was völlig anderes?

Würde behaupten, hier geht es genau um die andere Richtung.
Wir wollen ein PC-OS was echtzeitfähig ist, nicht mit den PC ein Echtzeit-Kastel steuern...


B.t.w. Um einfach ein "Echtzeit System" mit Bitwig u-he und co zu haben, muss man nur:
z.B. Ubuntu-Studio installieren (https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel)
Bitwig, u-he e.t.c. installieren.
Wie in Windows/Mac konfigurieren > man kann loslegen.

Das Thema was mir zurzeit in diesen Thread wichtig ist, ist reine Bonus-Aufgaben...
 
Passt schon. WDM / CoreAudio sind Audio-Treiber + Soundserver. ASIO ist ein Eigener Treiber + Soundserver weil WDM nicht Musikergeeignet ist.

Unter Linux wird halt recht sauber unterschieden was Treiber ist und was Soundserver ist. Der Treiber läuft im Kernel (für das Gerät ja es gibt für Classcompilant auch generische Treiber) und der Server im User-Kontext. Ob bei Mac oder Win der Soundserver jetzt im User oder Kernel läuft weiß ich nicht ist aber auch nicht relevant.

Unter Linux sind die Treiber immer wie bei ASIO voll konfigurabel weswegen es kein weiteres System bedarf. Die Soundserver darf man sich dann halt nach eigenen Belieben aussuchen und einrichten.

Pulse-Audio ist halt für die Breite Masse der User gedacht und Jack für Leute die Musik (recording) machen.
 
Weiß Jemand was es mit diesen ominösen HardwarePuffer in Soundkarten auf sich hat?

Warum kommen, meist, wenn man ASIO verwendet Störgeräusche, und bei WDM (normaler Windows Ton) nicht?
Diese "ASIO-Störgeräusche" lassen sich mit den Puffer verändern, je niedriger der Puffer, desto hochfrequenter die Störgeräusche, bei 128 kriegt man sie fast nicht mehr mit, aber 32 und 64 Sampels deutlich hörbar... (wenn hörbar)
(ist mir schon auf unzähligen System aufgefallen, zurzeit kann ich es auch leicht bei mir nachprüfen, wenn ich meinen Wandler als USB-Soundkarte benutze, und seinen ASIO-Treiber verwende. Vermutlich wegen einer Masseschleife // drum hab ich den Wandler normalerweise via Glasfaser auf der Soundkarte hängen)
 
Ein DAC / ADC wandelt mit 44.1 / 48 / ... kHz kontinuierlich PCM in Musik / Musik in PCM.
Ein DSP kann mit so einem Kontinuierlich Datenstrom auch Arbeiter, er ist ja dafür gebaut. Ein PC kann das so nicht. Deswegen werden n Samples in den HW Puffer gesammelt und wenn der Voll ist wird der PC per HD-Interrupt aufgefordert die Daten abzuholen / neue Abzuliefern. Der PC Arbeiter also Blockweise. Die Größe des Puffers und die Sampling-Frequenz bestimmen somit die minimal mögliche Latenz.
Audio - > ADC - > Puffer - > Verarbeitung - > Puffer - > DAC - > Audio

Genau genommen sind es min 2 Puffer einer der Geschrieben / Gelesen wird und einer der Verarbeitet wird und es wird ständig getauscht.
 
Ich habe null Ahnung davon, wie sich irgendwas unter Linux verhält, aber Core Audio und ASIO sind schon zwei ziemlich unterschiedliche Paar Schuhe. Bei ASIO handelt es sich um eine Treiberarchitektur, die versucht, die Windows-interne Geschichte (also WDM) zu umgehen, damit kleinste Latenzen möglich sind. Core Audio hingegen ist sozusagen das OSX Equivalent für WDM. Ermöglicht aber von Haus aus, anders als WDM, bereits sehr kleine Latenzen, weshalb viele Interfaces, sofern denn class compliant gehalten, auch komplett ohne zusätzliche Treiber für OSX geliefert werden und dennoch meistens zumindest einigermaßen laufen. Extra Treiber für OSX braucht man nur dann, um nochmals niedrigere Latenzen zu erreichen.
Mal als ganz grobe Hausnummer, von welchen Werten wir hier so reden: Mein Zoom UAC-2 bietet beide Betriebsmodi, class compliant alleine (gut, wenn man das bspw. mit einem älteren Rechner oder einem Tablet benutzen möchte) und per Treiber. Mit Treiber komme ich bei 64 Samples auf 5,9ms RTL, im CC Modus immerhin auch noch auf 8,3ms - ein Wert, der sich unter Windows niemals nur per WDM erreichen lässt (ok, ich glaube, Cakewalk/Sonar hat da mal was versucht, weiß aber nichts genaues...), weshalb man bei CC Interfaces unter Windows meist ASIO4All bemühen muss.

Wie dem auch sei, unter OSX braucht es eben nicht zwingend die Umwege über einen extra Treiber, wenn auch die Performance mit einem gut programmierten Treiber nochmal deutlich besser ist.

Windows hat ja mittlerweile mit WASAPI nachgelegt, also ich denke es macht (heutzutage) mehr Sinn Core Audio und WASAPI (statt WDM) gegenüberzustellen. Ich zumindest bekomme mit WASAPI schon recht brauchbare Latenzen.
 
Ich habe null Ahnung davon, wie sich irgendwas unter Linux verhält, aber Core Audio und ASIO sind schon zwei ziemlich unterschiedliche Paar Schuhe. Bei ASIO handelt es sich um eine Treiberarchitektur, die versucht, die Windows-interne Geschichte (also WDM) zu umgehen, damit kleinste Latenzen möglich sind. Core Audio hingegen ist sozusagen das OSX Equivalent für WDM. Ermöglicht aber von Haus aus, anders als WDM, bereits sehr kleine Latenzen, weshalb viele Interfaces, sofern denn class compliant gehalten, auch komplett ohne zusätzliche Treiber für OSX geliefert werden und dennoch meistens zumindest einigermaßen laufen. Extra Treiber für OSX braucht man nur dann, um nochmals niedrigere Latenzen zu erreichen.
Mal als ganz grobe Hausnummer, von welchen Werten wir hier so reden: Mein Zoom UAC-2 bietet beide Betriebsmodi, class compliant alleine (gut, wenn man das bspw. mit einem älteren Rechner oder einem Tablet benutzen möchte) und per Treiber. Mit Treiber komme ich bei 64 Samples auf 5,9ms RTL, im CC Modus immerhin auch noch auf 8,3ms - ein Wert, der sich unter Windows niemals nur per WDM erreichen lässt (ok, ich glaube, Cakewalk/Sonar hat da mal was versucht, weiß aber nichts genaues...), weshalb man bei CC Interfaces unter Windows meist ASIO4All bemühen muss.

Wie dem auch sei, unter OSX braucht es eben nicht zwingend die Umwege über einen extra Treiber, wenn auch die Performance mit einem gut programmierten Treiber nochmal deutlich besser ist.

Windows hat ja mittlerweile mit WASAPI nachgelegt, also ich denke es macht (heutzutage) mehr Sinn Core Audio und WASAPI (statt WDM) gegenüberzustellen. Ich zumindest bekomme mit WASAPI schon recht brauchbare Latenzen.

so ist es, mit WASAPI ist man bei Windows 10 auf den richtigen Weg gekommen, wobei es genau gesehen zwei verschiedene WASAPI Verbindungen gibt. Es gibt shared und exclusive WASAPI. Das Verhalten der Schnittstellen um im Low Latency Modus zu arbeiten ( < 10ms) muss allerdings von der Anwendung bei den neuen Windows 10 Schnittstellen angefordert werden. Genaueres kann man hier nachlesen:
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio

Unabhängig davon konnten die WASAPI Latenzen seit Windows 8.1 auch generell reduziert werden, was ebenfalls im (englischen) Artikel steht:

"Bei allen Anwendungen, die Audio verwenden, wird die Round-Trip-Latenz um 4,5-16 ms verringert, ohne dass Codeänderungen oder Treiberaktualisierungen vorgenommen werden müssen, verglichen mit Windows 8.1. .a) Anwendungen, die Fließkommazahlen verwenden, haben eine niedrigere Latenzzeit von 16 ms. b) Anwendungen, die Ganzzahlen benutzen, haben eine niedrigere Latenz von 4,5 ms.

Vor Windows 10 habe das System alle Audiodaten in einen Buffer mit 10 ms Latenz geschrieben, wobei ein neuer Audiotreiber jetzt niedrigere Buffer anfordern könne bis 1ms. Die 10 ms haben bedeutet dass die CPU alle 10 ms aus dem "Schlaf" aufgeweckt wurde um die Audiodaten im Buffer zu verarbeiten, bei 1 ms wird die CPU alle 1 Millisekunden aus dem Schlaf geweckt (falls sie überhaupt schläft und nicht mit anderen Aufgaben beschäftigt ist). Ursache für die früheren minimalen Latenzen von 10ms seien die Stromsparfunktion, weil tiefe Latenzen mehr Strom benötigen würde und daher die Batterie belaste.

Offensichtlich hatte Microsoft früher jedoch auch an das Festnetz angeschlossene PC immer mit diesem minimalen 10ms Buffer ausgestattet, was mir jetzt die Stromsparfunktion der Batterie als Begründung aus meiner Sicht eher billige Ausrede ist.

Microsoft hatte sich früher (bei seinen eigenen Schnittstellen) schlicht zu wenig um Audio Professionals gekümmert. Auch wird erst mit dem nächsten Funktions-Upgrade von Windows 10 eine andere mühsame Behinderung für unsere DAW's aus dem Wege geräumt, nämlich die Möglichkeit mehr als 120 Plugin einzusetzen (was bereits seit Windows XP, Vista der Fall ist ). Ursache dafür liegt in der programmierten Schnittstelle von Windows um Dll Funktionen aufzurufen.

Auch gibt es noch eine dritte Baustelle mit Windows 10, nämlich die Begrenzung der Multimedia Audio Funktionen auf 12 CPU Kerne (nur unter Windows 10 aber).
Ursache für diese Behinderung von mit Windows Audio arbeitenden Programmen sei die Verlegung der Windows Multimedia Schnittstelle neu in den Kernel Mode des Systems, früher lag diese MMCSS im User Mode des Systems und konnte daher mehr Prozessor- Threads abarbeiten.

Windows 10 ist also aus meiner Sicht noch immer nicht generell besser als seine Vorgänger, leider. Und das notwendige Windows 10 Release um mehr als 120 Plugins gleichzeitig auszuführen könnte sich auch wieder verzögern, da Microsoft offenbar wieder Schwierigkeiten hat um wie geplant das nächste Funktionsupgrade sauber genug hinzukriegen. Das im April geplante Upgrade könnte sich also um 1-2 Monate verzögern. Bei mir auf jeden Fall, denn ich Upgrade meine Systeme generell erst mit 3-4 Monaten Verzögerung.
Auch diese alle 6 Monate stattfindenen Release sind ein gutes Argument gegen Windows 10, jedenfalls für alle jene Personen die wenig Zeit haben um das Betriebssystem neu aufzusetzen und allenfalls bereits registrierte Software wiederholt aktivieren zu müssen.

Schon aus diesem Grund (Langfrisitg sicher laufende registrierte Software ohne Update Druck) wäre für mich ein eigenes Musik Betriebssystem eine echte Erleichterung.

Aus meiner Sicht gibt es beim Betriebssystem Kern Windows seit vielen Jahren keine wirklich notwendigen Neuerungen mehr. Jegliche den Menschen als Neuigkeit erscheinenden Features basieren nicht auf den Kernfunktionen eines Betriebssystems, sondern liegen in neuer Zusatzsoftware bis hin zu den kleinen Apps die mit einem OS nicht viel zu tun haben. Auch das gewandelte Erscheinungsbild von Windows hat wenig mit den notwendigen Kernfunktionen zu tun.
Auch die stetige Weiterentwicklung der Webbrowser haben wenig mit dem Betriebssystem am Hut.
Ein gutes Musik-OS könnte viele Jahre bestehen ohne das man etwas an den Schittstellen ändern müsste, Patches wären zwar auch hier möglich, aber nicht notwendig sie vornehmen zu müssen.
 
Zuletzt bearbeitet:
Sehr interessant...

Musik Betriebssystem: +1
(würde sich doch beinhart ein realtime Linux, mit minimalistischer Grafischer Oberfläche anbieten...)
 
Stimmt, ich hatte die WASAPI Nummer ganz vergessen (arbeite eben selber unter OSX und auf dem Rechner des wWs ist das eher irrelevant, auch wenn ich manchmal ein paar Sachen dort ausprobiere).
Für mich ist das etwas, was irgendwie zu spät kommt (wobei ich mich gerne vom Gegenteil überzeugen lasse), denn mittlerweile ist ASIO ja ein durchaus gefahrenerprobtes Protokoll, welches in den allermeisten Fällen dann eben auch sauber läuft.
Aktuell scheint jedenfalls OSX noch die bessere Variante für Multiclient-Geschichten zu sein - aber es stellt sich natürlich die Frage, wie oft man das wirklich braucht. Ich nutze das eigentlich nur zum Ausprobieren, weniger beim eigentlichen Musikmachen. Klar, ist schon ganz nett, wenn man mal 'n Garageband Song bekommt und nicht vorher extra Logic schließen muss, damit das auch läuft (und das mit egal welchem Interface), aber in der Praxis kommt's eben dann doch nicht so oft vor.

Wie dem auch sei, ich würde zum aktuellen Zeitpunkt - zumindest noch - eine dezidierte Musik-Arbeitsumgebung (ob jetzt auf generischer oder spezieller Hardware laufend, das sei mal dahingestellt) für wünschenswert halten und so etwas, falls ausgereift, auch persönlich in Betracht ziehen.

Allein (von daher das "noch"), ich glaube, dass da den Leuten, die so etwas machen, die Zeit davon läuft. Was für uns Nutzer übrigens eher gut ist. Denn auch wenn es aktuell noch diverse Dinge gibt, die man umschiffen muss, wenn man sich ein standard-rechnerbasiertes Setup zusammenschraubt, so werden die doch quasi jeden Tag weniger.

In nicht allzu ferner Zukunft wird's eben auch Convertibles, Laptops und andere kleinformatige Recher geben, die genug Leistung bringen, um so gut wie allen Anforderungen zu genügen, und im Zweifelsfall kann man die eben auch stacken, was ja jetzt schon (bspw. über den VSL-Kram) recht gut klappt. Ferner erleben wir in punkto Kleinstlatenzen aktuell auch endlich mal wieder einen nennenswerten Schritt nach vorne (nach beinahe 10 - oder sogar mehr - Jahren quasi absoluten Stillstands), da sich mehr und mehr Firmen dann doch um gescheite Treiber kümmern und es mit TB auch ein Protokoll gibt, über welches das anscheinend etwas leichter zu realisieren ist.
Wenn ich mir anschaue, dass ich auf einem 9 Jahre alten Rechner mit einem 200€ Interface bereits durchgehend mit 64 (oder sogar 32, wenn es denn gerade nicht Alchemy sein muss) Samples und resultierender 4-6ms Latenz arbeiten kann, dann ist es alles andere als illusorisch, zu vermuten, dass es in wenigen Jahren selbst für Ottonormalsequenzernutzer möglich sein wird, das auf Werte um die 2-3ms (dauerhaft und stabil) runterzuschrauben. Gehen tut das ja jetzt bereits, aber man muss dafür halt noch recht tief ins Portemonnaie greifen oder einige Widrigkeiten (wie etwa Remote-Rechner) in Kauf nehmen. Und dann hätte ein dezidiertes OS mehr oder minder ausgespielt, denn die eine extra Millisekunde, die man dann vielleicht noch gewinnen kann, ist ja selbst für Leute, deren Timingbewusstsein sehr akkurat ist, so gut wie zu vernachlässigen.

Hinsichtlich der Kontrolle eines solchen Systems, speziell im Live-Einsatz, wird sich sicherlich auch noch was tun (auch wenn ich tatsächlich ziemlich erstaunt bin, dass es außer dem OSX-gebundenen Mainstage wirklich recht wenig Lösungen gibt, von Live vielleicht mal abgesehen, aber das ist ja meist als Track-Schleuder in Gebrauch), ansatzweise sieht man ja jetzt schon ganz brauchbare Tablet/Smartphone-Lösungen. Da braucht man dann eben nur noch ein 2-4 HE Rack (je nach Anschlussbedarf) und ein günstiges Controller-Tablet, fertig ist der Lack.
 
Sehr interessant...

Musik Betriebssystem: +1
(würde sich doch beinhart ein realtime Linux, mit minimalistischer Grafischer Oberfläche anbieten...)

An sich pflichte ich bei. Aber wenn sich da nicht wirklich auf breiter Front was tut, wird das nicht passieren. Linux gibt's ja nun schon viele Jahre - und das Angebot an Musiksoftware ist doch immer noch sehr überschaubar. So lange da nicht einer der Platzhirschen aufspringt, also Firmen vom Kaliber Steinberg und Native Instruments, wird sich das mMn leider auch kaum ändern. Klar, ist schön, dass es Bitwig und den U-He Kram für Linux gibt. Aber was ist mit den ganzen Sample-Libraries? Oder überhaupt mit einem umfangreich ausgestatteten Sampler? Oder mit einem wirklich komplett ausgestatteten Sequenzer, der bspw. im High End Filmveronungsgeschäft mitspielen könnte? Ohja, ich weiß, dass es da mittlerweile auch ein paar Reaper-User gibt. Aber in den großen Studios spielen Bitwig, Reaper und die Linux Geschichten a la Ardour eben überhaupt keine Rolle, da laufen ProTools, Cubendo, vielleicht mal Logic und vielleicht mal DP. Inkl. aller möglichen, fast ausschließlich Kontakt-basierten Libraries.
Ich persönlich würde, wenn ich mir ein dezidiertes, skalierbares System zusammenschrauben würde, aktuell jedenfalls auf Windows setzen (auch wenn ich derzeit mit einem Mac arbeite). Das kann man ja auch von der nervigen Umwelt mehr oder minder effizient abschotten, indem man eben nicht ins Netz geht und sich auch keine fragwürdige Software installiert.
 
win10 ist ansich, nicht nur m.M., eine fragwürdige Software...

VST3 gibts von Steinberg auch für Linux.
Kontakt immer noch VST2.
Vielleicht gibts dann auch Linux support für Kontakt, wenn sich NI mal VST3 hingibt.

Die Nachfrage, ist gegeben...
 

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Antworten
3
Aufrufe
2K
moonbooter
moonbooter
R
Antworten
16
Aufrufe
36K
daslicht
daslicht
greenman
  • Artikel
Antworten
4
Aufrufe
50K
sigale
sigale

Oft gelesene Themen

Zurück
Oben