Chromecast integration now stutters, and speaks "wake" before any announcement, when part of a routine

[Biggsyboi]

Following the latest update, if I use the Chromecast integration to say something in the device page, it starts speaking and then stutters after a few words and starts again.

I have a routine where it announces that a hot water dispenser is finished boiling when the power draw drops to 0, but now it's saying "wake" before the rest of the announcement. It never used to do this and the word "wake" isn't typed in the message.

I know it's in Beta, but just wondering if anyone else is having this problems...

[dnickel]

Interesting. I just removed Wait statement in a piston because I thought WebCore was goofing up and inserting the word Wait into my Speak statement.
So, it's not me going crazy, a Bug?

@bobbyD

[mike.maxwell]

Try changing the TTS delay enable option in the driver.

[Biggsyboi]

I can confirm, disabling "TTS delay enable" fixes the issue of it saying "Wait" (sounded like "Wake" to me!) before any announcement

Edit: I can't reproduce the stuttering now, either. However, I have at least one speaker where the hub can't control it at all even after initializing it...But it still reports the correct volume when I change it via other methods.

[dnickel]

I don't get the "Wait" anymore with TTS off but it now takes about 5 seconds before it speaks. I also tried the volume value in the WebCore implementation instead of setting it in a separate line of code before the Speak command and it didn't seem to work.
I'll test that manually today when the wife it out and confirm.

@nh.schottfam

[nh.schottfam]

Would need to see webcore full logs for the piston to understand what you are saying.

[dnickel]

Simple piston to Speak. Doesn't change volume. Device stays at 30 no matter what the piston says. More info to help somewhere else?
Doing a Set Volume before the Speak works.

16/12/2022, 13:29:02 +375ms
+3ms ╔Received event [Home].test = 1671226142375 with a delay of 0ms, canQueue: true, calledMyself: false
+16ms ║RunTime initialize > 15 LockT > 0ms > r9T > 8ms > pistonT > 7ms (first state access 4 m:7 3 12)
+18ms ║Runtime (5318 bytes) initialized in 8ms (v0.3.114.20220928_HE)
+19ms ║╔Execution stage started
+140ms ║║Executed device command [Living Room pair].speak(testing 1 2 3,60) (114ms)
+143ms ║╚Execution stage complete. (124ms)
+145ms ╚Event processed successfully (143ms)

app:122022-12-16 13:30:45.357debugDashboard: Request received to test a piston

app:9602022-12-16 13:30:45.343debugReleased Lock and exiting

[dnickel]

@nh.schottfam
Do you know if this was addressed in the lastest bug fixes?

[nh.schottfam]

what are the logs for the device showing?

I'm trying to understand if this a device problem vs. a webCoRE problem.

First pass of logs look correct on webCoRE side

[dnickel]

Device shows nothing except the log enable:

Still at 30 even though the piston is set to 59:

The piston did run and talk but only at 30.

[dylan.c]

@mike.maxwell

Try changing the TTS delay enable option in the driver.

UPDATE: Read to the end of my post...it wasn't working but now it is.

Note that this change does not appear to work for my 1st gen Google Home Hub. I set up a test TTS rule with my Hub and a Mini as output devices and the Hub doesn't want to cooperate. Using the Chromecast Video driver with any delay amount (1, 3, or 5 seconds) results in the entire TTS string is played, but is preceeded by "wait." With a delay setting of "None" or "No Selection," the first portion of the message is not played.

For kicks, I tried changing the driver to Chromecast Audio. With this driver, the delay duration is not selectable, only available as ON or OFF. Directly from the "Speak" setting on the driver page, I tried to play the notification "Old MacDonald Had A Farm, E I E I O." The results were different with each setting...

Delay off: Farm, E I E I O.
Delay on: Donald Had A Farm, E I E I O.

Now here is the weird part. I had switched back and forth between the audio and video drivers a couple of times with no real change at any point. But the last time, after changing the driver back to Chromecast Video with a 1 sec. TTS delay, the test rule in RM started working correctly with no "wait" at the beginning. My only theory is that by using the "Speak" command directly from the device page, I may have triggered some sort of update or reinitialization somewhere. Either way, now it works.