On 21.9.2010 03:37, Jason White wrote:
upstream Speech-Dispatcher is moving toward a model in which the daemon is run by the user rather than system-wide.
Yes, this is correct.
What I don't understand is how this model is supposed to accommodate scenarios such as the following. 1. BRLTTY (with speech support) loads early in the boot process. Speech-dispatcher either has to be run as root or as a non-root system user with access to the audio device, since nobody is logged in at that point.
BrlTTY currently only runs under root, so it will automatically autospawn an instance of Speech Dispatcher running under root. This is deprecated but functional. If you are using ALSA and have a multi channel soundcard or DMIX set up, it will speak. However, Pulse Audio will refuse to play sounds originating from the root user to ordinary users. And I think for very good reasons. I think BrlTTY needs to have a better notion of users and sessions and then it will interconnect well with Pulse Audio, DBUS and the other desktop technologies. Speech Dispatcher is just an intermediate who can't do much about it.
If the user later starts an X session then we don't want a second speech-dispatcher instance to be started, as this could then compete for the audio device with the global instance - exactly what Speech-Dispatcher is designed to prevent.
To prevent concurent speech, in the users session model, Speech Dispatcher will use ConsoleKit in the 0.8 release. This is not to say that only one will be active at a time. As many will be active as many active sessions there are (same computer, multiple seats etc.)
2. Same as above, but with Speakup as the assistive technology.
Same as BrlTTY.
3. Gdm log-in, possibly in combination with any of the above scenarios. Likewise for other X-based log-in tools that might become accessible at some point.
GDM runs in its own session, so there is no problem. Speech Dispatcher gets started, when GDM tries to use it.
4. Administrators who log in temporarily as root from a console session instead of using su or sudo. (No, I'm not one of those except in emergencies...)
Do you mean from a text console? Then you *are* root and you are in your own active session. Speech Dispatcher gets autostarted and works normally.
I think Debian should coordinate this upstream, but in the absence of a solution to the above issues I think running it as a system-wide daemon is the only reasonable default, prefearbly as a non-root system user with suitable permissions.
With regards to current pragmatic solutions: 1) Using ALSA, user-session Speech Dispatcher can output sound even from inactive sessions, so all the scenarios work. 2) Pulse already enforces the session privacy policy, and this already is in the distributions, so decisions made in Speech Dispatcher development won't influence it. It is not important whether it runs as a user or system services. If the session is inactive, it's inactive and we won't get any sound from Pulse Audio. There is no magic way that would instantly resolve all troubles, just the Speech Dispatcher developers didn't take it for some strange reason. We have fixed many things in the 0.7.1 release and the only remaining major thing required is using ConsoleKit (if available) for determination of the current activity of the user session. This has been forced upon us by some decisions made in Pulse Audio, our main audio output system. I think these are correct decisions, just they were deployed a little bit too early. We are very happy that, only recently, the development of Speech Dispatcher was speeded up significantly by cooperation between various developers. We very much welcome any contributors and/or individual patches. Work is also needed in BrlTTY and Speakup. Best regards, Hynek Hanke -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
