Re: Multiple Emacspeak sessions

[Tim Cross <tcross@xxxxxxxxxxx>]

I tend to agree with Raman. There are some not so obvious issues which
would need to be considered - once you have multiple threads you would
have to consider issues such as making sure all threads got equal
opportunities to access the speech device and none get locked
out. This is even further complicated by the temporal and context
restraints on speech. The spoken feedback would become very difficult
to following if it constantly alternated between different contexts
(buffers, programs etc) and if parts of the speech are broken up into
smaller parts to give fairer access for different threads, blocks of
speech could become so seperated temporally that they would become
difficult to follow etc. 

Tim
T. V. Raman writes:

> Starting a single server that serves all emacspeak instances
> is no different conceptually 
> than having one speech server per session because in the
> former case, the single server instance would have to spawn
> threads one per connecting session.
> The problem is not so much the speech server buffering the
> input  --it already does this--
> the problem is that the first thing Emacspeak needs to do
> whenever it sends out speech is to first flush previously
> ongoing speech. This is *absolutely* necessary to keep the
> system responsive, and I do not see a way around it.
> 
> Even if the server checked to see if "someone else was
> talking"
> before flushing ongoing speech, the moment you implemented a
> solution like that there would be an immediate need to make
> the server "intelligent" about deciding whom to interrupt
> and whom not to interrupt --all in all it's just a long
> slippery slope that leads nowhere.
> 

-----------------------------------------------------------------------------
       To unsubscribe or change your address send mail to
"emacspeak-request@xxxxxxxxxxx" with a subject of "unsubscribe" or "help"