Cleanly quitting an audio stream

What’s the correct method of quitting an audio stream so as to also exit the skill cleanly?
I find that telling it to Stop will cut the stream, but the skill will always fail to load again when invoked: “There was a problem with the requested skill’s response”.
Additionally, I find an Invalid Directive in my activity log:
“No other directives are allowed to be specified with a Dialog directive. The following Directives were returned [AudioPlayer.Stop]”.
Calling the skill a second time allows me back in.

From a user-perspective, having handling following a stoppage (cutting the stream) and having a closing greeting is usually a great experience. Are you able to share a screenshot of how you have the Audio Player currently set up on Voiceflow and connected path(s)?


I’ve since been experimenting with what I can do with Next and Previous.
Not really what I’m after. I’d rather I was able to handle stoppages properly and having the skill restart when called again without error.

Not even the blocks after “Next” behave as expected.
If I say no to the following prompt, the audio stream continues playing.
Saying “Alexa, stop” only takes it to the beginning of the skill and on the first prompt, the stream just continues playing.
The only way to get the speaker to be quiet is to ask Alexa to play something else.

Saying previous to “New Block 11” brings Alexa to respond: "There was a problem with the requested skill’s response”.

I’ve encountered similar issues too. I’ve never fully understood why a stream persists after you trigger the “end session” flow, or even weirder, why it persists sometimes after your skill prematurely errors/exists itself out. Is it something at the VF layer? Something with Alexa? User behavior caused?

Try to

1/ Add the “audioplayer.stop” directive to your “end session" flow at least. And - if you insert this at other parts of your skill, you have to make sure it doesn’t mess with the audioplayer’s functionality since there’s stuff happening under the hood on the Alexa side, i.e. buffering/prepping the stream before it actually plays, and setting up for the next stream, etc.

2/ Wait for Alexa to finish her prompt before answering (as the user). Never barge in with your answers, e.g. “Alexa, yes!”, especially if your skill uses the audioplayer. In general, I’ve found that barge-in commands, buckles under stress testing, e.g. multiple continuous barge-in commands, and makes for a less stable experience.

Terry

Meanwhile, on other fronts :slight_smile:

Thanks for your contribution, Tezza! Adding the audioplayer.stop directive did the trick to cut the audiostream.

I’m still looking for a clean way of leaving the skill should the user say “Alexa, Stop!” in the middle of an audiostream, since it still prevents the skill from loading again the next time it’s called. (Please refer to my first post). I’ve tried adding a Stop Intent, but it’s unrecognised at that stage - I think it’s because Alexa may have officially “departed” the skill once an audiostream plays.

How do other skills manage this problem?

Awesome - I’m glad that helped :slight_smile:

1/ Re leaving the skill from in the audiostream - this isn’t possible given how Alexa is architected. Yes, you are right, when you enter the audioplayer, you are technically no longer in your skill and are inside their audioplayer environment. In other words, the intents inside the audioplayer are all built-in and the major ways it behaves is preconfigured:

2/ There are other related constraints - or benefits, depending how you look at it. For example, even if you exit the audio player, AND even if you exit your skill after this, the audio player and your skill are still readily invocable (i.e. without your invocation name). That means if you say “Alexa, Next” or “Alexa, Resume” after you exit your skill, and your skill leverages the audioplayer, your skill will restart seemingly from nowhere. See some relavant verbiage:

"When your skill sends a Play directive to begin playback, the Alexa service sends the audio stream to the device for playback. Once the session ends normally (for instance, if your response included the shouldEndSession flag set to true ), Alexa remembers that your skill started the playback until the user does one of the following:

  • Invokes audio playback with a different skill.
  • Invokes another service that streams audio, such as the built-in music service or the flash briefing.
  • Reboots the device.

I suspect that it was architected like this because of the main use case is listening to music, what Alexa is mainly used for today, and what you’re designing it for too (radio streaming), I believe.

Terry

1 Like

I might consider using AudioPlayer.ClearQueue/CLEAR_ALL instead of STOP depending on where you are in your flow. In my skill, I have both Cancel and Stop execute the same flow. If I use Audioplayer.stop before the user has started an audio stream, Alexa tells me there was a problem with the skill. With Clearqueue/CLEAR_ALL the doc says “clears the entire playback queue and stops the currently playing stream (if applicable).” In my scenario, cancel or stop before I start a stream no longer throws an error and after a stream is playing it stops it.

{
“type”: “AudioPlayer.ClearQueue”,
“clearBehavior” : “CLEAR_ALL”
}

I’m having a very similar problem when trying to create the Google Action.
Whenever I call Stop or Quit whilst playing a webstream, I’m told is not responding.
How should I go about stopping the stream cleanly?
The blocks are very similar to the Alexa Skill one I posted above.
I’ve even tried to create a new intent for Stop/Quit, but I think those phrases may be reserved.