@danny, @brian Does this article on Audiostream go some way to describing your issues with UPnP and DLNA?
I know a lot of people that will have come here from Meridian Unplugged think bits are bits, but I have heard for myself that it is not the case and clearly everything in the chain makes a difference.
Nobody from Meridian unplugged would say bits are bits, that’s for sure.
We at Roon are strong believers that bits are bits, however, processing those bits can create analog differences that are very real. In the end, what matters is how those bits get turned into waves.
The DAC’s “first half” is digital, the “second half” is analog. If anything can introduce noise into the “second half”, then even though bits are bits to the “first half”, the output can be radically different.
I’m ignoring clock jitter on the DAC’s input, as that is a solved problem by reclocking with a good crystal (maybe not for all, but Meridian eliminates this issue).
For example, putting a electrically noisy ethernet PHY chip next to your DAC will not make a difference at all to the “first digital half”, but it may destroy the “second half’s” output.
The article mentioned above is noting that processing audio in a “computer” has a bunch of side effects you may not notice. High speed RAM, SSDs, magnetic hard drives, WiFi PHYs, ethernet PHYs, CPU clocks, etc… they can cause problems of varying degrees if your DAC and analog stages are not isolated properly.
UPnP has pros and cons in this regard. There are many issues here, and I’m still begging @brian to write a good post about this on our blog, but I’ll name 1 of each here.
A pro of UPnP is that the clock is owned by the receiver. This is not the case with AirPlay, where the shitty crystal in your computer, which is being bombarded with high frequency noise from everything else in the computer, is driving the signal.
One of many cons of UPnP is that the burden of decoding a complex compressed data stream, which requires quite a bit of machinery, is the burden of receiver. This has many many consequences, but I’m going to leave it to @brian to explain that in his blog post.
Are you referring to the source material or the actual equipment after the file has been ripped. I know that you once brought to the attention of the Meridian Unplugged board that bit perfect rips might sound different
Meridian - Streaming » Has anyone compared rip methods in Sooloos
And this view was generally discredited .
Yes, the source material and the way it is transferred, Cat 5 cable etc.
Not wishing to start that discussion again here though as the two sides will never agree. Just wanted to see if the UPnP article on Audiostream was on the same subject the danny was referring to.
I can attest to UPnP being susceptible to UTP cable influences as well as the amount of network switches used. When testing a Synology NAS with PS audio PWD MKII and Linn Klimax DS/1 endpoints, more switches means a more agressive and sharp sound, while certain UTP cable types can slightly soften the sound / make it more fluid, but also make it less articulate. Depending on how critical you are, cables might be considered a non-issue, but I would strongly advise having as little switches as possible between media source and your most important endpoint. I also found the MD600 and MS600 or 818 to be very sensitive to this. For example, I tried tucking the MD600 far away (it’s noisy) but found that due to the extra switches (and cables?) in the path, the resultant sound was less free-flowing and less expressive.
Are you referring to network switches?
Indeed, network switches. I had 4 new identical ones, and added one after the other, each time listening to the result. Witch each addition (in series with the previous one), the sound became less “analog”, for lack of a better word.
What was your final listening endpoint in that situation with 4 switches? Meridian endpoints would have reclocked everything so even jitter wouldn’t have been an issue. Bits being bits, jitter and noise is all you have to ruin the sound. The switches and cables, if kept away from your endpoint, shouldn’t have introduced noise into a properly isolated endpoint, and the endpoint should be reclocking to avoid jitter.
I personally would avoid endpoints that can’t render messy digital signals with a clean clock, rather than blame the gear along the way. Everything in the computer and everything on the way has room for this dirtiness, but your endpoint has the power to clean that crap up way better than any “clean source” could even start to achieve.
The final endpoint for that test was the Meridian MS600, but I also heard it with the 818 that I purchased later.
Reclocking in theory is perfect but my suspicion is that it’s still not the same as having low jitter signals in the first place, and perhaps we’re not measuring the right things… I know this is not a popular thought but in the end I can only report on what I hear.
If people want to read more, see my review:
http://hifi-advice.com/Meridian-MD600-MS600-review.html
Ah ha! I remember reading this review.
I trust you heard what you say you heard, and I’ve seen Bob Stuart (who has much older ears than I do), pick up things by ear that I would have needed an oscilloscope to detect, so I know to not argue sound quality with ears that can pick up the differences. 
Fundamentally, unless your power is perfect re-conditioned and everything is electrically isolated (optical?), you will always have noise and imperfect clocks. I would never have believed it was hearable until I witnessed Bob identify the result double blind.
Anyway, when we have our DSP stuff in Roon soon after launch, I’m glad we’ll have someone like you taking a hack at it!
Sorry, but Network Switches having ANY impact on Sound Quality is simply a red herring
And Jitter and Reclicking had Zero to do with Data sent by Ethernet Packets involving Error Correction, Checksums, Packet Retransmission.etc
Data arrives at Sooloos Endpoints by Ethernet Packets… And if they do not identically match the original data, they are discarded and not used… Jitter is not even in the picture
The only thing to be wary of with Network audio are high RFI / EMI levels… And steps can be taken to alleviate those
Forgot to mention… The Sooloos Endpoints don’t Reclock data… There’s no need to as the data arrives via Ethernet Packets
The Meridian Processors do indeed Reclock data… And in those cases, the Data arrives as LPCM over SPDIF cables (or perhaps via Speakerlink / AES)
Different requirements for different data transmission standards
@Ronnie you are righy to say the Ethernet packets to networked Meridian endpoints aren’t reclocked. They are clocked for the first time inside the endpoint! There is not difference to that endpoint whether the whole song is in memory or coming to it over the network, because everything is buffered in the ram of the device faster than realtime and playback occurred from that buffer. My reclocking was in respect to the SPDIF, as you said. That’s a possibility in @Christiaan’s 818 case, but not his MS600 case. I have no idea what he was hearing with the MS600, because it’s not a clocked digital audio stream that is going to the MS600 – it is digital and packetized.
Its one of the biggest technology advantages the Sooloos streaming protocol and RoonSpeakers have. The clock is almost always owned by the endpoint. Only when streaming live material is it not.
UPnP is similar, but with significantly more machinery.
Airplay and Songcast are clocked at the source 
That said, I’ll keep to the technology while staying out of the discussions of subjective qualities that my ears can’t hear.
Thanks for doing the honours with the sanity clause, Ronnie.
I try to be as open-minded as possible, but occasionally have to remind myself that self deception is a more likely answer than defying the laws of physics.
If I remember correctly a prior review advocated raising an MC200 off the ground with Cerapucs to improve bass slam.
There’s a review of them (as speaker feet - a snip at $600 in 2005) in Tweakers Asylum.
The clue is in the name.
The MC200 is basically an Intel Atom motherboard in a custom case with a nice USB audio device in there.
There was a real reason why it is vertical… the way the heated air flows inside, when it is vertical, it cools more effectively. Heat dissipation without a fan was always a concern for Sooloos products. We only ever got it done on a few devices, and the Control1/10/15 was the most difficult of the bunch. The entire back surface of that thing is a heat sink.
Everyone is entitled to their opinion and I definitely don’t want to start a tweaking vs sanity discussion, but just as an FYI, one doesn’t have to use Cerapucs or other pricey products to hear this effect. I used Cerapucs with the mC200 as I had them lying around anyway. Ordinairy cheap cones/spikes however will also have a similar effect. Just try it.
Please can we confine Roon forums to discussion pertinent to Roon, there are numerous online forums where these matters are debated at length.