Flite suspends when already suspended, incorrectly resumes

[adrian]

I suspend recognition after I receive a hypothesis then use Flite to verify what the user said. Even though OpenEars is suspended, Flite suspends it again and then resumes.

2016-01-07 01:18:02.400 [Debug] [main] [SpeechRecognizer.swift:202] pocketsphinxDidReceiveHypothesis(_:recognitionScore:utteranceID:) > The received hypothesis is LIZ with a score of 0 and an ID of 0
2016-01-07 01:18:02.403 [Debug] [main] [SpeechRecognizer.swift:150] suspend() > suspending pocketsphinx
2016-01-07 01:18:02.404 [Debug] [main] [SpeechRecognizer.swift:157] pocketsphinxDidSuspendRecognition() > Pocketsphinx has suspended recognition; suspended: true
2016-01-07 01:18:03.329 Patter[4539:1910316] I’m running flite
2016-01-07 01:18:03.393 Patter[4539:1910477] Audio route has changed for the following reason:
2016-01-07 01:18:03.420 Patter[4539:1910477] There was a category change. The new category is AVAudioSessionCategoryPlayAndRecord
2016-01-07 01:18:03.433 Patter[4539:1910477] This is not a case in which OpenEars notifies of a route change. At the close of this function, the new audio route is —SpeakerMicrophoneBuiltIn—. The previous route before changing to this route was <AVAudioSessionRouteDescription: 0x165dcf00,
inputs = (
“<AVAudioSessionPortDescription: 0x16524690, type = MicrophoneBuiltIn; name = iPhone Microphone; UID = Built-In Microphone; selectedDataSource = Bottom>”
);
outputs = (
“<AVAudioSessionPortDescription: 0x16536200, type = Speaker; name = Speaker; UID = Speaker; selectedDataSource = (null)>”
)>.
2016-01-07 01:18:03.444 Patter[4539:1910477] Audio route has changed for the following reason:
2016-01-07 01:18:03.445 Patter[4539:1910477] There was a route override.
2016-01-07 01:18:03.456 Patter[4539:1910477] This is not a case in which OpenEars notifies of a route change. At the close of this function, the new audio route is —SpeakerMicrophoneBuiltIn—. The previous route before changing to this route was <AVAudioSessionRouteDescription: 0x166d8800,
inputs = (
“<AVAudioSessionPortDescription: 0x166b0830, type = MicrophoneBuiltIn; name = iPhone Microphone; UID = Built-In Microphone; selectedDataSource = Bottom>”
);
outputs = (
“<AVAudioSessionPortDescription: 0x1784cb50, type = Receiver; name = Receiver; UID = Built-In Receiver; selectedDataSource = (null)>”
)>.
2016-01-07 01:18:03.493 Patter[4539:1910316] I’m done running flite and it took 0.163496 seconds
2016-01-07 01:18:03.493 Patter[4539:1910316] Flite audio player was nil when referenced so attempting to allocate a new audio player.
2016-01-07 01:18:03.494 Patter[4539:1910316] Loading speech data for Flite concluded successfully.
2016-01-07 01:18:03.515 Patter[4539:1910316] Flite sending suspend recognition notification.
2016-01-07 01:18:03.524 [Debug] [main] [SpeechRecognizer.swift:157] pocketsphinxDidSuspendRecognition() > Pocketsphinx has suspended recognition; suspended: true
2016-01-07 01:18:03.526 [Debug] [main] [SpeechRecognizer.swift:162] pocketsphinxDidSuspendRecognition() > superfluous call
2016-01-07 01:18:04.445 Patter[4539:1910316] AVAudioPlayer did finish playing with success flag of 1
2016-01-07 01:18:04.597 Patter[4539:1910316] Flite sending resume recognition notification.
2016-01-07 01:18:05.105 Patter[4539:1910316] setSecondsOfSilence wasn’t set, using default of 0.700000.
2016-01-07 01:18:05.106 [Debug] [main] [SpeechSynthesizer.swift:51] fliteDidFinishSpeaking() > flite finished speaking
2016-01-07 01:18:05.108 [Debug] [main] [SpeechRecognizer.swift:175] pocketsphinxDidResumeRecognition() > Pocketsphinx has resumed recognition.

[Halle Winkler]

Thanks, I’ll check this out for the upcoming release.

[Halle Winkler]

I’ve looked into this, but these two classes (intentionally) don’t communicate state to each other. You should be able to send a call to suspend in fliteDidFinishSpeaking or alternately pocketsphinxDidResumeRecognition at the conclusion of flite speech to immediately re-suspend – if this doesn’t work, please create a replication case for me so I can confirm that that specific approach will work in a future update: https://www.politepix.com/forums/topic/how-to-create-a-minimal-case-for-replication/

[adrian]

Suspending immediately after Flite resumes does work. If you intend for Flite to resume like this you may want to document it — I was pretty surprised.

[Halle Winkler]

Hi,

Well, the intention is for Flite to do its own suspension and resumption on an in-progress listening loop – the usual situation is that listening is either stopped, or it is not stopped and not suspended, so Flite does the right thing since it has to suspend listening for TTS and then handle its own resumption. I can document that if Flite speech is used while listening is already suspended, the suspension state has to be reasserted in the callback at the end of speech.

[Author]

Posts