[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how is pulseaudio supposed to work?

On Sun, 2007-12-16 at 15:30 +0100, Andreas Bierfert wrote:
> Sorry for hopping into the discussion this late but I still think that it is
> NOT the duty of window managers to setup pulse correctly. Sound is something
> inherent to the system and not a user session. Since prominent(tm) opinion
> seems to diverge from this we should at least take care that these things are
> handled by the system automatically. By adding support for this to all window
> manager packages we will just work around the general problem but not solve it.
> One good solution would be to make a general requirement for window managers in
> fedora to execute some config setup script when they launch. This script then
> takes all relevant items for the current config and starts them up. This way
> future changes to pulse can be handled but also on a more global scope addition
> of future magic can be handled gracefully via /etc/sysconfig where it belongs
> and not by hoping that all package maintainers will correctly fix up their
> packages in time.

No, no, no.

First of all, ideally, any service should be started by the app that
actually needs it, either implicitly or automatically. You're right that
it's not the duty of the window manager to start a sound server like PA,
but I don't think the wm is what's starting it in this case. I believe
it's the session manager, which makes sense because the session manager
is a part of a bigger app (the DE) that knows it will actually use the
sound server.

If you want to run a script each time X is started, that's what xinitrc
does, but there's no call for an X session to start the sound server,
unless, say, it were part of the X protocol like they were planning on
doing with MAS (http://www.mediaapplicationserver.net/).

Again, ideally, services (including system ones) should 1) only be
started and 2) actually be started when it is called for. Something
similar to the way kernel modules are autoloaded when there's a need for
the service. Or xinetd does for some services which use it (though with
an option to actually stay resident).

The question is how will this automation be inserted into PA. Will it be
by inference when the pulse libs are used? Or when an attempt is made to
open the network socket?

It's not exactly rocket science determining WHEN the need for PA is upon
the system. I'm sure it's just a matter of time before an approach is
decided, but if an interim solution for Fedora is called for ...
hmmm ... maybe I will backpedal. Maybe xinitrc might not be a bad place.

Richi Plana

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]