Speech Dispatcher roadmap discussion.

[Luke Yelavich]

On Thu, Oct 16, 2014 at 09:17:23AM EDT, Bohdan R. Rau wrote:
> As speech-dispatcher would be used to retrieve speech waveforms for
> different purposes - it may interfere with normal sessions. Fetching (or
> storing) data must be uninterruptable by others (so commands like CANCEL ALL
> won't cancel generating data for fetch). In other side - long part of text
> sent to speech-dispatcher may cause long lags in applications like
> screenreader or speech notification - synthesizer may be slow, and
> synthesizing 10 minutes of speach may lock these synthesizers (like Ivona)
> for minute.

You make valid points here, however I think spinning up a new instance of 
Speech Dispatcher for dealing with sending audio directly back to clients is 
overkill. I have actually been wondering whether it would be worthwhile 
re-architecting Speech Dispatcher such that every client that connects to the 
server gets its own synth module instances loaded, along with a totally 
separate set of threads in the server to manage each client. At the moment, we 
have a single thread that manages speaking operations, which has to manage 
priority queues, as well as pending messages from multiple clients.

> By the way - there should be possible to quit speech-dispatcher
> automatically when client closes connection. For example: if I have speech
> enabled in login manager - after succeful login Orca quits, but
> speech-dispatcher still seats on socket, consumes memory and waits for
> system shutdown. I see no reason to miss a kilobyte of memory for the
> program I do not use.

I already have a solution for this in the works along with the move to using a 
GLib main loop, at least in the main thread of the server. It takes the form of 
a timeout, where when the last client disconnects, a timeout is initiated, and 
once that timeout is reached, the server shuts itself down. The timeout is 
configurable in seconds to whatever you desire. At the moment a value of 0 
disables the timer, but we could also do more with that, and allow a value of 
-1for an immediate shutdown of the server when the last client disconnects.

I'll comment on the rest of that mail and your other emails re protocol when I 
have more time to more closely look at them and better understand your proposal.

Thanks for your input.

Luke