Setup mycroft on Adafruit Voice Bonnet

Hello, I’m trying to setup mycroft (Linux version, not Picroft) on Adafruit Voice Bonnet on Pi 3B.

What I did and what is working is the following:

  • Install Raspberry Pi OS Lite 64bits
  • Install Adafruit Voice Bonnet following Raspberry Pi Setup | Adafruit Voice Bonnet | Adafruit Learning System
  • Install Mycroft (Linux install, not Picroft)
  • Pulseaudio: pactl set-default-sink 1 → works
    • Sink: alsa_output.platform-soc_sound.stereo-fallback
  • pactl set-default-source 1
    • Source: alsa_input.platform-soc_sound.stereo-fallback
  • speaker-test -c2 → works
  • sudo arecord -f cd -Dhw:2 | aplay -Dhw:2 → works
  • Audio troubleshooting following the instructions of gitbook dot io
    • arecord -d 10 test.wav → works
    • aplay test.wav → works
    • mycroft-start audiotest → works
  • Devise registration on mycroft website → works
  • Launch mycroft with CLI: works, I even see that the mic is working (the display of the volume works)
  • I see that the wakeword “Hey mycroft” works (more or less, it’s difficult to be recognised)
  • Increased the volume with alsamixer → works

What is not working:

  • With Picroft, I didn’t manage to make anything working, so I went to the “Linux” install
  • Main issue: I don’t hear anything from mycroft
  • Tried the specific configuration, but didn’t work (Picroft - Mycroft AI)

Would anybody have an idea?

For information, I had also run: mycroft-config set listener.device_name "seeed-2mic-voicecard: bcm2835-i2s-wm8960-hifi wm8960-hifi-0"

And I see it in my user config file:

{
  "max_allowed_core_version": 21.2,
  "listener": {
    "device_name": "seeed-2mic-voicecard: bcm2835-i2s-wm8960-hifi wm8960-hifi-0"
  }
}

Without this, the mic doesn’t work in the CLI

I don’t know what is useful, so let me paste what I see in the CLI:

Hello, would anybody have a piece of advice?

what’s in the audio log on startup?

Hello, thanks for your reply, here is the log:

"/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/mycroft_bus_client/client/client.py", line 182, in on_message
    self.emitter.emit('message', message)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 113, in emit
    handled = self._call_handlers(event, args, kwargs)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 96, in _call_handlers
    self._emit_run(f, args, kwargs)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_executor.py", line 50, in _emit_run
    future = self._executor.submit(f, *args, **kwargs)
  File "/usr/lib/python3.9/concurrent/futures/thread.py", line 161, in submit
    raise RuntimeError('cannot schedule new futures after shutdown')
RuntimeError: cannot schedule new futures after shutdown
2022-10-20 06:32:51.895 | ERROR    |   638 | mycroft_bus_client.client.client | Exception closing websocket: RuntimeError('cannot schedule new futures after shutdown')
2022-10-20 06:32:51.896 | WARNING  |   638 | mycroft_bus_client.client.client | Message Bus Client will reconnect in 5.0 seconds.
2022-10-20 06:32:56.915 | INFO     |   638 | mycroft_bus_client.client.client | Connected
2022-10-20 06:32:56.918 | ERROR    |   638 | websocket | error from callback <bound method MessageBusClient.on_message of <mycroft.messagebus.client.client.MessageBusClient object at 0x7f8e2360a0>>: cannot schedule new futures after shutdown
2022-10-20 06:32:56.919 | ERROR    |   638 | mycroft_bus_client.client.client | === RuntimeError('cannot schedule new futures after shutdown') ===
Traceback (most recent call last):
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/mycroft_bus_client/client/client.py", line 154, in on_error
    self.emitter.emit('error', error)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 116, in emit
    self._emit_handle_potential_error(event, args[0] if args else None)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 86, in _emit_handle_potential_error
    raise error
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/websocket/_app.py", line 407, in _callback
    callback(self, *args)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/mycroft_bus_client/client/client.py", line 182, in on_message
    self.emitter.emit('message', message)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 113, in emit
    handled = self._call_handlers(event, args, kwargs)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_base.py", line 96, in _call_handlers
    self._emit_run(f, args, kwargs)
  File "/home/pi/mycroft-core/.venv/lib/python3.9/site-packages/pyee/_executor.py", line 50, in _emit_run
    future = self._executor.submit(f, *args, **kwargs)
  File "/usr/lib/python3.9/concurrent/futures/thread.py", line 161, in submit
    raise RuntimeError('cannot schedule new futures after shutdown')
RuntimeError: cannot schedule new futures after shutdown

I also see some error messages in the CLI (Connection failure: Connection refused) which is apparently related to pulseaudio? I have the feeling that pulseaudio is working though :confused:

I ran into that error a couple of times:
For (1) - see Connection refused?
For (2), I vaguely recall that pulseaudio and mycroft were running as different users. Setting them to the same user fixed it.

Hope this helps.

-Mike Mac

Have you tried putting these lines in your mycroft.conf file:
{
“play_wav_cmdline”: “aplay %1”,
“play_mp3_cmdline”: “mpg123 %1”
}

Thanks @whynine , I checke mycroft-config get and I already have:

  "play_wav_cmdline": "paplay %1 --stream-name=mycroft-voice",
  "play_mp3_cmdline": "mpg123 %1",

So I guess it’s OK, isn’t it?

Thanks @mike99mac
(1) Indeed, I had seen your other post, but I don’t find the systemd config file for pulseaudio, would you have an idea where it is? (I don’t see anything in /etc/systemd/system, but the command systemctl --user restart pulseaudio.service works (pulseaudio works afterward).

And sudo systemctl status pulseaudio gives Unit pulseaudio.service could not be found.

While pulseaudio --check ; echo $? returns 0 (I think it’s a good sign?) and pactl list shows me the Adafruit voice bonnet (“seeed-2mic-voicecard”)

(2) sudo ps -efl | grep pulse returns:

0 S pi          7807    7534  0  80   0 - 105651 do_sys 00:13 ?       00:00:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal

And for mycroft, I get:

1 S pi           915       1  0  80   0 - 293342 futex_ Oct20 ?       00:00:00 python3 -m mycroft.skills
1 S pi           916       1  0  80   0 - 293342 futex_ Oct20 ?       00:00:00 python3 -m mycroft.skills
1 S pi           918       1  0  80   0 - 293342 futex_ Oct20 ?       00:00:00 python3 -m mycroft.skills
0 S pi          8055       1 17  80   0 - 49945 do_sel 00:39 pts/0    00:00:04 python3 -m mycroft.messagebus.service
0 S pi          8061       1 21  80   0 - 89783 futex_ 00:39 pts/0    00:00:05 python3 -m mycroft.audio
0 S pi          8064       1 28  80   0 - 178951 do_sel 00:39 pts/0   00:00:06 python3 -m mycroft.client.speech
0 S pi          8067       1 18  80   0 - 105045 do_sel 00:39 pts/0   00:00:04 python3 -m mycroft.client.enclosure
0 S pi          8100    8064  0  80   0 -   571 do_wai 00:39 pts/0    00:00:00 /home/pi/.local/share/mycroft/precise/precise-engine/precise-engine /home/pi/.local/share/mycroft/precise/hey-mycroft.pb 2048
0 D pi          8102    8100 36  80   0 - 56682 lock_p 00:39 pts/0    00:00:02 /home/pi/.local/share/mycroft/precise/precise-engine/precise-engine /home/pi/.local/share/mycroft/precise/hey-mycroft.pb 2048

So I understand both are running as “pi”, correct?

Thanks @whynine , I checke mycroft-config get and I already have:

  "play_wav_cmdline": "paplay %1 --stream-name=mycroft-voice",
  "play_mp3_cmdline": "mpg123 %1",

So I guess it’s OK, isn’t it?

If you try these commands manually, do they work ok and you get sound?

They work, yes, I get sound for both

No, pulseaudio just starts somehow. I never bothered figuring out how.

Yes, all mycroft and pulse processes are running as pi, which is good.

The only other idea I have is the permissions on where the socket is created, somewhere under /proc I believe (don’t have access to my system at the moment). Does ‘pi’ have R/W access?

Hope this helps

Hum, let me investigate about this permissions thing, I’m not sure exactly what to look at… :confused: