Response speed with media_player component

[s00500]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I feel like the responsetime with the current setup is bad. Specifically I am talking about the time when esphome gets the link and the audio starting to play, it is usually a few seconds for me which feels uttermost long...

Describe the solution you'd like

I did play around a bit and I feel the issue is the mp3 encoding (OR the media_player and esphome_audio handling it...)
What I did was fall back to the config from before esphome_audio using mmw and the speaker. This seems to be broken on 2024.12 but work fine on 2024.11 (where the new speaker with volume control already exists...)

If I run like so the TTS response frome homeassistant cloud comes as a .wav file and plays instantly. This fixes the issue fully, and I am very similar speed repsonses than I am getting on my VoicePE (where the actual format used seems to be .flac)

Describe alternatives you've considered

maybe there is more hope in the new nabu mediaplayer in progress ?

Additional context

I am also running everything over https everywhere, just mentioning it here, does not seem to be the issue.

Does anybody else feel the response time issue on the mediaplayer ?

[s00500]

Link to the esphome issue I created regarding the non working speaker in .12:
esphome/issues#6656

[TheStigh]

I'm guessing you're using https for fetching the reply from HA?

[s00500]

Yes that is correct

[TheStigh]

Yes that is correct

Switch to http - that will really decrease the delay. If you're using any stationary sounds, make sure you proxy them to avoid reloading them every time.

[s00500]

Negative, I tested that yesterday and it did not improve a lot

I am runnig the wakeup sound over http from a different location though...

Again, even when using https: when I use the speaker instead of the mediaplayer and the response gets sent as a wav instead of the mp3 it is blazing fast, so I dont really see why https would be the issue... unless the mediaplayer uses a different process for fetching the file? Have not looked into the actual implementation of the components yet... (also midnight in my timezone, so I should get back to this tomorrow ;-))

[TheStigh]

Negative, I tested that yesterday and it did not improve a lot

I am runnig the wakeup sound over http from a different location though...

Again, even when using https: when I use the speaker instead of the mediaplayer and the response gets sent as a wav instead of the mp3 it is blazing fast, so I dont really see why https would be the issue... unless the mediaplayer uses a different process for fetching the file? Have not looked into the actual implementation of the components yet... (also midnight in my timezone, so I should get back to this tomorrow ;-))

You're using the new PE version? Not received mine yet :) Earlier versions you cannot combine media_player and speaker due to shared i2c, but the new PE should do this just fine. So I do not know how the media_player do it (yet) until I get my own in couple of weeks.

What I do know is loading mp3 over https is quite slower compared to http.

You are pointing to local and not to the cloud (nabu) ?

[tetele]

HTTPS + domain resolution (as opposed to static IP) is a real speed killer

[s00500]

trim.6E85DF21-11CA-4695-960E-E6C39D570DC3.MOV

Here is Test one, using the old speaker setup, quite snappy even with https and local dns lookup (which really should not take long...)

[s00500]

Now here is test number 2 with the current setup (esphome_audio + adf pipeline)

Suddenly the time between receiving the tts link and actually playing it becomes a few seconds ?

trim.85123687-02CF-4DB5-B79A-CD1617E70FFD.MOV

[s00500]

And here is the final test using the voice pe... but that is an unfair one ofc, just for reference
https://github.com/user-attachments/assets/337cb4ad-23af-4ce1-a219-21fcd24b6c64