GoogleTTS responding with 503 error (even after the URL fix)

Hallo Ben,

no problem, thanks for your work!

Hi all,

also looking forward to be able to configure the TTS URL in the binding … I’ve also looked into alternatives to be less dependent on 3rd party services like google TTS (or any other). Also did some of the users mention they do not like to transmit data to the web for text to speech.

After some experiments with scripts I ended up writing a small M$-Windows REST service that can generate an mp3 from an Url (Prototape available here: https://dl.dropboxusercontent.com/u/1781347/RESTTTS.zip).

It’s in an early stage and only works on windows …

Once we can configure the URL in the binding I’ll give it a test with the squeezebox action - currently I only experimented with the browser (http://127.0.0.1:8089/Service/TTS?text=).

with kind regards,
Patrik

Thanks for this work Ben.
I agree it would be nice to move away from cloud services that may change or stop.
FYI the asterisk and and anki crowd implemented some new changes to their googletts calls that seem to work (for the moment).
(https://github.com/zaf/asterisk-googletts/blob/master/googletts.agi)
(https://github.com/AwesomeTTS/AwesomeTTS/blob/develop/addon/awesometts/service/google.py)

voicerss seems to be gone…

as an alternative, i managed to install picotts locally using this instructions.

http://blog.robotnet.de/2014/03/25/speak-friend-and-enter-speech-synthesis-with-espeak-and-svox-pico-for-the-raspberry-pi/

seems ok.

@Nicola_Reina This looks pretty interesting. to my mind having a local TTS engine seems like a good idea.

Do you have any details of how you handled the integration with Openhab. i.e. did you somehow configure it to read urls and return a wav like the google TTS service, or did you do it some other way.

BTW I Stumbled across some info about installing on Jessie and that these packages are now available:

https://packages.debian.org/jessie/all/libttspico-data/download
https://packages.debian.org/jessie/armhf/libttspico0/download
https://packages.debian.org/jessie/armhf/libttspico-utils/download

if you add the following to your sources.list:
deb http://ftp.de.debian.org/debian jessie main non-free

you can apt-get them, seems to work ok.

I completely agree - a local TTS service makes a lot more sense. VoiceRSS is working ok in my test setup (sorry it is a very busy time of year I haven’t had a chance to code it up properly yet) but the delay is noticeable, especially when announcing long sentences that have to handled in two requests (VoiceRSS only allows up to 100 chars per request).

I am going to look into a ttspico and see if I can get that working. Would love to be free of these online services!

Hi I installed it locally using the instructions at the link .
I have not yet integrated it but in the end it could just be a matter of using exec binding…
I mean you do not have to have any wav file you just pass the sentence to speak to the command and… it speaks

Hey guys,

I spent some time today playing around with pico2wave and building a simple PHP script to replicate what the Google TTS service does. Had some reasonable success, instructions below.

You should be able to run this on a local server (using apache or the like) and then point your Google TTS binding to this URL. It expects two parameters in the URL - language (e.g. en-GB) and message to translate.

Installation

  • install the necessary dependencies (pico2wave, lame)
    • sudo apt-get install libttspico0 libttspico-utils libttspico-dev libttspico-data lame
  • install PHP composer (needed to install/use phplame)
  • copy the two files attached here to a folder under /var/www
    • e.g. /var/www/tts
    • ensure your web server has sufficient permissions to create files in this directory (e.g. owned by www-data)
  • run composer to resolve the necessary dependencies
    • sudo composer install
  • setup your web server to allow requests to /var/www/tts
    • beyond the scope of these instructions
  • test by typing in the following to your browser;

I am using this in my hacked Squeezebox speak action (which I have hardcoded to call this URL) and it is nice and quick and the GB voice is quite fluid and sounds really good IMO.

Let me know if this helps!
Ben

tts.pdf (810 Bytes)

This file is actually a ZIP, so rename the extension to .zip and extract the two files to your /var/www/tts folder.

I’ve been playing with this as well over the last few days. I’m quite happy with the pico2wave results. I did this with a rule instead which I’ll share for those interested. Again pico2wave and lame need to be installed. First a lambda expression to replace squeezeboxSpeak

val org.eclipse.xtext.xbase.lib.Functions$Function3 squeezeSay = [
    String playerID,
    String message,
    int volume |
            executeCommandLine("pico2wave@@--wave=/tmp/openhab.wav@@"+message)
            Thread::sleep(500)
            executeCommandLine("lame@@-V2@@/tmp/openhab.wav@@/tmp/openhab.mp3")
            Thread::sleep(500)
            squeezeboxPlayUrl(playerID,"/tmp/openhab.mp3",volume) ]

then just replace squeezeboxSpeak with squeezeSay.apply ie:

squeezeSay.apply("mainPlayer","My Message",20)

Make sure the directory you use (in my case /tmp) can be reached by both openhab and the logitech media server. If openhab is running on a faster computer, you may be able to decrease the sleep times. The only downside is that squeezeboxPlayUrl does not have a resume function.

I have just create a pull request with some changes to the Squeezebox io and action bundles to allow TTS URL configuraton. Note that I have removed the language config option as this is just a parameter in the TTS URL. The URL just needs a single %s parameter which is substituted with the text to be translated. I have also updated the openhab_default.cfg with details about the new configuration options.

1 Like

Using these updated Squeezebox io and action bundles, along with my tts.php script from above, I now have entirely local TTS notifications with no reliance on any cloud services.

Ben, how is the lag time doing it locally? Do you have the tts on the same box as openhab or another local network box?

The delay is barley noticeable using my local TTS service, my notifications are almost instant now. I am running the TTS service on a different VZ container than the openHAB container (but on the same physical host).

FYI - my changes to the Squeezebox action have been merged so if you grab the latest SNAPSHOT build you can test these changes out (you will need both the io.squeezserver and action.squeezebox bundles).

Added a page to the WIKI with these details;

3 Likes

What changes are needed to make openHAB use the new TTS provider for rules and such? I have the setup working as you describe. I can test TTS with success in my browser passing the URL example you have given, but when I define my Google TTS url within openhab.cfg, it doesn’t seem to work. I do get audio, but it seems to be only the last file or test I used via the browser test example and not the actual strings being passed by openhab. For example, I have a test rule to fire every 2 mins and announce the time. when it runs now, it repeats “hello” as used in the test string: http://172.16.0.51/tts/tts.php?lng=en-GB&msg=Hello.

I can see the following in the logs when I intentionally make it throw an error:

2015-12-29 16:12:00.057 [WARN ] [.i.m.i.tts.TTSServiceGoogleTTS] - Error while connecting to Google translate service
java.io.FileNotFoundException: http://172.16.0.51/tts/tts.php?lng=en-GB&msg=en

This shows me it’s only passing “en” to the server and not the actual string.

Any thoughts or insight would be awesome! Thanks!

The Google TTS service substitutes two parameters into the URL - the first is the language (defaults to ‘en’) and the second is the text to be spoken.

So you will probably need to update your TTS URL to;

http://172.16.0.51/tts/tts.php?lng=%s&msg=%s

And then specify your Google TTS language as en-GB.

That did the trick! I thought I had tried it specified like that, but maybe not. In any case, it’s working like a charm. Many thanks!

I’m really pleased with the new local TTS solution Ben has described. It’s running quite well for the last four days. Thanks!

1 Like