#Respeaker Lite Issues

1 messages · Page 1 of 1 (latest)

stiff gull
#

Hi y'all. I am reimplementing @maiden sphinx's satellite based on the Seeed Respeaker Lite board with ESP32S3 soldered on it. Meanwhile it's running with the unmodified version of the example configuration and working generally. I have two issues however I am struggling a bit with and hope somehone has an idea.
1: WiFi connection. The Wifi seems to have some issues. I have it located next to WiFi base station (like 1 m) and the signal strength is -31 dB. However I had severe issues getting it connected at all (connection repeatedly lost in the ESPs log). Setting power_save_mode: none in the config at least made that stop, however the router is reporting current data rates between 150 Mb/s and 1 Mb/s. Mostly 5/1.
2: TTS timeout: When the generated response is a bit longer (more than maybe 20 s or so), the response will not be played back and timeout errors in the HA core log. This does NOT happen with my other Satellites (Pi based Wyomings) using the same pipeline. Short responses play fine. The error log begins with:

2025-01-29 20:56:33.138 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SpeechManager._async_get_tts_audio.<locals>.handle_error() at /usr/src/homeassistant/homeassistant/components/tts/__init__.py:844 (None) Traceback (most recent call last): File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run self._context.run(self._callback, *self._args) ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 846, in handle_error if audio_task.exception(): ~~~~~~~~~~~~~~~~~~~~^^ File "/usr/src/homeassistant/homeassistant/components/tts/__init__.py", line 786, in get_tts_data extension, data = await engine_instance.internal_async_get_tts_audio( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ message, language, options ^^^^^^^^^^^^^^^^^^^^^^^^^^ ) ^

nimble orchid
#

I did not really take time to investigate it, but I had Wi-Fi issues with the ReSpeaker Module. I purchased some 2.4 GHz Wi-Fi patch antennas with the same matting connector on Amazon and that solved my problem.

stiff gull
#

Do you mean you replaced the ones that came with the modules or that you didn't have antennas at all? I suspected the antenna first but dropped the tought since swapping with another modules antenna didn't change anything. If it is a bad design however, that could surely make a difference then...

maiden sphinx
#

Yeah I also use different antennae on every XIAO S3. The stock one is awful. Also make sure it's connected all the way down.

nimble orchid
maiden sphinx
#

Sorry, kids played

stiff gull
#

Will try different Antenna then. Thanks a lot for the tip. Anyone any thoughts on the missing reply?

stiff gull
#

Hi @maiden sphinx . I still can't figure out why long TTS responses time out. In the ESP log on the device I get following error messages for long responses (more than a sentence):
`[10:44:31][D][voice_assistant:641]: Event Type: 2
[10:44:31][D][voice_assistant:733]: Assist Pipeline ended
[10:44:32][D][esp-idf:000][ann_read]: I (312992) esp-x509-crt-bundle: Certificate validated

[10:44:37][D][esp-idf:000][ann_read]: E (318390) transport_base: esp_tls_conn_read error, errno=No more processes

[10:44:37][D][esp-idf:000][ann_read]: W (318392) HTTP_CLIENT: Connection timed out before data was ready!`

Shorter responses (up to approx. a sentence) however work fine:
`[10:44:51][D][voice_assistant:641]: Event Type: 2
[10:44:51][D][voice_assistant:733]: Assist Pipeline ended
[10:44:52][D][esp-idf:000][ann_read]: I (333277) esp-x509-crt-bundle: Certificate validated

[10:44:53][D][nabu_media_player.pipeline:173]: Reading FLAC file type
[10:44:53][D][nabu_media_player.pipeline:184]: Decoded audio has 1 channels, 48000 Hz sample rate, and 16 bits per sample
[10:44:53][D][nabu_media_player.pipeline:211]: Converting mono channel audio to stereo channel audio
[10:44:56][D][voice_assistant:515]: State changed from STREAMING_RESPONSE to IDLE`

I already tried to add
http_request:
timeout: 60s
verify_ssl: false

to my personal confif, but still same result. Currently I am running out of ideas...

stiff gull
maiden sphinx
stiff gull
#

Hi, @maiden sphinx, I just noticed that you added the possibility to OTA update the XMOS FW in your repo. Since I ust recompiled to test the fix for the wakesound record issue I tried to find the ""upload firmware" button/action but failed. How is it supposed to be activated?

maiden sphinx
stiff gull
# maiden sphinx I didn't officially add it yet. It's just possibility to do it. YAML should be c...

Just checked it out, now that's it added, works like a charm. While doing this I wondered about the benefit of using 48 kHz rate though. In your repo readme you explain that you achieve better playback quality with 48 kHz but is that really related to the microphone? I assume that the idea is that the XMOS chip cancels the audio playback thus allowing wakeword detection while playing back (e.g. "stop"). That probably only works well when the sample rates for audio input and output align. Having found out however that the wake sound is obviously not being cancelled out I wonder if that works at all. The reason I am asking is that I wonder if having 48 kHz sampling rate might maybe be an issue downgrading performance of wakeword detection and STT since MicroWakeWord was trained with 16 kHz as was e.g. Vosk STT (which I use).

maiden sphinx
# stiff gull Just checked it out, now that's it added, works like a charm. While doing this I...

Ok, here's explanation:
Respeaker Lite is ruling not only microphones, but speaker too, as you know.
16kHz sample rate is enough for speech, but music on that sample rate sounds awful.
PE firmware is using 48k for speaker, and 16k for microphones. However, on Respeaker Lite microphones and speaker are using same i2s interface in full duplex mode. It doesn't affect quality of connection, but results in restriction of using same sample rate for both mic and speaker - you can't set two different sample rates on one i2s connection.
Seeed initially had 16kHz firmware. I convinced them to release one, that is set to 48k. Then some clever guy from community modified PE microphone code to cut (resample) 48k to 16k, because HA and microwakeword expect 16k and don't work with 48k input.

So here we are now. 16k on microphone, 48k on speaker.

stiff gull
#

Thanks for the explanation. Makes total sense. Just couldn’t find the resampling bit in the config which is clear since it’s in the code:-)