• 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 30
Xbmc not working for blind users.
#91
(2014-03-11, 19:21)pvagner Wrote: I haven't moved further however I prefer comtypes over pywin32.
I tried comtypes and it worked great. Thanks for pointing me in that direction. I think I'll put it together as a module addon and throw it on my repository, and then use it instead running a subprocess.
(2014-03-11, 19:21)pvagner Wrote: Anyway I have got some packaging issues here to consider:
- What about 3rd party python modules such as comtypes? Should we create seperate XBMC addons for them or should we bundle into this addon?
The same goes for speech dispatcher for linux. Speech-dispatcher has python bindings which communicate with the speech-dispatcher daemon using sockets. I have packaged this as a seperate addon.
I think libraries that will be generally useful for addons should be put into module addons, and those that are really only going to be used for the addon in question should just be bundled in. So I would think that speech-dispatcher could just be included in the addon, especially since it looks like it's just a single file module.
Of course, the XMBC team might have a different opinion, I'm not sure. As for comtypes, I am leaning towards making it into a module addon, though it could go either way since it is windows only and not necessarily something that will be broadly used (of course I've done very little windows specific python coding so I'm just guessing here).
#92
Just in testing I've got SAPI working using comtypes and properly interrupting speech with the sleep value lowered to 100. Seems to work pretty well. I'll probably put this into the actual code tomorrow.
#93
Added a new version to my repository: 0.0.9

Repo

I could of sworn I posted twice since my last post. Perhaps I never actually submitted them Smile

I added a comtypes addon module to my repository.
This new version implements SAPI using comtypes with interrupted speech and the interval lowered to 100ms. It seems to work pretty well.

I spent 6 hours yesterday trying to use the Flite library directly via ctypes, and it finally worked great in the python console. Put the code into the addon and it crashes XBMC Angry
At least I learned a lot about using ctypes Smile

Anyway, I instead added a threaded tts backend base class and implemented Flite using that and subprocesses to achieve interruptible speech. Seems to work well so far.

I think next I'll do some testing with my OSX virtual machine to get something working there. Flite may work there already.
Then I'll take a break on the backends and work on speaking more text.

Added a new version to my repository: 0.0.13

Repo

Actually meant to post that last post this morning, but I keep forgetting to click post reply or something Smile

This version adds a backend using the OSX say command. I would love someone with an actual OSX system to test it because the sound on my virtual machine is awful. I can tell it works, but not how well.
Also added a backend using espeak via ctypes.

I just noticed that changing to a different backend from eSpeak and then back to eSpeak crashes XBMC. I'll have to see what's up, but it works otherwise.
#94
Avesome. I am sorry I haven't finished my stuff yet. Hopefully during the weekend I will be able to test the new things and complete what I am about to submit.
I only have linux and windows so mac testing is waiting for someone else.
Also I can remember you were wondering about ATV2. I know nothing about development for IOS, but IOS 7 has This TTS API. Perhaps there is a way on how to use it from XBMC.
#95
(2014-03-14, 19:09)pvagner Wrote: Avesome. I am sorry I haven't finished my stuff yet. Hopefully during the weekend I will be able to test the new things and complete what I am about to submit.
Hey, we each do what we can. I've had a lot of time lately and the challenge and learning has also been keeping my interest.
(2014-03-14, 19:09)pvagner Wrote: Also I can remember you were wondering about ATV2. I know nothing about development for IOS, but IOS 7 has This TTS API. Perhaps there is a way on how to use it from XBMC.
Yeah, the tricky part will be accessing that API. It might be the only way though, because you can't seem to run subprocesses from xbmc on ATV2 for some reason. I also don't think the sound output is accessible from other programs. I can get Flite running (from ssh), but it doesn't output sound. If I could get subprocesses working, I could output the speech to a wav and play that in via xbmc.playSFX() which isn't a great situation either. So via the API would be best if we can do it Smile
#96
Okay send at least my Windows TTS related tweaks as a pull request because now I had to manually merge it for the second time. This is well tested here and I have found no crashes so far.
#97
This was the first time I've merged a pull request. I think I managed to pull it off Smile
#98
Added a new version to my repository: 0.0.14

Repo

Localize window names via XBMC strings
Localize quartz control table labels via XBMC strings
Removed 'Enable' setting to use XBMC enable/disable button instead
Added pausing to threaded backend base
Some tweaks to Flite to prevent crashing XBMC
Fixes for proper interruption when changing button controls
Now falls back to System.CurrentControl when getting control label, which works with settings items

pvagner - Merged:

Added NVDATTSBackend. This only works on windows. NVDA has to be running.
NVDA controller client library needs to be copied into the lib folder.
SAPITTSBackend: convert text to unicode before sending for TTS. Fixes issues speaking non ascii characters.
#99
Added a new version to my repository: 0.0.15

Repo

This version fixes new windows not interrupting the speech.

I restructured the backends, the tts.py file was getting unweildy. Each backend is in its own file in a new backends directory, and the rest of the code is in the __init__.py.
For now I included a copy of nvdaControllerClient32.dll, otherwise you have to copy it over on every time you install a new version from from a repository.
By the way do you know if some platforms will need the 64bit version? I included that as well, but if you're sure we won't need it I'll remove it.
In the future I could host the dll file on my web server, and have it downloadable from within the addon. I believe the official repo doesn't accept addons with binary files.
Added a new version to my repository: 0.0.16

Repo

Now speaks titles of dialogs
Now speaks text in OK and YES/NO dialogs
Wow, sounds like things are really taking off in this thread! Most of it sounds above my head, but it sounds like a lot more is possible than we might have thought at the start of the thread.
(2014-03-15, 00:32)ruuk Wrote: For now I included a copy of nvdaControllerClient32.dll, otherwise you have to copy it over on every time you install a new version from from a repository.
By the way do you know if some platforms will need the 64bit version? I included that as well, but if you're sure we won't need it I'll remove it.

I am sure we don't need that at least for the time being. NVDA is 32 bit process and will most likelly remain so because otherwise we would have to ship different version of NVDA for 32 bit and 64 bit architectures then.
XBMC uses 32 bit version of python as far I can tell. We might need a 64 bit of NVDA controller client if we were running 64 bit version of XBMC and also we would have to add condition to our TTS class to detect that fact and load 64 bit version of library instead. So until there is no mention of 64 bit NVDA controller client library in the code we don't need to ship it as a part of the addon.
A little localization related issue.
While directly assigning string to a variable in the code e.g.
Code:
stringvar="value"
It obviously becomes a string. By default ascii codec is used while automatically transcoding strings into / from unicode. Up to now we were doing no extra handling of this just yesterday I added some UTF8 decoding inside the NVDATTS and SapiTTS backends. For the TTS backends relying on subprocess UTF8 encoding is a sane default because most likelly system locale is set to UTF8 in most systems by default. Having said this I don't know if subprocess module does something to strings or unicodes.
However as you have recently added calls to xbmc.getLocalizedString() things started to become a bit complicated. xbmc.getLocalizedString() returns unicode string. So in order to be compatible with the rest the quick fix is to encode it from unicode to UTF8 otherwise we will get UNICODEDECODEERROR while trying to format it for speaking here
Code:
self.sayText('Window: {0}'.format(name),interrupt=True)
I don't know where exactly is the difference yet. Either this is a result of our formatting text or other text processing or while using info labels we are getting utf8 encoded strings instead of unicode.
I think the proper solution is to use unicodes internally and transcode where needed because currently with what I have proposed as a quick fix we are transcoding two times with some TTS backends.
After I'll test festival TTS backend and implement speech-dispatcher on linux I can work on this if you agree.

Greetings

Peter
(2014-03-15, 11:26)pvagner Wrote: A little localization related issue.
While directly assigning string to a variable in the code e.g.
Code:
stringvar="value"
It obviously becomes a string. By default ascii codec is used while automatically transcoding strings into / from unicode. Up to now we were doing no extra handling of this just yesterday I added some UTF8 decoding inside the NVDATTS and SapiTTS backends. For the TTS backends relying on subprocess UTF8 encoding is a sane default because most likelly system locale is set to UTF8 in most systems by default. Having said this I don't know if subprocess module does something to strings or unicodes.
However as you have recently added calls to xbmc.getLocalizedString() things started to become a bit complicated. xbmc.getLocalizedString() returns unicode string. So in order to be compatible with the rest the quick fix is to encode it from unicode to UTF8 otherwise we will get UNICODEDECODEERROR while trying to format it for speaking here
Code:
self.sayText('Window: {0}'.format(name),interrupt=True)
I don't know where exactly is the difference yet. Either this is a result of our formatting text or other text processing or while using info labels we are getting utf8 encoded strings instead of unicode.
I think the proper solution is to use unicodes internally and transcode where needed because currently with what I have proposed as a quick fix we are transcoding two times with some TTS backends.
After I'll test festival TTS backend and implement speech-dispatcher on linux I can work on this if you agree.

Greetings

Peter

That makes sense. If I understand correctly, you are saying we need to decode to unicode any strings we get that are not already unicode, work with them internally as unicode, and then encode then as necessary within the backends.
Please correct me If that was wrong. I think I am finally understanding unicode and encodings after years of python programming, but maybe that sentence proves otherwise Smile
Your can control xbmc with your voice with voxcommando. Find movie x etc. it's windows only tho.
  • 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 30

Logout Mark Read Team Forum Stats Members Help
Xbmc not working for blind users.5