If it's taking too long, I raise a notification to the user and direct them to the FAQ, where they are gently advised to try another TTS engine. I monitor the time it takes for the engine to call onInit. I have ' Google is slow to initialise' at the top of my 'known bugs' and 'FAQ' in the application. You can see here how I begin to handle TTS initialisation and the associated problems that can occur - lag included.įinally, to share my experience as to how I've dealt with the above. Making the engine static within this service would serve no purpose that I can think of. This opens another can of worms though, which I won't go into.Įffectively, binding to the engine in a service and checking that service is running when you want the engine to speak, is a 'singleton pattern'.
If you still want to proceed on this basis, you can attempt to get Android to prioritise your process and kill it last - You'd do this by using a Foreground Service. For the many, many users who incorrectly consider (dormant) memory usage directly proportional to battery drain, from my experience, this will cause uninstalls and poor app ratings.Īt the time of writing, Google TTS is bound to my app at a cost of 70mb. If you hold this binding in a background service, the service can be killed, putting you back to square one.Īdditionally, if you remain bound to the engine, your users will see the collective memory usage in the Android running application settings.
If the device is in a state where it needs to free up resources, which is the same state that causes an extended initialisation delay, Android is well within its rights to garbage collect this binding. But, there are further problems that you may wish to consider before doing this. Is there any way through which I can keep the TextToSpeech object alive and initialized at all times like say, through a service? Or would this be a bad, resource-consuming design?Īlso is using a static TextToSpeech object the right way to go, for my requirements?Īs you've noted, a way to avoid the initialisation time, is to remain bound to the engine. In summary, other than the above mentioned, no, you cannot reduce the initialisation time. The same came be said for the current state of the device - I think you'll find that after a reboot, where there is free memory and Android will not need to kill other processes, the initialisation time will be reduced. The more RAM and performant the processor, the less the initialisation time. I believe this is simply because they are using all available resources on the device to deliver the highest quality voice they can.įrom my own personal testing, this delay is directly proportional to the hardware of the device. Regardless of the above, the Google TTS Engine has the longest initialisation time of any of the engines I've tested (all of them I think). In API <21 - Set the KEY_FEATURE_NETWORK_SYNTHESIS to false inside your parameters. Particularly getFeatures() where you can examine the latency and requirement for a network. In API 21+ check out the options on the Voice class. You can also make sure that the request to speak is not being delayed further by selecting an embedded voice, rather than one dependent on a network: I asked a similar question some time ago and initialising the Text to Speech object on a background thread where it is not competing with other tasks, can reduce the delay slightly (as I see you are already doing in your posted code). Can we somehow reduce or eliminate the initialization delay of Google TTS Engine, programmatically or otherwise?.
It's fresh in my mind, as I've spent the last year rewriting my code and had to give great consideration to the surrounding issue. That isn't a shameless plug, it's to demonstrate that I use the design pattern you are considering and I've 'been through' what has prompted your question. I'm the developer of the Android application Saiy. Bypassing Google TTS Engine initialization lag in Android