how is pulseaudio supposed to work?

[Lennart Poettering]

On Tue, 18.12.07 10:20, Tomasz Torcz (tomek at crocom.com.pl) wrote:

> > You can configure PA so that it is autospawned when needed. However, I
> > do not recommend this. I recommend to start it from the session
> > manager like we do it right now for KDE and GNOME. Why? Because PA
> > nowadays does much more than just proxying access to the hw. It reacts
> > on hotplug events, network configuration changes, certain X11 events,
> > it is a network server, and so on and so on. For all these reasons it
> > is better to leave PA running all the time.
> 
>   If PA is so important, why not start it system-wide by default?

"Importance" is not really a good reason for making a daemon
system-wide instead of per-session.

PA is intended to be run as a session daemon. There's some support to
run it as a system daemon, too. However, unless you really know what
you do I discourage everyone to use it.

There are many reasons why I chose to make PA a session daemon: one
being desktop integration: if you want PA to hook into all kinds of
events of the various parts of the desktop than you want to run PA as
the same user as the rest of the desktop. Then, there is security: PA
exposes a lot of internal data via SHM segments. That data might be
security relevant. Opening it up for all users is thus problematic, it
is much safer to run PA and the clients as the same user. Then,
synchronisation with clients becomes a lot more difficult if you want
to do it with low overhead but without allowing clients to hang or
freeze the sound server. Then, there is the whole policy issue. If PA
decides based on some policy how sound is routed/processed
(i.e. volume, which device to choose) then the policy should be a
per-user thing. Then, there is simplicty: it's a lot easier if you
have everything in one process, instead of having a farm of
cooperating processes distributed among different user ids, and not
trusting each other. And the list goes on and on...

Admittedly there are a couple of drawbacks of PA being a session
daemon. One being that it is very difficult to play an event sound
while switching VTs on FUS. And sharing sound cards between multiple
active sessions is difficult too. But I think these disadvantages do
not  outweigh the advantages of the per-session design, far from
that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4