2015-06-22, 01:54
Ok so I got my Wetek Play and it is a pretty neat box. The default Android image is exactly what you would expect but uses the app store version of Kodi which is 14.2 atm. So I decided to go with Openelec as they are officially endorsed by Wetek and wetek even roll there own version. I opted for the Openelec official build from there site instead.
However out of the box the TTS plugin will not work with Google backend because, as Ruuk mentioned, it requires a mp3 player such as mpg123, or mpg321. Conversely though espeak plugin worked out of the box. Go espeak!
Openelec does not come with mpg321 by default so I unpacked the system image and added the mpg321 binaries form Debian armhf arch as it just needs a few support libs like libao4, libao-common, libid3tag0, libmad0 and zlib1g which were easy enough to include. You move all the libs from the arch path to /usr/lib in the case of openelec.
Ok so all going swimmingly I tested mpg321 from the command line on some normal mp3s they worked fine. But still no sound from the screen reader. Hmm ok so something else is going on. Turns out OpenElec/Kodi 15 defaults to holding the audio interface open for a minute which combined with UI sounds which is also default meant the audio device was being locked. Why that happens with Google and not epeak is because Google uses mp3 -> wav -> aplay where as espeak can tap into aplay directly. So turn both those off and hey I have speech ... only this is the weird part speech at 8 times the speed? Well maybe not 8 times but super fast anyway. For some reason the Google mp3 when played with mpg321 on armhf plays super fast. But I discovered that if I pass --stereo param it speaks normal. Ok so I spent the next hour chewing through the add on I found what I was looking for in lib/backends/audio/__init__.py
--- CUT ---
371,372c371,372
< _playArgs = ('mpg321','-q',None)
< _pipeArgs = ('mpg321','-q','-')
---
> _playArgs = ('mpg321','-q','--stereo',None)
> _pipeArgs = ('mpg321','-q','--stereo','-')
-- CUT --
And hey presto.. voices now work at normal speed! Would be lovely to be able to slow it down a touch but I suspect I would need to make some new options for the google backend.
There was something that did flag in the log though which might be more generic.
--- CUT ---
WARNING: CPythonInvoker(0, /storage/.kodi/addons/service.xbmc.tts/main.py): the python script "/storage/.kodi/addons/service.xbmc.tts/main.py" has left several classes in memory that we couldn't clean up. The classes include: N9XBMCAddon7xbmcgui6WindowE,N14PythonBindings31XBMCAddon_xbmc_Monitor_DirectorE
-- CUT --
For the record the python installed on openelec is Python 2.7.3
Now is use it works pretty much as expected and is pretty sweet for your general navigation and information windows. Personal things I have noticed which is a limitation for Google is it will describe punctuation like underscored and hyphens if they are not part of a word. So I had to change file names to ones with spaces.
But the problem I have noticed. Sometimes, more often than not, when starting streaming videos the dialog will continue on into the start of the playing video even announcing "Window: Video Full screen" which stops the video audio from playing. If you muck about enabling and disabling audio pass-through while the video is playing the audio will come back. I am guessing this is because as the audio is being passed to another program there is no way to halt it (short of killing the process) when a video starts and so it conflicts and locks the audio device. I looked into the poll interview parameter but I am not sure how or what that actually is.
I need to point out here that the WePlay openelec build uses Alsa and not pulseaudio so does not play well with multiple sound sources. Bummer.
So my question is, is there way to ignore certain messages from the window UI. Specifically when playing streaming videos. They just seem a little superflous as we don't really need to know the video is playing if we can hear it's own audio start up first.
Once again thank you so much ruuk for your efforts in building this plugin it really is very sweet to configure and use.
Cheers,
EDIT:
Ok something more to add. I tested it with espeak and it seem espeak and the video audio will play concurrently meaning when the voice has stopped speaking the video audio continues as normal. The same dialog is spoken "Window: Full screen Video" but it does not lock the device.. Hmm
I need to look into the addon a little more but can we assume aplay is the key here and that by using that it does not lock the audio device away from the video audio? The problem is converting mp3->wav->aplay without locking the audio device. I am going to have a look at mplayer and see if that works better.
EDIT 2:
A thought occurs to me. In the System settings - Audio section. It lists the GUI sounds options as being NEVER, ONLY WHEN PLAYBACK IS STOPPED, and ALWAYS. Can we have a similar option in Kodi Screen Reader where it will disable on video playback and hopefully will not over ride the audio of the video playing?
I'll investigate this myself but I don't know the code as well as others so I am guessing it will take me a lot longer.
Thanks.
However out of the box the TTS plugin will not work with Google backend because, as Ruuk mentioned, it requires a mp3 player such as mpg123, or mpg321. Conversely though espeak plugin worked out of the box. Go espeak!
Openelec does not come with mpg321 by default so I unpacked the system image and added the mpg321 binaries form Debian armhf arch as it just needs a few support libs like libao4, libao-common, libid3tag0, libmad0 and zlib1g which were easy enough to include. You move all the libs from the arch path to /usr/lib in the case of openelec.
Ok so all going swimmingly I tested mpg321 from the command line on some normal mp3s they worked fine. But still no sound from the screen reader. Hmm ok so something else is going on. Turns out OpenElec/Kodi 15 defaults to holding the audio interface open for a minute which combined with UI sounds which is also default meant the audio device was being locked. Why that happens with Google and not epeak is because Google uses mp3 -> wav -> aplay where as espeak can tap into aplay directly. So turn both those off and hey I have speech ... only this is the weird part speech at 8 times the speed? Well maybe not 8 times but super fast anyway. For some reason the Google mp3 when played with mpg321 on armhf plays super fast. But I discovered that if I pass --stereo param it speaks normal. Ok so I spent the next hour chewing through the add on I found what I was looking for in lib/backends/audio/__init__.py
--- CUT ---
371,372c371,372
< _playArgs = ('mpg321','-q',None)
< _pipeArgs = ('mpg321','-q','-')
---
> _playArgs = ('mpg321','-q','--stereo',None)
> _pipeArgs = ('mpg321','-q','--stereo','-')
-- CUT --
And hey presto.. voices now work at normal speed! Would be lovely to be able to slow it down a touch but I suspect I would need to make some new options for the google backend.
There was something that did flag in the log though which might be more generic.
--- CUT ---
WARNING: CPythonInvoker(0, /storage/.kodi/addons/service.xbmc.tts/main.py): the python script "/storage/.kodi/addons/service.xbmc.tts/main.py" has left several classes in memory that we couldn't clean up. The classes include: N9XBMCAddon7xbmcgui6WindowE,N14PythonBindings31XBMCAddon_xbmc_Monitor_DirectorE
-- CUT --
For the record the python installed on openelec is Python 2.7.3
Now is use it works pretty much as expected and is pretty sweet for your general navigation and information windows. Personal things I have noticed which is a limitation for Google is it will describe punctuation like underscored and hyphens if they are not part of a word. So I had to change file names to ones with spaces.
But the problem I have noticed. Sometimes, more often than not, when starting streaming videos the dialog will continue on into the start of the playing video even announcing "Window: Video Full screen" which stops the video audio from playing. If you muck about enabling and disabling audio pass-through while the video is playing the audio will come back. I am guessing this is because as the audio is being passed to another program there is no way to halt it (short of killing the process) when a video starts and so it conflicts and locks the audio device. I looked into the poll interview parameter but I am not sure how or what that actually is.
I need to point out here that the WePlay openelec build uses Alsa and not pulseaudio so does not play well with multiple sound sources. Bummer.
So my question is, is there way to ignore certain messages from the window UI. Specifically when playing streaming videos. They just seem a little superflous as we don't really need to know the video is playing if we can hear it's own audio start up first.
Once again thank you so much ruuk for your efforts in building this plugin it really is very sweet to configure and use.
Cheers,
EDIT:
Ok something more to add. I tested it with espeak and it seem espeak and the video audio will play concurrently meaning when the voice has stopped speaking the video audio continues as normal. The same dialog is spoken "Window: Full screen Video" but it does not lock the device.. Hmm
I need to look into the addon a little more but can we assume aplay is the key here and that by using that it does not lock the audio device away from the video audio? The problem is converting mp3->wav->aplay without locking the audio device. I am going to have a look at mplayer and see if that works better.
EDIT 2:
A thought occurs to me. In the System settings - Audio section. It lists the GUI sounds options as being NEVER, ONLY WHEN PLAYBACK IS STOPPED, and ALWAYS. Can we have a similar option in Kodi Screen Reader where it will disable on video playback and hopefully will not over ride the audio of the video playing?
I'll investigate this myself but I don't know the code as well as others so I am guessing it will take me a lot longer.
Thanks.
