Continuing a PENDING TTS request

42 views
Skip to first unread message

David Wiz

unread,
Mar 5, 2014, 10:23:50 AM3/5/14
to uni...@googlegroups.com
Hello, hopefully I can explain this well enough,
so I have a TTS engine, I wrote a simple plugin around it and a simple client for testing it.
My client opens a session and channel, sends the SPEAK request, gets response, starts streaming audio, all fine. On the server side, the request goes through channel_speak(), responds with an IN-PROGRESS message, and the server starts calling my read_frame() function. While that's playing I send a second SPEAK request, get a PENDING response, still all as expected.
The first request finishes, a COMPLETE response is sent, and the second request starts getting handled by the channel_speak() function. Unfortunately, at this point, nothing is calling the read_frame() function. My client gets the empty marker indicating IN-PROGRESS and sits waiting for data that never comes. While waiting for data, if I then send a third request, my second request suddenly starts playing while this third request goes into PENDING; when the second request COMPLETEs, the third goes through the channel_speak() function and once again halts up, waiting for the read_frame() calls that never come.

Without looking at the code (it's kind of long and currently under NDA but I can probably tease out a minimal example in the next couple days if needed) does anything strike anyone as being wrong? Did I miss a step? Is the client supposed to respond with something when it receives the COMPLETE or second IN-PROGRESS responses? Is the plugin supposed to do something other than respond IN-PROGRESS and return TRUE at the end of the channel_speak() function?
Is there anything I can do to try and narrow down the problem a little?
Thank you very much for taking the time to read my problem.

Arsen Chaloyan

unread,
Mar 6, 2014, 5:42:15 PM3/6/14
to UniMRCP
Hello David,

Your explanation of the problem is very clear but doesn't match my expectation, perhaps yours too.

I'd start with the fact that your read_frame() function is supposed to be called periodically as long as the RTP session is active irrespective of any MRCP requests being pending, complete or in-progress. If you insist that the callback is not called, then I guess the client may have sent a re-INVITE and disabled the RTP stream in the meantime, which is not so likely. I don't see any other reason so far.

BTW, I tried the same and sent two SPEAK requests from the client to the server using the demo synthesizer plugin and got the expected results in a timely manner. Make a network capture and see where the problem is in your case.



--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

David Wiz

unread,
Mar 7, 2014, 12:56:04 PM3/7/14
to uni...@googlegroups.com
Hello,
that's actually very helpful.  Previously my client, upon receiving COMPLETE message, would destroy the channel and session so subsequent requests needed to reopen everything.  I changed that to just eat the message and reuse the same session/channel over and over.
After receiving a COMPLETE message (even without another pending SPEAK request) it is not explicitly doing anything to the connection but the server does stop calling my read() callback (which I'd written to send zeroed buffers when there's nothing left to synthesize) and my client doesn't complain that there's no more data so I have to wonder if maybe there's something implicit happening in the client library (or perhaps elsewhere in my client code) that is causing problems.  I will investigate this, if I understand correctly it sounds like a problem with my test client rather than the server or plugin.
Thank you!
Reply all
Reply to author
Forward
0 new messages