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
