TTS - detailed infos triggered to close (queue)

[keyoss]

if all speech outputs are enabled, the selected element output is too close to the next element.
result is that sometimes the voltage will override the altitute speech. this will cut the previous triggered output. please add some more milliseconds before the output of the next elements.. it seems they are triggered in row, without waiting for the last element to finish.

battery voltage reads three points after the comma? like 16.791¿ (maybe shorten to 2 digits?)

a global interval selection is already a nice thing, it would be great to have an advanced feature that will allow to have an individual interval for EACH selected element.

like:
altitude 15 sec
battery 30 sec

exception schould be LOSS or WARNINGS and FAILSAFE.. theese should get the highest priority...

[squilter]

I agree that voltage doesn't need 3 decimal points. One is enough.

Allowing different intervals for different values would just make a mess. If I read altitude every 5 seconds and battery every 12 seconds, which one is going to take priority at the 60 second mark? I'm also not really sure what advantage this would bring.

If it ends up talking over itself, you should just increase the interval. The short interval is best if you are only interested in reading one value (i.e. voltage). You shouldn't use the short interval If you want the app to read every value that it is capable of reading.

[m4gr3d]

The issue here is that we are dropping the previous speech by use of QUEUE_FLUSH.

This make sense for high priority events, but for status events, we should be queuing the messages instead by using QUEUE_ADD.

[m4gr3d]

Overloading speak(...) with an additional parameter (speakNow?) should do the trick.

High priority events will set speakNow to true, while status events will set it to false.

[arthurbenemann]

Or just create a speakNow method.

[m4gr3d]

@arthurbenemann both methods will use the exact same logic except for the queuing parameter, so it's preferable to avoid duplicating logic.
Unless speak is expanded to include the additional boolean parameter, and speakNow is just a delegate to it with the parameter set to true.

[squilter]

@ne0fhyk The worry here is that the user will request a periodic status update that takes 20 seconds to read, and they will set the interval to 15 seconds. If we QUEUE_ADD it, then the queue will grow faster than the lady can read it. After a few minutes it will just be reading really outdated info.

[m4gr3d]

@squilter in that case, we can use isSpeaking, or UtteranceProgressListener to figure out when the current speech is done.

Toggle a flag when a speech is added, and reset it when it's done. While the current speech is not done, any non high priority events should be discarded.

[keyoss]

latest 2.4 fixed the issue..

only in 'vol-ts' is a small click/hickup..