(2014-04-19, 22:26)eckythump Wrote: I have now acquired a github account and the wavserver (httpttsd) can be found there.
My repo is: https://github.com/sjhoran/httpttsd
I've cleaned it up a bit since I first shared it here.
ruuk: Feel free to add it to your downloads page.
Will do.
(2014-04-19, 22:26)eckythump Wrote: I'm still very new to git, so please also let me know if I've made any glaring omissions.
I've been using it for a year, and there's still a lot I don't know
But the basics aren't too bad. I just use everything else infrequently enough that I forget it by the time I need it again.
(2014-04-20, 05:26)eckythump Wrote: There seems to be a bug in the latest revisions. I haven't tried 0.0.39, but it's there in .40 and .41. I suspect it's related to your playsfx fix.
On my raspberry pi, running OpenELEC 3.95.5, I just get the same thing spoken over and over again, typically "Window: Home" as tht's the first thing said upon startup.
I can see that the wavserver is receiving requests for the correct things and sending them back, and I can even see that the wav files being created are right (I copied a couple and manually checked).
I changed to the espeak backend and the problem persisted. It did however switch to espeak first, but then repeated the first thing said with that engine.
Don't have the time right now to take an in depth look to see if I can spot what's going on with this. Hopefully you'll read this and it'll be immediately obvious.
Another interesting quirk is that after I changed to espeak and it kept repeating "addon information" as that's the first thing said after going "OK", I went back into configure and switched back to ttsd, went OK, and it started repeating "Window: Home" again, which suggests whatever caching oddness is going on is engine bound.
Well, it's not related to the fix, I think, so much as it's related to my detection of when to use the fix.
When using XBMC to output speech, the addon uses xbmc.playSFX() to play the wavs. playSFX() was designed just to load a few sound effects, and it caches the wav for quick playback. So the first problem with this for the addon was that if you play a wav with the same file name, it will just use the cached wav. To overcome this I created each wav with a different file name. This quickly led me to discover that the wav cache is never cleared (other than on a skin change) and so it basically just keeps filling memory. So what the fix does is add a useCached parameter to playSFX() that when set to False, will dump the cached wav and play the new one instead.
When using this fix, the same file name is used (otherwise you would still be adding cached wavs, not to mention this is more convenient). Now if you're using a version that doesn't have the fix and the addon thinks it does, it will use the same file name and you will get the behavior you described.
I'm not sure why it was speaking Window: home again after you changed the engine, but it's probably related to whatever I did wrong in detecting the presence of the fix.
I'll look at it and see what's wrong.
I just got my Raspberry Pi a couple of days ago and originally tested these versions with OpenELEC 3.95.6 and it worked fine.