The only time queue_process_entry should lock the queue gard is when it
is removing the item from the queue. This happens only when the item
was successfully processed.
1. Don't lock or unlock queue_guard during queue_clear.
It is locked when queue_clear is called, and it should remain so.
2. Protect runner_must_stop with queue_guard in
the request_espeak_stop function.
The following condition should always hold: queue_guard is locked while
testing or modifying runner_must_stop.
3. Rename stop_guard to acknowledge_guard. This is a more
descriptive name. This mutex simply protects the acknowledgement of
the stop request from being lost.
4. Remove the pthread_mutex_lock from the top of queue_process_entry,
because queue_guard is already locked when the function is called.
The stop_speech function needs to test the return code from
espeak_Cancel() to be sure the operation was successful before
signaling the callback to stop the audio.
This commit removes the synthcallback function since it wasn't doing
anything. Also, it has been reported that this may be causing the
sluggishness when espeakup is asked to shut up.
Thanks to Chris Brannon for finding this.
I have added queueing support so that when we read from the softsynth we
can put the text and commands we have read into a queue. This will
allow us to retry calling espeak_synth() if we fill espeak's internal
buffer.
