Mic/Audio Issues on Pi Zero Satellite

[joshward9182]

I am trying to get a satellite set up with a Pi Zero W & ReSpeaker 2-Mic hat.
Rhasspy version 2.5.7, installed via Docker.

Manually typing the text to recognise works, with a successful link to the base station (see image) but the microphone & speaker don’t seem to be working.

The drivers are installed and tested in the Raspberry shell. They are also picked up in the Rhasspy “devices” under Settings and show as “working!” when I run the test.
However, it just doesn’t seem to do anything.

Below is a copy of my profile.json:

{
    "dialogue": {
        "system": "rhasspy"
    },
    "intent": {
        "remote": {
            "url": "http://192.168.0.101:12101/api/text-to-intent"
        },
        "system": "remote"
    },
    "microphone": {
        "arecord": {
            "device": "plughw:CARD=seeed2micvoicec,DEV=0",
            "udp_audio_host": "",
            "udp_audio_port": ""
        },
        "system": "arecord"
    },
    "mqtt": {
        "enabled": "",
        "host": "192.168.0.101",
        "password": "redacted",
        "site_id": "satellite",
        "username": " redacted"
    },
    "sounds": {
        "aplay": {
            "device": "plughw:CARD=seeed2micvoicec,DEV=0"
        },
        "error": "${RHASSPY_PROFILE_DIR}/wav/beep_error.wav",
        "recorded": "${RHASSPY_PROFILE_DIR}/wav/beep_lo.wav",
        "system": "aplay",
        "wake": "${RHASSPY_PROFILE_DIR}/wav/beep_hi.wav"
    },
    "speech_to_text": {
        "remote": {
            "url": "http://192.168.0.101:12101/api/speech-to-text"
        },
        "system": "remote"
    },
    "text_to_speech": {
        "remote": {
            "url": "http://192.168.0.101:12101/api/text-to-speech"
        },
        "system": "remote"
    },
    "wake": {
        "raven": {
            "udp_audio": ""
        },
        "system": "raven"
    }
}

[joshward9182]

Energy levels also increase when I say something.

It just doesn’t pick up a wake word and hangs when “listening for command” when “Wake Up” is pressed.

[cakp59]

Hello,
I have the same hardware configuration.
I had the same problems because of the lack of power of this raspberry PI.
In my cas, now, I use hermes and the wake word is also hermes so that I have no more power issues beaucause my master is a powerful NUC used for Home Assistant.
If needed, I can show you my configuration.

[joshward9182]

@cakp59 Thanks for the response.

I am running a master on my Home Assistant server also, so this is only intended to record and send the audio. I have it connected to the master by Remote HTTP (this part seems to be working OK).

I would like to see your configuration, if that’s OK. It might help me highlight any differences.

[cakp59]

my home assistant send answer to satellites questions.
For audio, my home assistant is linked with mpc of all satellites.
When I wan music on a satellite, on the satellite I send the request for music to home assistant. Home assistant active the mpc on the resquester satellite. By today, I have an big issue ’ beaucause of echo I can’t send an another request. I must work on AEC technic.

[cakp59]

I use raven on my master

[cakp59]

!!! on version 2.5.7.2 an issue : wake word don’t run anymore well
I am waiting for a patch

[joshward9182]

That’s similar to what I have, just using MQTT instead of HTTP.
(I also got MQTT to work between them).

Could I see what you have in your Audio Recording settings?

[joshward9182]

I have tried disabling the Wake Word to pinpoint where the issue might be, like this:

When I press the “Wake up” button in the UI, the following is what I get on the Pi console:
Like it doesn’t hear anything, even though the audio input is definitely working.

[DEBUG:2020-10-29 15:41:33,408] rhasspyserver_hermes: Waiting for transcription (session_id=b12136f5-0ce9-4443-a371-772dabfcf478)
[DEBUG:2020-10-29 15:41:33,437] rhasspyserver_hermes: -> AsrStartListening(site_id='satellite', session_id='b12136f5-0ce9-4443-a371-772dabfcf478', lang=None, stop_on_silence=True, send_audio_captured=True, wakeword_id=None, intent_filter=None)
[DEBUG:2020-10-29 15:41:33,457] rhasspyserver_hermes: Publishing 182 bytes(s) to hermes/asr/startListening
[ERROR:2020-10-29 15:42:03,478] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 866, in api_listen_for_command
    handle_captured(), messages, message_types
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 959, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 449, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

[joshward9182]

Still an issue
Nobody else had this issue with a Pi Zero W?

I’ve tried the installation now through Docker, Debian package and a VENV. They all exhibit the same behaviour, so there seems to be a common issue (me??).

When using the ‘Speak’ button (like the following image), the audio is played back through the speaker, as expected.
Further verifying the connection to the ReSpeaker hat.

[DEBUG:2020-10-30 15:04:26,806] rhasspyserver_hermes: -> TtsSay(text='testing', site_id='satellite', lang=None, id='2e9c0a1f-2aad-44f5-a0de-c2d065412cb0', session_id='')
[DEBUG:2020-10-30 15:04:26,856] rhasspyserver_hermes: Publishing 119 bytes(s) to hermes/tts/say
[DEBUG:2020-10-30 15:04:28,677] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/satellite/playBytes/2e9c0a1f-2aad-44f5-a0de-c2d065412cb0, id=9bf8edf3-facb-4019-94cb-6e9486624b7a)
[DEBUG:2020-10-30 15:04:28,787] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=9bf8edf3-facb-4019-94cb-6e9486624b7a)

I have also had success with recording and replaying with a bash session inside the container, using the following:

arecord -r 16000 -c 1 -f S16_LE test.wav
aplay -r 16000 -c 1 -f S16_LE test.wav

[rlongfield]

I just completed a fresh install of Rhasspy on my Pi Zero W using docker.
Followed the guide exactly except for setting my ReSpeaker Mic 2 hat as the default device in /usr/share/alsa/alsa.conf.

I haven’t tried speaking to Rhasspy yet as I’ve had limited time at the device but I just clicked the ‘Wake Up’ button on my satellite.
The web interface said it was listening for a command and then it stopped which I expected.
I checked the logs and I found some unhelpful information (for me at least).

[ERROR:2020-10-30 19:32:24,298] rhasspyserver_hermes:
Traceback (most recent call last):
File “/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py”, line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File “/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py”, line 1869, in dispatch_request
return await handler(**request_.view_args)
File “/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/main.py”, line 866, in api_listen_for_command
handle_captured(), messages, message_types
File “/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/init.py”, line 959, in publish_wait
result_awaitable, timeout=timeout_seconds
File “/usr/local/lib/python3.7/asyncio/tasks.py”, line 449, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2020-10-30 19:31:54,276] rhasspyserver_hermes: Publishing 184 bytes(s) to hermes/asr/startListening
[DEBUG:2020-10-30 19:31:54,244] rhasspyserver_hermes: -> AsrStartListening(site_id=‘Kitchen-Sat’, session_id=‘9b34f890-d589-4816-982c-342bae68df9a’, lang=None, stop_on_silence=True, send_audio_captured=True, wakeword_id=None, intent_filter=None)
[DEBUG:2020-10-30 19:31:54,217] rhasspyserver_hermes: Subscribed to hermes/error/asr
[DEBUG:2020-10-30 19:31:54,200] rhasspyserver_hermes: Waiting for transcription (session_id=9b34f890-d589-4816-982c-342bae68df9a)

[joshward9182]

@rlongfield looks like the same log messages as me…

I wonder if it’s an issue with 2.5.7 on a Zero

[rlongfield]

I don’t know.
I do know that it is not the hardware.
I am able record with ‘arecord fiename.mp3’ and play it back with ‘aplay filename.mp3’.

I went to double check but my network connect to the pi has become completely unstable. I am now unable t login or connect to the web interface, even after rebooting. Not sure if it’s related to Rhasspy or maybe my SD card is failing.

[cakp59]

Hello all,
Here is my new configuration with http. It is OK with a satellite RPI ZERO WH / master NUC core I5

[Seb]

did you get it to work? I’m having the same problem

[donburch]

Hi Seb, Which problem are you having ?

One of my satellites is a RasPi Zero W with reSpeaker 2 mic. I didn’t use Docker since it only runs rhasspy. I use External MQTT, and the satellite is configured with arecord and aplay (device plughw:CARD=seeed2micvoicec,DEV=0 for both); Porcupine Wake Word; and Hermes MQTT for Speech to Text, Intent Recognition and Text to Speech.

If you use the RasPi Zero’s wi-fi you will want to turn off wi-fi power saving to reduce drop-outs
sudo iw dev wlan0 set power_save off