Software engineering part II
I promised Orac I would say a few words from a software engineering perspective on the second aspect of the OPs question, media servers.
As a recap: software engineering is a process of matching desired outcomes, to expected outcomes and then to actual outcomes. And from a software engineers perspective we are living in a world of logic, trust and problem determination and we use evidence and probabilities to guide us in this process.
So in this our situation, the user requirement is as follows. As a lover of high fidelity music reproduction, I want to get the music encoded in a high resolution music file from a storage location that is anywhere in the world to the DAC I am using to replay music and feed the music into that DAC with as close to perfect timing as possible so that I can get the maximum pleasure and enjoyment from my music. 
The acceptance criteria includes very high resolution files, maybe 192/24 or even higher if my DAC supports this. Some users might have acceptance criteria that they want to do this without needing any basic computer user experience.
Ok, so at first sight we have quite an engineering challenge. We have all heard of jitter and its timing effects on musical reproduction. If the media server alone, possibly sitting in a data centre in Germany say and not just in the room in which my hifi sits, has to feed the music data into the DAC by itself in real time with really high precision we would all be in big trouble. Think of all those network cables, switches, coper cables, fibre cables etc. the data has to travel over with no tolerance for delays or degradation of data. We call this realtime communication or in software engineering terms synchronous communication. When there is a consequence to the receiver of the communication being mistimed it is just very very hard to do from four feet let alone 2000 miles.
Fortunately we have a well understood and well trodden software engineering solution. We put a cpu and a buffer in the digital streamer right next to the DAC and split the problem into two stages. Stage one is between the hard drive and the cpu in the music streamer. Stage two is between the cpu in the music streamer and your speakers.
The second stage is realtime or synchronous communication still - feeding the DAC from the CPU in the streamer using the smallest path possible and with great timing. And then having the amplifier take that signal and use it to drive your loudspeakers so that the music reaches your ears. Thats entirely the job of the streamer, amplifier and loudspeaker designers to do and how well they do it explains why some audio components cost a few £100s and others cost upwards of £35-40k.
The first stage however has now been converted from a real time synchronous problem to what we in software engineering terms call an asynchronous problem. In other words we can set things up so that we no longer need to move the data with perfect real time precision. The good news is that whilst this is still challenging, it is also a well understood and solved software engineering problem.
So the software engineers use a variety of trusted software components like TCP. This is a way of getting data from computer a to computer b across a network reliably, which allows the majority of the internet and your home local area network to work really well. They add their own software engineering code to create a digital stream that chops the music file into chunks and send it to the cpu in the streamer. It uses the same checksum technology we were talking about earlier to validate that each data chunk sent from the media server matches the data chunk received by the cpu in the streamer.
The data is stored in a buffer in the streamer which is a small amount of memory which holds a few seconds of the music. You can hear this at work. Play some music and pull out the ethernet cable connected to your streamer (carefully 
) The music will continue to play for a few seconds. If it stops immediately, talk to your hifi dealer about an upgrade pdq!!! 
The practical upshot is that the data gets from the hard drive in the data centre in Germany to the cpu next to the DAC with no data loss. And assuming there is sufficient bandwidth to handle the stream there will be no degradation in the sound due to data loss, except for the music cutting out if the buffer ever empties.
There are lots of media servers that have been written to do this digital streaming job. One standard approach is to use upnp. A standard for media servers. There are good well coded examples such as spoon’s asset, twonky, bubble to name a few. Roon is another solution that uses their own protocol called RAAT to do the same job. There are also more expensive solutions available that bundle the server and storage solution into one, though they are not strictly necessary to get a bit accurate stream.
So earlier in this thread I made a controversial statement that we are all in big trouble if different media servers start sounding different. The reason why is that getting data from place a to place b in computer terms asynchronously is a difficult but solved problem.
So if there are observable differences between the sound of two media servers it is either a) a software defect in the media streamer or one of the components it uses or b) some other secondary impact on the streamer must be occurring.
On a) by all means test different media servers to death in terms of sound if you enjoy that. I am sure the developers of the servers would love to get extra end user testing results. Best to direct your observations to the developers concerned as Simon did with Naim as that is the fastest way to fix it.
On b) Simon and I and others were discussing the primary mechanisms by which that could happen earlier in the thread. There are three most likely to make a difference I think.
1 - The software running on the streamer (not the software running on the media server) when it is converted to machine code and is running, generates noise from the streamer cpu. That noise changes when there is a dramatic change in the type of instructions running on the cpu. The noise could, if it leaks into the dac, change the character of the sound fed to the speakers.
That explains the flac v wav differences some people (including me) on some streamers could hear years back. I struggle to imagine how, at a software engineering level perspective, two bit-identical files sent to the streamer using the exact same media server and configuration, and the exact same network path can sound different unless someone plugs in a hairdryer Simon did however suggest one way there might be a possible secondary impact from the way the streamed code is encoded.
In software engineering terms we normally rely on asserting that the test data fed to the system has led to a predictable output and use that to validate that the software is working. I would welcome a problem determination orientated discussion on what other factors might make the outcome of that test invalid if we have a specific example in mind. I could learn so much. But perhaps not in this thread!
2 - The noise from the hardware device running the server cpu, disk drives, network card, network cable etc. might leak into the streamer and again change the character of the sound. In this case, as Simon mentioned, modern switches and networking components do quite a good job of reducing that noise.
3 - A corruption on the hard drive that houses your music data. Note in this scenario the type of disk used makes no difference. Again I can think of no situation where a WD gold drive sounds better than a WD RED drive. So make sure you back up your music folders. Because a hard drive crash or corruption will occur with very high probability eventually. Thats why I personally have a NAS, and two backup NAS with one offsite. But thats my choice and its not strictly necessary. Just take sensible precautions.
So what is my advice to the OP on media servers. Again I think it is really straightforward.
- Frankly, take for granted that the media server, if it has a good reputation, does a good job of moving the data from its storage location to your streamer in a bit perfect digital stream.
- Choose a media server based on its features and its known reliability.
- If you know how to install software onto a pc, mac or linux and configure it to point to your beautifully (accurately
) ripped files, then by all means do that. Examples would be roon, asset, bubble etc. If you are less sure on how to do this, by all means buy an all in the box solution.
- In my personal view, get the media server as far away from the hifi as possible assuming your media server is connected to the rest of your network and the internet when you listen.
My personal choices have been asset and now Roon. They run on an always on small hp desktop pro in my office which cost me a few hundred pounds refurbished. It also runs plex and provides me vpn access to my network. Asset was easy to install and it worked well. So was roon and I personally love the curation of content and the features to manage multiple versions of the same album seamlessly. And its tidal / qobuz integration. Some other Linn users swear by their new app. I tend to swear at their new app but then I am a luddite
Keep enjoying the music. 
