Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Streaming External power supply for MC200

I have a ferrite on the LAN cable, you should loop the cable through. Anyway, it makes no difference to my ears. I completely disconnected it as well and no difference.
Just my experience on the MC200. Chris

The only pertinent comment I can add here is what Meridian said to Nick and I at Bristol

There they said that they had tried many combinations and configurations and they found that it's possible to have too little or too much Ferrite...........and the way it was packed or configured was also a factor

As regards "Recommendation", I prefer to wait until Meridian hopefully release modified ID40 Cards or some other Mods to the MS600

I have also tried some commercially available Ferrite Filters from Maplin...........2 on the RJ45 Cable just before entry into an ID40..........and I think it has made a small, but noticeable difference.......and that is after a lot of other steps to isolate the Sooloos components from all other Network devices on my Network

Hi Ronnie
Since Ethernet is so "noisy" do you think there is value is placing the hub/switch as far as possible away from the AEP?
/Marcus

Lets get this clear before getting the wrong end of the stick turns into fact.

UDP is a potentially unreliable network protocol. It is used for fire and forget light weight performance rather than assured reliability such as with TCP. With UDP, it is perfectly possible to have lost or out of order packets. However, in a wired home network, if you get either of these situations, something is wrong with the network. A UDP packet stream should be 100% as reliable as a TCP connection in the Sooloos environment.

There is some handshaking going on with audio packets, but it appears to be at quite a course level. But UDP does provide a packet based network where data received can be checked for correctness.

It is not PCM data over SPDIF and it is also fair to say that, with Meridians buffering expertise, there is no way that the audio endpoint is likely to be clocked by the core.

And as follow-on questions:

1) "lost" Packets would mean that the Sooloos Architecture was potentially not Bit-Perfect.

2) "Out-of-Order" Packets would be resequenced in their Original Correct order due to the Packets essentially having a "Sequence Number" or "stamp" which allows the Endpoint to Sequence the Data into its original order, unlike LPCM over SPDIF, which has no such "Sequence" Data.

This is a really interesting thread. I hope we can keep the dialogue open-minded and reach some interesting conclusions.

My 2p here; I don't really know the differences between network protocols etc. so it is very informative to learn more about this.

I understand (just about) that there should be no real effect here when dealing with audio packets to ID40, MS600 etc.

However, I have also experienced a change in SQ from the ID40 when changing my network path AND location of core and store. I know it's not PSU changes but relevant to the discussion all the same.

To my ears (and I don't rule out tricks in my head):-

MD600 core/store in room #1 feeding the ID40 in room #2 through just 3 network wired switches sounded better than;

Core in room #1 calling from store in room #2 to ID40 in room #3. Core in this case was sat on the network via TP Link powerplugs and well within the bandwidth of the plugs.

Packets are packets - I understand. There should have been no difference - I understand.

My ears told me there was a difference - I do not understand.

As I say, I cannot rule out tricks in my head. But, I also suspect that there is more to network audio than we've currently understood.

Hi Ian

To describe UDP as unreliable is perhaps a little unfair, I agree it is a fire and forget, but it is essentially a very reliable protocol with a low overhead in terms of resources, no need to go too deep here but TCP is more reliable as it is a statefull protocol as opposed to UDP which is stateless. However, in Meridians case, TCP being more reliable than UDP a protocol that works perfectly well is over egging the pudding, be aware also that for TCP to be statefull it requires an amount of overhead to maintain that tracking info. I guess Meridian assessed both and went with the UDP, as I have never suffered any dropouts I think they got it right. TCP UDP differences

Russ

Hi Nick
As mentioned previously, Powerline / Powerplug networking is known to introduce very high levels of RFI / EMI into an Ethernet Network.......which can be a major reason why people don't achieve anywhere near the published or claimed levels of performance that the Powerplug manufacturer's claim

Having the Audio Endpoint connected to a Core via Powerplugs (and maybe across Switches) is potentially going to increase the RFI Levels within the Audio Endpoint itself

And increasing the RFI Levels within the Audio Endpoint leads to increased potential for the AE's Clock to become corrupted, thereby leading to higher Jitter Levels on the Output Stream.......thus leading to degraded Audio performance

IMHO, the only way to test this would be to have the Two different Cores at the same physical network location........whilst also perhaps minimizing the number of Network Switches between the Meridian Core and Audio Endpoint........thus minimizing and Equalizing overall RFI Levels between the 2 Cores for testing purposes

This would allow for a truer "Core v's Core" Performance Test.......which as we know, Meridian claim Zero Difference between, despite the obvious potential for them to increase their Sales significantly by claiming the opposite

Well, this "no way" or "unlikely" is where I find the only reasonable explanation as to why users, myself included claim they hear differences when affecting the core/store with a high-quality linear PSU or change the network topology.

My hypothesis is that jitter or what we usually percieve to be jitter traits are indeed factors on this store-core-endpoint PCM in UDP packets over ethernet connection much like SPDIF connections.

Much unlike the traditional way of a network streamer like HDI Dune that reads a large part of an entire FLAC file into its endpoint RAM, decoding to PCM and playing it back in its entirety with the internal clock.

And are you therefore implying that if the FLAC files were being sent all the way to the Endpoint, that these issues would not be a factor?

If that is what you are saying (as when you analogize to HDI Dune Server above) then why would that be?

@Russ

You misunderstood my post.


I don't think my comments are unfair.

@Ronnie

In a hard wired network as Meridian recommend, both these should be a non issue. Add wireless, power line and routing, then things can be different. A well constructed wired network should be no less reliable than say a piece of coax running SPDIF between a transport and a DAC.

UDP offers many advantages compared to SPDIF and is more akin to running something like DD/DTS over coax but with the advantage that, if the application so required, it can be a bi directional communication so error control can be incorporated into the application.

Imho, the additional assured reliability of TCP is not required. Whilst TCP offers a closely coupled handshake and additional safeguards to handle lost or out of order packets and other bits, these can interfere dramatically with the timing of packets. IMHO, a very rare (should be non existant) lost packet that may even go unnoticed is probably less of an annoyance to the listener than having the system resync/buffer whilst a lost packet is recovered from. UDP also allows multicast broadcast for linking multiple zones which makes for far more efficient use of network than point to point connection that is needed with if using TCP - not that Sooloos is particularly heavy on the network if configured properly.

However, no matter which network solution is chosen, imho it's not going to be robust enough to pass a master clock signal needed for audio timing and therefor the audio stream is going to be clocked by the audio endpoint with exactly the same accuracy as if the audio endpoint was decoding a FLAC. There are huge benefits for this data being PCM based, leading to simplicity and optimisation of design of the audio endpoints. With less to do, there is less chance of them polluting the audio output. At the very least, it nullifies the FLAC vs WAV debate

It seems fairly clear that EMI/RFI from the PSU of the MC200 is polluting the 861. Dropping the noise coming out of the MC200 (by whatever means, over ethernet or mains) decreases the noise in the 861.
The question of how that noise manages to get into the 861 is both the least and most interesting one.
Least because it shouldn't be happening and most because it is happening.