Schade. Eigentlich dachte ich mir, dass Xine es endlich fertig bringen wird, ein brauchbares Jack-Output zu integrieren. Ed Wildgoose hat bereits Ende 2004 eine entsprechende Änderung an die Xine-MListe geschickt. Die Entwickler scheinen sie allerdings "verpennt" zu haben. Wildgoose fragte nach und wurde noch ein Mal gebeten den Patch zu übermitteln. Wie es aussieht auch diesmal ohne Resultate.
Nun frage ich mich provokant, warum es eigentlich die MPlayer-Coder fertig bringen eine bio2jack-basierende Lösung (die auch funktioniert) zu integrieren und die Xine-Leute die selbe verwerfen? Solange Xine keine Jack-Ausgabe bietet wird es von vielen Rechnern entfernt und durch MPlayer ersetzt werden.
Ich könnte mir vorstellen, dass Jack einfach von vielen Leuten keine Bedeutung angemessen wird. Die meisten User, die auf Soundwrapper setzen, nehmen eben, was ihnen vom Desktop Environment aufgedrängt wird: aRts bei KDE und ESD bei Gnome (soweit ich weiss). Und unter dem ersten Wrapper noch nen zweiten laufen zu lassen (oder die Rollen zu vertauschen) macht wohl nicht viel Sinn.
Ich persönlich hoffe ja, dass die soundwrapper ganz aussterben. Ein grossteil der Applikationen teilt sich bei mir schon jetzt problemlos die soundkarte, dank alsa's dmix-plugin.
Entschuldige bitte, aber wie kommst Du auf die Aussage, dass "alle diese Jack benutzen" (sollen)? Jeder soll den Sound-Server nutzen, den er für gut hält. Es macht nur wenig Sinn mehrere Sound-Server zu nutzen. Jack hat sich mittlerweile zu einem Standard im Sound- und Multimediabereich unter Linux etabliert. Sogar so alterswürdige Applikationen wie xmms kommen mit einem Plugin daher. Eine der wenigen Ausnahmen, die Jack nicht unterstützen ist Xine. Sogar KDE kann ihre Ausgaben auf Jack umlenken. Wenn das nichts heißen soll
Also ganz ehrlich: Ich nutze Linux auch seit vielen Jahren, und bin eigentlich immer halbwegs auf dem laufenden. Aber Jacks sagt mir auch nichts. Hättest du mich bis heute gefragt: "Was ist Jack", hätte ich zuerst an einen Schauspieler gedacht, aber nie an einen Soundserver ;)
Welche Distrie nutzt Jack per default, was kann Jack, warum sollte man Jack nutzen, und wer sagt folgendes: "Standard im Sound- und Multimediabereich" ? :)
(Das heisst nicht das Jack schlecht ist, oder nichts taugt. Aber irgendwie scheint deine Darstellung etwas überzogen zu sein)
Belege, Verbreitung? Und mir ist neu das Linux im professionellen Audio-Bereich überhaupt eine Bedeutung hat. Und warum soll das dann auch noch für Xine wichtig sein?
Was der Bauer nicht kennt, ... Schaue Dir mal Ardour an (Screenshot). Die Applikation unterstützt außer Jack keine andere Lösung. Warum es wichtig für Xine ist? Weil es keinen Sinn macht 10 Sound-Server auf einem System zu installieren (auch wenn es oftmals der Fall ist). Jack hat das Zeug eine Standardlösung zu werden und die Sound-Ausgabe, wie damals Alsa die Sound-Devices, zu revolutionieren. Die Sound-Macher unter Linux werden schon ihre Gründe haben, warum sie auf Jack schwören.
Sorry, aber irgendwie ist Deine Argumentation für mich nicht schlüssig. Gut, der Screenshoot sieht nicht schlecht aus, aber wenn die Applikation nur mit Jack funktioniert, ist das eher ein Armutszeugnis der Applikation als ein Argument für Jack.
Und, wenn Jack die gleiche Qualität haben soll wie dieses unbrauchbare Alsa, dann brauch' ich es mir garnicht erst anzusehen.
Hinzu kommt dann noch die Motivation. Warum soll ich überhaupt einen Sounddaemon verwenden? Normalerweise schaue ich nicht gleichzeitig Film, höre eine CD und spiele nen Egoshooter. Das verkraftet mein Gehör eh nur seriell. Zudem bedeutet eine zusätzliche Ebene zwischen Programm und Soundkarte üblicherweise nur eine Soundverschlechterung.
Sorry, aber irgendwie ist Deine Argumentation für mich nicht schlüssig. Gut, der Screenshoot sieht nicht schlecht aus, aber wenn die Applikation nur mit Jack funktioniert, ist das eher ein Armutszeugnis der Applikation als ein Argument für Jack.
Mehr noch: Es ist klar, dass der Hauptentwickler von Jack sein eigenes Produkt benutzt ;-).
>Mehr noch: Es ist klar, dass der Hauptentwickler von Jack sein eigenes Produkt benutzt
Paul Davis benutz JACK nicht, weil "es sein eigenes Projekt ist", sondern weil er es genau zu diesem Zweck entworfen hat: als den ersten Linux-Audioserver, der den Einsatz von Linux als professionelles Harddiskrecordigsystem erlaubt. Alle anderen sind lediglich geeignet, Systemsounds auszugeben, während man sich eine CD anhört - für eine Audio-Workstation wäre das etwaS knapp
>Normalerweise schaue ich nicht gleichzeitig Film, höre eine CD und spiele nen Egoshooter.
ES geht bei Jack, wie schon gesagt eben nicht nur um hören und sehen von fertigem Material, sondern um das Erzeugen und Bearbeiten von selbstgemachten Sounds. Da gibt es sog. "Musiker" die stellen dem ganzen Kram her, den sich alle anderen dann anhören müssen und diese Typen können das mit Jack eben auch in Linux.
Um es noch verständilicher zu machen: Frage: ich habe einen Mix von 16 Stereospuren, von denen ich 4 an einen LADSPA-Echoeffekt weiterleiten, den ganzen Rest durch JAMin mastern und anschliessend auf eine 24/96 Wav-Datei aufnehmen will - wie soll das gehen? (einzige)Antwort: mit Jack.
alle ernst zu nehmenden Soundapplikationen für Linux und die meisten frei lizenzierten für MAC-OS kommunizieren über JACK, Jack ist im vorigen Jahr bei den britischen Open Source Awards einer der Gewinner gewesen.
Und mir ist neu das Linux im professionellen Audio-Bereich überhaupt eine Bedeutung hat. Nun, wuerde man der Aussage folgen, dann duerften viele Projekte nicht existieren. So argumentieren auch viele Windows-Benutzer in Bezug auf Linux. ;)
Und warum soll das dann auch noch für Xine wichtig sein? Um ehrlich zu sein, bin ich auch ein Fan von Jack. Meiner Meinung nach ist es eine sehr wichtige Multimedia-Entwicklung der letzten Jahre. Die Moeglichkeiten des Servers sind beeindruckend. Positiv faellt auf, dass fast alle Multimedia-Applikationen unter Linux auch Jack unterstuetzen. Einzig Xine fällt hier aus der Reihe. Auch ich bin mittlerweile auf MPlayer umgestiegen (ungern) und nutze Xine nur in Ausnahmefaellen. Wie bereits mein »Vorschreiber« sagte, habe auch ich keine Lust 2 Sound-Server zu installieren, nur damit ich Xine eine Sound-Ausgabe entlocken kann.
Zum Glueck haben wir zwei verschiedene Vorstellungen, was eine Soundworkstation an Funktionalitaet braucht. Gerne verzichte ich auf eine so "saubere Loesung" wie dmix Plugin und nutze statt dessen 5.1 Funktionen, leite den Sound-Ouptput von einer Applikation in eine andere und habe die Moeglichkeit alle Kanaele und Ausgaben von jeder Applikation nicht nur separat zu "verdrahten", sondern auch auszusteuern. Dafuer nehme ich auch einen "hack" wie Jack in Kauf Nix fuer Ungut, aber ich glaube, dass wir nicht einer Meinung sein werden, denn viele der Applikationen, die ich benutze setzen Jack voraus :)
Die Anwendungen, die ich nutze, haben entweder gar keine JACK-Unterstützung (Xine-basierte Programme, SDL-basierte Programme/Spiele, VDR) oder eine schlechte (MPlayer).
Du kannst mir übrigens bestimmt sagen, wie man jackd als root ausführen und trotzdem mit beliebigen Benutzern, die in der Gruppe audio sind, auf jackd zugreifen kann.
Du kannst mir übrigens bestimmt sagen, wie man jackd als root ausführen und trotzdem mit beliebigen Benutzern, die in der Gruppe audio sind, auf jackd zugreifen kann.;-)
Wenn Du darauf hinaus willst, dass es nicht funktioniert, dann muss ich Dich leider enttaeuschen. Es gibt diverse Patches, die es ermoeglichen. Suche dazu zum Beispiel nach Patches von Kjetil Svalastog. Ob es Sinn macht, sei dahin gestellt. Warum sollen zwei User simultan auf das selbe Device Sounds ausgeben? Wer's aber mag...
Nein, darauf wollte ich nicht hinaus. Hier läuft grad ne DVD in 5.1-Sound mit Kaffeine (Xine) über jack. :-)
Ich will mir nur ersparen, jack ständig als der jeweilige User zu starten. esd kann z.B. über Init-Skripte gestartet werden. Ich hab hier auch eines für jack, nur kann ich dann nur als root Musik abspielen. Mit dmix hat man solche Probleme gar nicht erst.
Manche Programme lasse ich unter einem anderen Benutzernamen laufen (mpd z.B.). Die sollen natürlich auch Zugriff auf die Soundkarte haben, genauso wie mein Hauptbenutzer, wenn ich Kaffeine für DVDs nehme.
Mit jack als Systemdienst würde ich alles darüber laufen lassen.
Achja, wenn ich jackd als User starte, krieg ich natürlich keine Echtzeitpriorität und bei viel Aktivität, z.B. durch Encodieren, setzt der Ton manchmal aus. Auch dafür müsste ich jackd mit root-Rechten ausführen.
Jack hat den großen Vorteil einer sehr geringen Latenz (latency). Wenn KDE z.B. gleichzeitig (d.h. mit so geringer Verzögerung wie möglich) mit dem Klicken auf einen Knopf einen Sound abspielen will, dann ist Arts schlecht darin (bei meinem System verzögert sich der Sound um ca 1 Sekunde) und Jack gut darin (Latenz nicht wahrnehmbar).
Wenn du einen ganzen Song abspielst ist das ziehmlich egal, weil es wirklich niemanden kratzt wenn du nach dem Drücken des Start- Buttons noch eine Sekunde warten mußt, wenn du aber Audiobearbeitung machst, dann ist es sehr wichtig, dass der cursor und die Musik das gleiche tun, bzw. wenn du auf Halt drückst nicht noch eine Sekunde nachgespielt wird.
Das mit der niedrigen Latenz ist aber auch gleichzeitig ein Nachteil, wenn z.B. nebenbei ne Anwendung kompiliert wird oder man nen Kernel mit tar xvjf entpackt. Da sind hier Aussetzer vorprogrammiert.
Ich verstehe auch nicht, weshalb Xine eine Jackd-Anbindung haben sollte. Es reicht doch für solch eine Anwendung eine Kernel-unterstützte Alsa-Anbindung vollkommen aus. Die vom Jackd angegangene Problematik der Beseitigung von Latenz-Problemen ist doch für einen Video-Player vollkommen irrelevant. Außerdem ist Jackd leider noch viel zu kompliziert zu konfigurieren. Solange die Konfiguration der Sound-Devices nicht ähnlich komfortabel, wie die Konfiguration eines Alsa-Device z.B. unter Gnome ist, wird sich Jackd im 'Linux-Mainstream' nicht durchsetzen, meine ich zumindest. Vielleicht kannst Du es ja implementieren...
>> Es reicht doch für solch eine Anwendung eine Kernel-unterstützte Alsa-Anbindung vollkommen aus. Das Problem an einer solchen Anbindung ist die exklusive Belegung der Devices. Will man einen zweiten Stream öffnen, muss der erste geschlossen werden. Dass dies weder zeitgemäß noch praktikabel ist, braucht nicht erwähnt werden.,
>> Außerdem ist Jackd leider noch viel zu kompliziert zu konfigurieren. Um ehrlich zu sein, verstehe ich diesen Einwand nicht. Die Installation des Servers ist ultraleicht, denn man braucht dazu weder etwas an der HW zu ändern noch eine Menge an Config-Files zu lesen. Verzeihe, aber bei mir war das Ding nach ca. 1 Minute einsatzbereit. Die Problematik ist eher, dass Du wohl Sound-Server und Sound Architectur verwechselst. Jack setzt (unter Anderem) auf Alsa auf, und muss deshalb nicht im GNOME konfiguriert werden.
Das Problem mit der exklusiven Belegung des Sounddevices haben nur JACK-User. Andere Anwendungen geben sich mit dmix zufrieden.
Natürlich muss jack in GNOME als Ausgabeplugin für GStreamer konfiguriert werden (jacksink), sonst spucken Rhythmbox und Co. keinen Ton aus, weil das ALSA-Sounddevice ja exklusiv von jackd genutzt wird.
Entschuldige, aber das was Du schreibst ist Unsinn. Die exklusive Belegung des Devices hat nur indirekt etwas mit dem Sound-Server zu tun. Jede Applikation die direkt auf ein Device zugreift, blockiert es. Es spielt dabei keine Rolle ob ich Arts, dmix Plug oder Jack benutze. dmix Plug fungiert dabei als eine Art "Sound-Server fuer Arme", weshalb die Lösung von fast allen Programmierern die sich mit M4L beschäftigen, abgelehnt wird. Zitat von MythTV: "the dmix plugin is evil!!!" Die Gründe sind vielseitig und in fast jedem Projekt nachzulesen.
Es ist kein Unsinn. Beherrscht die Soundkarte Hardware-Mixing oder nutzt man dmix, können normalerweise mehrere Anwendungen das Sounddevice nutzen.
Mit JACK ist das anders, da es explizit exklusiven Zugriff auf das Sounddevice fordert und sonst nicht läuft. Es duldet also niemanden neben sich. aRts, esd und polypaudio hingegen lassen sich z.B. auch mit dmix nutzen.
Und ja, dmix ist teilweise eine Katastrophe, nämlich wenn man 5.1 Sound drüber jagen will. Leider gibt es da keine Alternative. aRts ist zu fett, esd unbrauchbar und jack wird von viel zu wenigen Anwendungen unterstützt.
Man sollte IMO dmix verbessern. Hauptsache, es ist kein zusätzlicher Soundserver notwendig. Unter Windows ist ja auch das Soundsystem DirectSound für das Softwaremixing zuständig und da läuft es praktisch perfekt.
Es ist dir schon klar, dass Du hier zwei verschiedene Sachen vergleichst. MythTV ist nicht mit xawdecode zu vergleichen, denn es sich zwei Applikationen die nicht mal den selben Funktionsumfang haben.
Wenn dann bitte auch im Kontext: (Or, more precisely, dmix is evil when used incorrectly. Apologies to any ALSA developers for the drama. ;)
Meiner Ansicht nach ist dmix für den gewöhnlichen Audio-Nutzer vom Funktionsumfang ausreichend. Allein - wie es oben schon heraus klingt - die Konfiguration ist schwer und führt häufig zur Fehlkonfiguration, was dann zum Bashing auf dmix führt.
Wenn die Installation kinderleicht ist, warum bekommt dann artsd hier keine Verbindung zum jackd, obwohl dieser im Hintergrund läuft und das Device blockiert? Da muss wohl doch einiges umkonfiguriert werden. ;-) artsd über esd ist dagegen eine Kleinigkeit.
Kann mir mal einer jetzt genau erklären wo die unterschiede zwischen einem Soundserver wie Jack/arts ... und gStreamer liegen. Ich lese in letzter Zeit sehr viel über gStreamer und das es den alten Soundserver von Gnome ersetzen soll... wenn Jack so gut ist, warum nehmen dann nicht die aktuellen Distris ihn in ihre Roadmap auf, Jack ist ja nun nicht gerade ein neues Projekt!
kann als wrapper gestartet werden genauso wie jeder andere soundserver auch..... soviel kompetenz in einem Linuxforum, echt toll! Da mag man sehnsüchtig an die Zeit zurück denken als Linux noch einer kleinen aber feinen Gruppe vorbehalten war......
GStreamer kann esd gar nicht ersetzen, weil GStreamer kein Soundserver ist. Bei Ubuntu wurde esd durch polypaudio ersetzt, nen anderen Soundserver.
Dank GStreamer braucht sich ein Programm nicht mehr um die unterschiedlichen Soundserver (arts, esd, jack, nas, polypaudio, ...) bzw. Soundsysteme (alsa, oss, ...) zu kümmern, sondern kann auf eine festgelegte Schnittstelle zugreifen, die dann den Stream über die GStreamer-Pipeline auf das tatsächliche Output-Plugin leitet. Diese Output-Plugins werden als sink (Abfluss) bezeichnet. Welches genutzt werden soll, wird mit gstreamer-properties eingestellt.
Daneben enthält GStreamer auch Plugins, um MP3, Ogg Vorbis, DVDs usw. zu demultiplexen bzw. zu decodieren. Totem und Rhythmbox machen z.B. davon Gebrauch. Weiterhin bietet GStreamer die Möglichkeit, Audio und Video via lame, libvorbisenc oder mpeg2enc zu encodieren. Natürlich gibt es auch grafische Output-Plugins für die ASCII-Art-Library, die XVideo-Extension und X11-Shared-Memory, über die Totem und andere GStreamer-basierte Videoplayer das Bild ausgeben können.
aRts ist eine Kombination aus Soundserver und Multimedia-Framework. So nutzt Noatun das mpeglib-Plugin von aRts, um MP3-Dateien zu dekodieren. amaroK hat ebenfalls ein aRts-Plugin, kann aber auch GStreamer oder Xine nutzen.
Da GStreamer hierbei weit mehr Möglichkeiten bietet als aRts und auch eine größere Unterstützung erfährt, haben sich die KDE-Entwickler entschlossen, aRts zugunsten des desktopübergreifenden freedesktop.org-Projekt GStreamer aufzugeben.
Als Soundserver gibt es mit JACK eine Alternative zum artsd. Wer ALSA benutzt, hat mit dmix eine weitere Möglichkeit. Weiterhin kann man natürlich auch noch polypaudio oder auch esd verwenden.
Wie du siehst, ist aRts mittlerweile überflüssig geworden.
Von Manfred Tremmel am Do, 28. Juli 2005 um 13:23 #
> Das Problem an einer solchen Anbindung ist die exklusive Belegung der Devices.
Das Problem ist doch seit einiger Zeit gelöst. Gute Karten können eh mehrere Ausgaben gleichzeitig in Hardware und für andere mixt alsa die in Software zusammen. Die komplizierte DMix konfiguration gehört seit AFAIR der letzten ALSA Version der Vergangenheit an, weil das transparent automatisch aktiviert wird. Hab hier auf dem Notebook mit Intel-Sound (ICH4) zumindest keine gegenseitige Beeinflussung mehr. Bleibt die Frage, welchen sonstigen Nutzen ein Mediaplayer aus Jack ziehen könnte. Bei Soundbearbeitungsprogrammen ist es zweifelsohne eine klasse Sache, aber was bringt es xine?
Nach den Ergebnissen meiner Experimente mit Jack letzte Nacht würde Jack xine 5.1-Unterstützung bei gleichzeitigem Software-Mixing bringen. Mit dmix habe ich nur Stereo-Sound. Greife ich mit xine auf plug:surround51:0 zu, wird das Device leider exklusiv belegt.
Weiter an die ganzen leute die auf soundserver scheissen wollen: sie haben einen riesen vorteil, denn sie sind netzwerktransparent! (wie X11 fur grafik)
Hmmm, also soweit ich das sagen kann, ist der Support für den MPEG-PES-Demuxer seit den 0.99er-Versionen drinne. Wenn du mit Patches die Xine-Patches für das VDR-Xine-Plugin meinst: afaik hat R.Nissl (VDR-Xine-Plugin-Entwickler) irgendwann mal davon gesprochen, dass diese Patches nicht in das eigentliche Release der xine-lib integriert werden. Aber ich kann mich auch täuschen. Schau doch mal im Archiv der VDR-Mailingliste nach, da hat es so eine Frage schon mal gegeben.
ist irgendwie nicht so ganz aufschlussreich ... habe auch mal testweise die neuen Versionen kompiliert und kein vdr-support mehr, weder in der UI noch per direktem aufruf per vdr-URL.
Nachdem ja schon eine Menge von meinen Vorrednern gesagt wurde muss ich auch noch meinen Senf dazugeben. Ich habe wirklich viel mit Soundserver, Softwaremixen o. ä. herumexperimentiert.
Artsd von KDE ist vielleicht ein durchdachtes Framework, jedoch zu CPU-lastig und ressourcenhungrig, um praktikabel zu sein. Soweit ich weiß haben die KDE-Entwickler das auch gemerkt und arbeiten an Alternativen, freedesktop setzt glaube ich auch auf gstreamer auf.
Gstreamer ist ne tolle Sache, ich benutze es allerdings nicht.
Alsa ist die Ton-Schnittstelle des Kernels und kein Software-Mixer. Alle Sound-Server sind für den Ottonormalanwender meistens nur Software-Mixer, weil die Hardware das nicht kann oder die Funktionen vom Treiber nicht unterstützt werden. Alsa hat aber eine Plugin-Schnittstelle, hier kommt dmix ins Spiel. Alsa kann also mit dem dmix-Plugin Software-Mixen, jedoch ist das a) eine ziemliche Basterlerlösung, b) viele Programme funktionieren immer noch nicht mit dmix, obwohl alsa einwandfrei geht, c) ein Sound-Server gehört wie der Name schon sagt überhaupt nicht in den Kernelspace. Weil dmix auch wirklich nicht mehr kann als Tonspuren zu mischen, eignet es sich _überhauptnicht_ für professionelle Audio-Anwendungen.
Jack ist die momentan technisch sauberste und eine sehr gut implementierte Lösung. Entschuldigung, aber jack ist wie auf der Projektseite von Alsa nachzulesen auch das bevorzugte System zur Nutzung erweiterter Audiofunktionalitäten und wenn man es nicht kennt, zeugt das bei allem Respekt eher von geringerer Kenntnis der derzeitigen Linuxentwicklung, als davon, dass es ein schlechtes oder unbekanntes Programm ist.
Tatsachen: Jack ist einfach einzurichten, auf jeden fall einfacher als dmix. Das ist sicher. Es beschränkt sich auf die Installation und den Start des Audioservers jack bzw. jackd. Will man jedoch den Audio-Server als nichtroot im Echtzeitmodus laufen lassen, so muss man noch ein Modul für den Kernel kompilieren/installieren. Das war es. Alle mir bekannten professionellen Audio-Distris nutzen jackd. (siehe z. B. jacklab.org) Der einzige Grund, den ich mir vorstellen kann, dass die Normaldistris es nicht benutzen, ist die geringe Anzahl an Programmen, die ein entsprechendes Ausgabe-Plugin haben. Das ist äußerst schade und für mich unverständlich.
- mplayer kanns, aber nur eine Instanz auf einmal (das ist scheiße) - xine kanns nicht und wird es wahrscheinlich auch nie können - artsd kanns - gstreamer kanns - xmms und bmp könnens - die meisten anderen können es nicht - es gibt einige Möglichkeiten, Programmen Jack-Ausgabe zur Laufzeit "beizubringen"
Das wichtigste ist jedoch, jack ist nicht nur ein Software-mixer sondern bieten den Programmen auch die möglichkeit, miteinander zu kommunizieren. Ein geiles Stück Software also.
Was ich jedoch nicht verschweigen möchte, mir ist es öfter vorgekommen, das jackd aus irgendwelchen Gründen abschmiert. Man sollte die Entwicklung also jetzt unterstützen, damit wir in einem Jahr ein gutes, einheitliches und etabliertes Audio-Gespann (ALSA-Jack) unter Linux haben.
GStreamer ist kein Soundserver, sondern ein Multimedia-Framework, auf das andere Anwendungen zurückgreifen können, um Audio/Video zu encoden oder decoden oder um auf die Soundkarte zuzugreifen.
dmix läuft nicht im Kernelspace, sondern im Userspace, da es eine Erweiterung der libasound darstellt. Bei dmix muss man überhaupt nichts konfigurieren, da es einfach genutzt wird (ab alsa-lib 1.0.9).
jackd läuft hier nur mit Userrechten und kann nur von dem User genutzt werden, der ihn gestartet hat. Ich will aber auch als root noch aufs Sounddevice zugreifen können. Ich hab noch keine passende Konfigurationsoption gefunden.
Klar bietet jack wesentlich mehr Möglichkeiten als z.B. esd, aber ich brauche sie nicht.
Mir wäre ein transparenter Software-Mixer, wie ihn Windows bietet, wesentlich lieber. Vor allem muss er aber auch Stereo- und 5.1-Sound mixen können. Das fehlt mir unter Linux am allermeisten in Sachen Sound. Mangels jack-Unterstützung von xine kann ich das nicht testen. oss2jack kann ja leider nur Stereo, ist für mich also unbrauchbar.
Oh Mann. Es wird einem schwindelg von den vielen Verdrehungen und Halbwahrheiten, die Du hier verbreitest. Der reinste Horror! Fakt ist, dass es nicht nativ möglich ist Xine auf Jack laufen zu lassen. Lösungen wie OSS2Jack, dmix oder Parallele Server wie Arts mit Jack-Out sind zwar nett, aber nicht erwünscht. Hinzu kommt noch, dass Du dir dauernd wiedersprichst... Tzzz...
Welche Halbwahrheiten verbreite ich denn? Wo habe ich behauptet, dass Xine native Jack-Unterstützung hat?
Ich verwende kein oss2jack, dmix oder nen zweiten Soundserver, sondern das ALSA-Plugin, um direkten Zugriff auf ALSA auf jackd umzuleiten. Seit ALSA 1.0.9 steckt das im Paket alsa-plugins. Und dieses Plugin ermöglicht sogar 5.1-Sound, ganz im Gegensatz zu oss2jack und dmix, die nur Stereo können.
Nun frage ich mich provokant, warum es eigentlich die MPlayer-Coder fertig bringen eine bio2jack-basierende Lösung (die auch funktioniert) zu integrieren und die Xine-Leute die selbe verwerfen? Solange Xine keine Jack-Ausgabe bietet wird es von vielen Rechnern entfernt und durch MPlayer ersetzt werden.
Ich persönlich hoffe ja, dass die soundwrapper ganz aussterben. Ein grossteil der Applikationen teilt sich bei mir schon jetzt problemlos die soundkarte, dank alsa's dmix-plugin.
Gruß
Roman
Wie kommst Du drauf, dass anscheinend alle diese Jack benutzen?
theile
Hat eh mehr Verwirrung gestiftet, als Vorteile gebracht.
Welche Distrie nutzt Jack per default, was kann Jack, warum sollte man Jack nutzen, und wer sagt folgendes: "Standard im Sound- und Multimediabereich" ? :)
(Das heisst nicht das Jack schlecht ist, oder nichts taugt. Aber irgendwie scheint deine Darstellung etwas überzogen zu sein)
Jack ist gerade in der "professionellen" Linux Audio Developers Branche nicht mehr wegzudenken und kann als Quasi-Standard angesehen werden.
cu
Fabian
Und, wenn Jack die gleiche Qualität haben soll wie dieses unbrauchbare Alsa, dann brauch' ich es mir garnicht erst anzusehen.
Hinzu kommt dann noch die Motivation. Warum soll ich überhaupt einen Sounddaemon verwenden? Normalerweise schaue ich nicht gleichzeitig Film, höre eine CD und spiele nen Egoshooter. Das verkraftet mein Gehör eh nur seriell. Zudem bedeutet eine zusätzliche Ebene zwischen Programm und Soundkarte üblicherweise nur eine Soundverschlechterung.
Mehr noch: Es ist klar, dass der Hauptentwickler von Jack sein eigenes Produkt benutzt ;-).
Gruss,
Censor
Paul Davis benutz JACK nicht, weil "es sein eigenes Projekt ist", sondern weil er es genau zu diesem Zweck entworfen hat: als den ersten Linux-Audioserver, der den Einsatz von Linux als professionelles Harddiskrecordigsystem erlaubt. Alle anderen sind lediglich geeignet, Systemsounds auszugeben, während man sich eine CD anhört - für eine Audio-Workstation wäre das etwaS knapp
ES geht bei Jack, wie schon gesagt eben nicht nur um hören und sehen von fertigem Material, sondern um das Erzeugen und Bearbeiten von selbstgemachten Sounds.
Da gibt es sog. "Musiker" die stellen dem ganzen Kram her, den sich alle anderen dann anhören müssen und diese Typen können das mit Jack eben auch in Linux.
Um es noch verständilicher zu machen:
Frage: ich habe einen Mix von 16 Stereospuren, von denen ich 4 an einen LADSPA-Echoeffekt weiterleiten, den ganzen Rest durch JAMin mastern und anschliessend auf eine 24/96 Wav-Datei aufnehmen will - wie soll das gehen?
(einzige)Antwort: mit Jack.
alle ernst zu nehmenden Soundapplikationen für Linux und die meisten frei lizenzierten für MAC-OS kommunizieren über JACK, Jack ist im vorigen Jahr bei den britischen Open Source Awards einer der Gewinner gewesen.
http://builder.com.com/5100-6375-5136755.html?tag=tt
Das Du etwas, was eine vielleicht kleine Gruppe von Leuten wissen, nicht weisst, macht Dich nicht zu einem Experten.
>Und mir ist neu das Linux im professionellen Audio-Bereich überhaupt eine Bedeutung hat.
Willkommen im 21ten Jahrhundert.
Inzwischen gibt es Effekt-racks und professionelle Workstations, auf denen Linux/Alsa/Jack laufen.
>Und warum soll das dann auch noch für Xine wichtig sein?
Weil Xine dann auch von Leuten benutzt werden könnte, die mehr mit Musik (und vielleicht auch mit Filmen...) machen, als nur zu konsumieren.
Nun, wuerde man der Aussage folgen, dann duerften viele Projekte nicht existieren. So argumentieren auch viele Windows-Benutzer in Bezug auf Linux. ;)
Und warum soll das dann auch noch für Xine wichtig sein?
Um ehrlich zu sein, bin ich auch ein Fan von Jack. Meiner Meinung nach ist es eine sehr wichtige Multimedia-Entwicklung der letzten Jahre. Die Moeglichkeiten des Servers sind beeindruckend. Positiv faellt auf, dass fast alle Multimedia-Applikationen unter Linux auch Jack unterstuetzen. Einzig Xine fällt hier aus der Reihe. Auch ich bin mittlerweile auf MPlayer umgestiegen (ungern) und nutze Xine nur in Ausnahmefaellen. Wie bereits mein »Vorschreiber« sagte, habe auch ich keine Lust 2 Sound-Server zu installieren, nur damit ich Xine eine Sound-Ausgabe entlocken kann.
Gruss
demon
Und ganz ehrlich, ALLE soundserver sind nur ein hack - wenn xine auf jack verzichtet, was solls?
Gruss,
demon
Du kannst mir übrigens bestimmt sagen, wie man jackd als root ausführen und trotzdem mit beliebigen Benutzern, die in der Gruppe audio sind, auf jackd zugreifen kann.
Wenn Du darauf hinaus willst, dass es nicht funktioniert, dann muss ich Dich leider enttaeuschen. Es gibt diverse Patches, die es ermoeglichen. Suche dazu zum Beispiel nach Patches von Kjetil Svalastog. Ob es Sinn macht, sei dahin gestellt. Warum sollen zwei User simultan auf das selbe Device Sounds ausgeben? Wer's aber mag...
Gruss
demon
Hier läuft grad ne DVD in 5.1-Sound mit Kaffeine (Xine) über jack. :-)
Ich will mir nur ersparen, jack ständig als der jeweilige User zu starten. esd kann z.B. über Init-Skripte gestartet werden. Ich hab hier auch eines für jack, nur kann ich dann nur als root Musik abspielen. Mit dmix hat man solche Probleme gar nicht erst.
Manche Programme lasse ich unter einem anderen Benutzernamen laufen (mpd z.B.). Die sollen natürlich auch Zugriff auf die Soundkarte haben, genauso wie mein Hauptbenutzer, wenn ich Kaffeine für DVDs nehme.
Mit jack als Systemdienst würde ich alles darüber laufen lassen.
Achja, wenn ich jackd als User starte, krieg ich natürlich keine Echtzeitpriorität und bei viel Aktivität, z.B. durch Encodieren, setzt der Ton manchmal aus. Auch dafür müsste ich jackd mit root-Rechten ausführen.
Wenn KDE z.B. gleichzeitig (d.h. mit so geringer Verzögerung wie möglich) mit dem Klicken auf einen Knopf einen Sound abspielen will, dann ist Arts schlecht darin (bei meinem System verzögert sich der Sound um ca 1 Sekunde) und Jack gut darin (Latenz nicht wahrnehmbar).
Wenn du einen ganzen Song abspielst ist das ziehmlich egal, weil es wirklich niemanden kratzt wenn du nach dem Drücken des Start- Buttons noch eine Sekunde warten mußt, wenn du aber Audiobearbeitung machst, dann ist es sehr wichtig, dass der cursor und die Musik das gleiche tun, bzw. wenn du auf Halt drückst nicht noch eine Sekunde nachgespielt wird.
http://www.ukuug.org/events/linux2003/papers/TIwai/soundsystems/
Das Problem an einer solchen Anbindung ist die exklusive Belegung der Devices. Will man einen zweiten Stream öffnen, muss der erste geschlossen werden. Dass dies weder zeitgemäß noch praktikabel ist, braucht nicht erwähnt werden.,
>> Außerdem ist Jackd leider noch viel zu kompliziert zu konfigurieren.
Um ehrlich zu sein, verstehe ich diesen Einwand nicht. Die Installation des Servers ist ultraleicht, denn man braucht dazu weder etwas an der HW zu ändern noch eine Menge an Config-Files zu lesen. Verzeihe, aber bei mir war das Ding nach ca. 1 Minute einsatzbereit. Die Problematik ist eher, dass Du wohl Sound-Server und Sound Architectur verwechselst. Jack setzt (unter Anderem) auf Alsa auf, und muss deshalb nicht im GNOME konfiguriert werden.
Andere Anwendungen geben sich mit dmix zufrieden.
Natürlich muss jack in GNOME als Ausgabeplugin für GStreamer konfiguriert werden (jacksink), sonst spucken Rhythmbox und Co. keinen Ton aus, weil das ALSA-Sounddevice ja exklusiv von jackd genutzt wird.
Das kommt mir bekannt vor :D
http://www.mythtv.info/moin.cgi/DigitalSoundHowTo
MythTV -> Daumen hoch
Mit JACK ist das anders, da es explizit exklusiven Zugriff auf das Sounddevice fordert und sonst nicht läuft. Es duldet also niemanden neben sich.
aRts, esd und polypaudio hingegen lassen sich z.B. auch mit dmix nutzen.
Und ja, dmix ist teilweise eine Katastrophe, nämlich wenn man 5.1 Sound drüber jagen will. Leider gibt es da keine Alternative. aRts ist zu fett, esd unbrauchbar und jack wird von viel zu wenigen Anwendungen unterstützt.
Man sollte IMO dmix verbessern. Hauptsache, es ist kein zusätzlicher Soundserver notwendig. Unter Windows ist ja auch das Soundsystem DirectSound für das Softwaremixing zuständig und da läuft es praktisch perfekt.
Braucht unmengen an vorinstallierten Kram, ist grausam zu benutzten und lahmarschig.
Da kann man gleich bei xawdecode bleiben.
Wenn dann bitte auch im Kontext:
(Or, more precisely, dmix is evil when used incorrectly. Apologies to any ALSA developers for the drama. ;)
Meiner Ansicht nach ist dmix für den gewöhnlichen Audio-Nutzer vom Funktionsumfang ausreichend. Allein - wie es oben schon heraus klingt - die Konfiguration ist schwer und führt häufig zur Fehlkonfiguration, was dann zum Bashing auf dmix führt.
dmix is not evil but stubburn ;-)
Gruss,
Censor
artsd über esd ist dagegen eine Kleinigkeit.
Ich lese in letzter Zeit sehr viel über gStreamer und das es den alten Soundserver von Gnome ersetzen soll... wenn Jack so gut ist, warum nehmen dann nicht die aktuellen Distris ihn in ihre Roadmap auf, Jack ist ja nun nicht gerade ein neues Projekt!
Für Aufklärung wäre ich dankbar thx
Dank GStreamer braucht sich ein Programm nicht mehr um die unterschiedlichen Soundserver (arts, esd, jack, nas, polypaudio, ...) bzw. Soundsysteme (alsa, oss, ...) zu kümmern, sondern kann auf eine festgelegte Schnittstelle zugreifen, die dann den Stream über die GStreamer-Pipeline auf das tatsächliche Output-Plugin leitet. Diese Output-Plugins werden als sink (Abfluss) bezeichnet. Welches genutzt werden soll, wird mit gstreamer-properties eingestellt.
Daneben enthält GStreamer auch Plugins, um MP3, Ogg Vorbis, DVDs usw. zu demultiplexen bzw. zu decodieren. Totem und Rhythmbox machen z.B. davon Gebrauch.
Weiterhin bietet GStreamer die Möglichkeit, Audio und Video via lame, libvorbisenc oder mpeg2enc zu encodieren.
Natürlich gibt es auch grafische Output-Plugins für die ASCII-Art-Library, die XVideo-Extension und X11-Shared-Memory, über die Totem und andere GStreamer-basierte Videoplayer das Bild ausgeben können.
aRts ist eine Kombination aus Soundserver und Multimedia-Framework. So nutzt Noatun das mpeglib-Plugin von aRts, um MP3-Dateien zu dekodieren. amaroK hat ebenfalls ein aRts-Plugin, kann aber auch GStreamer oder Xine nutzen.
Da GStreamer hierbei weit mehr Möglichkeiten bietet als aRts und auch eine größere Unterstützung erfährt, haben sich die KDE-Entwickler entschlossen, aRts zugunsten des desktopübergreifenden freedesktop.org-Projekt GStreamer aufzugeben.
Als Soundserver gibt es mit JACK eine Alternative zum artsd. Wer ALSA benutzt, hat mit dmix eine weitere Möglichkeit. Weiterhin kann man natürlich auch noch polypaudio oder auch esd verwenden.
Wie du siehst, ist aRts mittlerweile überflüssig geworden.
Das Problem ist doch seit einiger Zeit gelöst. Gute Karten können eh mehrere Ausgaben gleichzeitig in Hardware und für andere mixt alsa die in Software zusammen. Die komplizierte DMix konfiguration gehört seit AFAIR der letzten ALSA Version der Vergangenheit an, weil das transparent automatisch aktiviert wird. Hab hier auf dem Notebook mit Intel-Sound (ICH4) zumindest keine gegenseitige Beeinflussung mehr.
Bleibt die Frage, welchen sonstigen Nutzen ein Mediaplayer aus Jack ziehen könnte. Bei Soundbearbeitungsprogrammen ist es zweifelsohne eine klasse Sache, aber was bringt es xine?
Mit dmix habe ich nur Stereo-Sound.
Greife ich mit xine auf plug:surround51:0 zu, wird das Device leider exklusiv belegt.
Weiter an die ganzen leute die auf soundserver scheissen wollen: sie haben einen riesen vorteil, denn sie sind netzwerktransparent! (wie X11 fur grafik)
Als netzwerktransparenter Server empfiehlt sich NAS.
Weiß da einer etwas zu?
Danke
- http://sourceforge.net/mailarchive/message.php?msg_id=12329107
- http://sourceforge.net/mailarchive/message.php?msg_id=11512824
ist irgendwie nicht so ganz aufschlussreich ... habe auch mal testweise die neuen Versionen kompiliert und kein vdr-support mehr, weder in der UI noch per direktem aufruf per vdr-URL.
Artsd von KDE ist vielleicht ein durchdachtes Framework, jedoch zu CPU-lastig und ressourcenhungrig, um praktikabel zu sein. Soweit ich weiß haben die KDE-Entwickler das auch gemerkt und arbeiten an Alternativen, freedesktop setzt glaube ich auch auf gstreamer auf.
Gstreamer ist ne tolle Sache, ich benutze es allerdings nicht.
Alsa ist die Ton-Schnittstelle des Kernels und kein Software-Mixer. Alle Sound-Server sind für den Ottonormalanwender meistens nur Software-Mixer, weil die Hardware das nicht kann oder die Funktionen vom Treiber nicht unterstützt werden. Alsa hat aber eine Plugin-Schnittstelle, hier kommt dmix ins Spiel. Alsa kann also mit dem dmix-Plugin Software-Mixen, jedoch ist das a) eine ziemliche Basterlerlösung, b) viele Programme funktionieren immer noch nicht mit dmix, obwohl alsa einwandfrei geht, c) ein Sound-Server gehört wie der Name schon sagt überhaupt nicht in den Kernelspace. Weil dmix auch wirklich nicht mehr kann als Tonspuren zu mischen, eignet es sich _überhauptnicht_ für professionelle Audio-Anwendungen.
Jack ist die momentan technisch sauberste und eine sehr gut implementierte Lösung. Entschuldigung, aber jack ist wie auf der Projektseite von Alsa nachzulesen auch das bevorzugte System zur Nutzung erweiterter Audiofunktionalitäten und wenn man es nicht kennt, zeugt das bei allem Respekt eher von geringerer Kenntnis der derzeitigen Linuxentwicklung, als davon, dass es ein schlechtes oder unbekanntes Programm ist.
Tatsachen:
Jack ist einfach einzurichten, auf jeden fall einfacher als dmix. Das ist sicher. Es beschränkt sich auf die Installation und den Start des Audioservers jack bzw. jackd. Will man jedoch den Audio-Server als nichtroot im Echtzeitmodus laufen lassen, so muss man noch ein Modul für den Kernel kompilieren/installieren. Das war es.
Alle mir bekannten professionellen Audio-Distris nutzen jackd. (siehe z. B. jacklab.org)
Der einzige Grund, den ich mir vorstellen kann, dass die Normaldistris es nicht benutzen, ist die geringe Anzahl an Programmen, die ein entsprechendes Ausgabe-Plugin haben. Das ist äußerst schade und für mich unverständlich.
- mplayer kanns, aber nur eine Instanz auf einmal (das ist scheiße)
- xine kanns nicht und wird es wahrscheinlich auch nie können
- artsd kanns
- gstreamer kanns
- xmms und bmp könnens
- die meisten anderen können es nicht
- es gibt einige Möglichkeiten, Programmen Jack-Ausgabe zur Laufzeit "beizubringen"
Das wichtigste ist jedoch, jack ist nicht nur ein Software-mixer sondern bieten den Programmen auch die möglichkeit, miteinander zu kommunizieren. Ein geiles Stück Software also.
Was ich jedoch nicht verschweigen möchte, mir ist es öfter vorgekommen, das jackd aus irgendwelchen Gründen abschmiert. Man sollte die Entwicklung also jetzt unterstützen, damit wir in einem Jahr ein gutes, einheitliches und etabliertes Audio-Gespann (ALSA-Jack) unter Linux haben.
GStreamer ist kein Soundserver, sondern ein Multimedia-Framework, auf das andere Anwendungen zurückgreifen können, um Audio/Video zu encoden oder decoden oder um auf die Soundkarte zuzugreifen.
dmix läuft nicht im Kernelspace, sondern im Userspace, da es eine Erweiterung der libasound darstellt. Bei dmix muss man überhaupt nichts konfigurieren, da es einfach genutzt wird (ab alsa-lib 1.0.9).
jackd läuft hier nur mit Userrechten und kann nur von dem User genutzt werden, der ihn gestartet hat. Ich will aber auch als root noch aufs Sounddevice zugreifen können. Ich hab noch keine passende Konfigurationsoption gefunden.
Klar bietet jack wesentlich mehr Möglichkeiten als z.B. esd, aber ich brauche sie nicht.
Mir wäre ein transparenter Software-Mixer, wie ihn Windows bietet, wesentlich lieber. Vor allem muss er aber auch Stereo- und 5.1-Sound mixen können. Das fehlt mir unter Linux am allermeisten in Sachen Sound.
Mangels jack-Unterstützung von xine kann ich das nicht testen.
oss2jack kann ja leider nur Stereo, ist für mich also unbrauchbar.
Entscheident für Linux ist Auspacken, Installieren, "Multimedia" CD oder DVD einlegen - abspielen, egal ob kodiert oder mit Region Code !
Und DAS bitte STABIL, EINFACH und ÜBERSICHTLICH, ohne Gefunmmel, Patches oder sonstiges Zeugs !
Sonst wird Windows genommen...
Mir doch egal was Du nimmst.
mfg
gruss
NikN
Wo habe ich behauptet, dass Xine native Jack-Unterstützung hat?
Ich verwende kein oss2jack, dmix oder nen zweiten Soundserver, sondern das ALSA-Plugin, um direkten Zugriff auf ALSA auf jackd umzuleiten. Seit ALSA 1.0.9 steckt das im Paket alsa-plugins.
Und dieses Plugin ermöglicht sogar 5.1-Sound, ganz im Gegensatz zu oss2jack und dmix, die nur Stereo können.
das soll sicher ffmpeg sein.