> Diese Programme müssen weiterhin ein Framework direkt nutzen. Ihre Zahl ist jedoch geringer als die der Programme, die nur relativ einfache Multimedia-Funktionen benötigen.
Für solche Programme ist es sowieso sinnvoller direkt auf Jack zuzugreifen. Allein schon wegen der niedirgeren Latenz, bei der eine weitere Abstraktionsschicht sicherlich keine gute Idee ist.
Dennoch fehlt mir hier die direkte Anbindung von Phonon an Jack noch, eventuell kommt das aber vielleicht noch. Bis dahin hat man wohl nur die Möglichkeit über Gstreamer an Jack zu kommen und da ist nicht gerade toll. Phonon -> Gstreamer -> Jack
[ ] Mir ist klar, das Multimedia mehr ist als Audioausgabe [ ] Ich weiss, das jack mir nicht hilft, bunte Bildchen auf den Moonitor zu zaubern ;) Nix für ungut, aber du verglkeichst äpfel mit birnen...
Nana kommt Leute, wir brauchen hier nicht das gewohnte Heise-Kästchen-Spielchen spielen oder?
auf de roben genannten Siete finden sich auch Kommentare. einer davon sagt dies:
> Re: jackd integration > by piters on Tuesday 06/Feb/2007, @08:54 > Hi, > certainly, having jackd interfaced somehow into Phonon would be great for everybody who wants to make music on Linux. > As far as I understand, jackd itself is not an engine... It is the way to get into your soundcard/midi and stream the data from/to there. So it is roughly at the level of ALSA or OSS... > On the contrary, Phonon relies on "hefty" backends such as xine, capable of doing all the file-decoding for mpegs, oggs, etc; and it is xine that would actually need to talk to jackd (rather than to ALSA, OSS, or so)... > So: it might be a question to the XINE developers to support jackd... > > Could some of KDE/Phonon specialist tell if my thinking is right? > > Any bright ideas to have jackd integrated somehow anyway?
Jack ist für (semi-)professionelle Audio Ein- und Ausgabe vorgesehen, nicht für Programme, die einfach nur mal ein bißchen Multimedia-Inhalte wiedergeben wollen. So gut Jack auch ist, es ist nicht abzusehen, daß Jack irgendwann Standard auf Otto-Normal-Desktop-Systemen wird. Und dafür ist es auch schlicht und einfach nicht gedacht.
Was wir brauchen ist ein Framework, daß bei Bedarf Jack nutzt (z.B. auch wenn Jack läuft und die Soundkarte blockiert), aber auch ohne auskommt. Und da ist Gstreamer schon auf genau dem richtigen Weg.
> Jack ist für (semi-)professionelle Audio Ein- und Ausgabe vorgesehen, nicht für Programme, die einfach nur mal ein bißchen Multimedia-Inhalte wiedergeben wollen.
Das weiß ich alles, aber trotzdem würde ich auch gerne die Soundausgabe einfacher Anwendungen, wie z.B. Teamspeak (was übrigens QT nutzt, die Verwendung von Phonon liegt also nahe) über Jack leiten können. Und das hat auch einen guten Grund, wer Jack kennt weiß nämlich was für tolle Sachen dann damit möglich wären. ;)
Gleiches gilt natürlich auch für einfache Musik und CD Abspielprogramme, könnten die den Sound über Jack leiten, dann könnte man die Musik in Echtzeit richtig schön verändern und z.b. der Musik die Akkustik eines Konzertsaales hinzufügen. Dazu braucht man Jack welches dann LADSPA nutzen kann.
Jack ist mehr als nur eine professionelle Lösung für Audiobearbeitungs und Musikerstellungssoftware, damit sind auch noch ganz andere Sachen möglich.
Von Kevin Krammer am Mi, 7. Februar 2007 um 16:58 #
Jack setzt aber vorraus, daß ein Prozess davor die Daten dekodiert hat, also zB einen OGG Vorbis Dekoder hat.
Das ist in der Terminologie von Phonon ein Backend. Ob das Backend dann über Jack ausgeben kann, liegt an den Möglichkeiten des Backends, Phonon kann das dann automatisch auch.
> Das weiß ich alles, aber trotzdem würde ich auch gerne die Soundausgabe einfacher Anwendungen, wie z.B. Teamspeak
Kleiner Fehler von mir. Im Fall von Teamspeak meine ich natürlich insbesondere die Soundeingabe und zwar bevor der Sound in Teamspeak weiterverarbeitet wird. Bei er Ausgabe macht es nicht so viel Sinn.
Ich finde das immer wieder interesant. Viele Leute setzen alle Arten von Abstraktion gleich und implizieren damit Bloat und Langsamkeit. Wie so oft hilft ein Blick auf die Details, der im Fall von Phonon deutlich macht, dass das Gegenteil der Fall ist:
ALSA kümmert sich um die Hardware:
Musikrohdatenströme (also nix MP3) mittels Gerätetreibern auf bestimmte Geräte ausgeben oder von diesen Geräten einlesen und die Steuerfunktionen der Hardware wie An/Aus, Laut und Leise und so weiter zu unterstützen.
Jackd das digitale Mischpult:
ALSA selber kann nur sehr wenige "Transformationen" wie Lautstärkeregelung vornehmen und kümmert sich rein um die Hardware. Nun möchte man aber gerne vorm Abspielen noch seinen Rohdatenstrom manipulieren, gezielt mit anderen Daten (oder gar in einer Rückkoppelung mit sich selbst, Stichwort "Hall") mischen, Freqenzfilter anwenden (Bassverstärkung bspw.) usw. Jack ist also ein digitales Mischpult. Der Heimanwender der Musik und Filme abspielt und ein bischen mit seinem Mikrofon was aufnimmt braucht es nicht, aber den Profimusiker freut es.
Xine der Entpacker:
Nun ist es ja allgemein bekannt, das Musik (und Filme) im Rohdatenformat äußerst unhandlich sind. Um dem Problem herr zu werden hat man also verschiedene Komprimierungsroutinen entwickelt, eben MP3, OGG-Vorbis, MPEG4 usw. usw. So wie es keinen Sinn macht eine Zipdatei direkt im Texteditor zu öffnen, macht es keinen Sinn ALSA oder Jackd mit einem MP3 zu füttern. Xine ist also der Entpacker für Multimediadaten aller Art.
Phonon der Multikultikit:
Weil es nun gar schrecklich viele Kompressionscodecs gibt und zu allem Überfluss auch noch verschiedene Konzepte gibt, wie man denen am besten herr wird und jedes dieser Konzepte seine Eigenheiten hat wäre es ziemlich töricht sich auf eins festzulegen, zumal KDE auch unter OSX und Windows funktionieren soll, die jeweils eigene Konzepte der Dekompression haben (Directshow und Quicktime). Phonon will also KDE-Anwendungen nun grundlegende Funktionen all dieser Konzepte unter einer einheitlichen Schnitstelle anbieten. Im Grunde macht Phonon nx anderes als: "Backend (bspw. Xine) hier sind die Daten und die Parameter die von der Anweundung gewünscht sind, jetzt entpack das mal und gibs dort aus wo es der Anwender haben will." Die Daten selber wandern also nicht erst duch Phonon hindurch. Phonon ist nur Kontaktvermittler zwischen Anwendung und Backend.
Also welchen Weg nehmen die Daten mit Phonon?
Applikation befielt über Phonon: Datei ABC -> bitte mit Xine entpackt -> (über Jackd verfremdet) -> dank ALSA auf meinen Boxen ausgeben.
Und was ist da jetzt das Problem bei? Dann nutzt du halt zusätzlich auch Jackd. Ich kann Musik auf ner großen Anlage auch ohne Mischpult ausgeben, mit ist es einfach besser, aber auf ner kleinen isses halt Overkill...
Genau, bei guter Software Architektur ist es durchaus üblich sehr viele Abstraktionsebenen zu haben, auch im eigenen System. Da landet man dann irgendwann bei der Meta-Meta-Meta Ebene.
Immer wieder kommen da undurchschaubare Konstrukte raus, die auch noch langsam sind, das muss aber nicht sein. Kommt immer drauf an wie es gemacht ist.
Mit dem Unterschied dass hier gerade keine Meta-Meta-Ebenen übereinander liegen. Der eine steuert (Phonon), der andere kodiert (Xine bspw.), der nächste mischt (Jackd), und der letzte spricht mit der Hardware (Alsa). Jedes genau eine Aufgabe.
Bitte berichtigt mich, wenn ich falsch liege. So wie ich das verstanden habe, ist Jack ein sound-deamon, der sehr viel mehr Funktionen in sich vereint, als z.B. artsd, dazu noch mit weit weniger Latenz. Das muss ja wohl so sein, sonst wäre er nicht erste Wahl für die "Profimusiker". Wenn aber Jack so viel besser ist, warum wird er dann nicht per default in den Distris eingesetzt? Hat's denn auch Nachteile?
Artsd war ein digitales Mischpult und Dekoder in einem. Einfache Mischfunktionen ("mische Musik und Systemklänge") werden heutzutage vom Kernel bereitgestellt (deswegen blockiert auch deine Soundkarte nicht mehr).
Jackd ist nur ein digitales Mischpult, aber darin deutlich leistungsfähiger als Artsd. Das heißt konkret, dass Jackd Artsd nicht allein ersetzen kann.
Um ein Video abzuspielen brauchst du in der Regel kein Jackd, für die Erstellung einer effektreichen Musikuntermalung eines Videos hingegen schon. Jackd braucht also nicht jeder. Und wenn man es braucht kann man es einfach dazwischenstöpseln.
Einfache Mischfunktionen ("mische Musik und Systemklänge") werden heutzutage vom Kernel bereitgestellt (deswegen blockiert auch deine Soundkarte nicht mehr). Nein, dmix läuft im Userspace (libasound.so).
Ich verstehe die Hierarchie, die Du hier skizierst. Im verlinkten Artikel zeigt aber ein Screenshot, dass über eine Phonon-GUI die HW ausgesucht werden kann, auf der abgespielt werden soll. Ist das nicht eher die Domäne von ALSA?
Von Kevin Krammer am Fr, 9. Februar 2007 um 13:05 #
Kernel und Treiber geben natürlich mal in erster Linie bekannt, welche Hardware mit welcher Unterstützung vorhanden ist.
Aber besonders bei der Verfügbarkeit mehrere Geräte braucht der Benutzer eine Möglichkeit, bestimmte Kombinationen festzulegen, denn nicht alles kann 100% automatisch eingestellt werden.
Mir würde es schon reichen, wenn sich jackd und Desktopaudio sich nicht mehr stören würden.
Das hiesse dann:
Nach dem Login startet automatisch jackd, bekommt den nötigen Exklusivzugriff auf Alsa und läuft normal stabil mit 5ms Latenz.
sämtliche Desktopsounds - vom Terminplaneralarm über das VoIP-Programm bis zum Audio/Videoplayer nutzen gemeinsam einen jackd-Klienten, der von einem Desktop-Sounddaemon wie PulsAudio esd oder dergleichen erzeugt wird. Wenn Phonon bei der Entwicklung einer solchen Lösung helfen kann, bin ich begeistert!!
Dennoch fehlt mir hier die direkte Anbindung von Phonon an Jack noch, eventuell kommt das aber vielleicht noch. Was soll das bringen? Willst du eine MP3- oder Ogg-Vorbis-Datei direkt an den jackd schicken? Irgendwer muss den Stream doch erst einam dekodieren.
... wenn KDE 4 kommt und wirklich plattformunabhängig sein sollte, ist es dann nicht Zeit für die Distributoren, vermehrt auf die KDE zu setzen? RedHat und Novell könnten dann auch für KDE-Support unter Windows Geld verdienen und relativ einfache und schöne Migrationsangebote machen. Auch andere Ideen von Novell haben ja das Ziel, Plattformunabhängig zu sein, wie Mono zeigt. Auf den Wettbewerb bin ich ja sehr gespannt.
Nö, da würde ich deinem Vorredner schon zustimmen, denn Schreibtisch wäre Desk, Desktop dementsprechend die Oberfläche des Schreibtisches, also die Arbeitsfläche
irgendwie macht mich das bis heute nachdenklich... wann ist überhaupt ein wort sächlich oder männlich bzw. weiblich? gibt es da keine regeln? könnte man das nicht fest definieren?
Deutsche Sprache schwere Sprache. Da gibt es keine Regel und man kann es nur auswendig lernen. Daher hat man es auch recht schwer, wenn man Deutsch als Fremdsprache lernt.
Von Anonymous Coward am Mi, 7. Februar 2007 um 16:50 #
Nein, aber das Interface. Wenn Du einen weiblichen Artikel verwenden möchtest, musst Du auch den Rest übersetzen, z. B. die PS (Programmierschnittstelle). Die API ist einfach falsch, da inkonsistent.
Die APS wäre richtig (Anwendungs Programmier Schnittstelle) das API wäre auch richtig, alles andere wohl falsch. Ich bleib auch bei die API, die Vorstellung einer Frau ist einfach schöner ;)
Von Martin Gaebler am Mi, 7. Februar 2007 um 17:25 #
Also: Ein Wort ist männlich, wenn es einen Schniedel hat, weiblich, wenn es ein Bärchen hat und sächlich, wenn es sabbert und in die Windeln kackt. Klar? Wusste ich es doch...
Ich glaube, ursprünglich waren Konkrete Dinge, wie ein Baum, eher männlich, während abstrakte, wie die Treue, eher weiblich. Da lässt sich allerdings heute nicht mehr anwenden, also kann man diesen Beitrag auch gerne ignorieren
Die Diskussion über das Geschlecht gehen im Großen und Ganzen an der Sache vorbei. Die meisten Ausdrücke kommen ja nun mal aus dem Englischen. Und in dieser Sprache ist nun mal so, daß Sachen, also nicht Lebewesen, immer sächlich sind. Bei Sachen wird im Englischen nicht zwischen männlich und weiblich unterschieden. Demzufolge heißt es streng genommen das KDE, das Mail, das file etc. Weshalb wir Deutschen Schwierigkeiten haben, das passende Geschlecht für original englischsprachige Ausdrücke zu finden, ist die Tatsache, daß wir auch bei Gegenständen eine "Geschlechtertrennung" vornehmen. Beispiel Mail: Wir übernehmen das Wort, übersetzen es für ins deutsche Wort Post. Und schon heißt es größtenteils die Mail und nicht korrekterweise das Mail. Übrigens schließe ich mich selber damit auch ein. Ich sage fälschlicherweise auch die Mail. Das ist nun mal der Nachteil, wenn man fremdsprachige Ausdrücke übernimmt. Allerdings sollte man aus dieser Problematik kein Dogma machen. Insofern ist es m.E. egal, welches Geschlecht man nimmt, wenn man das sächliche aus dem Englischen nicht übernimmt.
Es wäre nicht falsch, sondern unüblich. Sprache ist alles nur Konvention bzw. Nachahmung. Wenn alle die Mail sagen, dann ist es die Mail. Sprache ist Zweck, und nicht Selbstzweck.
Naja, das wäre auch ein Anfang. Zeig den Unternehmern mal kontact, konqueror und so zum reinschnuppern auf dem Windows Desktop und bei der nächsten Runde schiebt man den Unternehmen gleich ein Linux drunter. Sanfte Migration mit Einlern- und Gewöhnungsphase und am Ende spart das Unternehmen die Lizenzkosten für Windows und Office...
Von Anonymous Coward am Mi, 7. Februar 2007 um 16:54 #
Wenn überhaupt, dann das KDE, man sagt ja auch nicht die Environment. Ich würde aber eher dafür plädieren, dass KDE mittlerweile ein Eigenname ist und daher gar keinen Artikel braucht.
Wollen wir uns bitte darauf einigen, dass wir ein Hochdeutsch und deshalb eine verbindliche Sammlung für Rechtschreib- und Grammatikregeln besitzen? Vielen Dank!
Kommt mir schon etwas Off-Topic vor aber ja, es wäre Zeit, dass die Distributoren sich auf kde einschießen um solche Angebote machen zu können. Aber, da Du schon "den Wettbewerb" ansprichst, es sieht so aus, als würden sie das lieber lassen wollen, weil man sich da scheinbar mit dem Falschen anlegen würde. Lieber schließt man (Stillhalte-)Verträge ab und entwickelt (angeblich) gemeinsam in die selbe Richtung. Also ergibt das unterm Strich doch ein Nein, jedenfalls für Novell. Oder siehst Du irgendwo einen "mach's mit kde" Wettbewerb? Redhat hatte es noch nie so mit kde und die Anderen (debian, slackware, gentoo...) machen eigentlich nicht alles nur fürs Geld und werden Windows wohl weiter ignorieren. Was Shuttleworth insgesamt vorhat, wüsste ich eigentlich auch gern aber ist wohl nicht so leicht abzusehen.
Vielleicht denken die ja auch alle wie ich und meinen, wer sich auf Vista - statt des Vista Desktops - lieber kde installiert aber dann kein Linux benutzt, ist zu beschäftigt, Fliegen von den Gummiwänden zu futtern, um Supportverträge abzuschließen.
> Lieber schließt man (Stillhalte-)Verträge ab und entwickelt (angeblich) gemeinsam in > die selbe Richtung. Also ergibt das unterm Strich doch ein Nein, jedenfalls für Novell.
Wieviele Distributionen mit Stillhalteabkommen kennst Du denn noch außer Novell?
> Was Shuttleworth insgesamt vorhat, wüsste ich eigentlich auch gern aber ist wohl nicht > so leicht abzusehen.
Mmh, eigentlich redet er doch die ganze Zeit davon, was er vorhat. Und ich sehe auch nicht, dass er das nicht einhält.
Ich denke der Ansatz von Phonon ist ähnlich der Capi-Schnittstelle zu sehen, wo die einzelnen Programme parallel aufsetzen können. Klar ist mir dabei allerdings nicht, warum (semi-)professionelle Programme wie Jack nicht auch auf Phonon aufsetzen können?
Von Kevin Krammer am Fr, 9. Februar 2007 um 13:10 #
Das wäre aus der Sicht von Jack ein völlig unnötiger und störender Umweg.
Unter der Phonon API ist in erster Linie mal ein Dekoder- und Effektframework, diese Schritte sind aber bei Jack schon erledigt, bzw. kann von Jack explizit in eine Applikation zur Weiterverarbeitung umgeleitet werden.
Für solche Programme ist es sowieso sinnvoller direkt auf Jack zuzugreifen.
Allein schon wegen der niedirgeren Latenz, bei der eine weitere Abstraktionsschicht sicherlich keine gute Idee ist.
Dennoch fehlt mir hier die direkte Anbindung von Phonon an Jack noch, eventuell kommt das aber vielleicht noch.
Bis dahin hat man wohl nur die Möglichkeit über Gstreamer an Jack zu kommen und da ist nicht gerade toll.
Phonon -> Gstreamer -> Jack
[ ] Ich weiss, das jack mir nicht hilft, bunte Bildchen auf den Moonitor zu zaubern
;)
Nix für ungut, aber du verglkeichst äpfel mit birnen...
Der Fehler liegt daher also wohl eher an dir.
auf de roben genannten Siete finden sich auch Kommentare. einer davon sagt dies:
> Re: jackd integration
> by piters on Tuesday 06/Feb/2007, @08:54
> Hi,
> certainly, having jackd interfaced somehow into Phonon would be great for everybody who wants to make music on Linux.
> As far as I understand, jackd itself is not an engine... It is the way to get into your soundcard/midi and stream the data from/to there. So it is roughly at the level of ALSA or OSS...
> On the contrary, Phonon relies on "hefty" backends such as xine, capable of doing all the file-decoding for mpegs, oggs, etc; and it is xine that would actually need to talk to jackd (rather than to ALSA, OSS, or so)...
> So: it might be a question to the XINE developers to support jackd...
>
> Could some of KDE/Phonon specialist tell if my thinking is right?
>
> Any bright ideas to have jackd integrated somehow anyway?
lg
Erik
Was wir brauchen ist ein Framework, daß bei Bedarf Jack nutzt (z.B. auch wenn Jack läuft und die Soundkarte blockiert), aber auch ohne auskommt. Und da ist Gstreamer schon auf genau dem richtigen Weg.
Das weiß ich alles, aber trotzdem würde ich auch gerne die Soundausgabe einfacher Anwendungen,
wie z.B. Teamspeak (was übrigens QT nutzt, die Verwendung von Phonon liegt also nahe)
über Jack leiten können.
Und das hat auch einen guten Grund, wer Jack kennt weiß nämlich was für tolle Sachen dann damit möglich wären. ;)
Dazu braucht man Jack welches dann LADSPA nutzen kann.
Jack ist mehr als nur eine professionelle Lösung für Audiobearbeitungs und Musikerstellungssoftware,
damit sind auch noch ganz andere Sachen möglich.
Das ist in der Terminologie von Phonon ein Backend.
Ob das Backend dann über Jack ausgeben kann, liegt an den Möglichkeiten des Backends, Phonon kann das dann automatisch auch.
Ist das korrekt?
Wenn ja, gut dann sieht es natürlich anders aus, Jack braucht natürlich einen rohen Datenstream, der nicht kodiert ist.
Kleiner Fehler von mir. Im Fall von Teamspeak meine ich natürlich insbesondere die Soundeingabe und zwar bevor der Sound in Teamspeak weiterverarbeitet wird. Bei er Ausgabe macht es nicht so viel Sinn.
Wo war nochmal das Problem?
ALSA kümmert sich um die Hardware:
Musikrohdatenströme (also nix MP3) mittels Gerätetreibern auf bestimmte Geräte ausgeben oder von diesen Geräten einlesen und die Steuerfunktionen der Hardware wie An/Aus, Laut und Leise und so weiter zu unterstützen.
Jackd das digitale Mischpult:
ALSA selber kann nur sehr wenige "Transformationen" wie Lautstärkeregelung vornehmen und kümmert sich rein um die Hardware. Nun möchte man aber gerne vorm Abspielen noch seinen Rohdatenstrom manipulieren, gezielt mit anderen Daten (oder gar in einer Rückkoppelung mit sich selbst, Stichwort "Hall") mischen, Freqenzfilter anwenden (Bassverstärkung bspw.) usw. Jack ist also ein digitales Mischpult. Der Heimanwender der Musik und Filme abspielt und ein bischen mit seinem Mikrofon was aufnimmt braucht es nicht, aber den Profimusiker freut es.
Xine der Entpacker:
Nun ist es ja allgemein bekannt, das Musik (und Filme) im Rohdatenformat äußerst unhandlich sind. Um dem Problem herr zu werden hat man also verschiedene Komprimierungsroutinen entwickelt, eben MP3, OGG-Vorbis, MPEG4 usw. usw. So wie es keinen Sinn macht eine Zipdatei direkt im Texteditor zu öffnen, macht es keinen Sinn ALSA oder Jackd mit einem MP3 zu füttern. Xine ist also der Entpacker für Multimediadaten aller Art.
Phonon der Multikultikit:
Weil es nun gar schrecklich viele Kompressionscodecs gibt und zu allem Überfluss auch noch verschiedene Konzepte gibt, wie man denen am besten herr wird und jedes dieser Konzepte seine Eigenheiten hat wäre es ziemlich töricht sich auf eins festzulegen, zumal KDE auch unter OSX und Windows funktionieren soll, die jeweils eigene Konzepte der Dekompression haben (Directshow und Quicktime). Phonon will also KDE-Anwendungen nun grundlegende Funktionen all dieser Konzepte unter einer einheitlichen Schnitstelle anbieten. Im Grunde macht Phonon nx anderes als: "Backend (bspw. Xine) hier sind die Daten und die Parameter die von der Anweundung gewünscht sind, jetzt entpack das mal und gibs dort aus wo es der Anwender haben will." Die Daten selber wandern also nicht erst duch Phonon hindurch. Phonon ist nur Kontaktvermittler zwischen Anwendung und Backend.
Also welchen Weg nehmen die Daten mit Phonon?
Applikation befielt über Phonon: Datei ABC -> bitte mit Xine entpackt -> (über Jackd verfremdet) -> dank ALSA auf meinen Boxen ausgeben.
Du sprichst NUR von dir.
Ich brauche es, habe dafür auch plausible Anwendungsfälle und bin kein Profimusiker
Immer wieder kommen da undurchschaubare Konstrukte raus, die auch noch langsam sind, das muss aber nicht sein. Kommt immer drauf an wie es gemacht ist.
Grüße
Felix
So wie ich das verstanden habe, ist Jack ein sound-deamon, der sehr viel mehr Funktionen in sich vereint, als z.B. artsd, dazu noch mit weit weniger Latenz. Das muss ja wohl so sein, sonst wäre er nicht erste Wahl für die "Profimusiker".
Wenn aber Jack so viel besser ist, warum wird er dann nicht per default in den Distris eingesetzt? Hat's denn auch Nachteile?
Jackd ist nur ein digitales Mischpult, aber darin deutlich leistungsfähiger als Artsd. Das heißt konkret, dass Jackd Artsd nicht allein ersetzen kann.
Um ein Video abzuspielen brauchst du in der Regel kein Jackd, für die Erstellung einer effektreichen Musikuntermalung eines Videos hingegen schon. Jackd braucht also nicht jeder. Und wenn man es braucht kann man es einfach dazwischenstöpseln.
Nein, dmix läuft im Userspace (libasound.so).
Aber besonders bei der Verfügbarkeit mehrere Geräte braucht der Benutzer eine Möglichkeit, bestimmte Kombinationen festzulegen, denn nicht alles kann 100% automatisch eingestellt werden.
Das hiesse dann:
Nach dem Login startet automatisch jackd, bekommt den nötigen Exklusivzugriff auf Alsa und läuft normal stabil mit 5ms Latenz.
sämtliche Desktopsounds - vom Terminplaneralarm über das VoIP-Programm bis zum Audio/Videoplayer nutzen gemeinsam einen jackd-Klienten, der von einem Desktop-Sounddaemon wie PulsAudio esd oder dergleichen erzeugt wird. Wenn Phonon bei der Entwicklung einer solchen Lösung helfen kann, bin ich begeistert!!
Was soll das bringen? Willst du eine MP3- oder Ogg-Vorbis-Datei direkt an den jackd schicken? Irgendwer muss den Stream doch erst einam dekodieren.
PS: Heisst es eigentlich die oder das KDE?
Das KDE,
weil das "K Desktop Environment",
weil das Environment.
(Koole Schreibtisch Umgebung)
Liselotte
Und wenn, dann ist es die Environment da wir im Deutschen "die" Umgebung haben.
Da gibt es keine Regel und man kann es nur auswendig lernen.
Daher hat man es auch recht schwer, wenn man Deutsch als Fremdsprache lernt.
Oder sagt man "das Schnittstelle"?
Lulu
Felix
Bärchen hat und sächlich, wenn es sabbert und in die Windeln kackt.
Klar?
Wusste ich es doch...
Martin
Da lässt sich allerdings heute nicht mehr anwenden, also kann man diesen Beitrag auch gerne ignorieren
Wir übernehmen das Wort, übersetzen es für ins deutsche Wort Post. Und schon heißt es größtenteils die Mail und nicht korrekterweise das Mail. Übrigens schließe ich mich selber damit auch ein. Ich sage fälschlicherweise auch die Mail. Das ist nun mal der Nachteil, wenn man fremdsprachige Ausdrücke übernimmt. Allerdings sollte man aus dieser Problematik kein Dogma machen. Insofern ist es m.E. egal, welches Geschlecht man nimmt, wenn man das sächliche aus dem Englischen nicht übernimmt.
Sachsen sind auch keine Deutschen. Die Teutonen lebten/leben irgendwo bei Bielefeld. Suchen gehen.
lg
Erik
Also ergibt das unterm Strich doch ein Nein, jedenfalls für Novell.
Oder siehst Du irgendwo einen "mach's mit kde" Wettbewerb?
Redhat hatte es noch nie so mit kde und die Anderen (debian, slackware, gentoo...) machen eigentlich nicht alles nur fürs Geld und werden Windows wohl weiter ignorieren.
Was Shuttleworth insgesamt vorhat, wüsste ich eigentlich auch gern aber ist wohl nicht so leicht abzusehen.
Vielleicht denken die ja auch alle wie ich und meinen, wer sich auf Vista - statt des Vista Desktops - lieber kde installiert aber dann kein Linux benutzt, ist zu beschäftigt, Fliegen von den Gummiwänden zu futtern, um Supportverträge abzuschließen.
PS: natürlich "the".
> die selbe Richtung. Also ergibt das unterm Strich doch ein Nein, jedenfalls für Novell.
Wieviele Distributionen mit Stillhalteabkommen kennst Du denn noch außer Novell?
> Was Shuttleworth insgesamt vorhat, wüsste ich eigentlich auch gern aber ist wohl nicht
> so leicht abzusehen.
Mmh, eigentlich redet er doch die ganze Zeit davon, was er vorhat. Und ich sehe auch nicht, dass er das nicht einhält.
Unter der Phonon API ist in erster Linie mal ein Dekoder- und Effektframework, diese Schritte sind aber bei Jack schon erledigt, bzw. kann von Jack explizit in eine Applikation zur Weiterverarbeitung umgeleitet werden.