Re: PulseAudio
On Thu, Jul 18, 2013 at 07:05:16AM +0200, John Paul Adrian Glaubitz wrote:
> Yeah, I see that. But my original point was that the many griefs and
> complaints people about PulseAudio have originate from the fact that
> many people already used it when it simply wasn't ready yet, so it's
> not fair to use this as an argument against PA.
You suggest that PulseAudio is still not yet mature. The arguments Steve
Langasek made and my clueless user experience indeed confirm that
sentiment. What I do not understand here is why gnome is pulling it in
as a dependency in a stable release then.
In your reply to Wouter Verhelst you repeatedly argue how PulseAudio
saves time on your end. As has been pointed out this matches neither
Wouter's nor my experience. Clearly your claims are not universal. It
appears that your use case is significantly different from Wouter's or
mine. For instance installing PA breaks an existing mpd (and PA devs
acknowledge that, fixing this is harder though due to the architecture).
One of the main causes for grief with PA is that you cannot opt-in to it
like you can with Jack. Like PA, Jack can implement the default alsa
device, but it doesn't do that unless you ask it. Also you are in charge
to decide when to start Jack. That removes a fair amount of debugging,
because you can easily determine whether an issue is to be attributed to
Jack or not.
Just to be clear: Jack is not the solution here. It solves a different
problem: low latency.
As an aside note PA error messages smell badly. When running into a
crash with gdb attached to PA, I am told that my alsa device is behaving
strangely and that this surely is a bug in the alsa driver. The
possibility that PA would be stopped for traceback investigation was
simply not considered.
How much time does it take to write a utility, that listens to sink
state updates? It took me about three hours and a quite a bit of help
from #pulseaudio. It does not work like you connect to the bus and
listen for the signal. Instead you connect the session bus, to discover
the bus address to connect to. Then you tell the core object that you
want to receive signals for your sink and then you can actually listen
for the signal. Solving the very same task with mpd for instance is
radically easier. There are reasons for why so many steps are needed
with PA, but those are not spelled out in the documentation.
It also appears that much of the troubleshooting documentation
concerning PA, that appears in Google, is seriously broken. Half of it
advises modifying files in /usr, so it breaks when you upgrade the
package. This applies especially to Ubuntu related docs. While PA is not
responsible for this broken documentation, the creation was likely
caused by absence of useful troubleshooting documentation on the side of
PA.
So PA is not removing complexity, but adding to it. Surely a bit of
complexity is needed to solve sophisticated tasks, but it could indeed
do better. For instance pacmd list-* could get some verbosity switches
and hide some details in the default view. Scanning a pacmd list-sinks
output for the relevant info just takes too long (in addition to needing
to scroll the terminal).
The sheer number of issues I find when investigating a supposedly mature
project is stunning. Clearly PA does not "just work" for me and some
others. On the bright side I can recommend upstreams irc channel and
reported issues appear to get fixed quickly.
Helmut
Reply to: