Maybe a bug with two satellites

Development
1

Hello,

I may have found a bug in rhasspy 2.5.5. but I’m not sure… I do not have access to the logs with this curious supervisord bug when using systemd :frowning:

Configuration : one master and two satellites. Each satellite does its wakework detection with porcupine using UDP.

Everything works well… until that scenario :

  • trigger the first satellite saying the wakeword
  • trigger the second satellite saying the wakeword

Basically, it happens when the two satellites hear the same wakeword :wink:

What happens then :

  • the first satellite comes to the correct ending (I hear the sound of end of capture)
  • the second one switches in unknown state (I do not hear the sound of end of capture) and become unresponsive until I restart it.

Do you reproduce ?

2

Hi @farfade,

I haven’t yet upgraded to 2.5.5, I’m still on 2.5 pre, but still may be applicable.

I have one master and 4 satellites, and I haven’t been able to adjust the sensitivity of the microphones enough to stop them triggering at the same time from time to time.

I too thought the satellite had crashed/become unresponsive in the scenario you describe. Upon investigation I found the second satellite starts a new session and the session from the first satellite is aborted. The hotword is disabled after dectection and it listens for a command. However, if a second satellite triggers than the hotword on the first satellite is never reactived.

I added some code into my handler to activate the hotword if the session is ‘abortedByUser’:

// Switch Termination Reason
    switch (Message['termination']['reason']) {
        // Hotword fix for multiple satellites detecting wakeword.
        case 'abortedByUser':
            MQTT.publish('hermes/hotword/toggleOn', `{"Room": "${Message['siteId']}", "Text": "Hotword fix"}`);
            break;

My setup is complicated/awkward… That’s the best I’ve done for now. I’ve been meaning to create a custom diaglog manager and improve this in the process but haven’t had time.

Perhaps your issue is different (being 2.5.5), but I thought this might help. Good luck!

1 Like
3

This looks like a bug in the session management of the dialogue service. The second session should not terminate the first one.

In a session duplication case, a session started a few ms from another one the dialogue manager should terminate the second one.

I do not know if @synesthesiam has included session de-duplication in the dialogue manager yet.

4

Agreed it’s a bug. I’m surprised it hasn’t been raised before. I tried a few things to hack fix it, but quickly realised it needs to be resolved in the dialogue manager and I haven’t done a great deal of Python.

If memory serves me correctly, months ago when I was searching for any postings on the subject I believe I read you, @fastjack, were using a customised dialog manager and had added something to handle de-duplication. I thought something might trickle through the core release :sweat_smile:

5

@synesthesiam @Enc3ph4l0n @fastjack : could a session timeout on the satellite’s hotword service be a quick(-and-dirty) workaround before engineering de-duplication of sessions ? let’s say after 10 seconds, it auto-reactivates ?

I do not want to say it’s something that must be implemented to fix this particular error. But I wonder if a timeout on this service to re-enable listening-by-default is a good thing or not.

I say that because basically I just restart the rhasspy-satellite service manually to fix the problem.

6

OK, I think I see what’s happening here. I originally designed the dialogue manager like (I think) Snips’, where a new session would automatically abort an existing one. But with multiple site ids, this is not the right thing to do. I can just split the session queue by site id, and I think everything should work.

This looks like another bug. I only re-activate the hotword service if there are no more sessions. Again, not the right thing to do with multiple site ids :man_facepalming:

3 Likes
7

Was this issue fixed? On the latest 2.5.7 it seems to be having issue with two satellites hearing the wake word at the same time.
Not a huge issue as I don’t plan to have the satellites that close together normally. I was actually trying to test a couple of satellites side by side to see how well each could hear the wake word.

8

This is still an issue, but is being discussed here: https://github.com/rhasspy/rhasspy/issues/113

1 Like