Von Sie haben vergessen, Ihren Nam am Di, 31. Juli 2012 um 20:30 #
>Wohl eher KLANG -> Multimediaframework (z.B. GStreamer) -> Anwendung
GStreamer ist genauso ein Ungetüm wie Pulseaudio.
> KLANG wird wohl kaum alle Containerformate und Codecs in the Kernel rein ziehen wollen.
Nein, das .wav-Beispiel war etwas ungeschickt. Es ging mir nur darum zu zeigen, dass man praktisch nicht mehr braucht als open() und read() bzw. write() (eben wie cat). Man vergleiche das mit der ALSA-API. Dinge wie Puffergrößen etc. haben die Anwendung nicht zu interessieren. Schließlich kümmert sich ein Webbrowser auch nicht um TCP-Paketgrößen.
Du vergleichst Äpfel und Birnen. Gstreamer ist ein Multimedia-Framework, Pulseaudio ein Soundserver. Wenn du den Unterschied nicht kennst, solltest du dir besser irgendwelche Kommentare dazu sparen.
Es ging mir nur darum zu zeigen, dass man praktisch nicht mehr braucht als open() und read() bzw. write() (eben wie cat).
Nur bringt dir das rein gar nichts, wenn du z.B. mehrere Quellen oder Ausgabegeräte hast und diese dann On-the-fly wechseln möchtest.
Ok, dann geht es darum, dass die Framework Entwickler weniger Arbeit haben um mit der Mixer-/Ausgabeschicht zu sprechen.
Im Kommentar von Realist war die Kette in mehr Stufen gegliedert als üblicherweise sichtbar ist, daher bin ich davon ausgegangen, dass das in der von dir beschriebenen Kette auch so ist.
Ich verstehe jetzt, dass du die letzten drei Glieder in Realists Kette zu "Anwendung" zusammen gefasst hast, was ja auch Sinn macht, da diese drei Glieder im selben Prozess und daher nach außen nicht sichtbar sind.
Was ich unter Abstraktion verstehe sind z.B. die OSI-Layer. Niemand käme auf die Idee zu fordern, dass jede Anwendung die Ethernet-Frames selber verwaltet.
> Widerspricht sich das nicht? Noch mehr Abstraktion? Ja wo soll den noch mehr abstrahiert werden, außer direkt von den Hardware-Schnittstellen?
Die HW-Schnittstelle ist so ziemlich die niedrigste Abstraktionsebene die es gibt.
> Aber ich muss zugeben...wenn ich so an mögliche Abstraktionsebenen denke... ALSA->PulseAudio->GStreamer->Phonon->Endanwendung
Und in Zukunft dann: KLANG->Endanwendung
cat datei.wav > /dev/dsp044s16l
So wie seinerzeit /dev/fd0H1440
Wohl eher KLANG -> Multimediaframework (z.B. GStreamer) -> Anwendung
KLANG wird wohl kaum alle Containerformate und Codecs in the Kernel rein ziehen wollen.
>Wohl eher KLANG -> Multimediaframework (z.B. GStreamer) -> Anwendung
GStreamer ist genauso ein Ungetüm wie Pulseaudio.
> KLANG wird wohl kaum alle Containerformate und Codecs in the Kernel rein ziehen wollen.
Nein, das .wav-Beispiel war etwas ungeschickt.
Es ging mir nur darum zu zeigen, dass man praktisch nicht mehr braucht als open() und read() bzw. write() (eben wie cat). Man vergleiche das mit der ALSA-API. Dinge wie Puffergrößen etc. haben die Anwendung nicht zu interessieren. Schließlich kümmert sich ein Webbrowser auch nicht um TCP-Paketgrößen.
> Du vergleichst Äpfel und Birnen. [...]
Ich habe die beiden nicht verglichen. Ich habe lediglich geschrieben, dass beide für das was sie prinzipiell tun, unnötig komplex sind.
> Nur bringt dir das rein gar nichts, wenn du z.B. mehrere Quellen oder Ausgabegeräte hast und diese dann On-the-fly wechseln möchtest.
Der Beschreibung nach soll KLANG Routing können. Damit dürftest du sicher samplesynchron Quellen und Senken wechseln können.
Ok, dann geht es darum, dass die Framework Entwickler weniger Arbeit haben um mit der Mixer-/Ausgabeschicht zu sprechen.
Im Kommentar von Realist war die Kette in mehr Stufen gegliedert als üblicherweise sichtbar ist, daher bin ich davon ausgegangen, dass das in der von dir beschriebenen Kette auch so ist.
Ich verstehe jetzt, dass du die letzten drei Glieder in Realists Kette zu "Anwendung" zusammen gefasst hast, was ja auch Sinn macht, da diese drei Glieder im selben Prozess und daher nach außen nicht sichtbar sind.
KLANG->Endanwendung ist für mich aber das Gegenteil von mehr Abstraktion.
Mehr Abstraktion heißt für mich: Mehr Abstraktionsschichten. Und was hat z.B. das Decoding für Container und Formate im Kernel zu suchen?
> KLANG->Endanwendung ist für mich aber das Gegenteil von mehr Abstraktion.
KLANG möchte eine Schnittstelle anbieten, die abstrakter ist als die bisherige Kernelschnittstelle, so dass du oberhalb des Kernels weniger tun musst.
> Mehr Abstraktion heißt für mich: Mehr Abstraktionsschichten.
Mehr Abstraktion heißt bessere Abstraktion. Viele Schichten verderben oft den Klang/Brei.
> Und was hat z.B. das Decoding für Container und Formate im Kernel zu suchen?
Wie bereits geschrieben war das WAV-Beispiel blöd.
Ok danke, dann habe ich jetzt verstanden wie es gemeint ist.
Verstehen tu ich unter Abstraktion trotzdem was anderes
Nachtrag:
Was ich unter Abstraktion verstehe sind z.B. die OSI-Layer. Niemand käme auf die Idee zu fordern, dass jede Anwendung die Ethernet-Frames selber verwaltet.