[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Session integration in Speech Dispatcher
From: |
Bill Cox |
Subject: |
Session integration in Speech Dispatcher |
Date: |
Thu, 15 Apr 2010 08:35:56 -0400 |
I'd like to point out what I feel is a major benefit of Luke's session
management. In Vinux, we run speakup for the consoles, with
speechd-up to talk to a system-wide speech-dispatcher daemon. Users
logged into Gnome have their own copy of speech-dispatcher running.
Now, when a user crashes speech-dispatcher in gnome (which still
happens fairly often), he can still use speakup on the consoles,
because the system-wide speech-dispatcher is still running. Without
this feature, I think we would be forced to use espeakup instead for
the consoles.
I understand PulseAudio prefers to generate all sound on a per-user
session, but we have several sources for speech coming from root
processes: speechd-up, espeakup, SBL, and possibly Juniper.
PulseAudio needs to address this issue, but until then, Luke is forced
to run speech-dispatcher as a user process, while in Vinux we are
forced to run PulseAudio in system-wide mode to enable speakup on the
consoles.
Bill
On Thu, Apr 15, 2010 at 8:02 AM, Luke Yelavich <themuso at ubuntu.com> wrote:
> On Tue, Apr 13, 2010 at 09:41:42PM EST, Hynek Hanke wrote:
>>
>> Hello,
>>
>> I'd like to ask a few questions about commit
>> ? 9f4bd2ef1f60d5b5be6885fa6a29c3e38e3f662a
>>
>> ``More tightly integrate the server into a user session
>> [...]
>> When the user logs in, the SPEECHD_PORT environment variable is set
>> to a unique port number, which is the base port set in intl/def.h, plus the
>> user's UID.''
>>
>> 1) How do we know that this port base+user_id, will be free to use
>> for a given
>> user_id? If not, what happens?
>
> We don't, however I couldn't think of anything better at the time to ensure
> each user's speech-dispatcher instance didn't clash. There may also be a way
> one could check whether that port is in use, however scraping the output of
> netstat probably wouldn't have been the best solution.
>
>> 2) How does this coexist with spd-conf? If not, should
>> --enable-session-integration
>> cause spd-conf not to be installed? Or should spd-conf be modified
>> and left only
>> for diagnosis, not settings?
>
> My thoughts were that if session integration was used, spdconf shouldn't be
> needed, since things would be configured already for the user to get going.
>
>> 3) I see the documentation is completely missing. This needs to be fixed
>> before release.
>
> Unfortunately I didn't get time to address documentation for these changes,
> so this is a fair call.
>
> Luke
>
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd
>