Re: Activation of Speech Dispatcher under squeeze
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
Reply to: