Open monking opened 5 years ago
I haven't compiled or tested this, but here's a wild guess at the change: https://github.com/termux/termux-api/compare/master...monking:stop-tts
This request makes sense and would be nice to have! As a work around, I've setup a shell signal handler that kills the TTS service when my script is interrupted or exits. (Currently called on EXIT, but could be changed to be called only on SIGINT)
@monking did your change get tested? I'm using termux-tts-speak
as an output module for speech-dispatcher and the last part I need is to get it to cancel a message via SIGKILL
Unfortunately I'm not equipped to test my proposed change. I did say "I'd be happy to code this up," at the time, imagining helpful feedback to guide me. I didn't know then or now if my proposed code change is appropriate.
Feature description
I would like to be able to stop text-to-speech playback in progress. Some situations where this is useful: perhaps the playback rate or formatting of the text is not ideal, and I'd like to try again. Or perhaps I've piped more text into the TTS engine than I need, in order to search for some information, and I would stop the playback as soon as that information is found.
Background information
I think this would do the trick: https://developer.android.com/reference/android/speech/tts/TextToSpeech.html#stop()
This seems to be a public method, rather than static / singleton method, so it might need the original
TextToSpeech
instance in order to be called. To keep this instance accessible, perhaps there could be an option on thetermux-tts-speak
script (e.g.-i
for "interactive") which causes the script to not return until the speech is done, allowing an interrupt (control+c) signal from the shell to triggermTts.stop()
inTextToSpeechAPI.java
.[EDIT: I thought that the script
termux-tts-speak
exited right away (perhaps it used to), but I see now that it does not exit until the utterance is complete. So this enhancement might instead be "handle control+c interrupt"]I'd be happy to code this up, if someone would like to give advice on the architectural decisions (e.g. would I need to refactor the
TextToSpeechAPI::onHandleIntent
method into separate methods, to account for its newly varied behavior?). I also see that there is already code which seems to run during the whole "utterance" inResultReturner.returnData
(e.g.mTts.setOnUtteranceProgressListener
), so it may be as simple as optionally running the meat of this block synchronously.I will look later and edit if I find some.