Bing Speech Recognition Wake-Word Pause Issue

Yes - PauseListening / StopListening can interfere with the wake-word flow if they’re called from within the same Bing Speech Recognition workflow that is currently handling recognition.

What’s likely happening

With wake-word enabled, Bing Speech Recognition is managing a state machine:

1. wake word triggers
2. ding plays
3. it starts recording/sending data
4. it returns recognized text and runs your script

If your recognized-speech script calls PauseListening or StopListening while that session is still active, the skill can end up in a partially paused state and the next wake-word cycle may get stuck at "sending data".

Recommended approach

Instead of pausing the skill itself during robot speech, use a separate guard variable in ARC to ignore recognition while your robot is talking.

For example:

if (getVar("$RobotSpeaking", "false") == "true") {
  return;
}

print(getVar("$BingSpeech"));

Then, before your robot speaks:

setVar("$RobotSpeaking", "true");
Audio.sayEZBWait("Hello there");
setVar("$RobotSpeaking", "false");

If you are using Audio.say() instead of the wait version, you can monitor speech with the built-in variable:

• getVar("$IsSpeaking") for computer TTS
• getVar("$EZBPlayingAudio") for EZ-B audio

Better pattern for wake-word robots

A common pattern is:

• keep Bing Speech Recognition running
• when speech is recognized, set a "busy/speaking" flag
• ignore any new recognition while the flag is set
• clear the flag when the reply finishes

Example:

if (getVar("$RobotBusy", "false") == "true") {
  return;
}

setVar("$RobotBusy", "true");

var text = getVar("$BingSpeech", "");
print(text);

Audio.sayEZBWait("I heard you say " + text);

setVar("$RobotBusy", "false");

If you really want to pause listening

If you want to pause based on a button or external event, do it outside the recognized-speech callback, not from inside the recognition handler that is currently processing the phrase.

Also, if you need more advanced control than Bing’s built-in behavior, ARC lets you create a custom robot skill: https://synthiam.com/Support/Create-Robot-Skill/Overview

That can be useful if you want a dedicated "mute while speaking" state machine.

My recommendation

For your use case, I would avoid PauseListening and StopListening inside the recognized-speech script and use a variable flag instead. That’s the safest way to prevent the robot from hearing itself without breaking wake-word mode.

If you want, I can help you write the exact JavaScript script for your setup - are you using Audio.sayEZB() or Audio.say() for the robot replies?

Thank you, that explanation makes sense and matches what I am seeing.

I tested this further and confirmed that the wake word itself is working. The skill hears the wake word, plays the ding, and $BingSpeech updates correctly when I keep the recognized-speech script very simple.

The problem appears when I call PauseListening or StopListening from the script flow tied to the recognized speech. After that, the wake-word flow can get stuck at "sending data" and does not complete the recognition/script cycle correctly.

Based on your explanation, I am going to avoid using PauseListening or StopListening from inside the Bing recognized-speech callback. Instead, I will keep Bing running and use an ARC guard variable such as $ROE_Voice_IgnoreUntilMs or $RobotBusy to ignore any recognition that happens while the robot is speaking.

For now, I will keep the Bing recognized-speech script very small, something like:

print("$BingSpeech = " + getVar("$BingSpeech"));
controlCommand("ROE Audio", "ScriptStart", "ROE Voice Command Router");

Then the router will decide whether to act on the phrase or ignore it based on a busy/ignore window.

That seems like the safest pattern for wake-word use. I appreciate the clarification that the listener control commands should be used outside the active recognition callback flow.

That sounds like a solid approach, and your testing confirms the behavior well.

Using a small Bing callback plus a separate router/guard variable is the right pattern for wake-word projects in ARC. It keeps the Bing skill stable and avoids interrupting its recognition state machine.

A couple of tips to make your pattern even more reliable:

• Use one ignore variable with a timestamp or short timeout window, so the robot can ignore its own speech only for the brief period it is talking.
• If you are using computer TTS with Audio.say(), you can also watch getVar("$IsSpeaking").
• If you are using EZ-B audio with Audio.sayEZB(), use getVar("$EZBPlayingAudio").

Example guard pattern:

setVar("$RobotBusy", "true");
Audio.sayEZBWait("Hello there");
setVar("$RobotBusy", "false");

And in the Bing callback:

if (getVar("$RobotBusy", "false") == "true") {
    print("Ignoring speech while robot is busy.");
    return;
}

print("$BingSpeech = " + getVar("$BingSpeech"));
controlCommand("ROE Audio", "ScriptStart", "ROE Voice Command Router");

If you want, I can help you turn your ROE_Voice_IgnoreUntilMs idea into a clean ARC JavaScript router script.

Thank you. That matches what I found in testing.

I removed all PauseListening / StopListening calls from the router and changed the Bing recognized-speech script to only print $BingSpeech and start my separate voice router. That made the wake-word flow stable again.

Instead of controlling the Bing skill, my router now uses a timestamp guard variable:

Voice_IgnoreUntilMs

When a valid phrase is accepted, the router sets that to now plus about 15 seconds. If Bing hears the robot during that window, the router starts but immediately ignores the phrase.

I also publish a few diagnostics:

Voice_Busy
Voice_BusyReason
Voice_BusyUntilMs

This seems to be working much better because Bing remains "ears only" and the router handles whether to act or ignore.

I will continue testing with this pattern. Thanks for confirming that avoiding PauseListening / StopListening inside the recognition callback is the safer approach.