Internal streamer (Devialet Expert) at the end of 2016

[Antoine]

Latency is a non issue for non-broadcast music replay (in the home setting, not studio's) and asynchronous protocols that typically perform buffering. The only exception I can think of is when a single source is streaming to multiple and/or different receivers/endpoints.

It depends how much buffering the user is willing to accept. When I first installer AIR (2), the default buffer size was set to about 15 seconds (OSX > Wi-Fi > Ether > 200), which was highly inconvenient when skipping tracks frequently or wanting to fast pace or backtrack. This kind of control you cannot achieve with TCP, even in the home environment (who knows what other traffic is also competing; there is a lot in my setup).

I agree that those high levels of buffering (AIR had a maximum of 5s if I remember correctly) are there only for poor slow/unreliable networks. Seconds of buffering for a typically low bandwidth audio shouldn't normally be necessary or desirable. In the case of AIR it's there to mask other issues and even there it seems to fail in some cases due to the issues most likely not being related to buffer underruns but rather poor buffer management/corruption or timing/sync issues.

Even low latency 'local' protocols like ASIO perform some buffering.

UDP is a 'lower cost' data exchange network protocol, lower cost in the way that there's less overhead for sender, receiver and intermediate transport network. In a home situation for streaming offline music data I think there's generally no real need/advantage but it could be a nice to have. It's not really relevant to the buffering strategies for music or even video playback.