umstieg auf ubuntu ... selbsttötung oder erleuchtung

[changeling]

alsa-firmware ist in/bei jeder Distribution mit dabei.

Bei irgendeinem Ubuntu war es (oder alsa-firmware-loaders) aber mal nicht dabei und ich hatte dadurch ziemlichen Brass.

 

[khz]

Never ask a DAU (Dümmster anzunehmender User)
Also müßte ich auch Googlen und mein deutsch ist sowas von kaputt - in Müll geschmissen - das ich schlecht verständlich schreiben kann ... bzw sind hier nicht noch andere mit mehr Wissen als ich?
Naja erst mal Rosenheim Cops \o/
bbl

 

[lilak]

haha rosenheim cops, mann ich komm ursprünglich aus der ecke. das ist eine bayrische rapper posse?

 

[khz]

Das ist Ideal wenn man den Tag über

 

[dbra]

Sechs Screens nur zum Chatten? Ob das Spaß macht...

 

[mink99]

ja die logik würde mich auch mal interessieren. wie soll bei der übergabe von daten von einem programm zum nächsten latenzen im millisekundenbereich entstehen? erklärung bitte!

Das geht so aus der Grafik hervor ....

Aber bevor wir hier in einer Diskussion über ein Detail das eigentliche Problem aus dem Auge verlieren. Sorry jetzt kommt Informatik , betriebssystemkonzepte ....

Ich halte das Konzept einer integrierten daw für das immer noch erfolgversprechendste für digitale Studios.

Wie müsste es denn sein, was sind die Anforderungen ?

1.) systemweite (Betriebssystem-) Dienste

Eine daw greift über standardisierte systemschnittstellen (API s) auf die Hardware Treiber zu. Diese systemschnittstellen beinhalten ebenfalls den Übergang vom usermode in den kernelmode, bei dem auf die Hardware zugegriffen wird. Hier bieten die kernelmode Komponenten der systembibliotheken ebenfalls eine standardisierte API an, die von den hardwaretreibern bedient wird.

Für Daws haben diese APIs zwei ausprägungen, midi und Audio . Systemseitig stehen ebenfalls infrastrukturdienste wie Timer und Notifikationen sowie peripheriedienste wie USB oder firewireservices zur Verfügung.

Das war's, mehr braucht es nicht, was systemseitig zur Verfügung gestellt werden muss. Dafür würde ein alsa oder oss reichen.

(3:1 für Borussia !)

2.) applikationsnahe Dienste , die nur auf Anforderung zur Verfügung stehen
2.1)
Hier braucht es eine Plugin Schnittstelle , die bestimmte audio und midi Komponenten dynamisch laden kann und über die eine daw bestimmte teile der Audio oder midiverarbeitung delegieren kann. Diese Komponenten werden im applikationskontext der daw ausgeführt . Das ladspa system könnte dies analog der Vst oder Au Schnittstelle erledigen.
2.2)
Eine kommunikationsschnittstelle , in der unabhängige Applikationen untereinander audio und midi Daten hin und herstreamen können . Dabei bleibt allerdings eine Anwendung Master, die die systemzugriffe implementiert und darüber auch das latenzmanagement durchführt. Nach dem rückstandsfreien entsorgen von 80% des Codes kann jack den Rest übernehmen .

.......

Bei der bestehenden audioarchitektur sind etliche Basics aus der Informatik ignoriert worden, u.a. Kiss, pfeif nicht wenn du pisst , Separation of concerns und so weiter, dafür aber etliche antipatterns umgesetzt worden. Das meiste kann weg.

(4:1 ...)

Zurück zur eigentlichen frage. Es besteht keine Notwendigkeit, dass Programme Daten so massiv pipen. Und natürlich kostet jeder datentransfer zwischen Applikationen massiv zeit . Wir sind hier im Bereich interprozesskommunikation , und da ist jeder Aufruf teuer. Und wenn die datenweitergabe noch per Push erfolgt, also vom Sender aktiv initiiert wird, dann Rauschen die Millisekunden nur so durch die CPU.

 

[Anonymous]

Das ist Ideal wenn man den Tag über

in der folterkammer sitzt?

[ http://awesome.naquadah.org/images/6mon.medium.png (•BILDLINK) ]

 

[dbra]

ja die logik würde mich auch mal interessieren. wie soll bei der übergabe von daten von einem programm zum nächsten latenzen im millisekundenbereich entstehen? erklärung bitte!

Das geht so aus der Grafik hervor ....

Stimmt so aber nicht. Die Grafik macht keine Aussage in dieser Richtung.

Aber bevor wir hier in einer Diskussion über ein Detail das eigentliche Problem aus dem Auge verlieren. Sorry jetzt kommt Informatik , betriebssystemkonzepte ....

Ich halte das Konzept einer integrierten daw für das immer noch erfolgversprechendste für digitale Studios.

Wie müsste es denn sein, was sind die Anforderungen ?

1.) systemweite (Betriebssystem-) Dienste

Eine daw greift über standardisierte systemschnittstellen (API s) auf die Hardware Treiber zu. Diese systemschnittstellen beinhalten ebenfalls den Übergang vom usermode in den kernelmode, bei dem auf die Hardware zugegriffen wird. Hier bieten die kernelmode Komponenten der systembibliotheken ebenfalls eine standardisierte API an, die von den hardwaretreibern bedient wird.

Für Daws haben diese APIs zwei ausprägungen, midi und Audio . Systemseitig stehen ebenfalls infrastrukturdienste wie Timer und Notifikationen sowie peripheriedienste wie USB oder firewireservices zur Verfügung.

Das war's, mehr braucht es nicht, was systemseitig zur Verfügung gestellt werden muss. Dafür würde ein alsa oder oss reichen.

2.) applikationsnahe Dienste , die nur auf Anforderung zur Verfügung stehen
2.1)
Hier braucht es eine Plugin Schnittstelle , die bestimmte audio und midi Komponenten dynamisch laden kann und über die eine daw bestimmte teile der Audio oder midiverarbeitung delegieren kann. Diese Komponenten werden im applikationskontext der daw ausgeführt . Das ladspa system könnte dies analog der Vst oder Au Schnittstelle erledigen.
2.2)
Eine kommunikationsschnittstelle , in der unabhängige Applikationen untereinander audio und midi Daten hin und herstreamen können . Dabei bleibt allerdings eine Anwendung Master, die die systemzugriffe implementiert und darüber auch das latenzmanagement durchführt. Nach dem rückstandsfreien entsorgen von 80% des Codes kann jack den Rest übernehmen .

Eigentlich hast du hier sehr schön die Audio-Architektur unter Linux mit ALSA und Jack beschrieben... (EDIT: Bis auf den Master) Wie du darauf kommst, 80% des Jack-Codes entsorgen zu wollen, verstehe ich nicht. Was macht es denn "zweckfremdes"?

Bei der bestehenden audioarchitektur sind etliche Basics aus der Informatik ignoriert worden, u.a. Kiss, pfeif nicht wenn du pisst , Separation of concerns und so weiter, dafür aber etliche antipatterns umgesetzt worden. Das meiste kann weg.

Wo wurde bei ALSA oder Jack das KISS-Prinzip verletzt?

Zurück zur eigentlichen frage. Es besteht keine Notwendigkeit, dass Programme Daten so massiv pipen. Und natürlich kostet jeder datentransfer zwischen Applikationen massiv zeit . Wir sind hier im Bereich interprozesskommunikation , und da ist jeder Aufruf teuer. Und wenn die datenweitergabe noch per Push erfolgt, also vom Sender aktiv initiiert wird, dann Rauschen die Millisekunden nur so durch die CPU.

Das sagt nur jemand, der noch nie damit gearbeitet hat. Mal ernsthaft: Die freie Verschaltbarkeit ist wesentlich flexibler, als der blöde Plug-In-Mist (den es ja mit LADSPA und LV2 auch gibt). Außerdem reißt dann ein fehlerhaftes Plugin nicht die ganze DAW in den Abgrund. Ich weiß nicht, ob du's weißt: Sämtliche Ardour-Tracks und -Busse sind von außen per Jack sichtbar.

Die Datenweitergabe erfolgt bei Jack übrigens nicht per Push, Jack ruft Callbacks der Clients auf, die die Daten liefern. Ob bei Jack die IPC so teuer ist, weiß ich garnicht so genau... Bin jetzt kurz davor, mir die Jack-API mal näher anzusehen. EDIT: Bei 10 Clients sind es halt 20 Context-Switches mehr. Na und? Wir leben im Zeitalter der GHz-Prozessoren...

 

[dbra]

Noch eine kleine Ergänzung:

Eine kommunikationsschnittstelle , in der unabhängige Applikationen untereinander audio und midi Daten hin und herstreamen können . Dabei bleibt allerdings eine Anwendung Master, die die systemzugriffe implementiert und darüber auch das latenzmanagement durchführt.

Welchen Vorteil soll es haben, wenn eine Anwendung einen Master bildet? Das behindert nur ein flexibeles Konzept. Man merkt wohl, das du bei IBM arbeitest...

 

[mink99]

Zur Grafik

Ich sehe in der Grafik eine Zahl in rot, 2,6 Millisekunden genau unter einem mit jack bezeichneten Kästchen ...


Jack ist die personifizierte Verletzung des Kiss Prinzips .

Wofür ist jack denn da ? Ist es jetzt die systemschnittstelle zur Hardware , ein Interapplikations Audio und midi Streaming system, ist es der zentrale audio midi Hub als Master oder was ? Bereits das Konzept eines systemweiten audioservers ist notleidend. Die daw ist sinnvollerweise Master und muss es sogar sein. Deshalb ist die direkte Kommunikation daw <> alsa der bessere weg.

Gerade die unklaren Verantwortlichkeiten zwischen alsa und jack verletzen das Separation of concerns Prinzip.
Wenn jack sich ausschliesslich um die Interapplikations kommunikation kümmern würde, wären 80 % obsolet.

Die freie verschaltbarkeit setzt natürlich einen zentralen audio/midiserver voraus. Ob das jetzt nur deshalb so gemacht wurde, und die Applikationen deshalb nur teilfunktionalitäten implementieren, oder ob der Server implementiert wurde, weil es halt nur teilfunktionalitäten gab, weiss ich nicht.

Ob ein pluginkonzept als komponentenmodell weniger leistungsfähig ist als das pipen zwischen Applikationen sehe ich nicht.


Das ewige Argument, ein fehlerhaftes Plugin .... lasse ich nicht gelten. Wenn ein Plugin abraucht, benutzt Mans halt beim nächsten mal nicht mehr, es gibt ja genug .....

Wegen ipc , schau dir da nicht die jack API, sondern generell die ipc Dokumentation für Linux und auch die Intel Dokumente dazu an. Stichwort kontextwechsel.

 

[mink99]

Noch eine kleine Ergänzung:

Eine kommunikationsschnittstelle , in der unabhängige Applikationen untereinander audio und midi Daten hin und herstreamen können . Dabei bleibt allerdings eine Anwendung Master, die die systemzugriffe implementiert und darüber auch das latenzmanagement durchführt.

Welchen Vorteil soll es haben, wenn eine Anwendung einen Master bildet? Das behindert nur ein flexibeles Konzept. Man merkt wohl, das du bei IBM arbeitest...

Ex IBM bitte ...

Es geht darum, kann ein systemweiter Server (jack) die Qualität bieten, die eine dedizierte Applikation bietet. Ich sehe eher jack als eine IBM like One size fits it all Lösung .

 

[dbra]

Zur Grafik

Ich sehe in der Grafik eine Zahl in rot, 2,6 Millisekunden genau unter einem mit jack bezeichneten Kästchen ...

Damit ist hier wahrscheinlich die Jack-Latenz als ganzes gemeint.

Jack ist die personifizierte Verletzung des Kiss Prinzips .

Wofür ist jack denn da ? Ist es jetzt die systemschnittstelle zur Hardware , ein Interapplikations Audio und midi Streaming system, ist es der zentrale audio midi Hub als Master oder was ? Bereits das Konzept eines systemweiten audioservers ist notleidend. Die daw ist sinnvollerweise Master und muss es sogar sein. Deshalb ist die direkte Kommunikation daw <> alsa der bessere weg.

Wie du es bereits beschrieben hast. ALSA ist für die Kommunikation mit Hardware und für den Übergang in den Kernelspace verantwortlich. Jack sitzt in der nächsthöheren Schicht und verwaltet und implementiert das Routing der Datenströme und bietet die dazu notwendige Kommunikationsinfrastruktur. Es beinhaltet sowohl Audio als auch MIDI, da diese beiden Komponenten zueinander synchronisiert werden müssen. (Deshalb ist Jack-MIDI samplegenau) Da Jack ein Audioserver ist, gibt es natürlich diese Datenströme irgendwann per ALSA aus oder holt sie herein. Zudem kapselt Jack sämtliche ALSA-Aufrufe in sich, Clients kommen mit ALSA nicht in Berührung.

Gerade die unklaren Verantwortlichkeiten zwischen alsa und jack verletzen das Separation of concerns Prinzip.

Nope. Oben erklärt...

Grade dein Vorschlag mit dem direkten Aufsetzen der DAW auf der Hardwareschnittstelle verletzt das Separation of Concerns Prinzip. Wozu soll die DAW denn da sein. Um Audiodaten zu editieren oder die Hardware anzusprechen? (Dazu unten noch mehr)

Wenn jack sich ausschliesslich um die Interapplikations kommunikation kümmern würde, wären 80 % obsolet.

Die freie verschaltbarkeit setzt natürlich einen zentralen audio/midiserver voraus. Ob das jetzt nur deshalb so gemacht wurde, und die Applikationen deshalb nur teilfunktionalitäten implementieren, oder ob der Server implementiert wurde, weil es halt nur teilfunktionalitäten gab, weiss ich nicht.

Ob ein pluginkonzept als komponentenmodell weniger leistungsfähig ist als das pipen zwischen Applikationen sehe ich nicht.

Die Notwendigkeit eines Masters sehe ich einfach nicht. Was ist, wenn ich einfach so vor mich hinklimpern möchte. Da brauche ich keine DAW. Ich starte einen Softsynth oder schließe Hardware an, verbinde die MIDI- und Audio-Ein- und Ausgänge und los geht's. OK, jetzt möchte ich Aufnehmen. Starte dazu wieder ein Programm. OK. Jetzt kommt noch ein Sequencer dazu. Moment, wer soll jetzt der Master sein? Was ich an Jack so toll finde, man kommt weg von diesem monolithischen Müll. Ich kann mir meine Anwendungen passgenau so zusammenstellen wie ich es brauche.

Das ewige Argument, ein fehlerhaftes Plugin .... lasse ich nicht gelten. Wenn ein Plugin abraucht, benutzt Mans halt beim nächsten mal nicht mehr, es gibt ja genug .....

Dann könnte man ja auch gleich systemweit einen einzigen Adressraum nehmen. Spart auch Resourcen. Wenn ein Programm fehlerhaft ist, benutzt man es eben kein zweites Mal...

Wegen ipc , schau dir da nicht die jack API, sondern generell die ipc Dokumentation für Linux und auch die Intel Dokumente dazu an. Stichwort kontextwechsel.

OK, bereits oben hinzugefügt...

 

[dbra]

Ex IBM bitte ...

Tschuldigung...

Aber wenigstens mal wieder eine interessante Diskussion...

 

[mink99]

Bezüglich direktes aufsetzen auf der Hardware :

Hatte ich glaub ich erläutert . Das war das mit den systemschnittstellen ... Es geht nicht um das direkte aufsetzen auf der Hardware, sondern den Übergang von einer High Level API für midi und einer für Audio (userspace) in die systemaufrufe (kernelspace) . Also eine aufgebohrte alsa-lib .

Bezüglich audioserver und Applikationen als Client vs eine Applikation/daw als audioserver . Das Szenario was du beschreibst, ist nur eines von mehreren möglichen. Ich denke, dass der Studio "Pro Tools" Workflow eher durch einen externen audioserver behindert wird. Und auch das "ich jamme mit ableton" hat andere Anforderungen . Diese unterschiedlichen einsatzszenarien in einem audioserver zu ermöglichen , erscheint mir zu overengineered oder enterprisey. Deshalb mein Vorschlag des anderen komponentenschnitts, alsa für io und jack im reinen usermode optional ausschliesslich für die Kommunikation . Das sorgt dafür, dass die Funktionalität , die du brauchst, nur dann zur Verfügung steht, wenn sie auch gebraucht wird und die anderen Szenarien nicht behindert werden.

Zum Thema Komponenten / Plugins

Wiederverwendung von kleinen Funktionalitäten ist durchaus sinnvoll. Und eine komponentenschnittstelle absturzsicher zu gestalten, ist heute kein Problem mehr.


Für bestimmte Szenarien ist linux heute bereits gut einsetzbar, da bin ich nicht mehr so schwarz weiss wie eingangs noch, für andere sind meiner Meinung nach noch grosse Schritte notwendig. Ob aber die Developer diese anderen Szenarien auch sehen, und bereit sind, de dafür nötigen Umbauten vorzunehmen, werden wir sehen.

Hier wird Bitwig als erste komplett daw , die nach den auf den anderen Plattformen üblichen Konzepten konzipiert ist, hoffentlich ein Umdenken erzeugen.

 

[mink99]

Ich denke das Bild ist besser als diskussionsgrundlage

 

[Anonymous]

auch du scheiße,
was ne zusammengehackte bastelstube
versteh ich das richtig?
es gibt keinen basic i/o im kernel
und basic services gibts auch nicht
nur alles nur als so zusammengewürfelter kram? brrr
jack kenn ich, was aber macht pulse audio?

 

[dbra]

Wenn man die gezeigt Diagramme und die verfassten Postings nicht versteht, hält man besser den Mund.

 

[Anonymous]

liebelein, eine frage endet mit einem Fragezeichen, ne
aber lieber rumkotzen als aufklären, so gewinnt man die herzen der user

 

[dbra]

Ja, ich hab dich auch lieb.

OK. Pulseaudio wird beim "ernsthaften" Musikmachen eigentlich garnicht verwendet. Das ist der Audioserver des Gnome-Desktops. Also zum Abspielen von MP3s, Warntönen und zum Aufnehmen von Wavedateien etc. .

 

[khz]

Sobald eine ~Anwendung die Soundkarte belegt/nutzt steht sie anderen Anwendungem nicht mehr zur Verfügung.
(Z.B.: SC => ALSA => Phasex (SW-Synth).
Um nun mehrere Programme mit einer SC nutzen zu können gibt es jackd.
(Z.B.: SC => ALSA => qjackct(jachk) => Phasex & ams & qmidiarp & mx44 & seq24 & rakarrack & ardour & Bitwig & Renoise & wtf ... (Alles frei routbar (art modular)))
Kann man unter Mac/Win z.B. Nuendo audio/midi zu Cubase dann weiter zu (omg kenne ich Programme?) irgendwas quer routen und in RT wieder umpatchen?

ALSA also Kommunikation zwischen HW SC und einer SW Anwendung, jack(d) ist eine ~Patchbay.

Dadurch hat man einen flexiben digitalen modularen ~Synthesizer.
Man kann ja auch raus an externe HW routen und dann wieder zurück in ein Programm oder dank jacktrip über Internet zum Kumpel Rechner oder mit Netjack im lokalen Netzwerk oder ... .

Sry wegen den vielen Bildern, aber ich finde das für mich einfacher als 1k Worte. (Und t-kom freut sich! )

 

[mink99]

Hier in dem Beispiel sieht man sehr schön die unterschiedlichen Sichtweisen.
Aus einer bottom up Perspektive (Hardware ) ist jack ne Patchbay .
Aus einer Top Down Perspektive (daw) ist jack als zentraler audio/midiserver weitaus mehr.

Bei einer konsequenten Umsetzung des audioserver Konzepts gibt es keine zentrale DAW und keine Plugins, sondern alle am musizieren beteiligten Bausteine agieren als eigenständige Applikationen unter der Kontrolle des Servers . Dies bedeutet, dass diese Komponenten anders agieren als das das daw / pluginkonzept der anderen Betriebssysteme erwarten lässt.

Beispiel

Eine einfache Session mit 4 Tracks soll gebounced werden, Ergebnis sind 4 samplegenau positionierbare audiotracks.

Track 1 ist ein softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 2 ist ein weiterer softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 3 ist eine Audiospur , die von eine sampleplayer abgespielt wird
Track 4 ist eine externe drumbox via midi, (nicht Clock, sondern Noten)

Wir haben also folgende Applikationen gestartet

Einen midiplayer mit den mididaten von Track 1,2,4
Einen audioplayer mit den Audiodatei von Track 3
Einen audiorecorder , auf dem der mixdown schlussendlich landet
Softsynth 1
Softsynth 2

Und natürlich jack

Zum samplegenauen aufzeichnen braucht es jetzt beim drücken des recordbuttons folgende Schritte

Miditrack 1 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 1 beträgt
Miditrack 2 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 2 beträgt
Audiotrack 3 muss tickgenau gestartet werden
Miditrack 4 muss um soviele Ticks vorgezogen werden, wie die midi Outbound Latenz des midi Interfaces + die inboundlatenz des audiointerfaces beträgt

Die audiostreams als Ausgabe der softsynths zu verzögern , und dafür das midi clockgenau zu starten, kostet gesamtlatenz, die beim live einspielen von softsynths nicht akzeptabel ist.

Was bedeutet das für den audioserver ?
Er muss die verarbeitungslatenzen aller geladenen Applikationen kennen, und die Latenzen aller Peripheriegeräte. Er muss in der Lage sein, beim midiplayer z.b. Einzelne Tracks tickgenau unabhängig zu starten. Dies gilt auch fur audioplayer und recorder.
Dies gibt gibt einen immensen verwaltungsoverhead, denn der Server greift hierfür ja nicht auf eine einzelne , virher bekannte Applikation , sondern auf eine klasse von Applikationen zu. Nicht ein spezieller midiplayer muss fernsteuerbar sein, sondern alle. Eine systemweite latenzkompensation , die bei konsequenter Umsetzung des Linux Konzepts Voraussetzung ist, wäre mir zu enterprisey und zu riskant, das vollumfänglich ans laufen zu bringen, zumal einige der integrierten Schnittstellen ein konsequentes Layering vermissen lassen (was hat eine FireWire Schnittstelle in einer High Level API zu suchen ?)

Selbst Ardour hat dieses Konzept verlassen, und integriert inzwischen die midi Funktionalitäten selber, und verlässt sich nicht mehr auf die Kombination jack / externer midiplayer.

Kommen wir zum Layer 8 , dem Anwender . Der normale Musiker denkt nicht in Applikationen, sondern in Songs. Die ganzen in o.g. Beispiel erzeugten Daten, die audiofiles, die midifiles, das routing etc möchte er oder sie als einen Song zusammen speichern und Laden , total recall halt. Wo wäre es aus anwendersicht logisch das zu tun ?

Ich denke, da ist eine daw, die das wissen über die Umgebung hat, gerade aus Sicht latenzkompensation und total recall deutlich effizienter als ein systemweiter audioserver. Wenn man jetzt noch die Dinge mit einrechnet, die im Studiobetrieb sonst noch so anfallen können, wie DSPs, automatisierbare Peripherie , integrierte Hardware , so ist das Konzept eines zentralen audioservers das zweitbeste (von zweien)

 

[dbra]

Also erstmal zur Grafik: Die stimmt ja so eigentlich nicht, denn ALSA, OSS und FFADO sind teil des Kernels. Pulseaudio nutzt auch niemand zum Musikmachen, können wir also auch vergessen.

Bezüglich direktes aufsetzen auf der Hardware :

Hatte ich glaub ich erläutert . Das war das mit den systemschnittstellen ... Es geht nicht um das direkte aufsetzen auf der Hardware, sondern den Übergang von einer High Level API für midi und einer für Audio (userspace) in die systemaufrufe (kernelspace) . Also eine aufgebohrte alsa-lib .

Jede Applikation könnte sich die von dir geforderte Low-Level-Funktionalität selbst implementieren und direkt auf ALSA aufsetzen, oder auch die dazu relevanten Teile aus Jack nehmen und eine Lib für die allgemeine Verwendung draus machen.

Bezüglich audioserver und Applikationen als Client vs eine Applikation/daw als audioserver . Das Szenario was du beschreibst, ist nur eines von mehreren möglichen. Ich denke, dass der Studio "Pro Tools" Workflow eher durch einen externen audioserver behindert wird. Und auch das "ich jamme mit ableton" hat andere Anforderungen . Diese unterschiedlichen einsatzszenarien in einem audioserver zu ermöglichen , erscheint mir zu overengineered oder enterprisey. Deshalb mein Vorschlag des anderen komponentenschnitts, alsa für io und jack im reinen usermode optional ausschliesslich für die Kommunikation . Das sorgt dafür, dass die Funktionalität , die du brauchst, nur dann zur Verfügung steht, wenn sie auch gebraucht wird und die anderen Szenarien nicht behindert werden.

Wie bereits oben beschrieben, könnte sich jede Audio-Anwendung selbst zum "Master" über ALSA machen. Jede ernstzunehmende Audio-Anwendung unter Linux hat jedoch eine Jack-Anbindung. Warum? Weil Jack bereits alle von dir geforderten Featuers enthält, leistungsstärker ist und stabil läuft.

Zum IPC-Overhead: Das mehr an Funktionalität von Jack benötigt mehr Overhead als eine Low-Level-Lösung, da stimme ich dir völlig zu. Aber wie groß ist dieser wirklich? Ggf. muß ein Puffer einmal mehr pro Client kopiert werden und es fallen pro Client 2 zusätzliche Context-Switches an. Wenn du das wegläßt, was glaubst du, wieviel Nanosekunden hast du gespart? Fällt das bei einer Zyklusdauer von wenigen Millisekunden irgendwie ins Gewicht? Nein.

Und der zusätzliche Verwaltungsaufwand für die einzelnen Clients/Ports hat eigentlich auch keinen nennenswerten EInfluß auf die Performance.

Zum Thema Komponenten / Plugins

Wiederverwendung von kleinen Funktionalitäten ist durchaus sinnvoll. Und eine komponentenschnittstelle absturzsicher zu gestalten, ist heute kein Problem mehr.


Für bestimmte Szenarien ist linux heute bereits gut einsetzbar, da bin ich nicht mehr so schwarz weiss wie eingangs noch, für andere sind meiner Meinung nach noch grosse Schritte notwendig. Ob aber die Developer diese anderen Szenarien auch sehen, und bereit sind, de dafür nötigen Umbauten vorzunehmen, werden wir sehen.

Hier wird Bitwig als erste komplett daw , die nach den auf den anderen Plattformen üblichen Konzepten konzipiert ist, hoffentlich ein Umdenken erzeugen.

Über Plug-Ins brauchen wir uns eigentlich nicht zu Unterhalten. Es gibt LADSPA, LV2 und auch LinuxVSTs (dies hab ich noch nie benutzt) Das funktioniert eigentlich ähnlich wie unter anderen Plattformen auch.

 

[mink99]

Ich hab mal gemalt:



Das ist, was ich vorgeschlagen habe .....

 

[dbra]

Können wir bitte diesen Intel-Gehirndurchfall mit den Ringen weglassen? Nennen wir es User- und Supervisor-Mode.

 

[mink99]

Sorry, stell es dir vor, ändert nichts an der Aussage der Grafik ....

Supervisor ist als Ausdruck gefährlich, da das bei virtualsierun eine andere Bedeutung hat ....


Das Konzept ist, dass die io Funktionalitäten aus jack extrahiert werden und in das was im Bild alsa heisst, verschoben werden. Das Ergebnis kann dann meinetwegen auch jack heissen, oder Norbert oder wie auch immer.

Der Rest, der ipc Teil , der im usermode läuft , verbleibt.

Der firewirekram wird entsorgt, der programmierer muss zur Strafe ein IBM websphere Redbook lesen.
Pulse audio wird ebenso entsorgt und auf Treiber bzw Kernel ebene abgehandelt.


Ach so, wie kann jack für die basisfunktionalitat leistungsfähiger sein als alsa, wo es doch nur eine Shell um alsa ist ?

 

[dbra]

Aber das wäre doch ein großes Mess für die Anwendungsentwickler... Vorbei die Zeit der uniformen Datenweitergabe... Die Anwendung müsste einen Unterschied machen, ob sie Daten nun an ein anderes Programm oder an die physichen Outputs sendet. Ach ja, bei dir sollen die Anwendungen ja außer Timing nichts gemein haben... Naja, für mich kein besonders gelungenes Design.

Sieh's endlich ein, du hast verloren!

EDIT: Wie wär's denn mal, wenn du Jack einfach mal selbst ausprobierst? Installier dir Linux parallel auf deinem Musikrechner und berichte uns von den erreichbaren Latenzen unter WIndows und Linux. Das dürfte für sich selbst sprechen. Wenn dein Audio-Interface nicht unterstützt wird, nimmste halt On-Board-Audio. Sollte zum Testen reichen.

 

[mink99]

Sieh's endlich ein, du hast verloren!

Sagt dir der Ausdruck Pyrrhussieg etwas ?

Du hast gewonnen, nur du hast immer noch keine treiberunterstützung unter Linux, und auch ein ableton, kein reaper, kein Massive usw. Vielleicht irgendwann mal Bitwig .

Ist doch Quatsch .....

Dass das vorgeschlagene Konzept funktioniert, zeigen die nischenbetriebssysteme wie osx und Windows , die im Bereich Professional audio gegenüber Linux natürlich nicht wirklich relevante Marktanteile haben ....

Und natürlich, bis protools als der studiostandard von Linux auf w indows und Mac portiert wird, da werden noch Jahre ins Land gehen......

Wieso beisst du dich an der Uniformen datenweitergabe so fest ? Habe ich irgendwo behauptet, dass die ipc und das physische io über unterschiedliche APIs gehen müssen, auch wenn die implementation eine andere ist ? Die datenformate , die sinnvollerweise identisch sein sollten, haben wir garnicht diskutiert.

Wie eine uniforme API für midi aussehen könnte, zeigt z.b rtmidi. Das konnte ich mir vorstellen, dass so die alsa API für midizugriffe aussehen könnte ... http://www.music.mcgill.ca/~gary/rtmidi/
Und da gibt es keinen Grund, warum ipc nicht die gleiche API anbieten könnte.

...... Das war's also nicht ......

Zum Thema Linux ausprobieren . Ardour, was einer daw so wie ich es kenne, am Nächsten kommt, bietet leider noch nicht die Features , die ich für meinen Workflow und mein Setup benötige. Ich verfolge das allerdings ständig und werde, sobald dort die entsprechenden Features zur Verfügung stehen, dem auf jedenfall eine Chance geben. Und sei sicher, ich werde deine angebotene Hilfe gerne wahrnehmen

Niedrige Latenzen sind kein Selbstzweck , sondern man muss auch Material erzeugen können, was dann Latenzen verursacht.

 

[dbra]

Und da gibt es keinen Grund, warum ipc nicht die gleiche API anbieten könnte.

OK, da haste Recht. Aber es liegt auch an den verschiedenen Designphilosophien der Systeme. Wo bei Win eben eine DLL gebaut wird, kommt bei Un*x der Prozess.

 

[mink99]

Und da gibt es keinen Grund, warum ipc nicht die gleiche API anbieten könnte.

OK, da haste Recht. Aber es liegt auch an den verschiedenen Designphilosophien der Systeme. Wo bei Win eben eine DLL gebaut wird, kommt bei Un*x der Prozess.

Oder dass der Programmierer von system 1 nicht mit dem von system 2 spielen möchte .

 

[khz]

Selbst Ardour hat dieses Konzept verlassen, und integriert inzwischen die midi Funktionalitäten selber, und verlässt sich nicht mehr auf die Kombination jack / externer midiplayer.

Echt? Also hier (Gentoo && Debian) kann man Ardour zwar starten ohne das jackd läuft, Ardour startet aber automatisch dann jackd. Paul Davis hat ja extra jackd programmiert um das ~modulare zu realisieren.
Sonst hätten wir so Kisten wo man nichts ~modulares ~patchen könnte.

Bei Linux gibt es nicht - wie evt. bei einigen anderen Systemen - eine Endlösung. Es ist eher eine ewige Schlacht/Streit Kultur die im ständigen Prozess ist.
Wohin was geht formen wir teilweise aktiv mit. Also Programmierer und Anwender verschmelzen im Idealfall oder stehen im direkten Kontakt zueinander.
Keine Nachfrage/Angebot Moneyback ding.
Und es ist langsam, da nicht jede bekiffte Idee grade auf ein "Juhu" und "Klar das wirds, kommt in Kernel!", ... ist sondern sehr lange besprochen und programmiert wird.
Nur sinnvoller (was auch immer das ist) Code setzt sich durch bzw wird genutzt.

Und: es gibt Alternativen: Wer das nicht gut findet kann/soll Windows oder noch besser Mac nehmen.
Keiner sagt "pls komm zu uns, verschwende deine Zeit" sondern eher "don´t waste my time".
Es prallen halt sehr viele Individualisten aufeinander die evt. nicht New Age / Friede, Freude, Eierkuchen anhänger sind sondern eher ~Extremisten.