When requesting my flash briefing, I kept getting errors like this:

[57716ee8] core input error: open of `/tmp/AlexaPi-runtime-etC4np/DailyBriefingPrompt.51ed008e-1138-4784-a983-912fcc310e3c:Say:DAILYBRIEFING:DailyBriefingIntroduction_1235550225.mp3' failed
[57716ee8] core input error: Your input can't be opened
[57716ee8] core input error: VLC is unable to open the MRL '/tmp/AlexaPi-runtime-etC4np/DailyBriefingPrompt.51ed008e-1138-4784-a983-912fcc310e3c:Say:DAILYBRIEFING:DailyBriefingIntroduction_1235550225.mp3'. Che
ck the log for details.

On a hunch, since it referred to the path as an MRL, I wondered about the ":" characters in the filename and stuck "file://" in front of tmp_path at the following places in main.py and it seems to have fixed it:

# grep -n file: main.py 
267:                                            play_audio("file://" + tmp_path + directive['payload']['audioContent'].lstrip("cid:")+".mp3")
287:                                                            content = "file://" + tmp_path + stream['streamUrl'].lstrip("cid:")+".mp3"
315:                                    content = "file://" + tmp_path + stream['streamUrl'].lstrip("cid:")+".mp3"

I can submit this as a pull request if you prefer, but since I am running this on a Raspberry Pi 3 with Arch Linux, I wanted to first check and see if anyone else has seen this behavior (or is it something specific to my setup?) and get some input as to whether this is the proper fix... my experience with Python is extremely limited and new.

mDNS https://en.wikipedia.org/wiki/Multicast_DNS Makes things a lot easier when creating the Amazon oAuth security profile.

Instead of using the IP address you can use the hostname of the device in the .local domain eg http://raspberrypi.local This way it doesn't matter if the IP address changes and there is less scope for confusion.

I suggest we change the setup script and docs to tell users to add raspberrypi.local and localhost as the 2 hostnames.

This will need some testing to ensure it works with the operating systems that users will be using on their desktops to browse from.

• OS X is OK
• Windows 10 ?
• Windows 8?
• Windows 7
• Windows Vista / XP (do we care?) - I don't think we do - they're outdated, I think 7 is the minimum we should support if it works there; @renekliment
• Ubuntu 16.10 ??
• Ubuntu 16.04 (LTS) ??
• Ubuntu 15.10 ?? old, who cares
• Ubuntu 15.04 ?? old, who cares
• Ubuntu 14.04 (LTS) ??
• Arch Linux - needs to be installed manually, which I don't see as a problem, since Arch is DIY distro for advanced users, where they have to do everything themselves; we can just leave a note for them to install it
• Fedora ??

Any others??

There's also a question around network support, I don't think that mDNS needs any special support in the router other than broadcast addresses not being blocked, this might not work on corporate LANs or other more managed networks but so long as its suported on the typical domestic setup I think we should go with it. Localhost is there as a fallback and using IP address for advanced users in the docs?.

While waiting for Echo push notifications for a year now, I did a small extension of https://github.com/sammachin/AlexaPi to essentially enable push by submitting pre-recorded questions to AVS when triggered by an event. It worked pretty well, but the problem I faced is that response time is slow, typically 5 or even 10 seconds. I believe the approach used in https://github.com/alexa/alexa-avs-sample-app address those performance issues by streaming the audio to AVS (and maybe also streaming the response back, I asked that question, hoping to hear back from them). The approach is explained here - https://forums.developer.amazon.com/questions/10982/avs-takes-too-much-time-to-respond.html.

Is streaming audio to and from AVS in the plan for the new evolving AlexaPi?

Probably use https://docs.python.org/2/library/logging.html
As @lechat mentioned in #67.

I'd personally like it if we could also have colors with this new thing.

Just tried the latest version on a pc running ubuntu 14.04. It says hello before exiting with the following message:
line 498.. inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NORMAL, config['sound']['device'])
alsaaudio.ALSAAudioError: Device or resource busy [plughw:1]

Hi i could install all the stuff via SSH, then it did ask me to authorize, that's what i did. So i did close the script after with "ctrl + c" script ended but nothing happened.
So i did try to run the

python main.py

Traceback (most recent call last):
  File "main.py", line 84, in <module>
    decoder = Decoder(config)
  File "/usr/local/lib/python2.7/dist-packages/pocketsphinx/pocketsphinx.py", line 228, in __init__
    this = _pocketsphinx.new_Decoder(*args)
RuntimeError: new_Decoder returned -1

So i also did try to run

* sudo ./monitorAlexa.sh*
but the log show

Starting Alexa in silent mode...
python: can't open file '/root/AlexaPi/main.py': [Errno 2] No such file or directory

let me add i use @maso27 fork

I'd like to abstract the notifications out from the main code base into their own functions that then call whatever hardware we might be using, so I propose a number of functions like ind_record_on ind_record_off ind_ready etc.

Currently, it's kinda messy. We need to make it a little more general / modular.

We definitely need to support:

• device_platform triggering
• pocketsphinx / snowboy triggering
• keypress triggering when not running in daemon mode

There are various forks of the original project. Moreover, there are forks of those forks. The goal of this is that when a common code base is provided, we can unify the work of so many people, so we can work together to be effective, do not duplicate work and not to confuse end users.

Known forks that we would like to merge eventually (actually rather soon):

• AlexaPi for Raspberry Pi
  • @flooie https://github.com/flooie/AlexaPi/
  • @novaspirit https://github.com/novaspirit/AlexaPi
    • @PhyberApex https://github.com/PhyberApex/AlexaPi/tree/voice-activated
• @sammachin https://github.com/sammachin/AlexaCHIP
  • @jitto https://github.com/jitto/AlexaCHIP
  • @johnwskinner https://github.com/johnwskinner/AlexaCHIP
  • @billzajac https://github.com/billzajac/AlexaCHIP
• @dony71 https://github.com/dony71/AlexaOPi
  • @GadgetReactor https://github.com/GadgetReactor/AlexaOPi
• @pedrominatel https://github.com/pedrominatel/intel-edison-alexa
• @respeaker https://github.com/respeaker/Alexa

If you are one of the devs mentioned above and seeing this, please consider joining forces with us. The new code base that is gonna support multiple devices and OS platforms is gonna be ready in a week or two for testing and implementing new things. This is a note so you might consider this. If you have any questions, do not hesitate to ask in comments. Thank you!

If I first ask Alexa to play music from tune in, then ask Alexa to pause it and after that ask for flash brief, Alexa starts reading the brief and also opens tune in again, saying the radio name and playing music,
If I ask Alexa to stop music , it responds that it can only stop music if music is playing

This can be done once #30 gets merged. DONE
Might be a good idea to wait for #24 to be done. It is a good idea, but it can be later easily adjusted.
A sketch however can be done now.

Make a new device platform that uses one of these:

• https://github.com/derekstavis/python-sysfs-gpio
• https://github.com/vitiral/gpio
• https://github.com/vsergeev/python-periphery

It will be similar to the raspberrypi platform. I suppose LEDs are gonna be easy, the triggering (button or whatever) might a teeny-tiny bit tricky (debouncing, not missing it while polling the thing).

We also need to solve permissions to /sys/class/gpio stuff. We're gonna do it the way RPi does it. We need

• gpio group
• user alexapi in that group
• ~group of the corresponding stuff changed to gpio - google udev GPIO; on OpenWRT there's an udev alternative~~

This is DONE already.

We could then use this for anything that has GPIO exposed via standard kernel interface.

I'm not sure what the advantage of RPi.GPIO library and the clones is. I know it touches /dev/mem or /dev/gpiomem, but what for? Does it go around /sys/class/gpio?
We could even use this as an alternative for boards that have the python library (Raspberry Pi, Orange Pi, Turris router).

I'm not sure how the python library works. If it just polls the thing, it might be a good idea to implement inotify there.

An article in Czech: https://blog.frantovo.cz/c/355/GPIO%20v%C2%A0Raspberry%20Pi%20jako%20soubory (good for resources and commands)

I've installed the package exactly as outlined however I'm getting the following error message:

Oct 09 23:25:11 raspberrypi python[576]: alsaaudio.ALSAAudioError: Input/output error [plughw:1]
Oct 09 23:25:11 raspberrypi systemd[1]: AlexaPi.service: main process exited, code=exited, status=1/FAILURE
Oct 09 23:25:11 raspberrypi systemd[1]: Unit AlexaPi.service entered failed state.
Oct 09 23:25:12 raspberrypi systemd[1]: AlexaPi.service holdoff time over, scheduling restart.
Oct 09 23:25:12 raspberrypi systemd[1]: Stopping Alexa client for all your devices...
Oct 09 23:25:12 raspberrypi systemd[1]: Starting Alexa client for all your devices...
Oct 09 23:25:12 raspberrypi systemd[1]: Started Alexa client for all your devices.
Oct 09 23:25:17 raspberrypi python[1321]: Checking Internet Connection...
Oct 09 23:25:17 raspberrypi python[1321]: Connection OK
Oct 09 23:25:17 raspberrypi python[1321]: Home directory not accessible: Permission denied
Oct 09 23:25:17 raspberrypi python[1321]: W: [pulseaudio] core-util.c: Failed to open configuration file '/home/alexapi/.config/pulse//daemon.conf': Permission denied
Oct 09 23:25:17 raspberrypi python[1321]: W: [pulseaudio] daemon-conf.c: Failed to open configuration file: Permission denied
Oct 09 23:25:17 raspberrypi python[1321]: Home directory not accessible: Permission denied
Oct 09 23:25:17 raspberrypi python[1321]: W: [pulseaudio] core-util.c: Failed to open configuration file '/home/alexapi/.config/pulse//daemon.conf': Permission denied
Oct 09 23:25:17 raspberrypi python[1321]: W: [pulseaudio] daemon-conf.c: Failed to open configuration file: Permission denied
Oct 09 23:25:18 raspberrypi python[1321]: Home directory not accessible: Permission denied
Oct 09 23:25:18 raspberrypi python[1321]: W: [pulseaudio] core-util.c: Failed to open configuration file '/home/alexapi/.config/pulse//daemon.conf': Permission denied
Oct 09 23:25:18 raspberrypi python[1321]: W: [pulseaudio] daemon-conf.c: Failed to open configuration file: Permission denied

Anyone have any ideas?

Have you folks put thought into some type of module system for expanding AlexaPi?
For example, I use an oled display on some builds, an rfid read/writer on others.
I do not want to pullute the effort going into the refactor right now, I just wanted to put the topic up for discussion.

Thoughts?

I'm getting a crash immediatelly after Alexa's "yes" response. Any suggestions?

('setwarnings', (False,), {})
('cleanup', (), {})
('setmode', ('BCM',), {})
('setup', (18, 'IN'), {'pull_up_down': 'PUD_UP'})
('setup', ([24, 25], 'OUT'), {})
('output', ([24, 25], 'LOW'), {})
Checking Internet Connection...
Connection OK
('output', (24, 'HIGH'), {})
('output', (24, 'LOW'), {})
('output', (24, 'HIGH'), {})
('output', (24, 'LOW'), {})
('output', (24, 'HIGH'), {})
('output', (24, 'LOW'), {})
('output', (24, 'HIGH'), {})
('output', (24, 'LOW'), {})
('output', (24, 'HIGH'), {})
('output', (24, 'LOW'), {})
Play_Audio Request for: /opt/AlexaPi/src/resources/hello.mp3
('output', (24, 'HIGH'), {})
Player State: State.Opening
Player State: State.Playing
Player State: State.Ended
('output', (24, 'LOW'), {})
('add_event_detect', (18, 'FALLING'), {'callback': <function detect_button at 0xb64a5f0c>, 'bouncetime': 100})
Play_Audio Request for: /opt/AlexaPi/src/resources/alexayes.mp3
('output', (24, 'HIGH'), {})
Player State: State.Opening
Player State: State.Playing
Player State: State.Ended
('output', (24, 'LOW'), {})
detected the edge, setting up audio
Starting to listen...
Traceback (most recent call last):
  File "main.py", line 603, in <module>
    loop()
  File "main.py", line 558, in loop
    silence_listener(VAD_THROWAWAY_FRAMES)
  File "main.py", line 469, in silence_listener
    isSpeech = vad.is_speech(data, VAD_SAMPLERATE)
  File "/usr/local/lib/python2.7/dist-packages/webrtcvad.py", line 27, in is_speech
    return _webrtcvad.process(self._vad, sample_rate, buf, length)
webrtcvad.Error: Error while processing frame

Discussion for running on the Pi Zero.
Audio/USB Hub/Power/etc...

Component-based modular expansion design for Alexa-Pi project.

Goals:
• make complexity/diversity more manageable.
• facilitate parallel work.
• accommodate future (unknowable) additions.

From decentralizing critical knowledge to standardizing upgrades and replacement components, modular systems have proved themselves effective across industry. It is important, however, that this modularity is realized and implemented at both the correct level and degree of granularity. (that sounds horrible, but I will attempt to clarify)

One of the core goals of this project is to support a broad range of hardware platforms. There are bound to be discrepancies and differences of opinion as to the degree of attack. This is mine.

I feel a strong approach is to simplify each "platform" to the core functionality of the base hardware. This is a common hardware arrangement that can easily be spec'd against. If I purchase a Raspberry Pi3 in Oregon, it is going to be the same as my friend's in Bangalore. By concentrating on providing an accurate core for the base hardware platform, rather, we simplify development, unit testing, and increase reliability in the project.

Complexity is inherent in system/project design, and though it cannot be eliminated (or even reduced in some cases), it may be moved between regions/layers allowing more defined levels of abstraction. By shifting the onus of compatibility to the module or component level, we reduce the reliance on the core of the project to play "traffic-cop". It is no longer up to the core to maintain compatibility with an increasingly large number of extensions and add-ons that must be tested/approved. This is shifted to the actor bringing the module into the system, and is their responsibility to test and relay to what degree it "complies" with the core spec.

This is advantageous on a few levels. No longer does the core have to maintain a large amount of "one-off" manifests. The barrier to entry is much lower, as the core build is linked directly to a mass-produced piece of hardware. Any additional modules may be applied in a "package manager" style (here is some complexity creeping back in). The manager would have to gauge what modules were being loaded to identify conflicts, but it would be provided manifest files for each module in the system according to how they interface with the core. Each module would be responsible for its own description.

There are a number of solutions in varying degrees of effectiveness out there. MRAA (an Intel project to unify GPIO pin reference), Samsung's ARTIK (uses manifests to bridge IoT protocol gaps), or even Insteon that just incorporates X10 as a throwback to a passing technology.

Thoughts? Ideas?

• write a systemd unit file that's gonna be used on the vast majority of platforms
• refactor the classic init scripts along with monitor
  • when issuing /etc/init.d/AlexaPi stop, the monitor should stop too
    • should we get rid of /tmp/dont_start?
  • merge initd_alexa.sh and initd_alexa_monitored.sh, because they're doing almost the same thing - use some configuration handling in the init script to find out if the monitor should be started too; where do we store the config option? should use config from #11; setup script needs to reflect this too
  • use a .pid file which is unique - possibly /tmp/AlexaPi.pid
    • gets rid of pgrep python -a | grep main.py which could potentially hit another app
    • when the app starts a .pid file is written
    • the monitor checks that the file exists and a process with that PID exists, if not -> start an instance

• Write it to be very modular.
• Do it is as platform-independent as possible.
• It will have to implement some checks - or should we ask the user about everything?
• In python? Maybe in a later phase if it makes sense?
• Needs to setup OS platforms (covers requirements install for major systems)
  • try to do as much we can via pip
  • apt-get based systems
  • pacman/yaourt based systems
  • yum (or whatever Fedora uses) based systems
  • Mason wrote a pretty comprehensive manual for Arch on RPi: Arch setup and making it work under the alexapi user
• Needs to also setup device platforms.
  • Don't forget to do the install of GPIO libraries for RPi and OrangePi
  • Apart from the RPi udev/permissions stuff on Arch, we'll have to do a similar thing for general sysfs gpio platforms (#37)

As it turns out, a lot of people are having troubles setting up the audio devices correctly.
We should provide a tool, that figures out what the correct device name should be and optionally write it to config. EDIT: With souddevice, selecting recording device should be super easy, so there is probably no tool needed.

Possible features:

• select playback device (probably play sound on each?)
• select recording device (use sounddevice for that)
• record & play to hear the recording
• adjust some levels like recording level?

With sounddevice I hope setting up audio (not counting PA) will no longer be a problem, so this task may become irrelevant.

This is independent of any other issues, so anyone is welcome to take this up any time.

Right now, there's a lot of intertwined code regarding AVS communication (requests, response handling), triggering, recording, playback.

Splitting AVS into a separate module is especially important since we could then potentially support other services if available (Google Assistant for example), but what's more important, we could then start the work on new AVS API without much problems.

Hello!

I'm having a problem after the installation. Alexa doesn't to any voice command. I tried to use the /opt/AlexaPi/src/main.py -d command and that's what the terminal is showing me

pi@raspberrypi:~ $ /opt/AlexaPi/src/main.py -d Checking Internet Connection... Connection OK Play_Audio Request for: /opt/AlexaPi/src/resources/hello.mp3 Player State: State.Opening Player State: State.Playing Player State: State.Ended Traceback (most recent call last): File "/opt/AlexaPi/src/main.py", line 595, in <module> loop() File "/opt/AlexaPi/src/main.py", line 510, in loop inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NORMAL, config['sound']['input_device']) alsaaudio.ALSAAudioError: Device or resource busy [plughw:1]

I've tried changing the input to default but it still doesn't work. Could you help me fix this issue ?

Thanks a lot !

Running the latest code, and I have everything but the hotword detection working. If I use the button, everything is great, but for some reason, no matter what I do, it wont recognize "Alexa"

I'm not even sure where I can start with troubleshooting.

I am using a Blue Snowball microphone which is having no problems when saying any commands, but nothing happens at all with the hotword.

Any ideas on where I can start?

Hi,
I've finally got AlexaPi working after a few separate attempts due to various reasons.
It all works but I literally have to shout at my microphone to get the keyphrase to be detected. How exactly do I change the sensitivity of my microphone? It's a decent microphone and I don't normally have any issues like this.

I realise this isn't directly related to AlexaPi but I have no idea what AlexaPi uses and how I'd change the settings for it...

Interestingly it seems much more responsive when I run it directly and not the always on service, but maybe thats just coincidence.

• EDIT *

Just to add to this... It actually appears to be only having a problem with the keyword. When I'm giving the actual Alexa commands it all appears to work fine. Does anyone else find that the keyword detection is a little dodgy? Or could it just be my northern English accent combined with a cold? haha.

I am using a usb sound card an the card has a LED when recording the LED blinks so i used it with the java version the original obe by amaxon and its working but wih alexa pi not i tried every thing with the yaml file but with no luck i used plughw:1 and 1,0 but nothing happened

So I've been reading through Alexa Voice Service Functional Design Guide
and Alexa Voice Service Terms and Agreements and there's a lot of things that kinda suck that we don't have (yet) like:

• you can't change the wake word (does this mean having this option in config file is a no-go?),
• you have to indicate recording start and stop,
• the user needs to be able to mute the mic and this needs to be indicated,
• etc.

So I was thinking if any of you know if we have to also conform with those two documents even when we are just messing with it, not doing anything commercial. We can probably implement those things that we don't have yet, but it's gonna take some time. Is there an issue that we're doing the development "out in open" and people can use it now even if it doesn't comply with those two documents?

Also there could be a problem that the users could simply not connect the LEDs or whatever, so they'd lose the indication. Is that their problem then?

And there's also

Your Product must not have a product name or logo that is a variant of, or confusingly similar to, “Alexa”, “Echo,” “Amazon” or another Amazon trademark or logo.

@sammachin I believe you are the most experienced in this?

Hi,
Solved my own issue as i was writing it up

I had no audiooutput, but i could tell from the LED that it was recording and playing back.
Green and Red (I miss the Yellow for "transmitting)
It also would give a Green LED if i just said "Alexa"

The issue was that i had a HDMI monitor connected to set up the WI-FI. which i found out, as i'm sure most of you guys know already, that that kills the Audio Jack output.

Might be worth a mention in the instructions for others that are like me and just starting out using Pi.

We actually use this for recording only, so switching the lib will have no impact on playback.

Done in #180 (only in dev branch actually)

This is an extension and generalization of #22 and probably will be similar to device_platforms.

This covers:

• Pass a parameter to play_audio() which indicates if it's just Alexa speech or a music file.

• Implement corresponding config logic to enable users to use a different playback device for Alexa and for music.

  A use case for this is having an always on non-powered / low-power speaker for communicating with Alexa and having like a solid room stereo for music. You probably don't want Alexa shouting from your huge speakers and don't want to have them on all the time due to power consumption, the sound they make while they're on (mine are buzzing a little, ...), ...

• Implement audio_handlers. One of them would be the thing we have now (with the enhancements mentioned above), that is vlc if I'm correct.

An audio_handler that I'm personally gonna use is a thing that uses local vlc for Alexa speaking (what we have now) and my network mpd server for music. That way I can then control the playback with other mpd clients and my music playback is unified - I don't want multiple apps handling that. I'm not sure if it's okay with AVS ToC, but I'll investigate when we get there. If it is, I'll distribute it in the repo.

Users can then use our audio_handler files as templates and tweak them to their need. For example if they're gonna use the room stereo, they can add functions like mqtt messages to turn the speakers on / off.

Probably Travis CI? Do you guys have any experience with it? I can give it a shot.

There seems to be a problem with Tune-In support currently, I know this repo is in a state of flux currently but I figured I would raise an issue anyway.

Here is what happens when I run with the --debug flag:

Checking Internet Connection...
Connection OK
Play_Audio Request for: /opt/AlexaPi/src/resources/hello.mp3
[01b19658] pulse audio output error: PulseAudio server connection failure: Connection refused
[01aae110] pulse audio output error: PulseAudio server connection failure: Connection refused
Player State: State.Opening
Player State: State.Playing
Player State: State.Ended
0Play_Audio Request for: /opt/AlexaPi/src/resources/alexayes.mp3
[01aac8a8] pulse audio output error: PulseAudio server connection failure: Connection refused
[01a65e90] pulse audio output error: PulseAudio server connection failure: Connection refused
Player State: State.Opening
Player State: State.Playing
Player State: State.Ended
detected the edge, setting up audio
Starting to listen...
Debug: End recording
Debug: Sending audio to be processed
Sending Speech Request...
Processing Request Response...
JSON String Returned: {"messageBody": {"directives": [{"namespace": "Speaker", "name": "SetMute", "payload": {"mute": false}}, {"namespace": "SpeechSynthesizer", "name": "speak", "payload": {"contentIdentifier": "amzn1.as-ct.v1.Domain:Application:Music#ACRI#DeviceTTSRendererV4_b0983f7b-66be-4845-aef4-262924e93cd2", "audioContent": "cid:DeviceTTSRendererV4_b0983f7b-66be-4845-aef4-262924e93cd2_923030554"}}]}, "messageHeader": {}}
Play_Audio Request for: /tmp/AlexaPi-runtime-0jPrP8/DeviceTTSRendererV4_b0983f7b-66be-4845-aef4-262924e93cd2_923030554.mp3
[01c6b720] pulse audio output error: PulseAudio server connection failure: Connection refused
[01c4fbf8] pulse audio output error: PulseAudio server connection failure: Connection refused
Player State: State.Opening
Player State: State.Playing
Player State: State.Ended

Not sure what happened, but every 7secs or say it says "Hello". Not sure what you need to see, so let me know and I will post. RPi3

• Get rid of the fallback to the Desktop device_platform so users can see the errors on import and can decide to manually set another platform. The current state can be very confusing!

• Introduce something like .indicate_error() and .indicate_warning(), maybe with a persistent flag so we don't have crap code like this in main.py:

   platform.indicate_playback(False)
   platform.indicate_recording(False)
   for x in range(0, 3):
   	time.sleep(.2)
   	platform.indicate_recording()
   	time.sleep(.2)
   	platform.indicate_recording(False)
  

  Also, this is crap as well:

   def indicate_setup_failure(self):
   	while True:
  

  ... the platform shouldn't block the main program like this. If we need to block main, we need to do that over there.

• Unify code for device_platforms where it makes sense and unify code for device_platforms that use RPi.GPIO-like libraries, because it turns out in some cases we can use identical code.

• do .indicate_processing()

There are two sides of this:

• a support to run in under py3
• make py3 selectable & probably default

We need to be sure that there is no major drop in performance there to use it as default.

Also, we need to be sure that all the dependencies support this to do that. If they don't - find another solution if possible. The base should however support py3 without a problem - achieve this first.
Everything works in Python 3 except for the CHIP_IO library.

It would do / have / ...

• display a table with sections (mandatory, optional for X, optional for Y)
• show which dependencies / things are already installed, configured properly, ...
• used init system
• current user (root, alexapi, other (which))
• installed path
• if directories are writable
• state of configuration

We want this because

• this would help us with debugging if people have problems
• useful for people who want to do a manual install (on an unsupported platform for example)

Code

• New common repo
• Cleaner directory structure
• Platforms
  • Device platforms
  • OS platforms
  • Merge work in forks (and redirect those repos here if possible)
  • Make it possible to select multiple triggering methods when they are available
  • Refactor and merge @maso27's snowboy implementation
• Common configuration in the config file (no config in .py files), maybe YAML
• Python 3
• clean code

Docs (after the code is stabilized a bit)

• describe in detail things in CONTRIBUTING.md
• update Requirements section in README.md to include the fact that when installing AlexaPi on a remote headless computer, the user needs to also include the URL containing the IP of the machine in Allowed Return URLs in order to later access the auth page
• update Install section in README.md after it has been figured out in the new code base
• write a short guide explaining how to go from the old version to the new version
• update the documentation for developers when all the basic stuff gets settled

Going public (after the code is stabilized a bit and there is enough docs)

• Invite people to develop with us.
• Invite public to test.
• When we're confident enough, mark Sam's repo as deprecated and redirect people to our repo.

Other

• Use semantic versioning (http://semver.org/) when we're not doing backwards-incompatible changes every day.

This is actually a continuous thing, but we need to start.
I think doing it according to this: http://keepachangelog.com/en/0.3.0/ is a good idea.

The section Project history from README.md should be moved there (rewrite it according to that format) because it belongs there and we don't want to have a mile-long README. Also, we should add the stuff that's been changed so far.

The main reason for this is that people are actually starting to use this AlexaPi repo and it's a good idea to write at least breaking changes somewhere.

Things we'd like to do:

• distribution packages
  • Linux packages
  • Windows packages
  • OS X packages
• distribution images (SD card images for Raspberry Pi, etc.)

When playing back Tunein radio channels, I am not able to issue the Ctrl-C command. It also breaks voice detection thereafter. Requires a Ctrl-Z and a kill -9.

Sending Playback Progress Report Request...
Playback Progress Report was Successful!

I believe it would be of benefit to all parties to correlate benchmarks for different HW platforms. This extends from SDs to what processes are being run on the device.

Thoughts?

From what I see, we use it only to store the access_token and it makes no sense to force the user to install it and have it running.

We can easily replace it with a local sqlite database, which we can later use to also store timers, alarms, etc. The main thing here is to carefully think about where to store the DB file.

@sammachin Is there any particular reason for why you've chosen memcached originally?

Every once a while the audio turns into some sort of white-noise. It makes a terrible hissing sound (sometimes with the alexayes.mp3 or with the response mp3 files). When I manually try and play these files, I still hear the hissing sound via the aplay command. However, mplayer always plays them properly.

Here is the output -

pi@raspberrypi:~/Downloads $ aplay KnowledgePrompt.193ffa5c-72ab-4525-a563-21e0ff96c895_725789800.mp3 
Playing raw data 'KnowledgePrompt.193ffa5c-72ab-4525-a563-21e0ff96c895_725789800.mp3' : Unsigned 8 bit, Rate 8000 Hz, Mono
pi@raspberrypi:~/Downloads $ mplayer KnowledgePrompt.193ffa5c-72ab-4525-a563-21e0ff96c895_725789800.mp3 
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
Cannot open file '/home/pi/.mplayer/input.conf': No such file or directory
Failed to open /home/pi/.mplayer/input.conf.
Cannot open file '/etc/mplayer/input.conf': No such file or directory
Failed to open /etc/mplayer/input.conf.

Playing KnowledgePrompt.193ffa5c-72ab-4525-a563-21e0ff96c895_725789800.mp3.
Detected file format: MP2/3 (MPEG audio layer 2/3) (libavformat)
[mp3 @ 0x75bdb5b8]Estimating duration from bitrate, this may be inaccurate
[lavf] stream 0: audio (mp3), -aid 0
Clip info:
 encoder: Lavf57.41.100
Load subtitles in .
Selected audio codec: MPEG 1.0/2.0/2.5 layers I, II, III [mpg123]
AUDIO: 24000 Hz, 2 ch, s16le, 48.0 kbit/6.25% (ratio: 6000->96000)
AO: [pulse] Init failed: Connection refused
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
[AO_ALSA] Unable to find simple control 'Master',0.
Video: no video
Starting playback...
A:   1.3 (01.2) of 1.4 (01.3)  2.5% 


Exiting... (End of file)

Here is the mp3 file in question - https://www.dropbox.com/s/efjyesn9m7z2qh4/KnowledgePrompt.193ffa5c-72ab-4525-a563-21e0ff96c895_725789800.mp3?dl=0

Here is the white noise that I hear when aplay or main.py script executes it -
https://www.dropbox.com/s/ntwv6eud9m5zh27/White%20noise.mp3?dl=0

I am using Raspberry Pi 3 with the following program versions -

aplay: version 1.0.28 by Jaroslav Kysela <[email protected]>
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
VLC version 2.2.1 Terry Pratchett (Weatherwax) (2.2.1-0-ga425c42)
Compiled by buildd on testwandboard (Jan 24 2016 00:03:37)
Compiler: gcc version 4.9.2 (Raspbian 4.9.2-10)
Linux raspberrypi 4.4.26-v7+ #915 SMP Thu Oct 20 17:08:44 BST 2016 armv7l GNU/Linux
python 2.7.9
pip 8.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)
alsactl version 1.0.28
(I don't have PulseAudio installed)

Any idea what's causing this?

Thanks in advance @renekliment

We can see progress in this repo, so I'm opening this issue already, even though it's gonna take a while to get there.

After #24 is done, let's also support snowboy (so users can choose, let's not just replace pocketsphinx with it).

@maso27 and @flooie have done this in their repos based on the original project. We can learn from that.

So this thing ...

My thoughts / observations:

1. Sometimes it happens for an obvious reason like when she's talking about herself.
2. Sometimes it happens even when she doesn't say her name.
3. Snowboy might be more accurate and could solve (2).
4. Possible solutions:
   1. Disable listening when playing stuff - stupid.
   2. Do some sort of sound cancellation - oh man, this wouldn't be easy. This would depend on each specific device - we would probably need some calibration. And how exactly would we get the output audio? Syncing with the played file doesn't sound easy. Should playback_handlers provide interface for this? People have various operating systems and sound backends - this would be a nightmare to support all. PulseAudio has output monitors that could probably be used for this, I don't know.

Your ideas?

After the major refactors are done, clean up the code, so pylint doesn't produce warnings which in turn fail the tests. This contains sticking to PEP8, removing unused imports, etc. This should leave us with readable and beautiful code.

We also need to disable pylint warnings for using tabs instead of spaces and other things, if they're unsolvable or just pylint is wrong.

This should also solve #7 (we'll see).

Some sort of basic task list:

• Support for new API in an extra module
• Make sure the time is synced (NTP). We need this for timers/alarms to work properly.

Will there be near-future update to the new Alexa api that supports timers etc?

• don't require root when not needed
• install into /opt
• universal paths generally (no /home/pi or /root/, ...)
• universal init files for all platforms
• rewrite the setup script

Is there any possibility of creating a feature list that AlexaPi currently supports and in some cases to what extent it supports a particular features? I know the Alexa Voice Service provides a series of different API calls such as music and alerts. I realise that most of them work in a similar way but its difficult to know what is actually working at the moment. That way I know if I have a setup issue or if the particular feature isn't currently implemented.

Perhaps we could have a skills list that we define as working or not as the case may be.

Hello
in the log I get the message
"Checking Internet Connection....
Connection Failed"
but this only appears when I think I have the right device in the config file selected. When I select a wrong device I have no problem with the Connection.

As discussed in #30.

What's the easiest way to switch Amazon developer accounts post-installation?