Well thats annoying. I added debug into client/speech/mic.py to log the parameters to the MutableMic, restarted mycroft, and then it seemed to work.
The only other thing I did, was cat the /ramdisk/mycroft/ipc/mic_level file to see what was in it… It was static until I stopped mycroft and started it again. I’m going to check what happens at a reboot. In case the problem is at start up.
Hmm - no dice on startup…
Try stopping and starting mycroft…
And it works - something about the way it is starting - perhaps a race condition in the parts that run?
So after a reboot, the processes seem to be there, but there is one write to the mic_level file during startup and no further writes. I used debug, and it seems to get a few reads, then stall in self.pyaudio_stream.read(size, exception_on_overflow=False) (called from MutableMicrophone, passed into the mic listen loop, found in the wait_until_wake_word method). Guess the next question is why that stream stalls, and then seems to be okay on a restart of mycroft (but not a reboot).
It’s not timing - sleeps dont help (the auto_run.sh has them anyway). I was comparing the env of my putty terminal with the console that auto run first starts the mycroft services, and didn’t find anything specific there. I have checked if there was a difference between
source mycroft-core/start-mycroft.sh all and
./mycroft-core/start-mycroft.sh all but not seen a change in this behavior - it still only starts the second time.
I may try to log in with a screen and keyboard attached (which should put me at the console it’s started in I think), and see if a second run works or fails there, is my headless start making a difference? Nope - still loads with mic levels on the second time.