Support play_url with local file path with TTS

[postlund]

Context

I want to support streaming audio via AirPlay in the Apple TV integration, but mainly to support TTS. The regular play_url usually works quite poorly and it's been broken in tvOS for a while ("things" break until the device is restarted).

AirPlay uses RTP to stream and only supports local files. To steam a remote file would mean that the client first streams it downlink, potentially re-encodes it before sending it to the receiver. This would of course work (if I implemented support for it in pyatv), but it would also be kinda silly to do here since the local file is available on the file system. It's just not available to integrations.

Proposal

I see two alternatives:

1. Make it possible to instruct TTS to pass the local file path to the TTS file, instead of URL when calling the play_url service. Simple, but would be tricky to implement in a nice way in the frontend however.
2. Add separate support flags to the media_player component, so a media player can state if it supports local files or not. The TTS component can then look at the support flag and pick file name instead of URL, if that is supported. It's not foolproof as the same situation as I have, could potentially be valid the other way around.

Maybe there are better ways?

[postlund]

This request has gotten a little traction now and it would be nice if it can be considered for further discussions at least. Implementing this would allow me to support TTS to any AirPlay 1 speaker (including HomePod) via the Apple TV integration.

[micha91]

Maybe it would be the easiest and quickest way to add a new parameter to the play_media service and call it local_path or something like that. The TTS service (and potentially others) could fill this in addition to the media_id, which should be kept as is. If an integration (like yours) wants to use the local_path, it can be taken from the kwargs.
As an alternative, a new service called play_local_media could be added to the media_player. The TTS service could call it instead of play_media and in the media_player a default implementation could generate a URL from the given local path and call async_play_media. If someone wants to add a custom implementation for playing back local files, he can simply overwrite this function. This way, we could also unify the way local files are provided for playback via HTTP. As far as I know, the TTS service and local_source are both implementing a view to provide their files independently from each other.

[postlund]

One problem with passing local file path is that it (the file) isn't necessarily available when making the play_media call to the media player. Retrieving the URL will stream the file as it gets available and that is why my current hack loops for a while, waiting for the file to appear. The tts integration would have to wait for the download to finish before passing it over to the media player (assuming the target device supports playing local file). I don't see adding a new service for local files only is a good idea as it wouldn't work with built-in functionality, like TTS from the front end.

[micha91]

Okay, I had to dig a little deeper into the TTS service first - TTS waits for the file to be downloaded before calling the play_media service. TTS downloads it first to a memory cache and only if caching is enabled it will then be stored on disk in a separate task. So in the current implementation it is not even guaranteed that the file will always be written to disk. So both proposals I made would only work, if caching is enabled and you wait until the file is available. But it would have the nice side effect that you could also support the playback of media from the local_media source.
If your intention is to support TTS only, I would go with a completely different approach. HA provides the TTS data in its view by calling the async_read_tts(filename) method of the SpeechManager. If we would simply make the SpeechManager instance available in hass.data in the setup like this hass.data[DOMAIN]['speech_manager'] = tts you could access it in your play_media implementation and get the data in the same way as the view provides them.

But maybe we should discuss, whether it makes sense to let HomeAssistant itself provide additional protocols beside HTTP in general. We could for example let play_media use a real media_id for content provided by HomeAssistant such as local_media or TTS instead of URLs. This internal media_content_id could look like this: internal:[service]:[content_id]. Using this ID we could then build up an HTTP URL in the play_media implementation or build an RTP URL (which would also be served by Home Assistant) and other protocols could be implemented in the future.