speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with "end" callback in Python


From: Hynek Hanke
Subject: Problems with "end" callback in Python
Date: Mon, 14 Apr 2008 14:33:41 +0200

> The code is attached.  This is not an OLPC Activity but a standalone 
> program I use to try out new features 
Hello James,

I have tried to run the code you've sent and I can reliably reproduce 
the issue. I believe it has something to do with the way how you call 
speechd.client.speak() from inside the gtk loop, because outside of it, 
everything works normally (even in your application).

I'm not familiar with PyGTK however, so I don't see what exactly is 
going wrong. I'll try to describe my findings in hope you or someone 
else will have someidea.

As you describe, in your program, the SSIP Python interface often fails 
to deliver a callback to the client application (in fact, it freezes and 
no other communication with Speech Dispatcher is possible). The exact 
reason is that in  self._socket.recv(1024) (socket.socket.recv()) fails 
to return although the logs of Speech Dispatcher prove some new data 
have been written to the socket.

I found that this happens when cb_next_word is
called as a callback from keypress_cb() via
  timeout_id = gobject.timeout_add(100, self.next_word_cb)
but it doesn't happen, if I call it directly (around line 75):

   self.karaoke = True
                self.finished_flag = True
                #timeout_id = gobject.timeout_add(100, 
self.next_word_cb)                                               
                while True:
                    self.next_word_cb()
                    time.sleep(0.1);
            return True

This variant will reliably speak the whole document word-by-word with 
all the expected callbacks received.

Another interesting observation is that the mentioned _socket.recv(1024) 
returns and correctly receives all the pending callbacks just after I 
hit CTRL-C on the python interpreter running ReadETextsActivity.py and 
thus kill the main program thread.

Now, the _socket.recv() function in the python speechd library runs in a 
separate thread that is being launched from the Client object 
constructor. So apparently gobject.timeout_add() somehow disturbs socket 
opperations in other threads.

It seems really strange to me and quite unlikely that the python 
bindings themselves would be responsible.

With regards,
Hynek Hanke










reply via email to

[Prev in Thread] Current Thread [Next in Thread]