Optimal setup for LAN usage for different OS without "delay" (httpd lag/delay)

[bartfer]

I'll admit I'm a bit lost. I've started searching about music streaming "DIY" few weeks ago and MPD and mopidy seemed like the best choices for me.
My use case: There is 1 Ubuntu server which runs MPD in my LAN and has the music files and I'd like to listen to it on my mobile (android) and PC (win10) (same network - later use case is from different networks, but let's leave that for now, shouldn't be too different anyway). (Preferably using only 1 application to listen and control. And another futue use case could be casting to device)

Started out with mopidy was pretty easy to setup but then the "default'" client was freezing all the time... So I checked MPD out and yes this is really fast, no freezing at all.

My problem is that I'm using MPD to output audio using it's default HTTP server setting and this has serious lags. For example already came up here: #442 not sure I totally agree with or understand the answer there but at least the newer comment (using "mpv") helped me out a bit, that won't get out of sync in the magnitute of minutes (compared to vlc, firefox), only few seconds, but that is still not really bearable.

Alright so I shouldn't use HTTP for audio streaming. Then there are options like the "sattelite" setup or pulseaudio that came up. Didn't go down this road as installing MPD on the client machines seems like just such an overkill for me. Whenever a new mobile or PC joins the network the only thing they should need is 1 app that can connect to a stream to play it (and preferably control it) and nothing more. Would pulseaudio's RTP output work without delay (based on my inital search people mention delay there as well)? I'd also reject the solution that I need pulseaudio on all my clients (and not just the server) because of the same reason as above. (there is also snapcast, icecast, but as I see they are a bit for different goals, I may be wrong)

So as you see I'm a bit lost now. It's sort of ok that as there are no proper apps for windows I'd need to use a separate MPDController app and a separate for just listening - but this would be also true on android as far as i can see. What is the optimal setup for my use-case? I'd appreciate any ideas. It may not be the way to use MPD for this, I'm not sure, just seemed like this is a pretty good solution for many years but maybe for other use-cases.

Basically my question is: How are people using MPD without httpd output to listen on different devices? Pulseaudio, snapcast etc and install yet another thing on their clients? Or I'm missing something?
Thank you in advance! And of course otherwise great software, most likely it's just me who can't use it properly or looking for something else. :)

[MaxKellermann]

Sounds like Snapcast is the best solution for your problem.

[bartfer]

You are right, snapcast solves this (there is only about 1 second delay). (even though I need 2 apps, one for playing and one for control but that is fine if the playing one is running always in the background).
Thank you for the quick response! And thanks for maintaining this great project!

(btw if you can give any pointers regarding why it's not really possible/hard to solve to use httpd just out of curiousity I'd be interested, would love to learn. Opened up a discussion on mpv github about mpv network stream implementation, but I don't think that's going to be a too hot topic there. :) )

[skidoo23]

(...) I checked MPD out and yes this is really fast, no freezing at all.

That's why we are all into this MPD thingy ;)

My problem is that I'm using MPD to output audio using it's default HTTP server setting and this has serious lags. (...)
Alright so I shouldn't use HTTP for audio streaming.

Why not? Http is ubiqitous and volume control and mute are working instantly. Even some MPD clients like Cantata (Linux and abandoned Windows versions) and MALP for Android support http streaming. You don't even need clients, there are web interfaces available. Enough for listening and control.

How are people using MPD without httpd output to listen on different devices?
Pulseaudio

Pulseaudio Network? PulseAudio exclusively uses multicast RTP/SDP/SAP containing audio data. https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/ your local network needs to be in a good shape to deal with multicast traffic and Wifi make things even worse.

Snapcast - at least for my understanding - tries to be some kind of multi room or whole house audio solution like Sonos or HEOS. At the moment MPD is not a snapcast client which would be really nice. @MaxKellermann is there a way for lesser gifted people to contribute?

[bartfer]

Well if it's working for you instantly using httpd output then something is really strange. I've tried everything I could think of and the best "latency" I could achieve was about 1.5-2 seconds with mpv 0 caching. And based on other threads, comments etc. I'm not alone regarding this. What do you use to play the httpd output of mpd? I've tested MALP from those that you mention and it had great delays (I even opened up a topic there and everyone seemed to knew about it).

Didn't dive in too deep to pulseaudio as it seemed like another big project. Based on what I read I assumed many people uses that for non-delayed musiclistening from MPD. But not sure of course.

Yes Snapcast's goal is what you mentioned but it also solves the "delay/lagg" problem (ok there is a very very slight delay like 0.3-0.5 seconds but I'm okay with that).

To be perfectly honest I think this issue (httpd delay/lagg) can be solved contrary to some comments here and there but as I don't fully understand it I'm not 100% sure - that's why I asked about it.

[MaxKellermann]

The "httpd" output was never designed for low latency, and never will. Don't use it unless you want to run a radio station. Not for personal use.

[kingosticks]

Yes Snapcast's goal is what you mentioned but it also solves the "delay/lagg" problem (ok there is a very very slight delay like 0.3-0.5 seconds but I'm okay with that).

The goal of snapcast is synchronised audio between multiple clients. If you are getting acceptable latency that is just a side-effect related to the particular client(s) you currently have connected. If you add more clients (or bad clients) the latency will change. If you want low-latency audio you should avoid TCP.

Unicast RTP should work well, even on WiFi networks, and is supported by many clients. Pulseaudio supports unicast RTP (do not waste your time with multicast RTP at home).

[skidoo23]

Well if it's working for you instantly using httpd output then something is really strange.

Maybe there is a missunderstanding. HTTP streaming (and a combination of MPD and eg myMPD) does not special clients nor fiddling with configuration or network setup. Enter URL in your favorite browser and there is sound on server and/or client. Drawbacks are: audio is NOT in sync and there is a percebtible delay of several seconds between control changes (track, volume, pause, etc) and changes in sound.