Fix loading Mimic phonemes from cache

[forslund]

Description

This PR fixes loading cached phonemes when using Mimic1. Noticed this when testing the cache-sync PR.

The PR does 2 things:

• Make mimic 1 return phonemes in a similar way as Mimic2. This is an improvement in 2 ways, the string conversion gets pre-calculated, saving resources and the code becomes more similar to Mimic2.
• Make the PhonemeFile no longer save non-json-encodable as string. SInce this can't be loaded there's no reason allowing to save in this format

How to test

Switch to mimic1 as TTS, ask mycroft to say hello two times to use the cache and ensure it works.

Contributor license agreement signed?

CLA [ Yes ]

[devops-mycroft]

Voight Kampff Integration Test Succeeded (Results)

[chrisveilleux]

I am not sure I understand this PR. Consider:

import json
s = "[[1, 2], [3, 4]]"
json.loads(s)
[[1, 2], [3, 4]]

There should be no exception raised when these phoneme files are parsed by the built-in JSON parser. Why write our own?

[forslund]

Mimic 1 did not have a json deserializable phoneme format. and there is no guarantee other tts's has it either.

• The first commit makes Mimic1's phoneme data json serializable and deserializable
• There is currently no constraint that the phoneme data should be json serializable / deserializable so the second commit handles the case where the phoneme data is not a structure that can be serialized / deserialized.

If we add the constraint that the phoneme's returned from the get_tts() method should be json serializable we can drop the second commit of these.

[chrisveilleux]

I think I misunderstood the change when I first read it. Thanks for the clarification.

We should be consistent about the way we handle the phonemes. The comment about how some TTS engines will handle parsing themselves is telling. We should either handle the parsing inside the PhonemeFile object or outside of it. Right now we are doing both.

[forslund]

I can agree with that. Phoneme data will vary between TTS engines so previously the parsing of phoneme files were upto each TTS class, now with the PhonemeFile class that is sort of not a thing anymore.

I wonder if we instead of phonemes should cache the final visemes. Those are standardized while visemes are per TTS. It's weird to cache a pseudo format in between the raw format and the viseme.

Previously it made sense to cache the raw data since cache from previous runs were available and if a change in viseme encoding were made old cached files would work but nowadays we seem to clear the cache on startup. (also the cache object doesn't do any syncing from disk)

Drawback of doing this change would be that the mimic2-persistent cache will need to be rebuilt.

[forslund]

@chrisveilleux so what do you say? should I drop the second Commit in the PR and just doing the mimic1 phoneme format change? I would like to get something in place so that mimic1 functionality is restored.

[forslund]

I changed the last commit to instead of allowing strings to be loaded, we disallow non-json encodable objects to be saved in the first place.

[devops-mycroft]

Voight Kampff Integration Test Succeeded (Results)