On Tue, 18.12.07 10:20, Tomasz Torcz (tomek@xxxxxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
