My skill allows pausing an MP3 (eg for a phone call) and then resuming from the point we left off; I capture the offset and then feed it back in with the play request.

If the resume occurs before other Alexa operations are used, this works well.

But if the user has asked Alexa to do other things, those skills may have played their own MP3's. When that happens it can take a painfully long time for Alexa to find its place and resume playing, particularly when the user paused (for example) 45 minutes into an hour-long episode.

I presume this is because only one MP3 is cached in the Alexa hardware at a time, and jumping into the middle of a non-cached MP3 requires decompressing the audio up to the point where you want to resume playing.

Is there anything I, or Amazon, can do to improve this situation, short of breaking each of my programs up into smaller MP3s to set an upper limit on the resume time (which I don't have budget for, and which would conflict with other players' use of this data)?

Failing that, is there any way to determine whether the MP3 is or isn't cached before we start playing it, so we can guess whether we should ask the user to be patient while Alexa searches for the point where it paused?

Or give us the option of playing a sound-effect while it seeks? Tape fast-forward, maybe...

The current behavior, a frustrating silence while waiting to see if the request will work or not, is just not great UI design.

There are two use cases that come to mind:
1. A Skill could be developed that could help tune a musical instrument. The user would specify a note they will play, play it, and then the Skill would tell the user whether the note played was correct, sharp, or flat.
2. A Skill could be developed to tell the user the key in which they are singing. There could be a few well-known songs from which the user would choose to sing, and the Skill would tell the user the key they are singing. This would be great for some of us non-musician karaoke fans!

It'd be great to have a schema allowing the notification to the user that a command requested via a 3p skill has been executed successfully or not. For example

U: "Alexa, ask {my skill} to set the temperature of my oven to 220C and tell me when it's ready to bake"
A: "Ok, I'll send you a notification when the oven is ready"
... several minutes later...
<yellow light>
U: "Alexa, what's new?"
A: "You have one new notification from your oven. The {command} has been executed on {target}"

or

A: "one new notification from your oven. Something went wrong with {command}: please ask {your skill} for more info"

The ideal schema would look like

{
"event": {
"name": "AMAZON.RemoteCommand.Executed",
"payload": {
"remoteCommand": {
"command": "localizedattribute:command",
"target": "localizedattribute:target",
"parameter" : "220 C"
}
}
},
"localizedAttributes": [
{
"locale": "en-US",
"command": "Set Temperature"
},
{
"locale": "en-US",
"target": "your Oven"
},
]
}

I am a totally blind software developer and I want to learn how to develop Alexa skills. On the developer console when I go to create a new skill and enter the initial information about it, there is a visual only CAPTCHA to resolve before I can create the skill. I can't see the images so can't complete this CAPTCHA. Other CAPTCHAs I've found on Amazon have an audio option which is very good.

Can we have an audio alternative on the CAPTCHA please when creating a new skill. Better still, maybe no CAPTCHA at all. After all, whoever is doing this on the developer console is already logged in and known to Amazon. So is a CAPTCHA really needed here?

This same CAPTCHA seems to occur in other situations involving creating/modifying Alexa skills:
* I can write Lambda functions in the AWS console without this problem. If I create my own LAMBDA function to host a skill, I still have to create the skill so it's the same problem.
* I have worked out how to create a new skill by installing the ASK CLI on my computer and creating a skill from there. That's fine, but if for some reason I want to edit or do other things to it in the developer console, this requires some sort of conversion process. But that process also involves the same CAPTCHA.

I actually think this is more of a fix request than a feature request. I am only asking for the same feature that other developers already have. Alexa's own accessibility guidelines should require all CAPTCHAs to have at least an audio alternative to a visual only CAPTCHA.

Finally I would comment that there are many blind software developers around the world and it's likely a number of us are attracted to writing skills for a machine that talks. Amazon generally demonstrates a strong commitment to accessibility. This is a major barrier for totally blind developers so it should be fixed without delay. But there are other accessibility issues I've noticed in the Alexa developer console. I would ask Amazon to ensure the developer console meets widelyh accepted accessibility guidelines from now on.

Allow skills to be context sensitive based on the setting/location of the given alexa device.

For example, if you have an echo dot in each bedroom of a 3 bedroom house, it would be a lot more intuitive to be able to walk into the bedroom and say "Alexa, turn on the lights" - with the context being associated with the echo dot in that room - inferring just the lights in that room, not all lights in the house.

In addition, you'd still have the traditional tagging such that from elsewhere you would have to provide context - so from the kitchen, the message might be "Alexa, turn off the lights in bedroom one".

But in the kitchen, if you said "Alexa turn on the lights", this would, naturally, infer you only want the kitchen lights on. :)