Hello World example works but then hangs on macOS about tts-rs

[ndarilek]

It sounds like that's exactly by design. It does the same thing on other platforms--speaks the last line but doesn't exit. The speech calls usually don't block for very long, so without an artificial hang then you'd have a program that spoke for a couple MS and then exited.

Is that basically what you're saying happens? Or am I misunderstanding? Have you run this example on another platform, and is the behavior different? I guess you probably can't press enter on the mac version since I structured the artificial hang a bit differently, but Ctrl-c should work too.

And as an aside, I'm thrilled that this works on your M1. I have folks telling me it doesn't speak at all on their M1s. I'd be interested in getting you talking if you're willing to help out with that. Maybe it was due to a bug fixed in a newer macOS version. But I'm glad that it at least says something on an M1. :)

[rtfeldman]

It sounds like that's exactly by design. It does the same thing on other platforms--speaks the last line but doesn't exit. [...] Is that basically what you're saying happens? Or am I misunderstanding?

Yep, that's it. I didn't realize it was by design!

And as an aside, I'm thrilled that this works on your M1. I have folks telling me it doesn't speak at all on their M1s. I'd be interested in getting you talking if you're willing to help out with that.

Sure, happy to help! Want to send me a DM on Twitter and we can set something up?

[jquesada2016]

Do you think that blocking intentionally is the right behavior? I remember when I used this crate a few months back, no blocking occurred, rather, it did exactly as you mentioned; speaking for a couple ms and then exiting. I worked around this by either introducing a manual sleep timeout, or by implementing future for Tts, using the on_utterance_end callback, which worked really nicely.

[ndarilek]

No, I don't think that intentionally blocking is wise for a couple reasons. First, I don't think any of the underlying APIs block--or, at least, they don't block for any longer than it takes to queue the utterance internally. So making this API block would be counter to the behavior of every single API this crate binds to. Second, I don't see it benefiting any of my current use cases. I can't imagine a scenario where I'd want my program to block while text is speaking. If you have such a scenario then I'd be interested in hearing about it, and if there's something this crate can do to make that use case easier other than just blocking outright then I'm likewise interested. I just can't imagine blocking being wise in anything other than toy programs, but maybe I'm wrong.