"Mit der Freigabe der Version 1.0 steht knapp sieben Jahre nach der ersten Version von PulseAudio eine per Deklaration stabile Version des Systems bereit."
Nein und dem wird im Artikel auch gleich im nachfolgenden Satz widersprochen. Es werden sicherlich wieder ein paar Anhänger "klassischer Versionierungsschemata" johlen, aber hier ist eben ein weiteres Projekt, das seine eigenen Regeln definiert und sich nicht um Erwartungshaltungen schert. Man muss sich eben angewöhnen, die Aussagen der jeweiligen Entwickler zu berücksichtigen und zu respektieren, dann kann man den Blick auch wieder der Qualität der Software zuwenden.
Mozilla ist derzeit sicherlich das prominenteste Beispiel für Beschimpfungen wütender "Versionsnummern-Nazis", dabei könnte man das Entwicklunsmodell selbst sicherlich kontrovers diskutieren.
ALSA hatte früher gute Dienste geleieistet. Aber seit Jahren schon ist Pulse Audio die erste Wahl unter Linux. Sollen die ALSA-Enteickler doch mit an PA arbeiten. ALSA kann ab in die Mottenkiste. Es ist Teil der Geschichte von Linux. Aber in der heutigen Zeit genauso sinnvoll wie DOS als Betriebssystem für die neuesten Computer zu verwenden.
Tu dir selbst einen Gefallen und informiere dich vor dem Posten erst einmal was ALSA und Pulseaudio sind. Dann hättest du diesen peinlichen Kommentar nämlich sparen können.
Du schreibst ziemlichen Unsinn. ALSA kann überhaupt nicht in die Mottenkiste denn es ist das Audio-Subsystem von Linux auf Kernel-Ebene. PulseAudio ist nur ein Sound-Deamon ähnlich wie ESD der auf ALSA aufsetzt. Merke: ALSA -> Low-Level. PA -> High-Level.
Wobei Jack und Pulseaudio zwei verschiedene Zielgruppen haben. Das eine ist ein low latency Soundserver für professionelle Audioanwendungen (jack), das andere für Heimbenutzer und ihr Bluetooth-Headset (pulse).
Wobei das eine das andere nicht ausschließt. Man kann z.B. Jack als Hauptsoundserver benutzen und Pulseaudio dann diesen als Ausgabemedium wählen. Dadurch behält man den Komfort von Pulseaudio in Bezug auf USB -und Bluetoothgeräten, kann aber andererseits professionell mit dem Rechner arbeiten.
Zusammen mit dem GUI tool ist es sehr einfach einzustellen an welcher Schnittstelle etwas ausgegeben bzw. nicht ausgegeben werden sollte (HDMI, Dockingstation, Notebooklautsprecher, Notebookkopfhörer,...)
Unter Windows bekomme ich das nicht hin. Aber das ist mir eigentlich auch egal
Ich wollte nur sagen, dass ich das GUI tool mit dem ich PulseAudio Funktionen nutze sehr mag und das ganze gut läuft.
Wo nun der Vorteil/Nachteil ohne Sound-Daemon ist weiß ich nicht, da ich mich mit der Materie nicht auskenne (darüber habe ich in meinem Posting auch nicht geschrieben). Aber ich mag wie das umgesetzt wurde hier unter SL 6, mit PulseAudio, soweit ich das aus Anwendersicht beurteilen kann.
Man muss nichts mehr rumbasteln, weil der Sound-Daemon (Speziell Pulseaudio) die vorhandenen Ein -und Ausgabegeräte erkennt und man diese dann per Mausklick einstellen und in Echtzeit zwischen diesen wechseln kann.
Vor ein paar Jahren musste man sich bei allen Distributionen noch Gedanken machen ob der Treiber und die Hardware Hardware-Mixing beherrschen und dazu passend eine ALSA-Datei erstellen. Ansonsten konnte man nämlich immer nur eine Audio-Ausgabe auf einmal benutzen.
Seit sich Pulseaudio auf breiter Front durchgesetzt hat, gehören solche Probleme der Vergangenheit an.
Von Unerkannt am Mi, 28. September 2011 um 21:55 #
Ich kann mich noch dunkel an diese Zeit erinnern. Die Probleme sollten aber schon lange der Vergangenheit angehören, wenn man nicht gerade die OSS-Emulation braucht. Zumindest ist mir seit Jahren nichts in der Richtung aufgefallen und das ohne auch nur einmal PulseAudio installiert zu haben. So wie es sich anhört ist PulseAudio wohl praktisch wenn man oft zwischen verschieden Soundkarten umschalten muss.
>Seit sich Pulseaudio auf breiter Front durchgesetzt hat, gehören solche >Probleme der Vergangenheit an.
Hüstel... Als Pulsaudio auf breiter Front vor Jahren in die Linuxdistris gesteckt wurde gingen die Probleme richtig los. Das mag sich jetzt geändert haben aber anfangs war Pulsaudio einfach nur Mist. Eins der besten Beispiele für Bananensoftware... Wer es nicht glaubt darf gerne mal in den Archiven der Foren abtauchen...
Ja, Pulseaudio machte am Anfang mehr Probleme als es geholfen hat. Vor allem unter Ubuntu und im Zusammenspiel mit dem Flash-Plugin. Diese Zeiten sind aber schon lange vorbei. Natürlich gibt es Fälle, wo Pulseaudio Probleme hat und macht, diese sind aber weniger häufig als es manche Leute wahrhaben wollen.
Hüstel... Als Pulsaudio auf breiter Front vor Jahren in die Linuxdistris gesteckt wurde gingen die Probleme richtig los. Das mag sich jetzt geändert haben aber anfangs war Pulsaudio einfach nur Mist.
Deswegen hat der Entwickler ja auch selebr davon abgeraten PulseAudio in den Distris einzubauen. Aber Ubuntu hatte hatte nicht drauf gehört und Alpha Software in Betrieb genommen.
Eins der besten Beispiele für Bananensoftware...
Ja, das trifft dann aber eher auf Ubuntu zu. Und die ganzen anderen Alpha-Software Distributionen.
Von Unerkannt am Mi, 28. September 2011 um 21:06 #
Wie kam es denn dazu, dass man mittlerweile nicht mehr auf über Soundserver schimpft?
Soweit ich mich erinnern kann ermöglichte aRts zu seiner Zeit, dass Mischen von verschiedenen Tonquellen, was nicht jede Soundkarte selbst vermochte. Heute kann das ALSA selbst und aRts wurde eingestellt. In welche Lücke springt denn da PulseAudio? Netzwerktransparenz ist sicherlich eine wertvolle Eigenschaft. Nur wird die üblicherweise vermutlich keiner nutzen. Vielleicht sind Abstraktionsschichten so toll, dass man nie genug davon übereinander haben kann.
IMHO ist eine einheitliche Schnittstelle (Betriebssystemunabhängig) eine echte Beireichung für die Entwicklergemeinde. Selbst wenn es nur für die Spieleentwicklung ist. Mit OpenGL und Pulseaudio hat man auf allen Plattformen damit 2 Probleme weniger.
Von Unerkannt am Do, 29. September 2011 um 10:03 #
Ohne alles? Wenn die Ton brauchen nehmen sie einfach OSS. Gibt vermutlich nicht allzu viele Programme in der Unix-Welt die nicht OSS unterstützen, wenn sie Ton ausgeben wollen.
Von Unerkannt am Do, 29. September 2011 um 14:37 #
Da könnte ich auch nur spekulieren. Ich wollte einfach nicht glauben, dass bei FreeBSD die Uhren stehen geblieben sind. Also habe ich einen kurzen Blick in das Handbuch geworfen.
Von zettberlin am Do, 29. September 2011 um 22:05 #
> Gibt vermutlich nicht allzu viele Programme in der Unix-Welt die nicht OSS unterstützen, wenn sie Ton ausgeben wollen.
Deine Vermutung wäre vor gefühlten 10 Jahren noch wohlbegründet gewesen. Heute gibt es allerdings hunderte Sound-Programme für Linux, die teilweise einzigartige Fähigkeiten anbieten und die OSS durchaus nicht unterstützen. Darunter fast alle ernst zu nehmenden Kompositions-Tools und HD-Recorder, die oft nur noch mit Jack arbeiten oder zumindest ein aktuelles ALSA voraussetzen.
Ich musste unter Squeeze zu Opensound wechseln, da ich mit der dortigen Alsaversion meinen Soundchip zur Zeit nicht mehr betreiben kann. Diese Fehler treten tatsächlich manchmal auf. So beschwert sich VLC, er würde keine Soundausgabe finden. Trotzdem spielt VLC mit Ton ab. Bemerkenswert ist auch, dass der Sound, den ich jetzt höre (Squeeze mit OSS), besser ist als das, was Lenny bisher audiomäßig von sich gab (Lenny mit Alsa). Irgendwie "erschreckend".
aRTs als Beispiel heranzuziehen ist doch etwas vermessen, da dieses ein Musterbeispiel von "Gut gewollt, schlecht gemacht war". Außer einer Handvoll KDE-Programme unterstützte nämlich kaum ein Programm diesen Soundserver, weil er notorisch instabil und ein Resourcenfresser war. Und dadurch, dass kaum ein Programm aRTs unterstützte, musste man bei fehlendem Hardware-Mixing den Soundserver vor dem Starten eines Programms immer abschießen und danach neu starten. "artsdsp" funktionierte nämlich mehr schlecht als recht.
In welche Lücke springt denn da PulseAudio?
Pulseaudio funktioniert einfach. Wer z.B. wie ich ein USB-Headset zusammen mit einer normalen Onboard-Soundkarte benutzt, möchte nie mehr ohne Pulseaudio unterwegs sein. Ich kann z.B. den Soundserver anweisen das Headset nur für Skype zu benutzen, die Onboard-Soundkarte dagegen alle anderen Programme bedienen lassen. Oder ich kann per Mausklick im Lautstärke-Manager ein einzelnes Programm kurzfristig auf Stumm stellen, ohne das Programm selbst anfassen zu müssen. ALSA könnte das zwar auch theoretisch, aber nur mit sehr viel Handarbeit und Recherche.
ALSA könnte das zwar auch theoretisch, aber nur mit sehr viel Handarbeit und Recherche.
Die Handarbeit bei ALSA ergibt sich in erster Linie daraus, daß es keine guten Konfigurationstools dafür gibt und die Configdateien alle händisch erstellt werden müssen.
ALSA selbst hat mir mal mit seinen Fähigkeiten, Soundströme umzuleiten, sehr geholfen. Meine alte analoge TV-Karte hatte einen Audioausgang und der mußte mit einem speziellen Kabel (Buchse erforderte speziellen Stecker) in den Line-In Eingang meiner Soundkarte geleitet werden, damit man über die Soundkarte und die damit verbundenen Lautsprecher Sound hören konnte. Tja und eines Tages schleppte ich meinen Rechner für ein paar Tage zu nem Bekannten, aber das Audio Kabel hatte ich vergessen, weswegen ich eigentlich nur noch TV ohne Sound gucken hätte können. Zumindest war das unter Windows dann auch der Fall.
Aber ALSA hat mich gerettet, denn mit ALSA konnte ich das Signal des Soundchips auf der TV-Karte intern per Software auf meine Soundkarte umleiten und somit trotzdem TV mit Ton schauen. ALSA sei dank. Und Windows war ich da aufgeschmissen.
> Die Handarbeit bei ALSA ergibt sich in erster Linie daraus, daß es keine guten Konfigurationstools dafür gibt und die Configdateien alle händisch erstellt werden müssen.
Noch ein Punkt: Geräteänderungen erfordern bei ALSA einen Neustart des jeweiligen Programmes bzw. mindestens des jeweiligen Streams und Neueinlesen der Konfiguration, was aber selten implementiert ist. Bei PulseAudio passiert auch dann nichts, wenn mal für eine Weile überhaupt keine Soundhardware da ist (weil man z.B. die USB-Lautsprecher woanders hinstellt und dafür das Kabel abzieht), man hört eben blos nichts. Stecker wieder reinstecken und weiter geht's, ohne dass die Programme etwas davon merken. Man kann aber auch übergangsweise sein Bluetooth-Headset anschalten. Bei ALSA hört man dann trotzdem nichts, weil bestehende Streams nicht auf ein anderes Gerät geleitet werden können.
Für die meisten hier vermutlich unwichtig, aber PulseAudio gibt es auch für BSD, Windows und MacOSX. Damit hat man überall die gleiche Schnittstelle. ALSA gibt es nur für Linux, CoreAudio nur für OSX, OSS spielt nur noch unter BSD eine Rolle und DirectSound ist Windows-only. Mit PulseAudio kommt man überall weiter und hat eine höher-levelige API als z.B. per OpenAL oder SDL. Und wie JACK kann man eben auch sehr leicht Programme untereinander verbinden, was aber die meisten nie benutzen.
Damit habe ich bei c.a. jedem 10 Einschalten meines Rechners das Problem, dass die Karte irgendwie nicht richtig initialisiert wird. Dann kommt kein Sound. Oft nach sehr schrägem akustischem "Müll".
Von cyberpatrol am Do, 29. September 2011 um 08:32 #
Welcher Chip ist denn auf dem Teil? Zufällig ein iceXXXX? Konnte so auf die Schnelle nichts dazu finden.
Denn PulseAudio kann zumindest mit ice1712 Chips nicht umgehen. Würde mich zumindest wundern, wenn es das mittlerweile könnte. Mit ALSA alleine dagegen funktionierts problemlos out-of-the-box.
Und in Anbetracht dessen, dass ALSA auch noch dmix per default hat, sehe ich wirklich keinen Grund für PulseAudio. Das aber nur so nebenbei.
Und genau da steig ich aus! Ich dachte PA baut auf darunterliegende Soundsysteme auf? PA holt sich also von verschiedenen Sources die Audiodaten, mixt diese und schickt sie an - hier - ALSA. Warum also funktionierts mit ALSA alleine, nicht aber in Zusammenhang mit PA? Sollte es ALSA nicht vollkommen egal sein, ob der Audiostream von einer Anwendung direkt oder von PA kommt?
Von cyberpatrol am Do, 29. September 2011 um 11:28 #
Das Problem ist, dass die auf ice1712 Chips basierenden Karten keine normalen Stereo- oder Surround-Soundkarten, sondern (Semi-)Professionelle Audiokarten sind, die keinen eingebauten Verstärker und Master-Lautstärkeregler besitzen. Die besitzen lediglich für jeweils Ein- und Ausgang zwei separate Audiokanäle, die natürlich zu normalem Stereo zusammengemixt werden können, aber völlig unabhängig voneinander geregelt werden. Die ganz genauen Details kann ich dir jetzt auf die Schnelle leider auch nicht erklären. Würde aber, glaube ich, auch den Rahmen sprengen.
Der entscheidende Punkt ist aber, dass die Lautstärke z.B. nicht über einen einfachen Master-Regler verändert werden kann. Stattdessen benötigt man zur Lautstärkeregelung und zum Mixen generell eine spezielle Software namens envy24control, die wirklich jeden Kanal einzeln regeln kann und ein Patchbay enthält, weil das über den normalen alsamixer nicht möglich ist. Und genau diese Funktionalität beherrschen PulseAudio und dessen Mixer nicht und genauso wenig kann PulseAudio hier korrekt mit ALSA zusammenarbeiten. Die haben zwar wohl angeblich irgendeine Pseudo-Stereo-Umwandlung für diese Chips drin, nur dass sowas, wenn es denn wirklich existiert, wiederum die Vorteile und den Sinn dieser Audiokarten zunichte machen würde. ALSA beherrscht das alles aber mit Hilfe des zu den alsatools gehörenden envy24control perfekt.
Insofern ist PulseAudio für diese Karten absolut nicht zu gebrauchen, während ALSA diese Karten problemlos out-of-the-box und seit längerer Zeit sogar schon ohne .asoundrc unterstützt.
Und dank des übrigens auch schon seit Jahren per default aktivierten und ebenfalls perfekt funktionierenden dmix kann ALSA auch den Sound aller parallel laufender Anwendungen gleichzeitig wiedergeben. Also hat auch hier PulseAudio überhaupt keinen Vorteil gegenüber ALSA.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Sep 2011 um 11:29.
Von zettberlin am Do, 29. September 2011 um 22:22 #
> zum Mixen generell eine spezielle Software namens envy24control, die wirklich jeden Kanal einzeln regeln kann und ein Patchbay enthält, weil das über den normalen alsamixer nicht möglich ist
Na gut, ganz unmöglich ist es nicht. Die ICE1712/envy-Karten haben in envy24-control einzelne Regler für die Summe rein/raus. Es ist nur so, dass die Schnittstellen auf der Karte eben alle gleichberechtigt sind: 8 mono-Kanäle rein 8 mono raus plus 2 SPDIF.
Alsa sagt dazu ganz locker: gut, dann sind eben 0 und 1 jetzt rechts und links Stereo und die restlichen Ports kann der Nutzer ja mit Jack und envy24control nach Gusto benutzen, wenn es eine Karte mit mehr als 2 Hardware I/O ist.
PA versteht das nicht: wenn es mehr als zwei Kanäle gibt *muss* das doch irgend ein 5.1- Konzept oder sowas sein! Und was sollen überhaupt die ganzen Ports im Chip, für die manche Karten gar keine Hardware aufgelötet haben?! Das Konzept von PA sieht nur Konsumenten-Geräte vor.
Trotzdem sind envy24-Karten immer noch der Goldstandard für Soundkarten unter Linux. Weil Jack in so gut wie allen Distros PA suspendiert, wenn es startet. Problematisch wird es nur, wenn ein besonders ehrgeiziger Distributor glaubt, er müsse die Alsa-Schnittstelle extra für PA abstrahieren durch virtuelle Ports in einer asoundrc.
Der Platin-Standard sind übrigens HDSP-Karten wie die Hammerfall-Modelle von RME -- die unterstützt PulseAudio auch nicht.
Von cyberpatrol am Do, 29. September 2011 um 23:58 #
Sehr gut und richtig erklärt bis auf eine Kleinigkeit.
Alsa sagt dazu ganz locker: gut, dann sind eben 0 und 1 jetzt rechts und links Stereo und die restlichen Ports kann der Nutzer ja mit Jack und envy24control nach Gusto benutzen, wenn es eine Karte mit mehr als 2 Hardware I/O ist.
Ich denke eher, dass das nicht nur so locker dahin gesagt, sondern explizit so gewollt ist. Denn das ist ja eben die Funktionsweise dieser Audio-Karten.
Ich hab übrigens eine M-Audio Audiophile 24/96. Nicht ganz so gut wie die Hammerfall, aber zum Musik Hören sollte es reichen. Die Hammerfall-Modelle haben aber, meine ich, auch iceXXXX Chips drauf.
Es sind übrigens nicht nur manche Distributoren, die meinen, den Usern PA aufzwingen zu müssen, sondern auch so manche Softwareentwickler. Hängt z.B. nicht auch Gnome mittlerweile von PA ab? Ich meine, ich benutze Xfce unter Arch Linux und hab erfreulicherweise so überhaupt nichts mit PA zu tun, wenn ich nicht unbedingt will.
Im Übrigen habe ich auch den Eindruck, dass es nicht nur das Konzept von PA ist, nur Konsumer-Geräte vorzusehen, sondern dass auch die PA-Entwickler nicht wirklich Ahnung von richtigen Audio-Karten haben, wie man an dem ein oder anderen Kommentar in deren Bug-Tracker erkennen kann.
Ich kann persönlich leider nur von Problemen mit Pulsaudio berichten. Meine Frau verwendet Kubuntu und da gab es z. B. in Zusammenhang mit Skype nur Stress bis wir Pulsaudio deinstalliert hatten. Die gleich Erfahrung haben auch Bekannte von mir gemacht. Folglich bringt Pulsaudio genauso viele neue Probleme wie es welche löst. Wenn man professionelle Audioanwendung mir Jack macht (ist bei mir der Fall) dann ist Pulsaudio sowieso nur ein Hindernis.
Pulseaudio ist zum "Spielen", also zu allem, wofür man keine 100% Soundaus- und Eingabe benötigt, vielleicht ganz OK. Aber sobald man mit Harddiscrecording anfängt, kommt man an Jack nicht vorbei.
Lustigerweise funktionierte störungsfreies Harddiscrecording schon zu Vor-Pulseaudio-Zeiten einwandfrei (damals auch ohne Jack)...
Lustigerweise funktionierte störungsfreies Harddiscrecording schon zu Vor-Pulseaudio-Zeiten einwandfrei (damals auch ohne Jack)...
Aber auch nur dann, wenn die Sound-Hardware Hardware-Mixing unterstützte. Sobald dieser Fall nicht gegeben war, sah es sehr düster aus. "Dmix" bzw. "Dsnoop" waren damals ein einziger Krampf. Manchmal funktionierte es, sehr oft aber auch nicht.
Wenn man professionelle Audioanwendung mir Jack macht (ist bei mir der Fall) dann ist Pulsaudio sowieso nur ein Hindernis.
Im Zweifelsfall lässt man Pulseaudio eben über "jackd" laufen. Das geht nämlich auch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Sep 2011 um 14:32.
Von zettberlin am Do, 29. September 2011 um 22:26 #
>m Zweifelsfall lässt man Pulseaudio eben über "jackd" laufen. Das geht nämlich auch.
Theoretisch. In der Praxis ist PA nicht für die Anforderungen gebaut, die Jack von einem Client erwartet. Das ist allerdings nicht einmal die Schuld von PA, schließlich soll es ja gerade gutmütig alles unterstützen, was irgendiwe piep machen möchte.
Aber man kann PA ganz gut suspendieren, wenn man mit Jack arbeiten möchte....
bei mir sorgt es bislang nur für Ärger. im jahr 2011 erwarte ich, dass sound unter linux einfach läuft. Sobald bei mir irgendeine pulseaudio-anwendung läuft, melde sämtliche Programme die direkt auf alsa zugreifen wollen 'ausgabe belegt'. Sowas kenne ich sonst nur aus der vor-alsa-zeit.
Kontrollier doch mal Deine ALSA-Konfiguration in /etc/asound.conf (user-spezifisch überschreibbar durch ~/.asoundrc). Für ein reines PulseAudio-Setup sollte die z.B. so aussehen:
pcm.!default { type pulse } ctl.!default { type pulse }
ja, das löst das Problem (und das habe ich auch schon händisch eingetragen). Aber eigentlich erwarte ich schon, dass solche basics heute ohne manuelle Anpassungen laufen. Da waren wir gefühlt einfach schon weiter:-/
Ich tippe mal es ist nicht Ubuntu oder Debian. Dort werden das Paket "libasound2-plugins", welches den obigen Schritt automatisch durchführt, standardmäßig installiert. Auch unter Fedora sollte ein entsprechendes Paket ("alsa-plugins-pulseaudio") standardmäßig installiert sein. Unter OpenSuse gibt es auch ein entsprechendes Paket namens "alsa-plugins-pulse", unter ArchLinux heißt dieses einfach "alsa-plugins".
Von jjghjkkjj am Do, 29. September 2011 um 21:20 #
Bugs gibt es halt immer wieder, auch mit Pulseaudio und Alsa. Pulseaudio hatte halt temporär einen schlechten Ruf und es gibt wohl immer noch Soundchips, die damit nicht laufen. Ähnliches gilt manchmal auch für Alsa. Ein alter AD1885-Chip auf einem Intel845BG-Mainboard funktionierte plötzlich nicht mehr. Also musste ich auf OSS wechseln. Und? Hauptsache, ich höre etwas.
Die Funktionen, die Pulseaudio so bietet, lesen sich auf dem Papier ja recht gut, in der Praxis jedoch kosten sie, zumindest nach meiner bisherigen Erfahrung, zwischen 5 und 15% CPU Last, manchmal sogar noch mehr. Wer jedes bisschen Leistung braucht, weil er damit zB spielen will (Gott bewahre! Spielen! Und dann unter Linux! JEHOVA!), für den ist das einfach ein No-Go. Deshalb sollten meines Erachtens nach Distros, die Pulse ausliefern, auch eine Möglichkeit bieten, dieses einfach zu deaktivieren, auf Dauer oder kurzzeitig. Das fehlt leider noch. Teilweise ist das sogar so, dass, versucht man das Paket zu deinstallieren, es das ganze System mitzieht, da es als erforderliche Abhängigkeit überall eingetragen ist. Händisch in den Konfigurationsdateien rumfriemeln und /usr/bin/pulseaudio umbenennen, funktioniert zwar, nur sauber ist das nicht. Das ist zwar kein Problem mit Pulse selber, sondern Distro spezifisch, trotzdem nervt's. Und nein, pasuspender funktionierte bislang irgendwie nicht recht. Eine Idee für Pulse wäre doch, eine Möglichkeit in den GUI Tools zu schaffen, die CPU Last unter Verminderung der Qualität einstellen zu können.
"Mit der Freigabe der Version 1.0 steht knapp sieben Jahre nach der ersten Version von PulseAudio eine per Deklaration stabile Version des Systems bereit."
Nein und dem wird im Artikel auch gleich im nachfolgenden Satz widersprochen. Es werden sicherlich wieder ein paar Anhänger "klassischer Versionierungsschemata" johlen, aber hier ist eben ein weiteres Projekt, das seine eigenen Regeln definiert und sich nicht um Erwartungshaltungen schert. Man muss sich eben angewöhnen, die Aussagen der jeweiligen Entwickler zu berücksichtigen und zu respektieren, dann kann man den Blick auch wieder der Qualität der Software zuwenden.
Mozilla ist derzeit sicherlich das prominenteste Beispiel für Beschimpfungen wütender "Versionsnummern-Nazis", dabei könnte man das Entwicklunsmodell selbst sicherlich kontrovers diskutieren.
ALSA hatte früher gute Dienste geleieistet. Aber seit Jahren schon ist Pulse Audio die erste Wahl unter Linux.
Sollen die ALSA-Enteickler doch mit an PA arbeiten. ALSA kann ab in die Mottenkiste. Es ist Teil der Geschichte von Linux. Aber in der heutigen Zeit genauso sinnvoll wie DOS als Betriebssystem für die neuesten Computer zu verwenden.
Tu dir selbst einen Gefallen und informiere dich vor dem Posten erst einmal was ALSA und Pulseaudio sind. Dann hättest du diesen peinlichen Kommentar nämlich sparen können.
Du schreibst ziemlichen Unsinn. ALSA kann überhaupt nicht in die Mottenkiste denn es ist das Audio-Subsystem von Linux auf Kernel-Ebene. PulseAudio ist nur ein Sound-Deamon ähnlich wie ESD der auf ALSA aufsetzt. Merke: ALSA -> Low-Level. PA -> High-Level.
Kann man Pulse irgendwie mit Jack vergleichen?
Hatt vor Jahren mal eine Anwendung mit mehreren parallelen E/A, welche Jack bedingten. (Wußte aber nicht wirklich was ich tat, aber es funktionierte
)
Gruß u.
Wobei Jack und Pulseaudio zwei verschiedene Zielgruppen haben. Das eine ist ein low latency Soundserver für professionelle Audioanwendungen (jack), das andere für Heimbenutzer und ihr Bluetooth-Headset (pulse).
Wobei das eine das andere nicht ausschließt. Man kann z.B. Jack als Hauptsoundserver benutzen und Pulseaudio dann diesen als Ausgabemedium wählen. Dadurch behält man den Komfort von Pulseaudio in Bezug auf USB -und Bluetoothgeräten, kann aber andererseits professionell mit dem Rechner arbeiten.
Wenn es nach dir ginge, dann würde man auch alle 3D Treiber und DRI abschaffen, denn OpenGL reicht ja heute.
Deine Worte, im übertragenen Sinne.
Peinlich peinlich, Simon1.
"Sollen die ALSA-Enteickler doch mit an PA arbeiten."
Ja und eben genau das tun sie ja!
@Simon1--Was für ein dämlicher Kommentar.Wenn man schon keinen Plan hat sollte man doch bei Windows oder Apple bleiben.
Deine Logik ist bestechend einfach!
Glücklicherweise hast Du anonym gepostet. :-)
Zusammen mit dem GUI tool ist es sehr einfach einzustellen an welcher Schnittstelle etwas ausgegeben bzw. nicht ausgegeben werden sollte (HDMI, Dockingstation, Notebooklautsprecher, Notebookkopfhörer,...)
Unter Windows bekomme ich das nicht hin. Aber das ist mir eigentlich auch egal
Wo ist da jetzt der Vorteil zu einem System ohne Sound-Daemon?
Ich wollte nur sagen, dass ich das GUI tool mit dem ich PulseAudio Funktionen nutze sehr mag und das ganze gut läuft.
Wo nun der Vorteil/Nachteil ohne Sound-Daemon ist weiß ich nicht, da ich mich mit der Materie nicht auskenne (darüber habe ich in meinem Posting auch nicht geschrieben). Aber ich mag wie das umgesetzt wurde hier unter SL 6, mit PulseAudio, soweit ich das aus Anwendersicht beurteilen kann.
Man muss nichts mehr rumbasteln, weil der Sound-Daemon (Speziell Pulseaudio) die vorhandenen Ein -und Ausgabegeräte erkennt und man diese dann per Mausklick einstellen und in Echtzeit zwischen diesen wechseln kann.
Vor ein paar Jahren musste man sich bei allen Distributionen noch Gedanken machen ob der Treiber und die Hardware Hardware-Mixing beherrschen und dazu passend eine ALSA-Datei erstellen. Ansonsten konnte man nämlich immer nur eine Audio-Ausgabe auf einmal benutzen.
Seit sich Pulseaudio auf breiter Front durchgesetzt hat, gehören solche Probleme der Vergangenheit an.
Ich kann mich noch dunkel an diese Zeit erinnern. Die Probleme sollten aber schon lange der Vergangenheit angehören, wenn man nicht gerade die OSS-Emulation braucht. Zumindest ist mir seit Jahren nichts in der Richtung aufgefallen und das ohne auch nur einmal PulseAudio installiert zu haben. So wie es sich anhört ist PulseAudio wohl praktisch wenn man oft zwischen verschieden Soundkarten umschalten muss.
>Seit sich Pulseaudio auf breiter Front durchgesetzt hat, gehören solche
>Probleme der Vergangenheit an.
Hüstel... Als Pulsaudio auf breiter Front vor Jahren in die Linuxdistris gesteckt wurde gingen die Probleme richtig los. Das mag sich jetzt geändert haben aber anfangs war Pulsaudio einfach nur Mist. Eins der besten Beispiele für Bananensoftware... Wer es nicht glaubt darf gerne mal in den Archiven der Foren abtauchen...
Ich habe mich etwas missverständlich ausgedrückt:
Ja, Pulseaudio machte am Anfang mehr Probleme als es geholfen hat. Vor allem unter Ubuntu und im Zusammenspiel mit dem Flash-Plugin. Diese Zeiten sind aber schon lange vorbei. Natürlich gibt es Fälle, wo Pulseaudio Probleme hat und macht, diese sind aber weniger häufig als es manche Leute wahrhaben wollen.
Wie kam es denn dazu, dass man mittlerweile nicht mehr auf über Soundserver schimpft?
Soweit ich mich erinnern kann ermöglichte aRts zu seiner Zeit, dass Mischen von verschiedenen Tonquellen, was nicht jede Soundkarte selbst vermochte. Heute kann das ALSA selbst und aRts wurde eingestellt. In welche Lücke springt denn da PulseAudio? Netzwerktransparenz ist sicherlich eine wertvolle Eigenschaft. Nur wird die üblicherweise vermutlich keiner nutzen. Vielleicht sind Abstraktionsschichten so toll, dass man nie genug davon übereinander haben kann.
IMHO ist eine einheitliche Schnittstelle (Betriebssystemunabhängig) eine echte Beireichung für die Entwicklergemeinde. Selbst wenn es nur für die Spieleentwicklung ist. Mit OpenGL und Pulseaudio hat man auf allen Plattformen damit 2 Probleme weniger.
Auf welchem anderen Betriebssystem außer Linux wird denn noch PulseAudio eingesetzt?
Wenn man die Wahl hat, ... auf gar keinen.
Wie wäre es mit allen freien Unices?
Dann kannst du gleich OSS nehmen und bekommst nicht den Rattenschwanz an Seiteneffekten und Abhängigkeiten obendrauf.
Ich kenne kein Unix außer Linux und OS X, bei dem es Verwendung für soetwas wie einen Soundserver gäbe.
*BSD. Oder glaubst du, die hocken noch für ihren C64 im dunklen Keller ohne alles?
Ohne alles? Wenn die Ton brauchen nehmen sie einfach OSS. Gibt vermutlich nicht allzu viele Programme in der Unix-Welt die nicht OSS unterstützen, wenn sie Ton ausgeben wollen.
Und unter FreeBSD kann jede Soundkarte Hardwaremixing?
Ich vermute nicht. Wie wäre es aber mit VCHAN [1]?
[1] http://www.freebsd.org/cgi/man.cgi?query=sound&manpath=FreeBSD+8-current
Da ich mich mit FreeBSD auskenne:
Laufen die eingerichteten VCHANs völlig transparent oder muss man jedem Programm händisch einen solchen zuweisen?
Da könnte ich auch nur spekulieren. Ich wollte einfach nicht glauben, dass bei FreeBSD die Uhren stehen geblieben sind. Also habe ich einen kurzen Blick in das Handbuch geworfen.
> Gibt vermutlich nicht allzu viele Programme in der Unix-Welt die nicht OSS unterstützen, wenn sie Ton ausgeben wollen.
Deine Vermutung wäre vor gefühlten 10 Jahren noch wohlbegründet gewesen. Heute gibt es allerdings hunderte Sound-Programme für Linux, die teilweise einzigartige Fähigkeiten anbieten und die OSS durchaus nicht unterstützen. Darunter fast alle ernst zu nehmenden Kompositions-Tools und HD-Recorder, die oft nur noch mit Jack arbeiten oder zumindest ein aktuelles ALSA voraussetzen.
Ich musste unter Squeeze zu Opensound wechseln, da ich mit der dortigen Alsaversion meinen Soundchip zur Zeit nicht mehr betreiben kann.
Diese Fehler treten tatsächlich manchmal auf.
So beschwert sich VLC, er würde keine Soundausgabe finden. Trotzdem spielt VLC mit Ton ab.
Bemerkenswert ist auch, dass der Sound, den ich jetzt höre (Squeeze mit OSS), besser ist als das, was Lenny bisher audiomäßig von sich gab (Lenny mit Alsa).
Irgendwie "erschreckend".
aRTs als Beispiel heranzuziehen ist doch etwas vermessen, da dieses ein Musterbeispiel von "Gut gewollt, schlecht gemacht war". Außer einer Handvoll KDE-Programme unterstützte nämlich kaum ein Programm diesen Soundserver, weil er notorisch instabil und ein Resourcenfresser war. Und dadurch, dass kaum ein Programm aRTs unterstützte, musste man bei fehlendem Hardware-Mixing den Soundserver vor dem Starten eines Programms immer abschießen und danach neu starten. "artsdsp" funktionierte nämlich mehr schlecht als recht.
Pulseaudio funktioniert einfach. Wer z.B. wie ich ein USB-Headset zusammen mit einer normalen Onboard-Soundkarte benutzt, möchte nie mehr ohne Pulseaudio unterwegs sein. Ich kann z.B. den Soundserver anweisen das Headset nur für Skype zu benutzen, die Onboard-Soundkarte dagegen alle anderen Programme bedienen lassen. Oder ich kann per Mausklick im Lautstärke-Manager ein einzelnes Programm kurzfristig auf Stumm stellen, ohne das Programm selbst anfassen zu müssen.ALSA könnte das zwar auch theoretisch, aber nur mit sehr viel Handarbeit und Recherche.
Die Handarbeit bei ALSA ergibt sich in erster Linie daraus, daß es keine guten Konfigurationstools dafür gibt und die Configdateien alle händisch erstellt werden müssen.
ALSA selbst hat mir mal mit seinen Fähigkeiten, Soundströme umzuleiten, sehr geholfen.
Meine alte analoge TV-Karte hatte einen Audioausgang und der mußte mit einem speziellen Kabel (Buchse erforderte speziellen Stecker) in den Line-In Eingang meiner Soundkarte geleitet werden, damit man über die Soundkarte und die damit verbundenen Lautsprecher Sound hören konnte.
Tja und eines Tages schleppte ich meinen Rechner für ein paar Tage zu nem Bekannten, aber das Audio Kabel hatte ich vergessen, weswegen ich eigentlich nur noch TV ohne Sound gucken hätte können.
Zumindest war das unter Windows dann auch der Fall.
Aber ALSA hat mich gerettet, denn mit ALSA konnte ich das Signal des Soundchips auf der TV-Karte intern per Software auf meine Soundkarte umleiten und somit trotzdem TV mit Ton schauen.
ALSA sei dank. Und Windows war ich da aufgeschmissen.
> Die Handarbeit bei ALSA ergibt sich in erster Linie daraus, daß es keine guten Konfigurationstools dafür gibt und die Configdateien alle händisch erstellt werden müssen.
Noch ein Punkt: Geräteänderungen erfordern bei ALSA einen Neustart des jeweiligen Programmes bzw. mindestens des jeweiligen Streams und Neueinlesen der Konfiguration, was aber selten implementiert ist. Bei PulseAudio passiert auch dann nichts, wenn mal für eine Weile überhaupt keine Soundhardware da ist (weil man z.B. die USB-Lautsprecher woanders hinstellt und dafür das Kabel abzieht), man hört eben blos nichts. Stecker wieder reinstecken und weiter geht's, ohne dass die Programme etwas davon merken. Man kann aber auch übergangsweise sein Bluetooth-Headset anschalten. Bei ALSA hört man dann trotzdem nichts, weil bestehende Streams nicht auf ein anderes Gerät geleitet werden können.
Für die meisten hier vermutlich unwichtig, aber PulseAudio gibt es auch für BSD, Windows und MacOSX. Damit hat man überall die gleiche Schnittstelle. ALSA gibt es nur für Linux, CoreAudio nur für OSX, OSS spielt nur noch unter BSD eine Rolle und DirectSound ist Windows-only. Mit PulseAudio kommt man überall weiter und hat eine höher-levelige API als z.B. per OpenAL oder SDL. Und wie JACK kann man eben auch sehr leicht Programme untereinander verbinden, was aber die meisten nie benutzen.
Also das ist Käse.
OpenAL ist eine 3d Sound API, d.h. damit kannst du auch EAX & Co nutzen. Pulseaudio bietet das nicht.
(externe USB Karte)
Damit habe ich bei c.a. jedem 10 Einschalten meines Rechners das Problem, dass die Karte irgendwie nicht richtig initialisiert wird. Dann kommt kein Sound. Oft nach sehr schrägem akustischem "Müll".
Weiss jmd warum? Oder gar die Lösung?
Danke!
Der Omega13.
Welcher Chip ist denn auf dem Teil? Zufällig ein iceXXXX? Konnte so auf die Schnelle nichts dazu finden.
Denn PulseAudio kann zumindest mit ice1712 Chips nicht umgehen. Würde mich zumindest wundern, wenn es das mittlerweile könnte. Mit ALSA alleine dagegen funktionierts problemlos out-of-the-box.
Und in Anbetracht dessen, dass ALSA auch noch dmix per default hat, sehe ich wirklich keinen Grund für PulseAudio. Das aber nur so nebenbei.
Und genau da steig ich aus! Ich dachte PA baut auf darunterliegende Soundsysteme auf? PA holt sich also von verschiedenen Sources die Audiodaten, mixt diese und schickt sie an - hier - ALSA. Warum also funktionierts mit ALSA alleine, nicht aber in Zusammenhang mit PA? Sollte es ALSA nicht vollkommen egal sein, ob der Audiostream von einer Anwendung direkt oder von PA kommt?
Das Problem ist, dass die auf ice1712 Chips basierenden Karten keine normalen Stereo- oder Surround-Soundkarten, sondern (Semi-)Professionelle Audiokarten sind, die keinen eingebauten Verstärker und Master-Lautstärkeregler besitzen. Die besitzen lediglich für jeweils Ein- und Ausgang zwei separate Audiokanäle, die natürlich zu normalem Stereo zusammengemixt werden können, aber völlig unabhängig voneinander geregelt werden. Die ganz genauen Details kann ich dir jetzt auf die Schnelle leider auch nicht erklären. Würde aber, glaube ich, auch den Rahmen sprengen.
Der entscheidende Punkt ist aber, dass die Lautstärke z.B. nicht über einen einfachen Master-Regler verändert werden kann. Stattdessen benötigt man zur Lautstärkeregelung und zum Mixen generell eine spezielle Software namens envy24control, die wirklich jeden Kanal einzeln regeln kann und ein Patchbay enthält, weil das über den normalen alsamixer nicht möglich ist. Und genau diese Funktionalität beherrschen PulseAudio und dessen Mixer nicht und genauso wenig kann PulseAudio hier korrekt mit ALSA zusammenarbeiten. Die haben zwar wohl angeblich irgendeine Pseudo-Stereo-Umwandlung für diese Chips drin, nur dass sowas, wenn es denn wirklich existiert, wiederum die Vorteile und den Sinn dieser Audiokarten zunichte machen würde. ALSA beherrscht das alles aber mit Hilfe des zu den alsatools gehörenden envy24control perfekt.
Insofern ist PulseAudio für diese Karten absolut nicht zu gebrauchen, während ALSA diese Karten problemlos out-of-the-box und seit längerer Zeit sogar schon ohne .asoundrc unterstützt.
Und dank des übrigens auch schon seit Jahren per default aktivierten und ebenfalls perfekt funktionierenden dmix kann ALSA auch den Sound aller parallel laufender Anwendungen gleichzeitig wiedergeben. Also hat auch hier PulseAudio überhaupt keinen Vorteil gegenüber ALSA.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Sep 2011 um 11:29.> zum Mixen generell eine spezielle Software namens envy24control, die wirklich jeden Kanal einzeln regeln kann und ein Patchbay enthält, weil das über den normalen alsamixer nicht möglich ist
Na gut, ganz unmöglich ist es nicht. Die ICE1712/envy-Karten haben in envy24-control einzelne Regler für die Summe rein/raus. Es ist nur so, dass die Schnittstellen auf der Karte eben alle gleichberechtigt sind: 8 mono-Kanäle rein 8 mono raus plus 2 SPDIF.
Alsa sagt dazu ganz locker: gut, dann sind eben 0 und 1 jetzt rechts und links Stereo und die restlichen Ports kann der Nutzer ja mit Jack und envy24control nach Gusto benutzen, wenn es eine Karte mit mehr als 2 Hardware I/O ist.
PA versteht das nicht: wenn es mehr als zwei Kanäle gibt *muss* das doch irgend ein 5.1- Konzept oder sowas sein! Und was sollen überhaupt die ganzen Ports im Chip, für die manche Karten gar keine Hardware aufgelötet haben?! Das Konzept von PA sieht nur Konsumenten-Geräte vor.
Trotzdem sind envy24-Karten immer noch der Goldstandard für Soundkarten unter Linux. Weil Jack in so gut wie allen Distros PA suspendiert, wenn es startet. Problematisch wird es nur, wenn ein besonders ehrgeiziger Distributor glaubt, er müsse die Alsa-Schnittstelle extra für PA abstrahieren durch virtuelle Ports in einer asoundrc.
Der Platin-Standard sind übrigens HDSP-Karten wie die Hammerfall-Modelle von RME -- die unterstützt PulseAudio auch nicht.
Sehr gut und richtig erklärt bis auf eine Kleinigkeit.
Ich denke eher, dass das nicht nur so locker dahin gesagt, sondern explizit so gewollt ist. Denn das ist ja eben die Funktionsweise dieser Audio-Karten.
Ich hab übrigens eine M-Audio Audiophile 24/96. Nicht ganz so gut wie die Hammerfall, aber zum Musik Hören sollte es reichen. Die Hammerfall-Modelle haben aber, meine ich, auch iceXXXX Chips drauf.
Es sind übrigens nicht nur manche Distributoren, die meinen, den Usern PA aufzwingen zu müssen, sondern auch so manche Softwareentwickler. Hängt z.B. nicht auch Gnome mittlerweile von PA ab? Ich meine, ich benutze Xfce unter Arch Linux und hab erfreulicherweise so überhaupt nichts mit PA zu tun, wenn ich nicht unbedingt will.
Im Übrigen habe ich auch den Eindruck, dass es nicht nur das Konzept von PA ist, nur Konsumer-Geräte vorzusehen, sondern dass auch die PA-Entwickler nicht wirklich Ahnung von richtigen Audio-Karten haben, wie man an dem ein oder anderen Kommentar in deren Bug-Tracker erkennen kann.
Ich kann persönlich leider nur von Problemen mit Pulsaudio berichten. Meine Frau verwendet Kubuntu und da gab es z. B. in Zusammenhang mit Skype nur Stress bis wir Pulsaudio deinstalliert hatten. Die gleich Erfahrung haben auch Bekannte von mir gemacht.
Folglich bringt Pulsaudio genauso viele neue Probleme wie es welche löst.
Wenn man professionelle Audioanwendung mir Jack macht (ist bei mir der Fall) dann ist Pulsaudio sowieso nur ein Hindernis.
Kann ich nur bestätigen.
Pulseaudio ist zum "Spielen", also zu allem, wofür man keine 100% Soundaus- und Eingabe benötigt, vielleicht ganz OK. Aber sobald man mit Harddiscrecording anfängt, kommt man an Jack nicht vorbei.
Lustigerweise funktionierte störungsfreies Harddiscrecording schon zu Vor-Pulseaudio-Zeiten einwandfrei (damals auch ohne Jack)...
>m Zweifelsfall lässt man Pulseaudio eben über "jackd" laufen. Das geht nämlich auch.
Theoretisch. In der Praxis ist PA nicht für die Anforderungen gebaut, die Jack von einem Client erwartet. Das ist allerdings nicht einmal die Schuld von PA, schließlich soll es ja gerade gutmütig alles unterstützen, was irgendiwe piep machen möchte.
Aber man kann PA ganz gut suspendieren, wenn man mit Jack arbeiten möchte....
bei mir sorgt es bislang nur für Ärger.
im jahr 2011 erwarte ich, dass sound unter linux einfach läuft. Sobald bei mir irgendeine pulseaudio-anwendung läuft, melde sämtliche Programme die direkt auf alsa zugreifen wollen 'ausgabe belegt'. Sowas kenne ich sonst nur aus der vor-alsa-zeit.
Kontrollier doch mal Deine ALSA-Konfiguration in /etc/asound.conf (user-spezifisch überschreibbar durch ~/.asoundrc). Für ein reines PulseAudio-Setup sollte die z.B. so aussehen:
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
ja, das löst das Problem (und das habe ich auch schon händisch eingetragen).
Aber eigentlich erwarte ich schon, dass solche basics heute ohne manuelle Anpassungen laufen. Da waren wir gefühlt einfach schon weiter:-/
Welche Distribution verwendest Du denn?
Die desktop-orientierten Distributionen sollten inzwischen eigentlich standardmäßig so konfiguriert sein.
Ich tippe mal es ist nicht Ubuntu oder Debian. Dort werden das Paket "libasound2-plugins", welches den obigen Schritt automatisch durchführt, standardmäßig installiert.
Auch unter Fedora sollte ein entsprechendes Paket ("alsa-plugins-pulseaudio") standardmäßig installiert sein. Unter OpenSuse gibt es auch ein entsprechendes Paket namens "alsa-plugins-pulse", unter ArchLinux heißt dieses einfach "alsa-plugins".
Bugs gibt es halt immer wieder, auch mit Pulseaudio und Alsa.
Pulseaudio hatte halt temporär einen schlechten Ruf und es gibt wohl immer noch Soundchips, die damit nicht laufen.
Ähnliches gilt manchmal auch für Alsa. Ein alter AD1885-Chip auf einem Intel845BG-Mainboard funktionierte plötzlich nicht mehr. Also musste ich auf OSS wechseln.
Und?
Hauptsache, ich höre etwas.
Die Funktionen, die Pulseaudio so bietet, lesen sich auf dem Papier ja recht gut, in der Praxis jedoch kosten sie, zumindest nach meiner bisherigen Erfahrung, zwischen 5 und 15% CPU Last, manchmal sogar noch mehr.
Wer jedes bisschen Leistung braucht, weil er damit zB spielen will (Gott bewahre! Spielen! Und dann unter Linux! JEHOVA!), für den ist das einfach ein No-Go.
Deshalb sollten meines Erachtens nach Distros, die Pulse ausliefern, auch eine Möglichkeit bieten, dieses einfach zu deaktivieren, auf Dauer oder kurzzeitig. Das fehlt leider noch. Teilweise ist das sogar so, dass, versucht man das Paket zu deinstallieren, es das ganze System mitzieht, da es als erforderliche Abhängigkeit überall eingetragen ist. Händisch in den Konfigurationsdateien rumfriemeln und /usr/bin/pulseaudio umbenennen, funktioniert zwar, nur sauber ist das nicht.
Das ist zwar kein Problem mit Pulse selber, sondern Distro spezifisch, trotzdem nervt's.
Und nein, pasuspender funktionierte bislang irgendwie nicht recht.
Eine Idee für Pulse wäre doch, eine Möglichkeit in den GUI Tools zu schaffen, die CPU Last unter Verminderung der Qualität einstellen zu können.
> zwischen 5 und 15% CPU Last, manchmal sogar noch mehr. Wer jedes bisschen Leistung braucht, weil er damit zB spielen will
5- 15% sind immer zu viel, wenn das Dauerlast ist. Nicht nur, wenn man spielen will oder irgend was anderes Rechenintensives macht.