When the Linux console is e.g. switched to a graphical VT, the kernel
emits \x01P to notify that it is not able to read the screen any more,
and the software synthesis can thus release the audio card, for other
screen readers to take over.
This implements it by adding a paused_espeak variable that tracks
whether we have suspended espeak. When more text comes, we can simply
reinitialize espeak.
This fixes#10.
One of the new string handling routines is a wrapper for allocating
memory. This commit changes the rest of the code to take advantage of
that wrapper.
The reason I went to autotools was the multiple sound systems, but since
we are now just using espeak's audio processing we can go back to a more
simple build system.
The two variables, stop_requested and runner_must_stop were performing
the same function, so I am using one variable, stop_requested for this
function.
Since there is no reason currently for the softsynth thread to do this,
it makes better sense to have the synth thread control all interaction
with espeak.
pthread_cond_wait() can have spurious wakeups, so we need to be sure
that the condition is actually true when we return from this function.
Thanks to Chris Brannon for the patch.
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 goal is to create threads for the reader, que runner/espeak
processing and signal handling.
As of this commit, this code is still being worked on, so it is broken.
Make espeakup a multi-threaded program. One thread reads from the softsynth
device, queuing text and synthesis commands. The other thread processes
items from the queue.
