On Wed, Jul 17, 2013 at 01:26:34PM -0700, Steve Langasek wrote:
> Though if we're going to talk about bugs, even though the kernel audio
> drivers have long since adapted to meet pulseaudio's requirements, PA itself
> still manages to turn up some doozies.
>
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1019925
>
> Why in 2012 - four years later - does a stable release of pulseaudio manage
> to *crash* in response to a bluetooth hotplug event? Will systemd also
> crash in response to hardware hotplug events? :)
Given the praise PulseAudio has received in this thread, I went ahead
and tried it. I can confirm that it is not rock solid. A simple dbus
introspection can take down the whole server. I discovered this crash
within two hours after installing and it is not even hardware related.
Thanks to Tanu Kaskinen for quickly fixing (7c3d31a) it.
Even though the feature set looks very promising, the actual first user
experience still leaves some things to be wished for. For me it started
with the sound device muted. Nothing earth shattering, but it took me
five minutes to discover. Then it hooks into alsa in a strange way
breaking all amixer invocations, that lacked a device specification. It
also appears to be completely impossible[1] to revert the alsa hooking
without removing the pulseaudio package.
Then maybe you start interfacing with it and notice that upstream calls
their own API unstable[2] and not to be relied upon. Also my experience
shows that getting dbus interactions right is far more difficult than
invoking programs on a command line. The type checking of dbus method
signatures should make it much safer than the command line.
Unfortunately this safety does not pay off in practise. The type
checking only occurs at run-time, so untested code can still contain
interface bugs. Worse, you can subscribe to signals that do not exist
without getting any indication, that you are doing it wrong.
>From my perspective PulseAudio is a strange software with an interface
that vastly differs from what I am used to. It also feels intrusive,
because it acts on its own. There is some similarity to what we are
experiencing with systemd. For example there has been a huge number of
complaints concerning the journal, mostly about it being different from
what people are used to. Still it provides a number of practical
benefits[3].
How can this acclimatisation be made easier? For both projects there is
a lot of documentation. One issue is that both break a number of
unwritten assumptions[4]. Identifying and documenting these appears to
not have happened yet.
Helmut
[1] A simple pcm.!default { type hw; card 0; } in .asoundrc doesn't do
the trick even though this is appears to be the documented way.
[2]
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/DBus/ConnectingToServer/
[3] Ever used systemctl status to see the last 10 log messages from a
particular service, including stdout and stderr?
[4] I expected that just installing pulseaudio would not change the
behaviour of other programs. I expected that systemd would honour
LC_CTYPE. Nothing is guaranteeing these, still they caused surprise.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717213857.ga7...@alf.mars
