[pulseaudio-discuss] Proper PulseAudio use on accessible computers?

[Lennart Poettering]

On Wed, 21.11.07 13:05, Milan Zamazal (pdm at brailcom.org) wrote:

> What's the proper way to implement such environment?  Using a system
> wide daemon may not be the best idea.  But if the PulseAudio doesn't run
> globally, should it run as several different instances?  For instance:
> 
> - A PulseAudio server started from gdm setup scripts.
> 
> - A PulseAudio server started by the blind user's session.  What to do
>   with Speech Dispatcher output?  Should the gdm PulseAudio server
>   continue running and redirect the Speech Dispatcher output to the
>   user's server?  Or should Speech Dispatcher reconnect to the new
>   server once the gdm server disappears?
> 
> - A PulseAudio server started by the sighted user's session.  This is
>   probably a standard situation handled by suspending the previous
>   PulseAudio server and activating new PulseAudio server.
> 
> - How about Speech Dispatcher output from Linux text consoles before gdm
>   starts?  Should another PulseAudio server be run for the purpose??

On Fedora, our current plan is to start PA and other user daemons
(such as nm-applet) inside of the gdm pseudo-session. Each active
session has a PA daemon of its own, and gdm too, and everytime you
switch the session/gdm-screen a different becomes active and all
others give up access to the devices. We think that audio devices are
better not shared between sessions, a lot similar to other
input/output devices, like keyboards, mice and screens.

Audio on the raw console hasn't really been a priority for me. I do
acknowledge though that it should be a priority to make a11y work. 

When thinking of text consoles the problem arises that the same user
might be logged in on multiple consoles. (In contrast to X11 where
normmaly people don't start more than one X server for the same user)
PA is actually a per-*user* daemon which is right now started
per-*session*. I.e. if you have multiple sessions of the same user
only the first login will be able to start PA successfuly.

I guess the optimal solution would be be able to "refcount" the PA
daemon and combining that with autospawning on the console. I.e. some
logic that makes sure that PA is around as long as at least one X11
session for the user is around or one program on the text console is
using it. Then, we should globally enable autospawning. And if no X11
session for the user is active anymore and no program on any of the
text consoles uses it anymore then it is freed after some timeout.

I added this now to my TODO list. I can't make any promises though --
the list is already huge.

What exactly does this Speex Dispatcher do? From what you wrote above,
I got the impression that you do require the ability to continue
streaming while the foreground VT is changed from the gdm one to the
newly created session? That of course would be a big problem, since
the per-user PA daemons generally do not communicate with each other
for security reasons. Playing uninterrupted sounds when the active
session changes is simply not possible right now. However, I already
spent a bit of time thinking about it since eventually we might want
to add some "woosh" sound effect like MacOS X, when the session is
switched. But that's not really on my todo list right now.

Lennart

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