I have exactly the same issue with two separate similar setups on two raspi (3+ and 4).
rhasspy master:
raspi 4, mqtt broker
eye toy cam, direct connection
rhasspy client
raspi3
eye toy cam direct connection
both are running rhasspy docker 2.5.
eye toy mic was running fine at single setup with rhasspy 2.4.x
What I observed is a lot of audio packages via mqtt even before wake word detection.
I was wondering, if this is intended, since the mic is configured as directly connected…
Short answer yes. Long answer, no, I stopped using the external mqtt and that seemed to address it. So not sure if there was a latency problem or some part of it wasn’t fast enough to keep up with all the audio frames it was sending.
So i ended up just using the built in mqtt and exposing the ports so i could connect to it.
Hm, thats would not be possibel in my setup (if I don’t miss a point) as I want to have the master-satellite approach.
I have the feeling, that the issue only happens, if the command detection never gets any input.
I would like to define a timeout after wakeword detection, but did not achieve to find the option for this.
Below is my current webrtcvad section. Perhaps anybody has an idea how to add a correct timeout even in the “event” of endless silence…
I am still usign an external, but running on the “master” setup. The “satellite” pi is also configured to this external mqtt broker and my iobroker (home automation) connects as a client to it.
Yes, I guess so.
Meanwhile I switched the master to use the internal MQTT. Satellite connects to it using port 12183.
This setup is now quite stable.
I assume (don’t know exatly how I could test it) that audio frames are sent to the master. This is something I would not like, since the the wake word detection is on the satellite itself… I will further investigate.
yes - and I did another test: connected a different webcam - everything fine the whole night. reconnnected eye toy cam -> stream not open after 20 min.