The basic procedure for barge in is: 1. detect_speech unimrcp {start-input-timers=false,no-input-timeout=5000,recognition-timeout=5000}builtin:grammar/boolean?language=en-US;y=1;n=2 2. playback say:please say yes or no. please say no or yes. please say something! 3. handle begin-speaking event 4. break 5. when playback finishes... detect_speech start_input_timers 6. handle detected-speech event This is pretty much what play_and_detect_speech already does... see switch_ivr_play_and_detect_speech() in switch_ivr_async.c if you know C. Chris On Wed, Aug 1, 2012 at 1:49 PM, Liu, Xingkun <X.Liu@hw.ac.uk> wrote:
**
Thanks for your response, Hector!
Yeah, I am using detect_speech via a similar way to yours.
What I am more interested in is to use detect_speech app to handle user's barge-in.
After Chris mentioned the barge-in can be also handled by detect_speech I gave it a further thinking. Yeah, I could first "speak" the utterance and immediately resume ASR, then try to catch the begin_speaking event, then stop the TTS -- using this way to handle the user barge-in. (Chris, you may have a better idea, would you please let me know if you do?)
One thing I am worry about is that stopping currently playing media or utterance seems not work for me. When I recently try "api uuid_break <uuid>" it stopped currently playing music but also stopped playing following utterances which I sent to TTS soon later on after uuid_break.
Anyway I will try it further again and let you all know what I will get.
Cheers,