In code like this:
self.speak_dialog("something")
mycroft.audio.wait_while_speaking()
It was possible that the speaking of "something" would take longer to
start than the 0.1 seconds that was built into the wait_while_speaking().
The definition of this behavior is slightly fuzzy, but this is definitely
a case where the expectation is that previous request for speech would
start and complete. For now, I have just bumped the minimum wait to
0.3 seconds.
In the long run we might consider tracking specific speak requests and
generating a notification when that request has been serviced. Then the
skill could automatically hold off until that request has been serviced.
But the basic skill code won't have to change to make this happen, so
this additional sleep is adequate for today.
Also snuck in a minor change to a comment.
Add support for 'mycroft.mic.listen' on the messagebus to trigger the system
to listen for STT processing. This can be posted on the messagebus by outside
systems, such as a physical or GUI Listen button.
The recent change to remove Pystache introduced a bug in cases where
the passed-in key/value data included non-strings for the value. This
showed up in the weather skill which passed in "lat" and "lon" as floats.
Now the value is explicitly converted using str().
When the TTS engine provides visemes to the faceplate, the information
passed along consists of the mouth shape and the duration to display it.
When the system get backed-up for some reason (e.g. the CPU is briefly
overloaded), the code would attempt to catch up the animation but would
still send the 'expired' viseme across the serial port to the faceplate
with no wait-time. This results in a fast-moving mouth to catch up,
which isn't very pleasing.
Now the viseme is passed along with an expiration date, so if the time
to display it has already passed then the viseme code gets thrown away
instead of being sent across the (relatively slow) serial port. This
allows better catch-up.
Several refinements:
* Remove the "What time is it" preloaded example
* Page up/down now moves by 1/2 the # visible log lines instead of always 10 lines
* Reduce the frequency of full-screen redraws to 10 secs instead of 5 (because less needed with the corruption fix)
* Add the version of mycroft-core in the upper-right corner
* FIX: screen redraw now uses a lock, preventing corruption from drawing simultaneously from multiple threads
On certain platforms it escapes quotes which causes problems. Since we only use it for something as simple as key value replacements, it doesn't make sense to include it as a dependency
As noted on the Chromium Dev How-to [1] and on the
SpeechRecognition library docs [2], the Google TTS API
is really not the right API to call. While it's simple,
and allows you to authenticate via a simple token, it is
also limited to a max of *50* requests per day.
That's not a lot. I don't think many people will find that
useful, outside of quick testing (if they can even get an
API key - I couldn't figure out how to generate one that
worked correctly).
This commit introduces a new STT backend, google_cloud, so that
the Google STT backend can be deprecated eventually. To do so, we
needed to:
- Install the Google API Client Library
- Create a new STT class which knows how to turn a provided Google
JSON credentials file into a string (the SpeechRecognition library
expects you to pass in the JSON string, not a file path, nor an object).
Any person wishing to use this will need to:
- Enable the Cloud Speech API on the Google Cloud Platform console
- Create a new Service Account Key, and download the credentials to
a secure location
- Configure that location in mycroft.conf, like so:
"stt": {
"google_cloud": {
"credential" {
"json": { contents of downloaded credentials }
}
}
}
It's worth noting that the Cloud Speech API has a free quota of
60 minutes per month, which would probably stretch further than 50
individual requests. So for hobbyists, it should be nothing but
a net benefit.
[1] http://www.chromium.org/developers/how-tos/api-keys
[2] https://github.com/Uberi/speech_recognition/blob/master/reference/library-reference.rst#recognizer_instancerecognize_googleaudio_data-key--none-language--en-us-show_all--false
==== Tech Notes ====
queue command will start playback if no playback is running.
mpg123 and vlc services updated support queueing tracks while playing
==== Protocol Notes ====
mycroft.audio.service.queue message added
Remove usage of bash subshell in MSM for invocation of the
mycroft.message.send module. The virtualenv wouldn't be created in that
subshell, breaking Github-style installs of Mycroft.
==== Tech Notes ====
As soon as mycroft, mycroft.api or mycroft.skills.core were imported the
configuration was loaded (including reaching out to the web config).
This will reduce unneccessary configuration loadings and make it easier
to handle configuration in the tests.
A recent PR (#1192) eliminated the requirements that only applied to default
skills, not to the core itself. However this caused problems for skills that
were previously installed and had their PIP requirements satisfied by the
packages that came along with the mycroft-core Debian package previously.
As a hackinfix, we now re-run PIP on each skill during the MSM update, but
to limit the performance impact this only happens once per session. We
shouldn't to removing packages again in the future, so this should be a
one-time act that gets removed from MSM in the future (like at 18.02).
Åke Forslund
jarbasai
Michael Nguyen
penrods
Matthew D. Scholefield
Andrew Hayworth
devs-mycroft
mycroft-developers