[pulseaudio-discuss] System-wide daemon howto/best practices

[Lennart Poettering]

On Wed, 29.08.07 20:38, Jan Kasprzak (kas at fi.muni.cz) wrote:

Hi!

> on my home workstation I use a dual-seated setup (two monitors, two
> keyboards, two VGA cards, etc. - two independent users). I am
> looking for a way of using the sound card by both users
> simultaneously (I have problem that when one user's application
> opens the sound device and keeps it opened, the other user's ekiga
> cannot use it, which is quite annoying especially when receiving an
> incoming call).
> 
> I thought system-wide PulseAudio daemon might be the correct
> answer. I have read
> http://www.pulseaudio.org/wiki/SystemWideInstance,
> but I am not sure about how to best configure it:
> 
> * Is there any prebuilt init script for Fedora? Fedora RPMs does not
>   seem to have any (this is a minor problem, I can write it myself).

Not that I knew of. 

> * How to tell all user's sessions "use this PulseAudio daemon"?
>   Should I set an environment variable PULSE_SERVER somewhere in GDM
>   session startup scripts? Or use the default-server directive in
>   /etc/pulse/client.conf?

You have lot of different options:

You could stick it in /etc/pulse/client.conf (which is probably what
I'd). You could set $PULSE_SERVER. You could leave it out entirely if
the PA daemon is running locally. You could store it in the X11 root
window. (see pax11publish for that) If PULSE_SERVER is not set PA will
try $DISPLAY as a fallback, too. So basically, I did my best to make
it work even without too much manual configuration.

> * What about authentication? Is a pulse-access group membership the
>   recommended way? Or should I copy ~/.pulse-cookie to the home
>   directories of users I want to have access to the system-wide
>   daemon?

Both is fine. pulse-access is probably the best bay though.

> * Should user apps access the system-wide daemon directly? I have
>   also thought about each user having his own daemon, connected to
>   the system-wide one by (e.g.) module-native-protocol-unix.

Each time you add another layer of indirection audio latency becomes
worse. Thus I'd suggest using a single system-wide instance and that
should be it.

OTOH more and more policy is managed by the PA daemons and hence
running it per-session is much better then running it system-wide.

Inside RH we had a few disucssions how to handle multi-seat setups
with regards to audio best. Our conclusion was that audio cards should
be treated similar to mice and keyboards: i.e. each seat gets its own
pair of boxes (or a headphone) and they are not shared with anyone
else. OTOH I see how sharing a sound card would be handy. So in
the end we might end up with the optional solution of running a
tiny/dumbed-down pa system instance which sessions connect to. But
that's way down on my TODO list, and will always stay optional since
it is detrimental for latency.

Lennart

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