[pulseaudio-discuss] System-wide daemon howto/best practices
lennart at poettering.net
Mon Sep 3 12:36:23 PDT 2007
On Wed, 29.08.07 20:38, Jan Kasprzak (kas at fi.muni.cz) wrote:
> 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
> 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
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
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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss