When I use espeak to make navit speak, (using:
<speech type="cmdline" data="espeak -s 150 -v german '%s'" />
the GTK-GUI won't redraw until the espeak-process has finished and returns. As a workaround for the freezing one can use
<speech type="cmdline" data="espeak -s 150 -v german '%s' &" />
so the system()-call made by navit returns immediatelly. The downside, however, is that we might spawn two instances of espeak too close and the one called later can't use the soundcard (/dev/dsp in this case), since the instance spawned before hasn't yet finished. This way we can't guarantee that every sentence is really spoken and we *might* miss some important information for the driver. This blocking doesn't happen often but it happens.
This could be fixed by somehow calling espeak blocking but in another thread so that the GUI is not affected by this and using some kind of queue if there is new text to be spoken but the command before hasn't finished yet. In that case it must be avoided that the queue gets tooo large so that outputs aren't delayed tooo much.
