Mycroft not workintg

[CactiChameleon9]

Creating a bug report/issue

Required Information

• DietPi version G_DIETPI_VERSION_CORE=6 G_DIETPI_VERSION_SUB=34 G_DIETPI_VERSION_RC=3 G_GITBRANCH='master' G_GITOWNER='MichaIng'

• Distro version | buster

• Kernel version | Linux DietPiServer 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux

• SBC model | RPi 4 Model B (aarch64)

• Power supply used | works under stress

• SDcard used | works

Expected behaviour

Mycroft should start when I say "hey mycroft" and should reply with an answer

Actual behaviour

Before a uninstall and reinstall, the microphone was working (showed up in the cli-client which I ran using sudo sudo -u mycroft /mnt/dietpi_userdata/mycroft-core/bin/mycroft-cli-client), and from the logs being added too - it seemed to be able to recognize when I used the wake word but it never spoke. After a uninstall and reinstall, the mic is not detected and I am therefore unable to test anything else

Extra details

I have a usb microphone connected and a speaker to 3.5mm (and the 3.5mm audio force setting enabled)

[MichaIng]

Many thanks for your report. Most likely it is as we removed the hardcoded listener sample rate of 48000 Hz: https://github.com/MichaIng/DietPi/commit/c898bb8ba06d923689dda4bc0bd89ded7fb22eec#diff-23a984ebaf6da5119b9e82031f621aa5fd44b6fca6428699440584d55e51992e This fixed microphone input in some cases but broke it in others, depending on sound card support.

Please try to enable automatic software conversions plugin in dietpi-config > Audio Options, no reboot required, but a systemctl restart mycroft, I guess. This ALSA plugin will convert all capture and output, if required to a format that is supported by the sound card.

[CactiChameleon9]

I already had that enabled apparently, disabling it again doesn't help

[MichaIng]

I already had that enabled apparently

Ah makes sense, we apply that automatically on Mycroft (re)install since it is practically required to play (and record) all sound sources.

Strange that it does not work in your case, can you please try the following (append this listener setting, if the file already exists, not that the previous setting then requires a trailing comma ,):

cat << '_EOF_' > /mnt/dietpi_userdata/mycroft-data/.mycroft/mycroft.conf
{
  "listener": {
    "sample_rate": 48000
  }
}
_EOF_
systemctl restart mycroft

This is what we had in the default config previously, else nothing was changed in this regards. Actually with the above set, in my VMs often the microphone got stuck: You could see the mic meter in CLI with a value but not moving and nothing got recorded. With this omitted and auto-conversion plugin enabled instead, that issue was mostly solved, having a moving mic meter and voice recognition.

Btw, please also check /var/log/mycroft/voice.log and /var/log/mycroft/audio.log for actual errors. I always forget which one is for TTS and which one for STT 😄. For some reason, those errors are not shown in the CLI.

---

And another thing: In the online config (where you do device pairing), by default the British Male voice is selected, which is the local Mimic TTS engine. You need to build local Mimic to make this working: https://dietpi.com/docs/software/hardware_projects/#mycroft-ai Else switch to American Male or Google voice, although the latter also had problems from what I read... jep, the API changes, which has been updated at Mycroft dev branch but not yet released: https://github.com/MycroftAI/mycroft-core/pull/2763

[CactiChameleon9]

OK... So I have done your changed and the microphone shows. It clearly isn't picking up my voice because there has been no addition the voice.log. The audio.log has been complaining about no mimic despite the American male option set. I will try changing it to espeak temporally because I know that works and then turn down my microphone volume like suggested in the debugging section (it is around 600 without me speaking in the cli)

[CactiChameleon9]

OK. Mycroft now speaks, even when typing in the cli. However it doesn't like me when I try to talk to it.. Maybe I should lower the mic more?

[CactiChameleon9]

I managed to get it to work by using the mycroft-listen command.... So its the wakeword that isn't working for me. We can probably close this issue now because dietpi is no longer a factor (I think). Thanks for your help!!!

[MichaIng]

"Hey Mycroft" btw never worked for me (microphone working fine, but it never understood me, nor Google voice from translator, to rule out any accent issues), "Hey Jarvin" in like 50% of cases (Iron Man would be dead 😄), "Hey Ezra" mostly and only "Christopher" perfectly reliable. Not sure why that is. Good idea to play with the microphone level, although I also assured my voice is clear via recording.

[CactiChameleon9]

I got hey mycroft to work with using pocketsphyinx - but only when I was close to the mic (may be the mic, but I could then walk away and face the other direction and it would still get what I said), I will try going back to precise and testing with the other wakewords - good idea

[MichaIng]

I thought "Hey Mycroft" IS the "precise" STT engine, how can it be used with pocketsphyinx? pocketsphyinx was automatically used for the other key words, if I remember right my last test, while precise was always tested before (failing). So maybe it is the precise engine that does not work for some reason while the key word itself would work? Generally I am missing a way to 1. clearly know which key word works with which engine and 2. how to switch engines if the same key word can be used with different engines. That "always try precise first and fallback to pocketsphyinx if it doesn't work" doesn't look great to me, why not using only supported engines in the first place, reducing overhead, confusing error messages etc 🤔.

[CactiChameleon9]

The Hey Mycroft keyword actually is configured for both pocket sphinx and precise, telling (or typing to) mycroft to "set the listener to PocketSphinx" will change the default. I think the backup system is fine, because its only there if precise fails to start - not if it doesn't work for a users setup which cannot be tested without extra user input - although I do agree its a bit annoying