Re: PulseAudio
On 2013-07-19 11:56, Helmut Grohne wrote:
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.
Neither are yours. PA works fine for me with Bluetooth headsets and
regular sound cards on GNOME. Leaving regular gnome-bluetooth crashes
aside (that crash the shell, yay).
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).
PA should retract itself from the sound device when it's not in use.
ALSA architecture also does not allow different users to access a sound
device. (dmix is per user.)
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.
I don't think ptrace allows for that sort of self-tracing awareness,
does it?
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.
Obviously mpd solves a different problem.
Kind regards
Philipp Kern
Reply to: