Re: PulseAudio
On Fri, Jul 19, 2013 at 10:36:06PM +0200, Philipp Kern wrote:
> On 2013-07-19 11:56, Helmut Grohne wrote:
> 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).
I am aware that my use case is not universal. That is why I only pointed
my finger at particular issues.
> 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.)
I have no clue why/how, but with plain alsa I could play audio from two
different users simultaneously. It just worked and it stopped working
the moment pulseaudio was running.
> >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?
That's not the issue here. I was complaining about the software drawing
wrong conclusions from the behaviour it observed instead of just
presenting the unexpected situation. When people report bugs, we often
ask them not to quickly draw conclusions, because they might be wrong.
Some of the messages even feel insulting, because they try to tell me
what I want to do ("it's your own fault").
> >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.
True. That still makes them comparable, because they both implement a
common aspect. Both control a sound device that sometimes plays back
audio and other times doesn't. Both emit signals for state transitions.
This is why I find the comparison legitimate here. My comparison to Jack
also makes sense even though Jack solves a different problem. I just
compared a common aspect.
Helmut
Reply to: