[TTS] ~3 minute delay when sending text to Google cast / home

[CarlosGS]

The problem

There's a very large delay (varying ~3 minutes) when sending a TTS command to a chromecast device with the default method. See screen capture below.

I've verified this with [Chromecast 2,3, 4K and Google Home Mini] and with HASS installed in [Raspberry 4 and HassOS virtualbox VM].

I started using HASS in March 2020 and have always observed this. Please let me know what information you need

What is version of Home Assistant Core has the issue?

core-2021.2.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Google Cast (more likely: tts)

Link to integration documentation on our website

https://www.home-assistant.io/integrations/cast/

Example YAML snippet

# Text to speech
tts:
  - platform: google_translate
    language: 'es'

Anything in the logs that might be useful for us?

# Put your logs below this line
2021-02-16 15:29:28 ERROR (Thread-8) [homeassistant.components.cast.media_player] Failed to cast media https://www.home-assistant.io/images/cast/splash.png. Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address

Related issues & discussions:

• 20-60s buffering for LIVE media streaming & huge delay home-assistant-libs/pychromecast#356
• https://community.home-assistant.io/t/google-tts-plays-already-cached-text-to-speech-files-but-not-new-text-to-speech-requests/70988

[probot-home-assistant]

cast documentation
cast source
_{^{(message by IssueLinks)}}

[CarlosGS]

A workaround is to manually invoke the service media_player.play_media like this:

entity_id: media_player.home
media_content_type: music
media_content_id: "https://translate.google.com/translate_tts?ie=UTF-8&tl=es-ES&client=tw-ob&q=Esto es otra prueba mas"

That has no delay and doesn't store mp3 files within HASS.

[probot-home-assistant]

Hey there @emontnemery, mind taking a look at this issue as its been labeled with an integration (cast) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[CarlosGS]

I've observed that the audios in /tts/*.mp3 take a while to be generated. In fact each file only appears exactly when the audio finally plays.

This separate issue also mentions a large delay: #38346 (comment) (update: ignore this)

Looks like a TTS bug, could a moderator add the label integration: tts? Thanks!

[probot-home-assistant]

Hey there @pvizeli, mind taking a look at this issue as its been labeled with an integration (tts) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[emontnemery]

The problem in home-assistant-libs/pychromecast#356 is that the default media player built into chromecasts does not handle live streams well. That problem is very unlikely to have anything to do with the issue here.

If the tts media needs a lot of time to be generated, that's most likely the root cause.

[CarlosGS]

Thanks @emontnemery! Sorry for the initial mislabeling. I realized this while writing the report, as it happens 😅

Going down the rabbit hole, here are some more findings. I've ran this snippet:

from gtts import gTTS
tts = gTTS(text='Esto es una prueba', lang='es')
tts.save('prueba.mp3')

And on my personal machine, this is instantaneous.
However, on HassOS that save comand halts with a much dreaded delay. Bingo! (I ran it through the Terminal -community- addon, and needed to pip install gTTS).

This issue replicates exactly when running HassOS on a Raspi 4 and also when running HassOS on a VM (Core i5 with spare resources). They are connected through WiFi - but so is my personal machine that doesn't have a delay when running the python command.

Dependencies do differ a bit. Personal machine:

HassOS:

Unfortunately I can't find any useful or "replicatable" text in the logs (neither at the python execution, the supervisor log, core log, nor the internal journalctl log).

[CarlosGS]

Opened a query at gTTS in case they can provide more insight: pndurette/gTTS#281

[pndurette]

A workaround is to manually invoke the service media_player.play_media like this:

entity_id: media_player.home
media_content_type: music
media_content_id: "https://translate.google.com/translate_tts?ie=UTF-8&tl=es-ES&client=tw-ob&q=Esto es otra prueba mas"

That has no delay and doesn't store mp3 files within HASS.

Side note! This won't work anymore, Google Translate has pretty much removed this endpoint (it might work if you're lucky but it's very unreliable).

[CarlosGS]

I'd appreciate if more people can check if they have this TTS delay by running:

Note: you must change the text between each test, otherwise the generated audios are reused and played instantly. Even after a few days. Never reuse text while testing this.

[CarlosGS]

As a workaround, you can entirely drop the default engine (Google Translate) and choose PicoTTS:

tts:
  - platform: picotts
    language: 'en-GB'

For stability and privacy, it is not a good idea to provide Google Translate as the default TTS engine.
If you agree, please vote/comment here: https://community.home-assistant.io/t/tts-instead-of-google-translate-provide-local-text-to-speech-engine-as-the-default/299712

Leaving this issue open until resolved (or until Google finally drops this undocumented API, haha).

[CarlosGS]

Today I tested Google Translate TTS again, and it works as expected.
In case it helps others, here's how our setup changed since:

• Instead of a Virtual Machine, we installed HassOS NUC barebone on an Intel i5 with 8GB ram and SSD.
• Instead of WiFi, HassOS is wired directly to the router with a measured 300Mbps internet connection.
• We had CG-NAT (shared global IP address) now we have an individual global IP.
• We've kept HASS up-to-date with each new version.

The delays must have been fixed with some update in HASS or the networking libraries - remember that the issue used to replicate exactly on a dedicated, wired Raspberry setup.

I'm still puzzled that the delay only appeared within Docker. However, this could have also been due to the slightly different package versions.

Thank everyone for helping troubleshoot this issue! :)