Can you proxy via HA, like tts_proxy?

[pbulteel]

I'd like to be able to use a single port for HA and MASS. It seems that something's changed and MASS now uses 8095 - I don't remember that being the case several versions ago. I would like to be able to "proxy" the MASS stream and use a single port (I use 443 with an SSL cert.)

Of course if I do that with HA - MASS now requests it's audio to play on 8095 and http, so audio doesn't play anymore.

Am I missing a configuration setting or tweak? If I were to proxy /mass/ to port 8095, what would be needed for MASS to pass that fqdn, protocol and path to the streaming devices?

If it's not possible, this may end up being a feature request...

[marcelveldt]

This has always been the case. The mass api and web interface is hosted by HA but the streaming is local only on a dedicated tcp port.

[marcelveldt]

Btw and most devices do not even support local fqdn, let alone https. Besides that why add pointless https overhead for audio packets only, it is local only

[marcelveldt]

I am going to share a bit of a more detailed answer here because this question seems to popup more often for users with (over)complicated setups.

Music Assistant uses the Home Assistant webserver for all communication. So the frontend of MA is using the HA webserver and authentication etc.

Besides that, MA needs to be able to stream audio to client devices in a reliable way that works with all players.
We do this with a secondary, simple webserver hosted by default on port 8095 to serve the audio stream to clients.
This additional webserver is HTTP only for a reason: A lot of clients do not like the audio served from HTTPS and it adds a lot of overhead that is simply not needed just for audio packets.

This is not about running Home Assistant web interface behind reverse proxy etc. it has nothing to do with a web interface.
We are talking about the audio stream service here, yes that is http but that is all it is, the protocol.
There are very good reasons to host that on HTTP only and avoid dns lookups.

To prevent issues with DNS lookups (and additional overhead and latency!) we communicate the IP ADDRESS of the stream webserver to the clients. This IP address is resolved automatically from the "internal url" field in your Home Assistant config.

It seems people want to have that audio stream service behind proxies and/or HTTPS and overcomplicate it.
Guys come on, this is a solution for streaming audio to consumer devices, not to secure a bank ;-)

For example google cast players have the google dns servers hardcoded and will never be able to resolve internal dns names. That is why the stream service is hosted on its own as-simple-as-possible http port, otherwise I could have proxied it on the HA webserver. I did that for a reason, keep it as bullshit simple as possible to prevent issues.

So, I'm not a big fan of making this configurable because it will cause more support to handle and it will most likely not work in a lot of situations. Maybe some sort of hidden environmental variable that nobody knows about but then you are completely on your own with regards to support. I am busy enough supporting the regular setup.

What's wrong with opening a tcp port in your LOCAL network ?
Let alone all dns issues, why add the overhead of https to the audio stream which is local only ?

Just make sure that the TCP port 8095 is reachable from your audio devices in your LAN. There's nothing to secure about audio data. Come on, even the source audio from the streaming providers is hosted on HTTP for a reason!
Players have flaky and underpowered MCU's that can barely handle an HTTP stream, don't harm your audio by trying to enforce HTTPS or a dns name just for the sake of setting it all up like an enterprise solution, with all respects to your hard work setting that all up.

I respect all of your setups but I ask you to respect me that I do not want to add something to my code that is going to potentially break audio or cause me support. If you don't like it, move away and do not install Music Assistant.

So, if this really a thing I could add an environmental variable to set to override the default stream IP that is sent to players but I am not going to provide support if you are having issues with the audio stream as a result from that. I'm working for over 3 years on this project with various players and I can assure you that is going to cause real issues. Don't blame me, but blame the MCU creators in the various audio devices.

[Rudd-O]

This is no longer completely valid. The UI is on port 8095 and can be proxy-passed no problem. The port that streaming clients connect to is port 8097 by default (and if that port is taken the next one is used).

[OzGav]

Correct this is V1 info. I am slowly finding these and closing them to avoid confusion. Thanks for highlighting it.