Audio input failing over time

setup:
rhasspy version: 2.5.5, via docker image
hardware: rpi 4B, PS Eye for input (no additional alsa config)
os: buster

settings:
audio input: pyaudio
wake word: raven
dialogue mgmt: rhasspy

Hi everyone, new to Rhasspy here. I’m still familiarizing myself with the Rhasspy code architecture and audio engineering in general so pardon my lack of knowledge.

issue description:
After variable amounts of time of being left idle, audio input through PyAudio eventually fails trying to read the next chunk (relevant log excerpt below). This breaks audio input until the Rhasspy is restarted, but inevitably hits this error again. From this log, it took ~10 mins.
Relevant code

speculation:
From PyAudio’s persepctive, this overflow error can occur if the input buffer fills up and frames had to be dropped. PyAudio’s stream.read does have an optional param to swallow this exception being thrown, but it seems weird that it hits it at all. Haven’t dug into this much, but it looks like the default frames_per_buffer is 1024. Is this inconsistent with the Rhasspy documentation claim: “Streams 2048 byte chunks of 16-bit, 16 kHz mono audio by default”?

I’m not convinced this isn’t a problem with my audio setup since I would think others would hit this often. However, similar threads about wake word failing over time don’t mention this error. Let me know if you have any ideas. I might try editing the PyAdudio stream to use callbacks to see if that alleviates anything.

log excerpt:

[DEBUG:2020-08-31 11:10:10,209] rhasspywake_raven_hermes: Enabled
[DEBUG:2020-08-31 11:10:10,210] rhasspyasr_pocketsphinx_hermes: <- AsrToggleOn(site_id=‘default’, reason=<AsrToggleReason.PLAY_AUDIO: ‘playAudio’>)
[DEBUG:2020-08-31 11:10:10,210] rhasspyasr_pocketsphinx_hermes: Enabled
[DEBUG:2020-08-31 11:10:10,213] rhasspyasr_pocketsphinx_hermes: <- AsrStopListening(site_id=‘default’, session_id=‘default-default-c19a163a-c204-41cf-b72f-c9ee84582df6’)
[DEBUG:2020-08-31 11:10:10,213] rhasspyasr_pocketsphinx_hermes: Stopping listening (session_id=default-default-c19a163a-c204-41cf-b72f-c9ee84582df6)
[DEBUG:2020-08-31 11:10:10,214] rhasspyasr_pocketsphinx_hermes: Receiving audio
[DEBUG:2020-08-31 11:10:10,215] rhasspywake_raven_hermes: <- HotwordToggleOn(site_id=‘default’, reason=<HotwordToggleReason.DIALOGUE_SESSION: ‘dialogueSession’>)
[DEBUG:2020-08-31 11:10:10,215] rhasspywake_raven_hermes: Enabled
[DEBUG:2020-08-31 11:10:10,219] rhasspywake_raven_hermes: Receiving audio
[DEBUG:2020-08-31 11:10:12,122] rhasspy-wake-raven: Exiting refractory period
[ERROR:2020-08-31 11:20:03,876] rhasspymicrophone_pyaudio_hermes: record
Traceback (most recent call last):
File “/usr/lib/rhasspy/rhasspy-microphone-pyaudio-hermes/rhasspymicrophone_pyaudio_hermes/init.py”, line 121, in record
chunk = mic.read(self.frames_per_buffer)
File “/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/pyaudio.py”, line 608, in read
return pa.read_stream(self._stream, num_frames, exception_on_overflow)
OSError: [Errno -9981] Input overflowed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/lib/rhasspy/rhasspy-microphone-pyaudio-hermes/rhasspymicrophone_pyaudio_hermes/init.py”, line 128, in record
mic.stop_stream()
File “/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/pyaudio.py”, line 524, in stop_stream
pa.stop_stream(self._stream)
OSError: Stream not open
[DEBUG:2020-08-31 11:20:03,887] rhasspymicrophone_pyaudio_hermes: -> AudioRecordError(error=‘Stream not open’, site_id=‘default’, context=‘Device index: 0’, session_id=None)
[DEBUG:2020-08-31 11:20:03,887] rhasspymicrophone_pyaudio_hermes: Publishing 98 bytes(s) to hermes/error/audioServer/record

Found a related post:

The consensus seems to be the PS Eye driver is kind of busted? The OP had success by switching to arecord, but I’ll still poke around at this for a while. Perhaps getting another microphone to see if it can be reproduced.

Raspberry PI 4, PS Eye as a satellite, raven is wake word engine with custom wake word. Rhasspy running also as master on remote unraid server which is also running separate MQTT broker.

I just started playing with Rhasspy today and have the system recognizing speech and correctly doing intent recognition.

I am getting the same symptoms, my logs on the RPI4 are near identical to those reported by @archie
I hit the restart button and it recovers but crashes ususally within 10 - 15 minutes.