AVS remains in listening state after calling alexa twice rapidly

[RikJanssenph]

IMPORTANT: Before you create an issue, please take a look at our Issue Reporting Guide.

Briefly summarize your issue:

First running the AVS sample app for a long time resulted in a continuous listening state. Showing that the wakeword audio provider could not override. By calling "alexa" twice we can reproduce this state. Remaining silent or speaking an utterance doesn't change the state.
Applying tap-to-talk or hold-to-talk overrides the listening state.

What is the expected behavior?

At some point the AVS sample app should return to idle state. Allowing for new wakeword triggers to be accepted.

What behavior are you observing?

When debugging we see that the DialogRequestId is updated with the second wakeword detection (which is not allowed to override). Subsequently a StopCapture directive with the old DialogRequestId is dropped.

Provide the steps to reproduce the issue, if applicable:

Start the Sample app and call out 'Alexa' twice. The second Alexa should be called during the recognizing state.

Tell us about your environment:

What version of the AVS Device SDK are you using?

  <1.16.0>

Tell us what hardware you're using:

• Desktop / Laptop
• Raspberry Pi
• Other - tell us more:

Tell us about your OS (Type & version):

• Linux
• MacOS
• Raspbian Stretch
• Raspbian Jessy
• Other - tell us more:

We applied the real-time preempt kernel patch:

uname -a
Linux pi 4.19.71-rt24-v7+ #1 SMP PREEMPT RT Tue Nov 12 13:07:02 CET 2019 armv7l GNU/Linux

Attached log file

log_alexa_alexa.txt
One line # 520 you can see that the StopCapture directive is dropped.

[kjkh]

Hi @RikJanssenph,

Thanks for bringing this issue to our attention. We will investigate this further.

[kjkh]

Hi @RikJanssenph,

We have verified the bug and are tracking it internally. It will be fixed in a future release.

[makicombi]

here is a patch that fixed this problem for me (I put this here as avs-device-sdk does not accept pull requests at this time):

 CapabilityAgents/AIP/src/AudioInputProcessor.cpp | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/CapabilityAgents/AIP/src/AudioInputProcessor.cpp b/CapabilityAgents/AIP/src/AudioInputProcessor.cpp
index 06ee3672..7585b7bc 100644
--- a/CapabilityAgents/AIP/src/AudioInputProcessor.cpp
+++ b/CapabilityAgents/AIP/src/AudioInputProcessor.cpp
@@ -318,6 +318,13 @@ std::future<bool> AudioInputProcessor::recognize(
         begin = reader->tell();
     }
 
+    if (m_state == avsCommon::sdkInterfaces::AudioInputProcessorObserverInterface::State::RECOGNIZING) {
+        ACSDK_DEBUG(LX("skippingRecognizeEvent").d("reason", "keywordWhileRecognizing").d("keyword", keyword));
+        std::promise<bool> ret;
+        ret.set_value(false);
+        return ret.get_future();
+    };
+
     return m_executor.submit(
         [this, audioProvider, initiator, startOfSpeechTimestamp, begin, keywordEnd, keyword, KWDMetadata]() {
             return executeRecognize(

[celinval]

Thanks for sharing the patch. We currently do not accept pull requests but we'll address the issue in a future release.

[scotthea-amazon]

Hello @RikJanssenph,

This issue has been fixed in the 1.17 release. Thank you again for bringing this to our attention!

Best regards,
-SWH