Voice PE triggers itself while speaking

[cgoller-evia]

I've noticed that my Voice PE can trigger itself.
Artificial example with my custom assistant Jarvis (custom mikroWakeWord: "Jarvis"):

Me: "Jarvis ... tell me something about yourself"

Jarvis: "My name is Jarvis, I am you personal assistant" <-- Saying his own name out loud (which is also the wakeword) triggers the listening while still speaking

Jarvis (responding to the input: "I am you personal assistant"): "Thats nice of you but actually I don't require a personal assistant".

Did anyone experience something similar?
There is an easy workaround with a simple automation which mutes the assistant while speaking.
But I thought it might still be worth mentioning.

[cgoller-evia]

I just realised: as long as we want to be able to interrupt the voice pe while its still speaking there is probably no way around this right?

[omaramin-2000]

I've noticed that my Voice PE can trigger itself. Artificial example with my custom assistant Jarvis (custom mikroWakeWord: "Jarvis"):

Me: "Jarvis ... tell me something about yourself"

Jarvis: "My name is Jarvis, I am you personal assistant" <-- Saying his own name out loud (which is also the wakeword) triggers the listening while still speaking

Jarvis (responding to the input: "I am you personal assistant"): "Thats nice of you but actually I don't require a personal assistant".

Did anyone experience something similar? There is an easy workaround with a simple automation which mutes the assistant while speaking. But I thought it might still be worth mentioning.

Yeah, I experience the same sometimes using Linux Voice Assistant

[Wombleyy]

Having the same issue while using my own locally hosted Wyoming protocol TTS (Fatterbox). This happens during Conversation mode during replies that expect an additional response.

Checking the log, it is indeed hearing its own initial responses then stopping to respond to itself again during longer replies.

The trigger replies do not need to include the wakeword in my case. It just stops mid playback and starts a new reply when in conversation mode. This can become a feedback loop where it keeps talking to itself, becoming increasingly confused.

EDIT: And can confirm, if I mute the mic after speaking the prompt, then unmute when it completes long replies, it completes the long replies normally and awaits spoken response.

[Wombleyy]

This problem is less pronounced with the Assistant "Prefer handling commands locally" set to Yes. But then on replies that engage direct conversation mode again, the problem persists.

[nuzayets]

To be honest I think it's a bug with TTS streaming. I implemented streaming in a HAOS Azure TTS plugin and noticed that the 'end of speech playback' state transition (i.e. ring stops speaking animation, or reply listen activation) was triggered when the streaming stopped, not when the playback stopped. So, the Voice PE would transition to whatever state was after playing the TTS output, but the TTS output would continue to play. This easily happens if the stream is significantly faster than real-time.

I thought it was a problem with my streaming implementation but my patch ended up getting re-implemented upstream anyway and the bug persists and now I see people reporting this with other streaming TTS, I'm thinking it might be that Voice PE needs to find a new signal for transitioning away from the 'speaking' state.

[Wombleyy]

Indeed.

I've implemented an automation workaround that latches a mute when both playback and listening are detected at the same time, then unmutes if it initiated the mute.

This is less than ideal as you cannot interrupt during playback (which I presume is the reason it immediately begins listening again). This workaround also results in it sometimes going from listening to idle before TTS playback is complete and ready to accept the spoken response.

Without any sort of negative feedback filtering of the audio being played back, I can't think of a better solution than cutting off the mic.

Lacking that, the next best solution would indeed be not initiating listening until outgoing audio stream is complete (which it certainly knows or can know?). In this way, it would at least always await the user response when appropriate.

[mitrokun]

Normally, if the assistant hears wake word while responding, the session should end.
If they enter the listening phase, either the LLM response contained a question mark, or you encountered the issue described in this issue (premature session termination).

Also, a few notes:

• "Jarvis" wake word (and most of the community-generated based on Piper synthesis) are of poor quality, with a large number of false positives.
• Fast TTS engines/services with streaming support do not have the problem of premature session termination.

[Wombleyy]

Normally, if the assistant hears wake word while responding, the session should end. If they enter the listening phase, either the LLM response contained a question mark, or you encountered the issue described in this issue (premature session termination).

Also, a few notes:

* "Jarvis" wake word (and most of the community-generated based on Piper synthesis) are of poor quality, with a large number of false positives.

* Fast TTS engines/services with streaming support do not have the problem of premature session termination

The issue is not with premature session termination due to hearing the wake word. Although this desired behavior explains why it is listening. It seems to happen on sessions while an agent response is being played back, but expecting a reply from the user. (Agent replies that end in a question.)

The problem is that in that case, it then hears itself speaking and replies to the snippet of its own response that it heard. It begins talking to itself until it reaches a point that it does not expect any follow up response from the user.

When in conversation mode, interruption is not limited to hearing the wake word while agent audio is still being played back. If it did only allow interruption (during play back) by the microwakeword, this may solve the problem.

(I am using Okay Nabu as the wake word.)

[mitrokun]

When in conversation mode, interruption is not limited to hearing the wake word while agent audio is still being played back.

I mentioned this option:

• You asked a question
• LLM finished answering with a question
• An error occurs - the session ends
• Outside the session, the answer playback begins, and simultaneously the second round of the conversation begins.
• The satellite listens to itself.

Did you have similar problems before December (when the firmware version with Sеndspin support was released)?

[Wombleyy]

Yes, this option is mostly correct. Except that checking the traces and logs, no error occurs.

Only that once it begins listening to itself (with no part of the answer sounding like the wake word) it stops to reply to what it hears itself saying (a portion of the audio is transcribed as the next spoken reply).

Unfortunately I don't personally have a basis of comparison to prior versions. This is a new setup that I began this week. Maybe OP @cgoller-evia does?

[muldjord]

Have this same issue. My assistant starts feeding back into itself. I switched from "Hey Mycroft" to "Ok Nabu" since the "My" part of Mycroft seemed to often be part of the response as it would be talking about "My this or my that". That might have helped a bit (Note, further investigation shows this has nothing to do with the wake word), but it still happens quite often where it can sometimes keep feeding back 3-4 times before it stops.

It has started happening after I offloaded the faster-whisper to a separate machine. I can see from the output on the faster-whisper instance that it records its own answers and starts replying to them.

I am also using the ollama integration that connects to that same separate machine running a Qwen3.5:9B model. It all works very well, except for that feedback issue.

EDIT: Note that this further investigation shows that this is unrelated to my switching to running faster-whisper on a different machine. Se my post here for a temporary solution.

[Xalior]

Without encountering a wake-work I can confirm in testing against Qwen:3.5:9B with a GPU-accelerated 'faster-whisper' instance -- I've had this too...

I've even had the model comment that "that looks like the end of my previous answer" and ask me a follup question if I needed help :)

This is not because of the Wakeword, but because one can see the LEDs on the HAVoice have gone into "listen mode" before the end of the utterance. This happens with increasing likelyhood if the model answer is longer/more verbose - or, if mic sensitivity is turned down, the follow-up window (aka Mic engaged waiting for an answer to a question) finishes before the question has even been fully asked.

[muldjord]

I decided to regress to the 25.11.0 firmware from Nov 2025. This solved the issue for me. With this older firmware the conversation mode works as intended. It no longer starts listening for answers prematurely which forced it to record half of its own answer. Now it waits until it has finished playing the answer before starting to listen for my reply.