Re: pulseaudio related problems....
On Mon, Feb 17, 2014 at 09:02:56AM +0100, John Paul Adrian Glaubitz wrote:
> I don't know whether this is a good idea. What if I want to listen to
> something over my headphones which I don't others want to hear and
> I know about this "feature". I expect the sound to be over headphones
> only, yet it's blasting over the internal speakers as well and
> everyone in the room can hear me as well.
Heh. Can you tell me how to get this working? This application was the
number one reason for me to try PA (cause alsa doesn't do stream
re-routing).
So the task basically is "remove all present and future streams from a
sink" (sink is PA-speak for audio output). There are a few options that
can help to achieve this task:
* Set a different sink to be the default sink. This doesn't move any
existing streams.
* Unplug the sound card. This works with USB, PA will detect it and all
present and future streams are moved. I figured that this works less
well with onboard sound cards.
* Remove the PA module driving the sink. Oh well that was alsa, now you
have the null sink and no sound at all.
* "Cork" the sink. Well this doesn't move streams, it blocks them,
nothing is moved.
* Mute the sink. Again nothing is moved.
So I figured, even after a considerable amount of investigation I found
it impossible to achieve such a basic task even with the help of the
very welcoming #pulseaudio IRC channel. (If you ever have problems with
PA, one of the best things you can do is go to their IRC channel.)
This isn't the only deficit, that is by design. Ever tried to get
activity notification from PA for a particular sink (another thing alsa
doesn't do at all)? It works, but it feels somewhat complicated:
* You connect to your session dbus.
* You ask PA for its dbus address.
* You connect to the PA dbus. (Yes, it has its own dbus.)
* You look up all sinks. They are indexed by *numbers*, not names.
Those numbers are not stable. (This is one of the core critics of PA
proponents made against alsa, it's hilarious.)
* You watch the relevant signal.
* You invoke a PA-specific method that tells PA to actually start
generating the notifications you are interested in.
In defense, let me also tell you *why* this is so complex:
* PA is using a separate dbus, because that allows it to use a TCP
transport, so this control mechanism becomes network transparent,
which it wouldn't be on the session bus.
* PA is not emitting these notifications by default, because that was
deemed to be unacceptable for performance.
So rather than a buggy software, I see a software that is broken by
design in important aspects. As far as I can see, you cannot just fix
these issues without breaking tons of stuff. You'd be rewriting large
parts of PA and its API. In addition, the amount of knowledge about PA
internals required to achieve these tasks is impressive. I don't think
that an average user or even software developer has this knowledge.
Helmut
Reply to: