Arts hat eine wohl eher geringe Akzeptanz, es wird wenig eingesetzt und hat kaum Vorteile im aktuellen Stadium. Zumal selbst viele KDE Entwickler es nicht mögen
Bis vor kurzem hatte Arts noch einen für spezielle Fälle wichtigen Vorteil: Wenn Sounddaten durchs Netzwerk geschickt werden und die einzelnen Hosts eine verschiedene Endianess haben, kann Arts dies ohne zusätzlichen Konfigurationsaufwand on-the-fly ausgleichen, auch full-duplex. Seit diesem Jahr kann GStreamer das allerdings auch, womit die Diskussion so ziemlich beendet wäre.
Von BufferOverflow am Mi, 21. April 2004 um 13:11 #
Hm, GStreamer ist aber doch nur ne lib und kein Soundserver? Bin eher davon ausgegangen, dass Projekte wie jackit ( http://jackit.sourceforge.net ) dabei sind, arts abzuloesen.
Jack hat zwar eine niedrige Latenz und einen hohen Durchsatz, bezieht sich aber nur auf den lokalen Host, native Netzwerkfähigkeiten fehlen. Diese können bisher nur durch externe Plugins ermöglicht werden, die aber bisher eine inakzeptable Latenz aufweisen. Sowohl Arts als auch GStreamer sind da schon weiter.
Von Christian Nobis am Mi, 21. April 2004 um 18:52 #
> OSS und ALSA sind Soundkartentreiber. Fast Richtig, es sind beides Soundframeworks im Kernel, an die ein die eine einheitliche Schnittstelle zu den Soundkarten bereitstellen. Die Treiber bilden dann die Schnittstelle zwischen dem Soundframework und der Hardware (Soundchip).
> jackit, artsd, esd sind Soundserver. Ja diese nehmen den Sound von einem Programm/aus dem Netzwerk entgegen, mixen verschiedene Soundstreams und geben das ganze dann über das Soundframework an die Soundkarte weiter. Wenn du den Sound nicht übers Netzwerk weiterleiten willst und dein Soundkartentreiber das mixen verschiedener Soundquellen unterstützt, benötigst du normalerweise keinen Soundserver.
> arts, gStreamer, xine-lib sind lib um Sound abzuspielen. Das sind alles Bibliotheken bzw. Frameworks (Sie sind alle durch Plugins erweiterbar) um verschiedene Quellen (wav, mp3, ogg, cd oder aber auch Videoquellen) zu verarbeiten und an mehrere mögliche Ausgaben weiterzuleiten (OSS, Alsa, esd, artsd, jackid oder bei Video X11, xv, directfb, opengl).
Somit können z.b. alle Programme, die die xine-lib verwenden durch ein einziges Plugin/einen einzigen Codec um die Möglichkeit erweitert werden ein neues Videoformat abzuspielen oder die Sound/Videoausgabe an ein anderes System zu übergeben.
> Ist das richtig? Und wo gehört libalsa hin? Ein Programm kann auch die Soundkarte/Alsa direkt ansteuern und die libalsa stellt Funktionen dafür bereit, damit es das kann. Alternativ kann der Programierer natürlich auch alles selber implementieren aber wer will das schon?
Seit diesem Jahr kann GStreamer das allerdings auch, womit die Diskussion so ziemlich beendet wäre.
Bin eher davon ausgegangen, dass Projekte wie jackit ( http://jackit.sourceforge.net ) dabei sind, arts abzuloesen.
mfG
OSS und ALSA sind Soundkartentreiber.
jackit, artsd, esd sind Soundserver.
arts, gStreamer, xine-lib sind lib um Sound abzuspielen.
Ist das richtig? Und wo gehört libalsa hin?
Fast Richtig, es sind beides Soundframeworks im Kernel, an die ein die eine einheitliche Schnittstelle zu den Soundkarten bereitstellen. Die Treiber bilden dann die Schnittstelle zwischen dem Soundframework und der Hardware (Soundchip).
> jackit, artsd, esd sind Soundserver.
Ja diese nehmen den Sound von einem Programm/aus dem Netzwerk entgegen, mixen verschiedene Soundstreams und geben das ganze dann über das Soundframework an die Soundkarte weiter. Wenn du den Sound nicht übers Netzwerk weiterleiten willst und dein Soundkartentreiber das mixen verschiedener Soundquellen unterstützt, benötigst du normalerweise keinen Soundserver.
> arts, gStreamer, xine-lib sind lib um Sound abzuspielen.
Das sind alles Bibliotheken bzw. Frameworks (Sie sind alle durch Plugins erweiterbar) um verschiedene Quellen (wav, mp3, ogg, cd oder aber auch Videoquellen) zu verarbeiten und an mehrere mögliche Ausgaben weiterzuleiten (OSS, Alsa, esd, artsd, jackid oder bei Video X11, xv, directfb, opengl).
Somit können z.b. alle Programme, die die xine-lib verwenden durch ein einziges Plugin/einen einzigen Codec um die Möglichkeit erweitert werden ein neues Videoformat abzuspielen oder die Sound/Videoausgabe an ein anderes System zu übergeben.
> Ist das richtig? Und wo gehört libalsa hin?
Ein Programm kann auch die Soundkarte/Alsa direkt ansteuern und die libalsa stellt Funktionen dafür bereit, damit es das kann. Alternativ kann der Programierer natürlich auch alles selber implementieren aber wer will das schon?
Bis denne denn
Christian