Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

EXPECTING_SPEECH + SPEAK directive simultaneously on multi-turn conversation. #44

Closed
julianobRibeiro opened this issue Jun 29, 2017 · 11 comments
Assignees

Comments

@julianobRibeiro
Copy link

Hi,
My name is Juliano Ribeiro and I work for Qualcomm.
I notice that the current behavior from AVS SDK for EXPECTING_SPEECH Directive is to stop MediaPlayer in case any SPEAK directive is being playing out.

So, when I ask "Alexa, What is on my shopping list?" If shopping list is bigger then 5 items response from AVS will be 6 SPEAK directives (one for each item + 1 question asking if I would like to listen the rest of the items) + 1 EXPECTING_SPEECH ( to capture my response).

The problem with this use case is that EXPECTING_SPEECH directive is forcing MediaPlayer to STOP SPEAK directive and the question is interrupted as soon as it starts. In other words user can not listen to the question and does`t know what is happening.
*Note that, last SPEAK and EXPECTING_SPEECH are reaching device almost at same time.

Said that, here are my questions:

  1. Is EXPECTING_SPEECH suppose to force MediaPlayer to stop Speak directives content if they are playing?
  2. Is EXPECTING_SPEECH suppose to arrive together with SPEAK directive? I thought that EXPECTING_SPEECH would only be sent after device reports to the clould EXPECTING_SPEECH Event.

Can you please help me to review that?

Multi-turn conversation where we have just 1 SPEAK + 1 EXPECTING_SPEECH is working fine.

Thank you in advanced.
Juliano Ribeiro

@scotthea-amazon scotthea-amazon self-assigned this Jun 30, 2017
@scotthea-amazon
Copy link
Contributor

scotthea-amazon commented Jun 30, 2017

Hello Juliano,

It sounds as though the handler for the Speak directives is not being handled with a BLOCKING policy in DirectiveSequencer or that the ExpectSpeech directive is behaving as though it has a different dialogRequestId than the Speak directives. Can you confirm that your handler for Speak directives is registered as having a BLOCKING policy? Can you provide the dialogRequestId values for the Speak and ExpectSpeech directives in an instance where this problem occurred. There is a good change we will be able to see all that from the log of a DEBUG build. Can you post one to this thread?

Thank you,
-SWH

@julianobRibeiro
Copy link
Author

julianobRibeiro commented Jun 30, 2017

HI,

Thanks for quick response.
I am using SpeechSynthesizer provided by Amazon which is setting SPEAK directive as BLOCKING.
Please see code below:
avsCommon::avs::DirectiveHandlerConfiguration SpeechSynthesizer::getConfiguration() const { avsCommon::avs::DirectiveHandlerConfiguration configuration; configuration[SPEAK] = avsCommon::avs::BlockingPolicy::BLOCKING; return configuration; }

The SPEAK which is saying that I have X items on my shopping list has same DialogID as Recognize event:
2017-05-27 17:37:08.847 [ 8] I DirectiveSequencer:onDirective:directive={"namespace\:"SpeechSynthesizer"\,name\:"Speak"\,messageId\:"2139243b-1552-43fa-962a-cb14726167e0"\,dialogRequestId\:"254031a4-6de4-44c6-95fa-0ba14f840275"}

But all SPEAK directives that are arriving after that, one for each ITEM on shopping list, does not have dialodID.
2017-05-27 17:34:33.176 [ 8] I DirectiveSequencer:onDirective:directive={"namespace\:"SpeechSynthesizer"\,name\:"Speak"\,messageId\:"2a840ceb-1215-4e63-8a69-ba327c32098a"\,dialogRequestId\:""}

Same thing happens for EXPECTED_SPEECH directive, it also does not have DialogID
2017-05-27 17:34:33.177 [ 8] I DirectiveSequencer:onDirective:directive={"namespace\:"SpeechRecognizer"\,name\:"ExpectSpeech"\,messageId\:"6c386737-24d3-4011-a01b-fed33bf519ad"\,dialogRequestId\:""}

Thank you,
Juliano Ribeiro

@scotthea-amazon
Copy link
Contributor

scotthea-amazon commented Jun 30, 2017

Hi Juiano,
It looks like AVS may be mis-behaving. Can you provide an x-amzn-requestid for the initial Recognize request? That will hep us verify the behavior you are seeing if we are not able to reproduce it.
Thank you for bringing this to our attention!
-SWH

@julianobRibeiro
Copy link
Author

Sure.

Here is the x-amzn-requestid: x-amzn-requestid: 121315fffec65dfa-00006abf-0003fcbd-cfdea69fb1329a83-d98415b8-3

Thank you,
Juliano

@julianobRibeiro
Copy link
Author

Hi,

Do you have any feedback on that?

Thank you in advanced
Juliano Ribeiro

@scotthea-amazon
Copy link
Contributor

Hi Juliano,
We are actively looking in to this, but unfortunately, no firm answer yet. There is a question that you may be able to help us with: Do you experience the same behavior with move or showtime listings?
Thank you,
-SWH

@scotthea-amazon
Copy link
Contributor

Hi Juliano,
We were able to reproduce the same kind of behavior with movie listings (although there are AudioPlayer.Play directives mixed in) - so don't worry about checking it for us.
Thanks,
-SWH

@julianobRibeiro
Copy link
Author

OK. Thank you for the feedback.
/Juliano Ribeiro

@scotthea-amazon
Copy link
Contributor

Hello Juliano,

A client side fix has been implemented in the Directive Sequencer library. It will be included in the next release.

-SWH

@julianobRibeiro
Copy link
Author

Thank you for keeping me posted.

-Juliano

mradulan added a commit that referenced this issue Aug 8, 2017
Changes in this update
 - Added `AudioPlayer` capability agent.
   - Supports iHeartRadio.
 - `StateSynchronizer` has been updated to better enforce that `System.SynchronizeState`is the first Event sent on a connection to AVS.
 - Additional tests have been added to `ACL`.
 - The `Sample App` has been updated with several small fixes and improvements.
 - `ADSL` was updated such that all directives are now blocked while the handling of previous `SpeechSynthesizer.Speak`
    directives complete. Because any directive may now be blocked, the `preHandleDirective() / handleDirective()` path
    is now used for handling all directives.
 - Fixes for the following GitHub issues:
   - #44.
 - A bug causing `ACL` to not send a ping to AVS every 5 minutes, leading to periodic server disconnects, was fixed.
 - Subtle race condition issues were addressed in the `Executor` class, resolving some intermittent crashes.
@scotthea-amazon
Copy link
Contributor

Hello Juliano,

The fix for this was included in the 1.0.0 release.

Thank you,
-SWH

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants