Hi,

Thanks for all your replies, its great to know I am not suffering this issue alone.

I have actually gotten around the issue, and improved our IVR response times by taking inspiration from mod_tts_commandline and writing a LUA script that can be activated as a phrase.

It checks to see if the supplied text to speak is available as a cached wav file, and if not uses the cepstral swift command line to generate a new wav file in using an md5 hash of the text to speak.

This solves both problems, namely the issue with mod_cepstral and the concurrency problems, and the response times of using any TTS engine to generate sounds.

As long as most of your sounds are common amongst users (which ours are) then this simple LUA script ensures that the output is cached for future user.

Let me know if you would like to see the script.

Cheers
Tom

On 01/-10/-28163 08:59 PM, Brian West wrote:

You'll have the same problem you'll just move the location of the problem outside of FreeSWITCH! :P

/b

On Nov 6, 2011, at 7:18 PM, Patrick Lists wrote:

On 11/06/2011 05:24 PM, Anthony Minessale wrote:

It only works with v4 the rest have deadlocks in the cepstral itself....

Thanks Anthony.

Tom: I'm not very familiar with Cepstral but perhaps you could use
UniMRCP between FreeSWITCH and Cepstral?

More info at http://www.unimrcp.org/

Regards,
Patrick