Closed kahrendt closed 2 months ago
Firmware built successfully! :tada:
Download and extract the firmware to install with https://web.esphome.io
Make sure to choose esphome-voice-kit-esp32s3/esphome-voice-kit-esp32s3.factory.bin
.
Firmware built successfully! :tada:
Download and extract the firmware to install with https://web.esphome.io
Make sure to choose esphome-voice-kit-esp32s3/esphome-voice-kit-esp32s3.factory.bin
.
Firmware built successfully! :tada:
Download and extract the firmware to install with https://web.esphome.io
Make sure to choose esphome-voice-kit-esp32s3/esphome-voice-kit-esp32s3.factory.bin
.
There aren't too many drastic changes here, but instead just laying down a foundation for communicating directly between the micro_wake_word and voice_assistant components.
In general, the voice_assistant component has a pointer to the micro_wake_word component (if it exists). It can get the wake word objects from mWW via
get_wake_words()
. You can enable or disable the wake words by passing a vector of strings with the enabled friendly wake word names usingenable_wake_words()
, but this logic may be better to just keep inside the voice assistant component.The current code still relies on the
on_wake_word_detected
action to initiate a pipeline, but I have also setup a direct message from mWW to the VA with the full detection information. I'm still not sure what's the best approach here. Exposing it through the action let's users have fine-tuned control over it, but it may add latency. It could take up to 2 loops before the message is actually received by the voice assistant component based on how the tasks are setup. Not a huge deal, but if we try to eliminate the current required pause after the wake word, this delay may cause issues.The microphone task blocks on i2s_read instead of using a magic number delay. The mWW tasks block on reading/writing audio and features instead of a fixed delay.
I've also added a mute state to the microphone class. The
nabu_microphone
component implements this by just sending 0s instead of the actual data. If one channel gets a request to stop, it mutes the channel. If both channel microphones request a stop, then it will actually stop reading from the I2S bus. As such, I've added back the stopping microphone code to the voice assistant component that was previously commented out. Since microWakeWord is now always listening, the I2S bus will stay alive since that channel won't request a stop. Hopefully, this will make it easier for us to merge any voice_assistant changes back into ESPHome before the rest of the components are ready.