If we processed an entry from the queue successfully, we were removing
the entry itself from the queue but not freeing the memory allocated to
the entry.
When espeak_Cancel is called, change the value of user_data that is
passed to the events, and, in the callback, use this to test to see if
cancel was received. If the value of user_data has changed, discarde
events that have the old value. This patch is from Chris Brannon.
The user_data parameter is just a pointer that is passed into the
espeak_synth call that is passed back to the callback. In native mode,
we are not using it since there is not a callback. However, in alsa
mode, it will be used to indicate when a cancel was processed.
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.
