-
Notifications
You must be signed in to change notification settings - Fork 605
AVS cannot go into Speaking state #1143
Comments
This log is from our own DUT. Almost the same symptom, but not sure if it's the same root cause. |
Hi @zeusshuang, The Speak directive is being received, but the error starts at
This causes the Speak to be canceled. It looks to be related to the TemplateRuntime directive which comes in shortly after the Speak. Did you see these errors in previous versions of the SDK? |
Hi @kjkh , No, this symptom is from SDK 1.11. |
Hi @zeusshuang , checking no-speaking-DUT log looks like the Speak directive is being canceled by the next listening request. Listening...Thinking...2018-12-28 22:45:58.329 [ 23] I DirectiveSequencer:onDirective:avs_current_directive_namespace=SpeechSynthesizer Listening...2018-12-28 22:46:23.240 [ 3] I DirectiveRouter:cancelDirective:messageId=48f3a40e-fb47-4740-b4d7-ecbad8404729,action=calling From what I am seeing there is an utterance, so it goes to Listening state. Can you increase your test utterance interval to >10 seconds and see if this still happens? |
Is the issue fixed by increase the interval? we also have this issue here with sdk 1.11. 1.09 doesn't have such problem. It seems not interval problem. |
@kjkh @visayamv I also had the same problem with SDK version 1.11. 2019-01-09 07:04:02.600 [ e] I DirectiveSequencer:onDirective:directive={"namespace:"TemplateRuntime",name:"RenderTemplate",messageId:"e2699ef1-7a74-40de-a7eb-7cd95da99038",dialogRequestId:"69b85c19-bd67-4f9a-bf5b-3cb8032bc819"} 2019-01-09 07:04:02.603 [ 13] I NtkMediaPlayer:stopCalled |
Hi @liunanxuan , I see there is a ########################### in your log. Was any speech played ? |
I have filed an internal ticket to investigate further. In the meantime, @liunanxuan , can you provide an answer to the question above? |
Hi @visayamv ,
For this question, it looks okay while the interval is > 10 seconds by normal test. |
It does enter the speak state. However, when the instruction is processed, the instruction of the speak is cancelled. Causes the speak to call stopplaying. ================ |
@visayamv |
@visayamv please you see log. |
Hi @liunanxuan , i think you're analysis is right. We'll dig deeper into this. |
@visayamv Thanks for the support. I hope that you can solve it as soon as possible. This problem is very serious. All direcives that were previously enqueued will be cancelled. |
Hi @liunanxuan , |
@zeusshuang This problem is probabilistic. There is no need to restart sampleAPP. My situation here has the opportunity to return to normal under the next command。. |
Hi @visayamv , I have a new log for this case, it run about 34 hours, and 135-140 trigger events per hour (all are Q&A case, no play music), finally it seems try to go into speaking state (?) but never return forever. you can see the last speaking is at line#475416 (UTC 2019-01-11 20:39:00), and it seems it's working. (due to it's auto-test, I was not nearby the DUT). From Alexa APP History, the last command is: Alexa, launch daily word (The time is 20:39, same as log.) It's SDK 1.11 |
Hi @visayamv , |
following my fail log hours ago, I left this DUT static there (still under stuck state), and it seemes it will un-lack every hour, but it still cannot recovery and will failed a listening state. |
Hi @zeusshuang, I have taken a look into this, and it appears to me that the SpeechSynthesizer is related to this problem. I do think this is the same issue as reported in #948. In many of the logfiles you've uploaded, I have noticed the following error trace (which occurs only once): followed by repeated error trace: I believe that this indicates that the SpeechSynthesizer (SS) fails to release the dialog channel, which AIP (recognizer) needs to begin listening. SS and AIP share the Dialog channel, and so must gracefully release it when they are done. My take right now is that this is caused by a missing state transition with the SS MediaPlayer, resulting in the SS being locked up. I will need to dig deeper into the code, alongside your logs, to verify. I wanted to share these thoughts however today in case they help you to move forward independently. I will close out #948, as we will track the issue here. Thank you again for your patience in raising this issue to us. |
Changes in this update: **Enhancements** * Support was added for the `fr_CA` locale. * The Executor has been optimized to run a single thread when there are active job in the queue, and to remain idle when there are not active jobs. * An additional parameter of `alertType` has been added to the Alerts capability agent. This will allow observers of alerts to know the type of alert being delivered. * Support for programmatic unload and load of PulseAudio Bluetooth modules was added. To enable this feature, there is a [new CMake option](https://github.com/alexa/avs-device-sdk/wiki/CMake-parameters#bluetooth): `BLUETOOTH_BLUEZ_PULSEAUDIO_OVERRIDE_ENDPOINTS`. Note that [libpulse-dev is a required dependency](https://github.com/alexa/avs-device-sdk/wiki/Dependencies#bluetooth) of this feature. * An observer interface was added for when an active Bluetooth device connects and disconnects. * The `BluetoothDeviceManagerInterface` instantiation was moved from `DefaultClient` to `SampleApp` to allow applications to override it. * The `MediaPlayerInterface` now supports repeating playback of URL sources. * The Kitt.AI wake word engine (WWE) is now compatible with GCC5+. * Stop of ongoing alerts, management of MessageObservers, and management of CallStateObservers have been exposed through DefaultClient. **Bug Fixes** * [Issue 953](#953) - The `MediaPlayerInterface` requirement that callbacks not be made upon a callers thread has been removed. * [Issue 1136](#1136) - Added a missing default virtual destructor. * [Issue 1140](#1140) - Fixed an issue where DND states were not synchronized to the AVS cloud after device reset. * [Issue 1143](#1143) - Fixed an issue in which the SpeechSynthesizer couldn't enter a sleeping state. * [Issue 1183](#1183) - Fixed an issue where alarm is not sounding for certain timezones * Changing an alert's volume from the Alexa app now works when an alert is playing. * Added missing shutdown handling for ContentDecrypter to prevent the `Stop` command from triggering a crash when SAMPLE-AES encrypted content was streaming. * Fixed a bug where if the Notifications database is empty, due to a crash or corruption, the SDK initialization process enters an infinite loop when it retries to get context from the Notifications capability agent. * Fixed a race condition that caused `AlertsRenderer` observers to miss notification that an alert has been completed. **Known Issues** * `PlaylistParser` and `IterativePlaylistParser` generate two HTTP requests (one to fetch the content type, and one to fetch the audio data) for each audio stream played. * Music playback history isn't being displayed in the Alexa app for certain account and device types. * On GCC 8+, issues related to `-Wclass-memaccess` will trigger warnings. However, this won't cause the build to fail and these warnings can be ignored. * Android error ("libDefaultClient.so" not found) can be resolved by upgrading to ADB version 1.0.40 * When network connection is lost, lost connection status is not returned via local TTS. * `ACL` may encounter issues if audio attachments are received but not consumed. * `SpeechSynthesizerState` currently uses `GAINING_FOCUS` and `LOSING_FOCUS` as a workaround for handling intermediate state. These states may be removed in a future release. * The Alexa app doesn't always indicate when a device is successfully connected via Bluetooth. * Connecting a product to streaming media via Bluetooth will sometimes stop media playback within the source application. Resuming playback through the source application or toggling next/previous will correct playback. * When a source device is streaming silence via Bluetooth, the Alexa app indicates that audio content is streaming. * The Bluetooth agent assumes that the Bluetooth adapter is always connected to a power source. Disconnecting from a power source during operation is not yet supported. * On some products, interrupted Bluetooth playback may not resume if other content is locally streamed. * `make integration` is currently not available for Android. In order to run integration tests on Android, you'll need to manually upload the test binary file along with any input file. At that point, the adb can be used to run the integration tests. * On Raspberry Pi running Android Things with HDMI output audio, beginning of speech is truncated when Alexa responds to user text-to-speech (TTS). * When the sample app is restarted and network connection is lost, Reminder TTS does not play. Instead, the default alarm tone will play twice.
Thanks for opening this issue. It has been fixed in our v1.12 release. Thanks! |
Hi AVS team,
No sure if it's related to case #948
But I actually test it for case#948 , but the symptom is a little bit as case#948.
--> continue to play this youtube video: https://www.youtube.com/watch?v=BNZGrN8E_EM
After hours, AVS will not go into Speaking state. Sometimes, it only stop at Listening state, or Thinking state.
Will not return normal after stopped test for hours.
While this symptom happens, it still can see History from APP, so it seems it will still send audio to the cloud site.
attached log is from Pi3, the log is huge under DEBUG9, you can find last Speaking at line 2018915
1228_pi - Copy.zip
The text was updated successfully, but these errors were encountered: