Opened 15 years ago

Closed 14 years ago

#52 closed defect/bug (worksforme)

GTK-GUI freezes while commandline-speech is "working"

Reported by: kripton Owned by: KaZeR
Priority: minor Milestone: version 0.2.0
Component: core Version: 0.0.3
Severity: Keywords: gtk gui freeze speech


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' &amp;" />

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.

Change History (3)

comment:1 Changed 15 years ago by KaZeR

Currently, there is no multithreading at all in navit. This has to be discussed.

comment:2 Changed 14 years ago by KaZeR

  • Milestone set to version 0.2.0
  • Owner changed from somebody to KaZeR
  • Status changed from new to assigned

comment:3 Changed 14 years ago by KaZeR

  • Resolution set to worksforme
  • Status changed from assigned to closed

Annoucements have been modified. Let us know if it's better now. There still is no multithreading, but that's currently on purpose.

Note: See TracTickets for help on using tickets.