Das dürfte aber eine Minderheit sein, nämlich diejenigen Personen, die damals bei der Einführung von PA schlechte Erfahrungen damit gemacht haben und jetzt immer noch felsenfest davon überzeugt sind (Man nennt das auch Vorurteil), dass PA immer noch schlecht ist.
"die damals bei der Einführung von PA schlechte Erfahrungen damit gemacht haben"
Das kann schon sein. Bei mir war das so (etwa über zwei Jahre hinweg seit Ubuntu 8.04 bis zu meinem letzten Ubuntu) und selbst meine Live-CDs enthalten bzw. enthielten nie Pulseaudio. Ich bin da in guter Gesellschaft, siehe Debian Squeeze.
Poettering hat - wie immer - massive Kollateralschäden bei der Einführung von Pulseaudio in Kauf genommen. Von daher hält sich mein "Mitleid" in Grenzen. Wenn man nicht möchte, dass Linux auf dem Desktop auch nur den Hauch einer Chance hat, dann muss man genauso vorgehen wie Ubuntu in Version 8.04 mit der Einführung von Pulseaudio: Völlig unausgereifte Technologien als Standard einbinden. Nur weiter so.
In diesem Zusammenhang fragt man sich auch, warum solche Distros nicht die eigene Hardwareerkennung und eine schwarze Liste bekannter, mit Pulseaudio funktionsuntüchtiger Soundchips benutzt haben, um Pulseaudio während der Installation entsprechend einzurichten, d.h. im Bedarfsfall abzuschalten.
Prolinux hatte vor längerer Zeit ein Interview mit Poettering veröffentlicht und Poettering kannte die Pulseaudiodefizite im Hinblick auf bestimmte Soundhardware. Also hätten das auch die pulseaudioeinbindenden Distros wissen müssen.
Dass die Distributoren selbst Schuld haben stimmt, aber der Poettering überfährt alles und jeden. Als Debian gesagt hat, dass sie systemd nicht nehmen können (eher wollen), da es ja nicht unter kFreeBSD funktioniert, hat er es als "Toy-OS" bezeichnet. Man (vor allem er) sollte wohl darüber nach denken, dass es noch nicht sehr lang her ist, und man Linux genauso bezeichnet hat.
Des weiteren ist der Geschwindigkeitszuwachs wohl eher mau bis sehr wenig, den Mund er halt auch gerne mal sehr voll.
Bei Pulseaudio habe ich nie verstanden, warum die Funktionalität nicht ins ALSA genommen wurde.
Der Soundserver ist nur ein Teil von PulseAudio. Die Client-Bibliothek kann z.B. auch auf eine andere Technik portiert werden, ohne die API zu verändern, wie es auch mit ESD geschah. PulseAudio ist eine Highlevel-Schnittstelle, die nicht nur auf Linux sinnvoll ist. Das Problem vieler Audiosysteme, auch ALSA, ist, dass Anwendungen, die sie wirklich benutzen, eine ganze Menge Aufwand erfordern, um alle Möglichkeiten und Sonderfälle zu unterstützen, insbesondere wenn die Hardware bestimmte Fähigkeiten oder Funktionen nicht bietet. Bei PulseAudio wird all das vermieden, die Programme übergeben ihre Streams dem Server und fertig, der muss sich dann darum kümmern. Für den Nutzer geht dabei nichts verloren, denn die Funktionalität z.B. die Ausgabe auf verschiedene Geräte zu leiten existiert in der API, nur wird das zentral von einem Programm (z.B. KMix) geregelt. Klar kann ALSA einiges davon auch, wenn ich aber an der Hardware etwas ändere, muss ich entweder meine .asoundrc ändern oder Programme, wenn sie es denn unterstützen, mit -d hw:[irgendwas] aufrufen. Das geht nicht im laufenden Betrieb — bei PulseAudio schon.
Das fällt aber böse auf Fedora selbst zurück. :-) IMHO erhalten nur "Spielzeuge" eine kurze Unterstützung von 13 bis 14 Monaten. Eine Debianversion bringt es in der Regel auf etwa 36 Monate Lebenszeit.
es noch nicht sehr lang her ist, und man Linux genauso bezeichnet hat.
Der Durchbruch von FreeBSD steht kurz bevor! Nein erntshaft, warum soll man den technologischen Fortschritt durch irgendwelche, künstlich kompatibel gehaltene Altsysteme behindern? Aus welchem abwegigem Grund würde man ein Debian mit FreeBSD Kernel einsetzen? Außer dem, dass man es kann.
Bei Pulseaudio habe ich nie verstanden, warum die Funktionalität nicht ins ALSA genommen wurde.
PA sieht sich nicht als neue Sound-API welche ab jetzt alle verwenden sollen, sondern "Vermittler" zwischen existierenden, inkompatiblen Systemen. Also egal für welche API ein Programm entwickelt wurde, und welches Soundsystem für den Output genutzt wird, mit PA sollte es immer laufen, und der Anwender sollte dabei auch noch von den PA features profitieren. ALSA ist dabei ebenfalls eine austauschbare Komponente.
Den einzigen Vorteil welchen ich sehe wenn die Funktionalität in ALSA wäre hat polititische Gründe: es gäbe bei Problemen/Bugs keine Diskussionen wer schuld daran ist.
> hat er es als "Toy-OS" bezeichnet. Merke: Auch arrogante Scheißkerle können sehr gute Software schreiben.
Dabei würde ich gar nicht mal sagen, dass Lennart einer ist. Er ist nur sehr überzeugt davon, was er tut. Und damit ist er mir 100mal sympatischer als jemand, der irgendein Forum vollheult und von technischen Problemen von 2008 jammert, die er bei der vermeintlichen Arroganz eines Entwicklers verortet sieht.
Ich habe bisher noch kein technisch schlagkräftiges Argument gegen PulseAudio auf dem Desktop gesehen. Ich könnte mir einige im Embedded-Bereich vorstellen, aber selbst dort habe ich mit eigenen Augen gesehen, dass die Leute, welche solche Distros pflegen (ich spreche von OpenEmbedded), PulseAudio mit Freuden in ihre Softwaresammlung aufgenommen haben.
Ich habe bisher noch kein technisch schlagkräftiges Argument gegen PulseAudio auf dem Desktop gesehen.
Sehe ich genauso. PulseAudio mag vielleicht nicht die Wünsche von allen zu erfüllen, aber - und das ist für mich das Wichtigste - meine Wünsche erfüllt es zuverlässig und stabil. Denn ich wollte schon immer nur eine einfache Möglichkeit haben die Ausgabe meiner DVB-, Sound oder sonst einer Karte und meiner Anwendungen zu steuern. Dies war ach der einzige Grund, warum ich Jahre lang Jack nutzte.
Ich nutze Ubuntu 10.10, und dort ist PA eine Katastrope. Aufnahmen via Line-In sind mit PA nicht mal ansatzweise möglich (es sei denn, man liebt Stottern und Aussetzer).
Gottseidank kann man PA abwürgen und stattdessen Jack einsetzen.
Das dürfte aber eine Minderheit sein, nämlich diejenigen Personen, die damals bei der Einführung von PA schlechte Erfahrungen damit gemacht haben und jetzt immer noch felsenfest davon überzeugt sind (Man nennt das auch Vorurteil), dass PA immer noch schlecht ist.
Nein, das nennt man "Erfahrung nach Ausprobieren".
Versuch mal eine vernünftige (semi-)professionelle Audiokarte mit ice1712-Chip mit PulseAudio vernünftig so wie vom Hardwarehersteller und Nutzer gedacht ans Laufen zu kriegen. Dürfte dir wohl eher noch immer nicht gelingen. Solange PulseAudio noch immer nicht mit solchen Audiokarten, sprich mit allen Sound- und Audiokarten, umgehen kann, ist PulseAudio ganz einfach schlecht und eine Zumutung.
Für so ein Stereo-SoundBlaster- oder OnBoard-Sound-Geraffel und ein paar Computer-Spielchen mag das Teil einigermaßen funktionieren. Was vernünftiges kann das Teil noch immer nicht.
Und wenn deren Lösung zur Unterstützung der ice1712-Karten so aussieht, dass diese per ALSA-Konfiguration künstlich auf reine Stereo-Karten kastriert werden müssen, ohne dass sich die Entwickler noch nicht mal ansatzweise mit dem Sinn und der Funktionsweise dieser Karten auseinandersetzen, geschweige denn überhaupt mal versuchen, die zu verstehen (siehe den entsprechenden Bugreport (Link habe ich gerade nicht zur Hand)), dann ist das mehr als armselig. Hab von diesem Bugreport bis heute kein Update erhalten. Also dürfte sich da wohl auch eher wenig bis gar nichts geändert haben. Und dann auch noch die Schuld dafür ALSA in die Schuhe schieben wollen.
ALSA kann mit diesen Karten übrigens out-of-the-box ohne spezielle Konfiguration vernünftig umgehen, zumindest mit envy24control aus den alsa-tools.
Und dann noch die sehr merkwürdige Methode, PulseAudio zu starten. Kann das Teil noch immer nicht als systemweiter Daemon gestartet werden? Muss das Teil noch immer vom unpriviligierten User gestartet werden? Wird dann immer noch jeder andere User vom Sound ausgeschlossen? Und muss man sich beim Start von PulseAudio immer noch vorher entscheiden, ob man jetzt auf der Textconsole oder mit X arbeiten möchte? Sorry, aber sowas geht gar nicht.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Jan 2012 um 10:32.
"Für so ein Stereo-SoundBlaster- oder OnBoard-Sound-Geraffel"
Die üblichen SB Live-Soundkarten beherrschen unter Linux Hardwaremixing. Von daher braucht man da im Grunde so etwas wie Pulseaudio nicht. Pulseaudio ist aber unter Umständen ein Fortschritt auf Rechnern mit starker CPU und "armseliger" (Onboard-)Soundchip-Hardware.
"ohne dass sich die Entwickler noch nicht mal ansatzweise mit dem Sinn und der Funktionsweise dieser Karten auseinandersetzen"
Da fehlt schlicht das Audio- und Soundkarten-KnowHow. Die Macher um Opensound haben und hätten das besser hinbekommen.
Erschreckenderweise bin ich Pulseaudio selbst unter PC-BSD 9 begegnet. Wie so oft unter Linux, so funktioniert es auch dort nicht richtig. Danke Red Hat, danke Fedora. Wie gut, dass ihr Euch ansonsten so gut wie nie mit Multimediasoftware beschäftigt, auch wenn das zumeist vor allem rechtliche Ursachen hat. Nochmals danke.
Ich bin ein grosser Fan von Creative und seinen SoundBlaster Produkten und schalte seit Jahren die Onboard Soundkarte ab und stecke meine gute alte Live! drauf, sobald ein neuer PC gekauft wird, genau wegen dem 32 Kanal HW Mixing und guter Linux Treiber.
ABER: Schliess mal nen USB Headset an! Spätestens dann weisst du wofür PulseAudio gut ist.
Ich gebe den Sound auf einer angeschlossenen kleinen Hifi-Anlage mit entsprechenden Boxen aus. Dafür habe ich auch einen Kopfhörer. Ein USB-Headset habe ich aber nicht, eine solche Art der Soundumleitung würde hier also gar nicht genutzt werden. Gibt es denn irgendeine Soundumleitungsmöglichkeit von Pulseaudio, die theoretisch und vielleicht auch unbeabsichtigt zum Anfallen von GEMA-Gebühren führen könnte? :-)
ABER: Schliess mal nen USB Headset an! Spätestens dann weisst du wofür PulseAudio gut ist.
Sowas gibts wirklich? Ich wundere mich ja auch regelmäßig, wenn ich im Perlen-Katalog diese USB-Plattenspieler sehe. Ich dachte bisher eigentlich immer, dass USB für Daten-Übertragung und die Soundkarte und sowas wie Klinken- oder Cinch-Kabel für die Audio-Übertragung da wären.
Aber du bist dir ganz sicher, dass ALSA nicht auch von sich aus mit diesen USB-Headsets umgehen kann?
USB-Headsets sind anscheinend stark verbreitet. Dass ich das nicht wirklich bemerkt habe, hängt wohl eher an meinem schon fortgeschrittenen Alter. Und: Pulseaudio ersetzt Alsa nicht, insofern kann Alsa mit USB-Headsets zuverlässig umgehen, dank Pulseaudio.
Und: Pulseaudio ersetzt Alsa nicht, insofern kann Alsa mit USB-Headsets zuverlässig umgehen, dank Pulseaudio.
Und ohne PulseAudio?
Übrigens finde ich es auch äußerst merkwürdig, dass PulseAudio zuerst ALSA benötigt, um die Audio-Daten zu bekommen, um dann das schlechter zu machen, was ALSA alleine ohnehin schon sehr viel besser kann, und den ganzen versaubeutelten Kram dann wieder an ALSA zur Ausgabe zu schicken.
Oder übersehe ich da was, wenn ich eine ice1712-Karte erst mit Hilfe einer abstrusen ALSA-Konfiguration auf Stereo kastrieren muss, damit PulseAudio noch immer nicht mal halbwegs damit umgehen kann? Für die Ausgabe benötigt PulseAudio dann natürlich auch wieder ALSA. Macht irgendwie echt Sinn.
Das weiß ich schlichtweg nicht, gerade als Nichtbesitzer eines entsprechenden USB-Headsets.
Ich habe allerdings vor kurzem PC-BSD 9 installiert und da arbeitete Pulseaudio mehr oder weniger gekonnt mit OSS (Opensound) zusammen. Pulseaudio ist "nur" der Soundserver, Du könntest alternativ z.B. Esound verwenden, wenn Pulseaudio unter Umständen Deine CPU durch die Decke jagt. Funktioniert das Hardwaremixing Deiner Soundkarte, dann brauchst Du normalerweise keinen Soundserver. Ob Alsa oder Opensound solche USB-Kopfhörer über das Hardwaremixing meiner alten SB Live ohne Pulseaudio ansprechen könnten? Auch hier muss ich mangels Testobjekt leider passen.
Die üblichen SB Live-Soundkarten beherrschen unter Linux Hardwaremixing. Von daher braucht man da im Grunde so etwas wie Pulseaudio nicht. Pulseaudio ist aber unter Umständen ein Fortschritt auf Rechnern mit starker CPU und "armseliger" (Onboard-)Soundchip-Hardware.
Auch bei fehlendem Hardwaremixing braucht man PulseAudio nicht. Das kann ALSA mit dem schon seit einigen Jahren per Default aktiviertem dmix ganz alleine out-of-the-box. Die ice1712-Karten haben auch kein Hardwaremixing in dem Sinne, funktionieren aber perfekt mit ALSA.
Ich hatte meine OnBoard-Soundkarte zwar noch nie aktiviert und ausprobiert, bin mir aber ziemlich sicher, dass ALSA das Mixen per dmix auch mit diesen billigen AC'97-Karten hinbekommt.
Da fehlt schlicht das Audio- und Soundkarten-KnowHow.
Das ist mehr als offensichtlich. Da fehlt aber bei weitem nicht nur das Audio- und Soundkarten-KnowHow, sondern auch noch das KnowHow, wie Daemonen und Multiuser-Betriebssysteme funktionieren und dass es für einen Daemon und vor allem auch den Sound eigentlich völlig schnurz-piep-egal sein sollte, ob man jetzt X oder die Console benutzt.
Wenn mir das Audio- und Soundkarten-KnowHow fehlt, ist natürlich das allererste, was ich mache, einen Sound-Daemon zu programmieren und das kümmerliche Ergebnis dann als Quasi-Linux-Standard zu bezeichnen, auf dass dann diverse Desktop-Umgebungen und Distributionen den Mist als Dependency zwangsweise benötigen.
"die damals bei der Einführung von PA schlechte Erfahrungen damit gemacht haben"
Das kann schon sein.
Bei mir war das so (etwa über zwei Jahre hinweg seit Ubuntu 8.04 bis zu meinem letzten Ubuntu) und selbst meine Live-CDs enthalten bzw. enthielten nie Pulseaudio. Ich bin da in guter Gesellschaft, siehe Debian Squeeze.
Poettering hat - wie immer - massive Kollateralschäden bei der Einführung von Pulseaudio in Kauf genommen. Von daher hält sich mein "Mitleid" in Grenzen. Wenn man nicht möchte, dass Linux auf dem Desktop auch nur den Hauch einer Chance hat, dann muss man genauso vorgehen wie Ubuntu in Version 8.04 mit der Einführung von Pulseaudio: Völlig unausgereifte Technologien als Standard einbinden. Nur weiter so.
Das ist aber nicht die Schuld von Pulseaudio, sondern die der Distributionen, wenn es zu früh ausgeliefert wird.
Bei Systemd wird sich ja auch Zeit gelassen mit der Umstellung. Das wurde bei Pulseaudio verpaßt.
In diesem Zusammenhang fragt man sich auch, warum solche Distros nicht die eigene Hardwareerkennung und eine schwarze Liste bekannter, mit Pulseaudio funktionsuntüchtiger Soundchips benutzt haben, um Pulseaudio während der Installation entsprechend einzurichten, d.h. im Bedarfsfall abzuschalten.
Prolinux hatte vor längerer Zeit ein Interview mit Poettering veröffentlicht und Poettering kannte die Pulseaudiodefizite im Hinblick auf bestimmte Soundhardware. Also hätten das auch die pulseaudioeinbindenden Distros wissen müssen.
Dass die Distributoren selbst Schuld haben stimmt, aber der Poettering überfährt alles und jeden. Als Debian gesagt hat, dass sie systemd nicht nehmen können (eher wollen), da es ja nicht unter kFreeBSD funktioniert, hat er es als "Toy-OS" bezeichnet. Man (vor allem er) sollte wohl darüber nach denken, dass es noch nicht sehr lang her ist, und man Linux genauso bezeichnet hat.
Des weiteren ist der Geschwindigkeitszuwachs wohl eher mau bis sehr wenig, den Mund er halt auch gerne mal sehr voll.
Bei Pulseaudio habe ich nie verstanden, warum die Funktionalität nicht ins ALSA genommen wurde.
> Bei Pulseaudio habe ich nie verstanden, warum die Funktionalität nicht ins ALSA genommen wurde.
Vor allem, wei ALSA eine Linux-only Lösung ist. PulseAudio gibt es z.B. auch für Mac OS X und Windows.
Der Soundserver ist nur ein Teil von PulseAudio. Die Client-Bibliothek kann z.B. auch auf eine andere Technik portiert werden, ohne die API zu verändern, wie es auch mit ESD geschah.
PulseAudio ist eine Highlevel-Schnittstelle, die nicht nur auf Linux sinnvoll ist. Das Problem vieler Audiosysteme, auch ALSA, ist, dass Anwendungen, die sie wirklich benutzen, eine ganze Menge Aufwand erfordern, um alle Möglichkeiten und Sonderfälle zu unterstützen, insbesondere wenn die Hardware bestimmte Fähigkeiten oder Funktionen nicht bietet. Bei PulseAudio wird all das vermieden, die Programme übergeben ihre Streams dem Server und fertig, der muss sich dann darum kümmern. Für den Nutzer geht dabei nichts verloren, denn die Funktionalität z.B. die Ausgabe auf verschiedene Geräte zu leiten existiert in der API, nur wird das zentral von einem Programm (z.B. KMix) geregelt.
Klar kann ALSA einiges davon auch, wenn ich aber an der Hardware etwas ändere, muss ich entweder meine .asoundrc ändern oder Programme, wenn sie es denn unterstützen, mit -d hw:[irgendwas] aufrufen. Das geht nicht im laufenden Betrieb — bei PulseAudio schon.
Danke, für den Einblick.
"hat er es als "Toy-OS" bezeichnet"
Das fällt aber böse auf Fedora selbst zurück. :-)
IMHO erhalten nur "Spielzeuge" eine kurze Unterstützung von 13 bis 14 Monaten.
Eine Debianversion bringt es in der Regel auf etwa 36 Monate Lebenszeit.
es noch nicht sehr lang her ist, und man Linux genauso bezeichnet hat.
Der Durchbruch von FreeBSD steht kurz bevor!
Nein erntshaft, warum soll man den technologischen Fortschritt durch irgendwelche, künstlich kompatibel gehaltene Altsysteme behindern? Aus welchem abwegigem Grund würde man ein Debian mit FreeBSD Kernel einsetzen? Außer dem, dass man es kann.
"Außer dem, dass man es kann."
Eben.
Mehr Gründe braucht es nicht.
PA sieht sich nicht als neue Sound-API welche ab jetzt alle verwenden sollen, sondern "Vermittler" zwischen existierenden, inkompatiblen Systemen. Also egal für welche API ein Programm entwickelt wurde, und welches Soundsystem für den Output genutzt wird, mit PA sollte es immer laufen, und der Anwender sollte dabei auch noch von den PA features profitieren.
ALSA ist dabei ebenfalls eine austauschbare Komponente.
Den einzigen Vorteil welchen ich sehe wenn die Funktionalität in ALSA wäre hat polititische Gründe: es gäbe bei Problemen/Bugs keine Diskussionen wer schuld daran ist.
> hat er es als "Toy-OS" bezeichnet.
Merke: Auch arrogante Scheißkerle können sehr gute Software schreiben.
Dabei würde ich gar nicht mal sagen, dass Lennart einer ist. Er ist nur sehr überzeugt davon, was er tut. Und damit ist er mir 100mal sympatischer als jemand, der irgendein Forum vollheult und von technischen Problemen von 2008 jammert, die er bei der vermeintlichen Arroganz eines Entwicklers verortet sieht.
Ich habe bisher noch kein technisch schlagkräftiges Argument gegen PulseAudio auf dem Desktop gesehen. Ich könnte mir einige im Embedded-Bereich vorstellen, aber selbst dort habe ich mit eigenen Augen gesehen, dass die Leute, welche solche Distros pflegen (ich spreche von OpenEmbedded), PulseAudio mit Freuden in ihre Softwaresammlung aufgenommen haben.
Btw: Auch auf dem N900 läuft ein PulseAudio ...
Sehe ich genauso. PulseAudio mag vielleicht nicht die Wünsche von allen zu erfüllen, aber - und das ist für mich das Wichtigste - meine Wünsche erfüllt es zuverlässig und stabil. Denn ich wollte schon immer nur eine einfache Möglichkeit haben die Ausgabe meiner DVB-, Sound oder sonst einer Karte und meiner Anwendungen zu steuern. Dies war ach der einzige Grund, warum ich Jahre lang Jack nutzte.
Cheers,
demon
Was ist für Dich "damals"?
Ich nutze Ubuntu 10.10, und dort ist PA eine Katastrope. Aufnahmen via Line-In sind mit PA nicht mal ansatzweise möglich (es sei denn, man liebt Stottern und Aussetzer).
Gottseidank kann man PA abwürgen und stattdessen Jack einsetzen.
Nein, das nennt man "Erfahrung nach Ausprobieren".
Versuch mal eine vernünftige (semi-)professionelle Audiokarte mit ice1712-Chip mit PulseAudio vernünftig so wie vom Hardwarehersteller und Nutzer gedacht ans Laufen zu kriegen. Dürfte dir wohl eher noch immer nicht gelingen. Solange PulseAudio noch immer nicht mit solchen Audiokarten, sprich mit allen Sound- und Audiokarten, umgehen kann, ist PulseAudio ganz einfach schlecht und eine Zumutung.
Für so ein Stereo-SoundBlaster- oder OnBoard-Sound-Geraffel und ein paar Computer-Spielchen mag das Teil einigermaßen funktionieren. Was vernünftiges kann das Teil noch immer nicht.
Und wenn deren Lösung zur Unterstützung der ice1712-Karten so aussieht, dass diese per ALSA-Konfiguration künstlich auf reine Stereo-Karten kastriert werden müssen, ohne dass sich die Entwickler noch nicht mal ansatzweise mit dem Sinn und der Funktionsweise dieser Karten auseinandersetzen, geschweige denn überhaupt mal versuchen, die zu verstehen (siehe den entsprechenden Bugreport (Link habe ich gerade nicht zur Hand)), dann ist das mehr als armselig. Hab von diesem Bugreport bis heute kein Update erhalten. Also dürfte sich da wohl auch eher wenig bis gar nichts geändert haben. Und dann auch noch die Schuld dafür ALSA in die Schuhe schieben wollen.
ALSA kann mit diesen Karten übrigens out-of-the-box ohne spezielle Konfiguration vernünftig umgehen, zumindest mit envy24control aus den alsa-tools.
Und dann noch die sehr merkwürdige Methode, PulseAudio zu starten. Kann das Teil noch immer nicht als systemweiter Daemon gestartet werden? Muss das Teil noch immer vom unpriviligierten User gestartet werden? Wird dann immer noch jeder andere User vom Sound ausgeschlossen? Und muss man sich beim Start von PulseAudio immer noch vorher entscheiden, ob man jetzt auf der Textconsole oder mit X arbeiten möchte? Sorry, aber sowas geht gar nicht.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Jan 2012 um 10:32."Für so ein Stereo-SoundBlaster- oder OnBoard-Sound-Geraffel"
Die üblichen SB Live-Soundkarten beherrschen unter Linux Hardwaremixing. Von daher braucht man da im Grunde so etwas wie Pulseaudio nicht. Pulseaudio ist aber unter Umständen ein Fortschritt auf Rechnern mit starker CPU und "armseliger" (Onboard-)Soundchip-Hardware.
"ohne dass sich die Entwickler noch nicht mal ansatzweise mit dem Sinn und der Funktionsweise dieser Karten auseinandersetzen"
Da fehlt schlicht das Audio- und Soundkarten-KnowHow. Die Macher um Opensound haben und hätten das besser hinbekommen.
Erschreckenderweise bin ich Pulseaudio selbst unter PC-BSD 9 begegnet. Wie so oft unter Linux, so funktioniert es auch dort nicht richtig. Danke Red Hat, danke Fedora. Wie gut, dass ihr Euch ansonsten so gut wie nie mit Multimediasoftware beschäftigt, auch wenn das zumeist vor allem rechtliche Ursachen hat. Nochmals danke.
Jein. Verstehe mich nicht Falsch.
Ich bin ein grosser Fan von Creative und seinen SoundBlaster Produkten und schalte seit Jahren die Onboard Soundkarte ab und stecke meine gute alte Live! drauf, sobald ein neuer PC gekauft wird, genau wegen dem 32 Kanal HW Mixing
und guter Linux Treiber.
ABER: Schliess mal nen USB Headset an! Spätestens dann weisst du wofür PulseAudio gut ist.
"Schliess mal nen USB Headset an!"
Ich gebe den Sound auf einer angeschlossenen kleinen Hifi-Anlage mit entsprechenden Boxen aus. Dafür habe ich auch einen Kopfhörer. Ein USB-Headset habe ich aber nicht, eine solche Art der Soundumleitung würde hier also gar nicht genutzt werden.
Gibt es denn irgendeine Soundumleitungsmöglichkeit von Pulseaudio, die theoretisch und vielleicht auch unbeabsichtigt zum Anfallen von GEMA-Gebühren führen könnte? :-)
Aber du bist dir ganz sicher, dass ALSA nicht auch von sich aus mit diesen USB-Headsets umgehen kann?
USB-Headsets sind anscheinend stark verbreitet.
Dass ich das nicht wirklich bemerkt habe, hängt wohl eher an meinem schon fortgeschrittenen Alter.
Und: Pulseaudio ersetzt Alsa nicht, insofern kann Alsa mit USB-Headsets zuverlässig umgehen, dank Pulseaudio.
Übrigens finde ich es auch äußerst merkwürdig, dass PulseAudio zuerst ALSA benötigt, um die Audio-Daten zu bekommen, um dann das schlechter zu machen, was ALSA alleine ohnehin schon sehr viel besser kann, und den ganzen versaubeutelten Kram dann wieder an ALSA zur Ausgabe zu schicken.
Oder übersehe ich da was, wenn ich eine ice1712-Karte erst mit Hilfe einer abstrusen ALSA-Konfiguration auf Stereo kastrieren muss, damit PulseAudio noch immer nicht mal halbwegs damit umgehen kann? Für die Ausgabe benötigt PulseAudio dann natürlich auch wieder ALSA. Macht irgendwie echt Sinn.
"Und ohne PulseAudio?"
Das weiß ich schlichtweg nicht, gerade als Nichtbesitzer eines entsprechenden USB-Headsets.
Ich habe allerdings vor kurzem PC-BSD 9 installiert und da arbeitete Pulseaudio mehr oder weniger gekonnt mit OSS (Opensound) zusammen. Pulseaudio ist "nur" der Soundserver, Du könntest alternativ z.B. Esound verwenden, wenn Pulseaudio unter Umständen Deine CPU durch die Decke jagt. Funktioniert das Hardwaremixing Deiner Soundkarte, dann brauchst Du normalerweise keinen Soundserver. Ob Alsa oder Opensound solche USB-Kopfhörer über das Hardwaremixing meiner alten SB Live ohne Pulseaudio ansprechen könnten? Auch hier muss ich mangels Testobjekt leider passen.
Ich hatte meine OnBoard-Soundkarte zwar noch nie aktiviert und ausprobiert, bin mir aber ziemlich sicher, dass ALSA das Mixen per dmix auch mit diesen billigen AC'97-Karten hinbekommt.
Das ist mehr als offensichtlich. Da fehlt aber bei weitem nicht nur das Audio- und Soundkarten-KnowHow, sondern auch noch das KnowHow, wie Daemonen und Multiuser-Betriebssysteme funktionieren und dass es für einen Daemon und vor allem auch den Sound eigentlich völlig schnurz-piep-egal sein sollte, ob man jetzt X oder die Console benutzt.Wenn mir das Audio- und Soundkarten-KnowHow fehlt, ist natürlich das allererste, was ich mache, einen Sound-Daemon zu programmieren und das kümmerliche Ergebnis dann als Quasi-Linux-Standard zu bezeichnen, auf dass dann diverse Desktop-Umgebungen und Distributionen den Mist als Dependency zwangsweise benötigen.