core: Wyoming integration returning incorrect URLs from piper
The problem
I have setup an Atom Echo as a voice assistant interface following the tutorial (https://www.home-assistant.io/projects/thirteen-usd-voice-remote/).
This works, however generated responses are not played back. Looking at the ESP logs, the Piper response URL sometimes ends in .raw, sometimes .mp3. The response needs to be in wav format, which I can manually do by changing the URL (see attached log snippet).
Unclear if related to https://github.com/home-assistant/core/issues/92528.
What version of Home Assistant Core has the issue?
core-2023.5.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
wyoming
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
[00:11:41][D][voice_assistant:112]: Response: "Sorry, I couldn't understand that"
[00:11:41][D][voice_assistant:127]: Response URL: "http://ha.k8s.services.lan/api/tts_proxy/dae2cdcb27a1d1c3b07ba2c7db91480f9d4bfd8f_en-us_47f5ba5b18_tts.piper.raw"
[00:11:41][D][voice_assistant:132]: Assist Pipeline ended
Additional information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 31 (10 by maintainers)
Commits related to this issue
- https://github.com/home-assistant/core/issues/92969 — committed to kiklhorn/esphome by kiklhorn 7 months ago
This was actually trivial to implement: https://github.com/esphome/ESP32-audioI2S/pull/12
You can test it with the following steps:
Copy the
i2s_audiocomponentloginto get a shelldocker exec -it addon_5c53de3b_esphome bashmkdir -p /config/esphome/my_components/i2s_audiocomponent:cp -ar /esphome/esphome/components/i2s_audio /config/esphome/my_components/Clone the patched
ESP32-audioI2Slibrarymkdir -p /config/esphome/my_libs/cd /config/esphome/my_libs/ && git clone https://github.com/robin-thoni/ESP32-audioI2SConfigure the new
ESP32-audioI2Slibraryesphome/my_components/i2s_audioandesphome/my_libs/ESP32-audioI2Sfoldersesphome/my_components/i2s_audio/media_player/__init__.py(NOT the__init__.pyfile at the root of the component, the one in themedia_playerfolder)cg.add_library("esphome/ESP32-audioI2S", "2.0.7")bycg.add_library("file:///config/esphome/my_libs/ESP32-audioI2S", None)Rebuild
It should now play the .raw files generated by HA, without eating the end of the file. Here’s a quick demo: https://owncloud.rthoni.com/s/DfcrJXLZoRLpFpq
I can confirm @grahambrown11, i have the same issue.
@synesthesiam , I tested the fix using the de version of HA and it is working fine with an esphome media player.
thank you once again for the fix.
Oh please someone merge that PR!
Same problems here:
Maybe a solution/workaround would be to add raw format support to ESP32-audioI2S? This way, the media player would be able to play raw files, eliminating the need for the speaker component altogether.
I see a few references to CODEC_MP3 in https://github.com/esphome/ESP32-audioI2S/blob/07cb6eb71fbc47d45185270b5c84c762a126bbc3/src/Audio.cpp. Adding a new raw “codec” shouldn’t be that hard, since it’s exactly what the i2s function expects. I might give it a try soonish.
I’m also getting the
.rawformat when using eithermedia_playerorspeakerin ESPHome, however the speaker component does playback the audio where the media player does not…media_player log:
speaker log:
It’s still not working for me when I use a
media_playerfor output, as the default voice assistant configuration does. Aspeakerworks fine but the volume can’t be controlled.And as noted in my comment above, two things: (1) no TTS comes out of the voice assistant, but I can send audio (including piper and other TTS!) directly from Home Assistant to the ESPHome
media_playerand it works; and (2) the ESP device thinks it’s playing audio, as the green pulsating LED continues pulsating for some period and then stops, as if it were speaking.This is all using ESPHome 2023.7.0 and HA 2023.7.2.
Here are some logs from ESPHome 2023.7.0 on an Atom Echo:
Two additional notes:
So I suspect the pipeline itself is somehow corrupting the response audio stream.