[Espeak] say(const std::string& text): is/can it be blocking?

[jgvictores]

[Espeak] say(const std::string& text): is/can it be blocking?

Is it streaming as before or can it now be used as an RPC service?

If so, hard-coded waits such as the following can be refactored: https://github.com/roboticslab-uc3m/follow-me/blob/b462dad42fc243732744ccb276249a341ce9c2d3/programs/followMeDialogueManager/StateMachine.cpp#L131

[rsantos88]

[Espeak] say(const std::string& text): is/can it be blocking?

No, it's not blocking but it's good to have a bit delay before muting

[jgvictores]

The server is implemented as RPC, so something could be done here, and I believe it should.

I think we have two options here:

1. Make it blocking. Advantage: No change in API. Disadvantage: We loose flexibility.
2. Create new function like checkSayDone. Advantage: We maintain and even gain flexibility. Disadvantage: Change in API, and small sync issues similar to those in controlboard.

I like the last option a bit more, but I'm open to opinions.

[PeterBowman]

I'd advise against the first option. In the future, if not done yet, you might want to implement a stopTalking (or shutUp 😀) method, which I believe would come up against serious difficulties when going the blocking way, at least as I found out while working on a similar problem at kinematics-dynamics (roboticslab-uc3m/kinematics-dynamics#106). Going back to the kin-dyn repo, we introduced not so long ago a wait method which might be of use here (prototype) and would count as a 2b option. That would require the least work downstream, just replace existing hardcoded waits with this new interface method.

[PeterBowman]

No, it's not blocking but it's good to have a bit delay before muting

Sorry, but this statement is false, the say command does block (here)...

[PeterBowman]

And it makes no sense to block since we provide pause/resume/stop commands. So I guess it should be unblocked, and a new wait command be added?

[jgvictores]

So I guess it should be unblocked

For sure.

and a new wait command be added?

Seems like the quick and fast solution.

Note that the checkSayDone alternative proposed above was in analogy with IPositionControl::checkMotionDone.

• Pro (I think): Easier to stop() before termination without using threads in API-user-land.
• Cons: From https://stackoverflow.com/questions/50062009/how-to-find-if-espeak-ended-the-speech espeak looks event-based, so we'd have to keep the state modified by events we catch via callback. Additionally, usually IPositionControl::checkMotionDone rolls out to be an ugly loop.

No strong opinions in a wait vs checkSayDone, but perhaps food for thought. ^^

[PeterBowman]

Another point: checkSayDone would allow multiple-client scenarios thanks to not blocking RPC comms on the server side.

Edit: YARP does not actually block port callbacks, thus allowing two clients to get their request handled independently at once, but Espeak will not process a queued say command until the previous one was completed (regardless of the espeak_Synchronize call).