[VIJO]

@@

[ruuk]

Well, it's not much better. But OpenElec is a really lightweight way to run XBMC, so that helps. The Pi also has more options for speech engines. I actually haven't done enough testing to compare though.

[VIJO]

@@

[ruuk]

Ill look into playing with the Pi myself at some point for the heck of it, It would be nice to be able to spend so little for a xbmc client. I really like how the windows version has turned out. So it would be a hard sell for me. Is it the purpose of the Http daemon and the wav server to offload the speech to another system or is it just for the purpose of using sapi voices?

The HTTP daemon is for both reasons. Currently one of the things I am doing is creating a speech server that uses the same code as the addon to either serve wavs from a host machine (like eckythump's but cross platform and in python) or play speech directly on the host machine.

On a side note, I kinda figured out couple things that weren't reading. Weather doesn't read at all except on confluence skin it will read the date selected and nothing else, On Quartz nothing. (I have it disabled for now, If you make any changes to it let me know and ill turn it back on.) On some repos pretty much the "Unofficial ones", when there is an Update sometimes what I am told looks like a webpage inside the xbmc skin pops up to explain the changes, This window doesn't even register on confluenc, On quartz I have yet to get it. Escape seems to get me out of it and then it doesn't pop up again until the next update.

Have you installed the keymap? Pressing F2 with the keymap installed will speak the non-focusable text on the window. At least for me, this works for weather in Confluence and Quartz and also for changelogs. This was added around about version 0.0.34 and I'd really like to hear where it is and isn't working well.

Do I understand that you are polling the JSON interface to provide what is read? If that is the case, Id wouldn't think it would be possible to read that. If I am wrong, Please slap some learnin on me.

I don't use the JSON interface. I use infolabels because I can get more text that way. I can only get the text from focusable controls whether I use infolabels or JSON.
To get other text, the addon either uses a map of info for standard windows or parses and processes the window xml file.

On an even more side note, I was wondering if there is any chance, Say with maybe 14 (Which I know is very long way off and still pretty much unplanned dev wise) that this functionally could be branched directly into the XBMC distro so that no one would need to worry about adding a repo to get it speaking. You know, someone install it, and on the first startup the just press F12, and voila, speech.

Well, the addon will eventually get into the official repository when it's ready. That can be done at any time, not just for new XBMC versions. As for having it included so that we can just start it with F12, I'm not sure how likely that is. We might get that in OpenElec. I sent a message to sraue describing a method of making that work, but I haven't heard back from him again.
The problem with adding into a default XBMC install is that then people believe that the XBMC team is somehow responsible for it's operation. They already have a hard enough time with that for other addons with people asking for support for an addon they have nothing to do with.

[VIJO]

@@

[ruuk]

For what it is worth, This is in Gotham Beta 4 using Quartz A.T.M., I went back to sapi direct because used less memory and for some reason I was getting glitching. Glitching was definitely coming from NVDA and not anything to do with XBMC.

I went back and re-installed the keymap to be sure. F2 does read the weather and time on home screen. However under addons-Weather, All I get is "Weather" "Refresh", Nothing else reads even with F2. Also another example, is in Settings-Sys Info, Nothing reads except selction, I.E. Summary, Storage, etc... None of the actual extra Info reads even with F2. Also, little info windows don't read, Like when a plugin fails.

I just tested it on windows. In seems that BeautifulSoup 4 (which I'm using to parse the window xml files) doesn't have a parser to use. I'll fix it

[ruuk]

Added a new version to my repository: 0.0.42.

Get it or the repository from the Downloads Page.

Changes:

• Change XML parsing to remove module and parser dependencies
  
• Remove bs4 import
  

---

Note: I rewrote a bunch of code for xml parsing, got it to work and now I'm going to bed. I did minimal testing, so I wouldn't be surprised if there are errors

---

Also I just realized that F3 will be broken for some items (ones that are parsed from xml) because I forgot to convert that bit of code. But I'll fix it tomorrow.
This version's changes should only cause any possible problems when pressing F2 or F3.

[VIJO]

@@

[eckythump]

ruuk:

I've tried playing with 0.0.41 again on OpenELEC 3.95.6, but I'm still getting a lot of xbmc crashes. The crashes aren't random, they always seem to happen when I navigate to the same places (such as system -> settings -> addons -> enabled -> services -> xbmc tts), so I've largely been fiddling with 3.95.5 until that's resolved.

I have a couple of thoughts/ideas relating to the PlaySFX caching behaviour.

I'm wondering if it wouldn't be better to always try and create unique filenames, even when it does appear that playsfx has usecache. This would solve the repeating issue on OpenELEC 3.95.5 and presumably other xbmc installs out there that people may be hesitant to upgrade if they're otherwise working fine.

Another thought is that instead of using time.time() to get unique filenames, perhaps you could import hashlib and use hashlib.md5(text).hexdigest() instead. I think the CPU overhead for the hashing would be negligible, and for installs that cache, you'd get unique filenames only for every unique wav, thus allowing the playsfx cache to be reused for all the repeated stuff like "Window: foo" and "Parent Directory", etc.

So they're my thoughts. What do you think?

Unrelated to the ideas above, I also have one useability thing worth mentioning. No idea if it's something you can do anything about, but figured it's worth bringing to your attention in case it is.

It's probably best if you try and witness this one first hand. Navigate to a file list that has several pages of items. Then press right once. Now you should be able to use up/down arrows to scroll entire pages instead of item-by-item. You'll notice that instead of just announcing the new position after scrolling, it announces it a couple of times for different positions i nthe scroll. On the pi, these announcements tend to overlap and be unintelligible. No idea if you get the same behaviour using page up/page down on a keyboard. I don't have those buttons on my remote control, so I can't test easily.

I'll try and set aside a little time later today to try out 0.0.42 on 3.95.6 and see if things are still flakey. I suspect the issue is OpenELEC/XBMC more than the addon. If I get the same crashes, I'll try and set PLAYSFX_HAS_USECACHE to False and see if it's specifically related to that.

Thanks again, and hope you're sleeping/slept well.

[eckythump]

Done a little more testing with 0.0.42 on OpenELEC 0.95.6..

The crashing specifically seems to occur with longer strings of text. It's happened with some shorter strings of text, but these were strings that when converted to speech still produced longer than average wav files (such as spelling out of acronyms).

I suspect .wav files over a certain size are making it crap out. I'm not seeing anything meaningful in the logfile, though. I'm quite confident that this is an OpenELEC/XBMC issue, not your addon. Aside from the crashes, though, the addon is working really well on 0.95.6 in terms of smoothness and being able to quickly navigate menus, etc.

Are you getting crashes with OpenELEC 0.95.6 on the raspberry pi?

[ruuk]

ruuk:
I have a couple of thoughts/ideas relating to the PlaySFX caching behaviour.

I'm wondering if it wouldn't be better to always try and create unique filenames, even when it does appear that playsfx has usecache. This would solve the repeating issue on OpenELEC 3.95.5 and presumably other xbmc installs out there that people may be hesitant to upgrade if they're otherwise working fine.

Unfortunately this won't work. The cached wav only get's cleared when you create a new one with the same filename.

Another thought is that instead of using time.time() to get unique filenames, perhaps you could import hashlib and use hashlib.md5(text).hexdigest() instead. I think the CPU overhead for the hashing would be negligible, and for installs that cache, you'd get unique filenames only for every unique wav, thus allowing the playsfx cache to be reused for all the repeated stuff like "Window: foo" and "Parent Directory", etc.

That's a smart idea except for the problem I just mentioned. What could be done is to use this principle to cache wavs on disk, so they would not have to be created again. I'm not sure this would give enough benefit for the effort though.

It's probably best if you try and witness this one first hand. Navigate to a file list that has several pages of items. Then press right once. Now you should be able to use up/down arrows to scroll entire pages instead of item-by-item. You'll notice that instead of just announcing the new position after scrolling, it announces it a couple of times for different positions i nthe scroll. On the pi, these announcements tend to overlap and be unintelligible. No idea if you get the same behaviour using page up/page down on a keyboard. I don't have those buttons on my remote control, so I can't test easily.

I haven't tried it on the Pi, but I don't imagine there will be a lot we can do about it. It's almost certainly a side effect of the Pi's slowness. I'll check it out when I get a chance. I don't have my Pi permanently set up anywhere yet partially because I need another HDMI cable. I thought I had an extra around somewhere, bit I guess I didn't

Done a little more testing with 0.0.42 on OpenELEC 0.95.6..

The crashing specifically seems to occur with longer strings of text. It's happened with some shorter strings of text, but these were strings that when converted to speech still produced longer than average wav files (such as spelling out of acronyms).

I would guess that has to do with memory usage. I might have to look at limiting the length of phrases, but if large words are causing problems, that may be harder to overcome. I imagine that different speech engines would cause this to different degrees depending on the bits/sample rate of the output. Of course, we only get eSpeak in openElec, but you can use others in RaspBMC for example.
I wonder if saving wavs to a tmpfs exacerbates this as it also using memory to store the wav.

I suspect .wav files over a certain size are making it crap out. I'm not seeing anything meaningful in the logfile, though. I'm quite confident that this is an OpenELEC/XBMC issue, not your addon. Aside from the crashes, though, the addon is working really well on 0.95.6 in terms of smoothness and being able to quickly navigate menus, etc.

Are you getting crashes with OpenELEC 0.95.6 on the raspberry pi?

I think I saw this issue when I first set up my Pi. I have and SD card with RaspBMC and one with OpenElec, and I don't know which one was doing it, but when I switched to the other it didn't and I forgot to follow up. I'm sure both have the issue, just one perhaps had more free memory for whatever reason, so in my limited testing it didn't occur. I'll do some more testing on my Pi soon and see if I can add anything to what you've found.
Thanks for taking the time to do some testing and for the keen observations though

[ruuk]

Added a new version to my repository: 0.0.43.

Get it or the repository from the Downloads Page.

Changes:

• Finish new xml parsing for F2 and F3
  
• Include comtypes and remove script.module.comtypes dependency
  
• Change F12 enable/disable method and removed script.library.xbmc.tts dependency
  

The addon now has no module dependencies, which means it can be installed with the single zip file.
Speaking on F2 and F3 should be working equally well or badly on all installations now.

[eckythump]

Another thought is that instead of using time.time() to get unique filenames, perhaps you could import hashlib and use hashlib.md5(text).hexdigest() instead. I think the CPU overhead for the hashing would be negligible, and for installs that cache, you'd get unique filenames only for every unique wav, thus allowing the playsfx cache to be reused for all the repeated stuff like "Window: foo" and "Parent Directory", etc.

That's a smart idea except for the problem I just mentioned. What could be done is to use this principle to cache wavs on disk, so they would not have to be created again. I'm not sure this would give enough benefit for the effort though.

I probably should've been a little clearer for that suggestion. I was thinking this might be worth doing for when PLAYSFX_HAS_USECACHE is False where we currently use time.time(). My thinking was that if you're on a system that's inevitably going to run out of memory because of the wav's being cached, using a hash will at least delay that a bit longer as it'll be able to make use of the cache occasionally for things it's said before.

The crashing specifically seems to occur with longer strings of text. It's happened with some shorter strings of text, but these were strings that when converted to speech still produced longer than average wav files (such as spelling out of acronyms).

I would guess that has to do with memory usage. I might have to look at limiting the length of phrases, but if large words are causing problems, that may be harder to overcome. I imagine that different speech engines would cause this to different degrees depending on the bits/sample rate of the output. Of course, we only get eSpeak in openElec, but you can use others in RaspBMC for example.
I wonder if saving wavs to a tmpfs exacerbates this as it also using memory to store the wav.

I don't think it is a memory issue, at least, not in the sense that it's running out. I have no issues at all on 0.95.5 with speech of any duration. It only seems to have started since the playsf usecache feature appeared in xbmc, and I suspect there's something weird going on there. Especially since it happens consistently on the same strings. I can go boot my pi now from being off, go System -> settings -> addons -> enabled addons -> services -> simple addon downloader somethingorother, and boom, it'll die, guaranteed, even though there's plenty of RAM left. I've also tested using non-tmpfs for writing the wavs and it happened then, too. I'll go and double check that right now...

Yep, dies regardless of tmpfs or not.

Hopefully OpenELEC 3.95.7 will appear soon. I'll be very interested to see how it goes. I really do think the issue is in XBMC, not the addon and I'd hate to see you spending time looking for bugs that aren't in your code. If I have time later, I'll see about reporting this as an OpenELEC bug.

[ruuk]

I probably should've been a little clearer for that suggestion. I was thinking this might be worth doing for when PLAYSFX_HAS_USECACHE is False where we currently use time.time(). My thinking was that if you're on a system that's inevitably going to run out of memory because of the wav's being cached, using a hash will at least delay that a bit longer as it'll be able to make use of the cache occasionally for things it's said before.

I'll go ahead and add that in, it's an easy change

I don't think it is a memory issue, at least, not in the sense that it's running out. I have no issues at all on 0.95.5 with speech of any duration. It only seems to have started since the playsf usecache feature appeared in xbmc, and I suspect there's something weird going on there. Especially since it happens consistently on the same strings. I can go boot my pi now from being off, go System -> settings -> addons -> enabled addons -> services -> simple addon downloader somethingorother, and boom, it'll die, guaranteed, even though there's plenty of RAM left. I've also tested using non-tmpfs for writing the wavs and it happened then, too. I'll go and double check that right now...

Yep, dies regardless of tmpfs or not.

Hopefully OpenELEC 3.95.7 will appear soon. I'll be very interested to see how it goes. I really do think the issue is in XBMC, not the addon and I'd hate to see you spending time looking for bugs that aren't in your code. If I have time later, I'll see about reporting this as an OpenELEC bug.

I guess we can wait and see if it goes away in the next version. If it's still there, I'll see if I can find any commits betwwen .5 and .6 that could possibly be affecting playSFX().
Did you happen do any testing that would make it clear that the issue is in fact with playSFX(). It just occurred to me that it could be something else in the code chain between getting the text and speaking it, especially since it has problems with specific texts. I think I'll do some testing - find a text it dies on, then comment out the playSFX() code and see if it still dies.

[ruuk]

Well, it was crashing when I was selecting a new video resolution (I tried several times). I commented out the playSFX() code, tried again and it didn't crash when I selected the resolution. Then when I backed out to the home screen, it crashed. After that it was fine and I could open the open the addon settings and everything. I uncommented the code and and restarted the addon and now when I go to open the addon it crashes.
So playSFX() definitely is the main problem. I don't know why it crashed when it went back to the home screen that first time, but if it's related, I imagine it is indirectly.