You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For (voice assistant related) functionalities like timer-alarms and awake-sounds after the wake-word has been detected, it would be great if the media_player component could play a locally stored PCM sound. For example in the esphome S3 Box firmware, this is used to play an alarm sound with the speaker component. But when using a speaker, you don't get a media_player usable from HA.
The workaround would be to host these sounds on a local HTTP Server and play back from there, but that isn't low latency and sounds like an unnecessary complication to me.
It of course would be great to integrate this into ESPHomes media_player natively, but that feature-request is still open.
Alternative Idea:
Is it feasible to provide a generic media_player, which has just an output speaker-component? But then of course the volume etc. is ignored when accessing the speaker directly.
The text was updated successfully, but these errors were encountered:
It seems like NabuCasa is working on a (XMOS specific?) Media Player implementation which will allow playback of local files already: https://github.com/esphome/voice-kit/tree/dev Maybe we should wait to see whether this aids in any way.
For (voice assistant related) functionalities like timer-alarms and awake-sounds after the wake-word has been detected, it would be great if the media_player component could play a locally stored PCM sound. For example in the esphome S3 Box firmware, this is used to play an alarm sound with the speaker component. But when using a speaker, you don't get a media_player usable from HA.
The workaround would be to host these sounds on a local HTTP Server and play back from there, but that isn't low latency and sounds like an unnecessary complication to me.
It of course would be great to integrate this into ESPHomes
media_player
natively, but that feature-request is still open.Alternative Idea:
Is it feasible to provide a generic media_player, which has just an output speaker-component? But then of course the volume etc. is ignored when accessing the speaker directly.
The text was updated successfully, but these errors were encountered: