Closed tholu closed 9 years ago
If you append the apikey to your URL, I don't see why voicerss would complain. With that said, you should perhaps consider downloading the mp3 locally, and serve it from the same machine that you run your code with. This has a few advantages:
You can keep the mp3 file for a certain phrase so you don't need to hit voicerss, and it will be served faster on subsequent requests.
You will have full control of the actual request invoked to the TTS api, for setting custom user-agent, header based authentication etc. This gives you some more flexibility
There is no way to control how Sonos will request the mp3 file, and you will be limited to the support they provide. One reason why this might not work for you, is that Sonos will look at the url, or namely the "suffix" of the url to make out what kind of encoding it has. If the url doesn't end in ".mp3", it will not treat it as such. You can mitigate that by locally storing it, or if you proxy the request and spoof a "correct" url.
What I have been doing is calculating a SHA1 hash of the phrase, then fetch and store it with that hash as filename. Then I serve it from a static web server (I usually use "node-static" npm module for it, but express would give the same functionality).
Thanks for your detailled answer! voicerss does not complain, but Sonos just doesn't play it. Maybe it's the .mp3 ending. I will try to locally store and serve it again with .mp3 at the end. Do you have the code you use at Github somewhere?
And it worked perfectly fine. Thanks!
I'm having troubles to play MP3 URLs from TTS APIs like the Google Translate API (blocks requests with wrong useragent) or from http://www.voicerss.org/api/ (needs free registration for API key).
I use it like that:
It just doesn't play. Any ideas for further debugging? See also https://github.com/mattwelch/sonosifttt/blob/master/sonosifttt.js (I'm building based on this code)