Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Streaming LAN isolator anyone?

Hi...

Going back to my original question, the LAN isolator from Acoustic Revive, I bought them and tried for 2 weeks, and my findings are...

1. There is subtle sound difference.
2. It feels like sound is filtered, (roll-off range is more narrow)
3. Meaning highs are bit rolled off and base attack is reduced.
4. But it also means that highs are bit smoother, and base is bit tight.

Conclusion.
If you have boomy base and too bright sound, try LAN isolator.

Hope this helps~

Funnily enough, I let it play music for twelve hours the other night (before turning it off to make another change to the system) as I realised the (newish) 818v2 could still be burning in. Must get around to starting this process again before heading back to the US for a few days...

Interested in the results of this.

Chang, where you placed the GISO in detail ?
Does the short cable delivered with the GISO is before or after the MS200?
Which other SL/Cat cable are you use ?

Robert

Cujo tested the Acoustive Revive product. Not the Giso.

Hi Ronnie,

Yes, I fully get what you're saying on Ethernet and error correction - don't worry. I read up on CRC error correction and it's pretty hairy-arsed for sure.

Not sure I made it clear that I had no intention of making specific assertions or recommendations about what cable to buy in which part of the system. I won't be buying any fancy cable between MD600 & 808v5, as the run is 20m and it would cost literally thousands.

My aim in the original post was just to throw in a bit more engineering-led thinking to sit alongside the obviously very deep well of IT-led knowledge that we have on this forum. The point was simply that, at the physical level (i.e. before error correction etc.), digital cables are affected to some extent by electrical, magnetic and mechanical influences that affect analogue cables and equipment.

BTW. Just to set the record straight, mercifully, the cable engineers did come up with adequate and cost-effective designs to account for skin effect in Ethernet cables - hence current ability to run Gigabit connections on cables costing a few quid. There�s the separate matter of the extent to which a problem is contained or reduced, so there are clearly more expensive designs that go further on this front, whatever one�s view of the value. It�s worth a quick search on Google to see what�s been done with successive generations of Ethernet cable design (purely in the IT world), not just around skin effect, but impressive tricks to minimise cross-talk as well to get data rates and bandwidth up.

Anyway, I have a question that�s bruising my brain a bit. I buy what you�re saying about the 100% infallibility of error correction over Ethernet, but this leaves me wondering about two things:
1. How does adding a GISO at the source end of an Ethernet run produce such a big improvement in sound for four contributors on this thread? Ralf told me that nearly all the gain is down to filtering out RF noise, so I�m wondering how a reduction in noise can help when TCP/IP is doing its thing. Not challenging here � just wondering where and why the gain is made. Could it be that the noise otherwise gets beyond the ID4x card, causing other damage to sound downline?
2. The ID41 card is widely reported to be a big step up from the ID41 and I�ve seen comments to the effect that this is largely down to better handling of noise. So again, given the reliability of Ethernet error correction, is the gain from noise reduction actually realised further downline?

Dave

If I understand your question correctly, I believe the gain in noise reduction is further down the line as the effect of interference from the ethernet cable on the internals of the end point is being minimised.

Hi Dave
We agree on the fact that the physical phenomena that you mentioned previously will also have an impact on Ethernet transfers

However, the Protocol was developed (and since refined) to make sure that even when these physical issues were 'impactful', that the Data arriving at the Endpoint was still Identical to what was actually sent

If I was to try and summarize or compare I might say the following:

In Analog, Digital over SPDIF and Digital over AES / EBU (SL) connections, ALL the 'Data' (Signal) received by the Endpoint is still used........and it is used even if the physical phenomena described above has impacted the 'data' (Signal) in some way.......so even if the 'data' (Signal) is 'modulated'; delayed timing wise; or "corrupted", the data still gets used by the Endpoint......and it gets used as the Endpoint does not know that the 'data' is "different" to what was sent and assumes the data to be 'correct'

Ethernet is different in that it allows the Endpoint to compare the Data received with what was sent......and will simply Discard any data which has been impacted by the physical phenomena you described earlier......it also allows the Endpoint to request that the particular impacted data be re-sent......and if it doesn't ever receive an identical 'packet' then the result is 'blanks" on a PC or Tablet screen.......or Dropouts in the Sooloos world

So, Ethernet prevents the use of 'impacted' data and allows obvious identification by the user that data is missing

This 'logic' comes from the IT world, where it was long ago decided that essentially "NO Data is better than the WRONG Data"......which is made sense of by the following examples

** better to display No Stock Price than the Wrong stock price........as the Wrong stock price could have catastrophic implications

** better to display No Reactor Core Temperature than the Wrong one (obviously still doesn't overcome faulty sensors producing the wrong result).........as again the Wrong temperature could lead those in charge to take the incorrect remedial actions

** better to leave a blank area on an X-Ray or MRI scan, than to present essentially 'false' information on the broadcast Scan.....as that could have catastrophic impact on the Diagnosis and possibly the patient

And the knock on effect of all the above for us in the Sooloos World is that Dropouts highlight to the Listener that there is an issue that he needs to deal with

Thanks Jeremy,

Yes, I think that makes sense.

I'll do my best to answer your question within the context of the Sooloos and Meridian world

Consider the MC200, which acts as a Core, Store and Endpoint in a Sooloos system

For reasons similar to that already explained, you can rest assured that the Music data is retrieved from the hard drive and sent along the various interfaces where the data arrives Identical and Intact at e.g. a point prior to the Digital output

That data then needs to be converted into LPCM Data, before being output over Speakerlink

So, the Data arriving at the Digital output 'card' is identical to that on the drive.......but it is known and acknowledged by Meridian that INTERNAL RFI / EMI within the MC200 causes the conversion to PCM to be adversely affected

And this results in basically higher Jitter on the Digital output which results in Audio that some / many users can determine as being good but maybe could be improved upon

Where does the RFI / EMI within the MC200 come from??.......typically from the 2.5" Magnetic object spinning at 5,400 to 7,200 rpm in close proximity to the Digital output card.......but also from the other components within the MC200 that are PC based and emit certain amounts of EMI

Hence the existence of the MS200 and MS600.......these have very simple interiors, all with the aim of dramatically reducing internal EMI compared to using the MC200 alone......and the result is that many here feel that their systems sound better as a result of disassociating the Data Storage from the conversion to LPCM


In a very similar manner, if you asked Meridian to summarize the differences between the 861v4, 861v6 and 861v8, they would simply say that they have 'engineered and developed' the internals of the 861 to have less and less internal RFI......thereby ensuring the LPCM output from the 861 is exhibiting lower and lower levels of Jitter.......and again, most here can hear those benefits

Thanks Ronnie,

This all makes perfect sense and it's good to know the background.

I just realised I said something else that might have confused people: when I said I'd compared different grades of Ethernet cable in my system, I meant the Speakerlink, not the run from source to endpoint. What I was saying about AES/EBU and component frequencies also related to AES (Speakerlink) rather than audio over IP, although as you say, exactly the same principles apply to the Ethernet connection before error correction has its say.

Re the link from MD600 to 808v5, I just put in good quality CAT7. The only 'science' I applied here was based on it being a long, 20m run and on going to a lot of effort to run it under the floor from one side of the house to the other. Wanted to do it right once.

PS The GISO clearly has different impact in different people's systems, but two weeks on, the GISO is a big factor in mine. If I was to say a major component change, like upgrading from 808.3 to 808v5, is a 10, then the GISO is firmly into the 5+ territory. The sort of thing that makes your ears glow and your mouth hang open.

Where I thought I had some kind of grasp on why, I'm not so sure now :-(

Just to add a 2p here....

I added a GISO on Friday. Has been well run in with 3-4 days of music. I spent 90 mins yesterday with 3 tracks switching GISO back and forth.

Really really hard to definitively say I can hear anything significant changing. Certainly nothing night and day going on. Nothing leaps out as different. It sounded awesome before and awesome after.

There is a hint of something that Jeremy noted earlier....."but with a slight concern that it doesn't appear quite as warm sounding as it did." I could talk myself in and out of this.

I'll do some more listening tests at the weekend. May recruit some local HH to help (you know who you are chaps).

I'm actually answering some of your question 1 as well as question 2 in this post......trust that's ok

A few years back, I heard an interesting story from a Meridian insider about how Meridian developed the Ruby Anniversary 808 to be their 'best Source' to date

So the Development team played, listened and tuned the 808 to offer the best quality CD replay and only when they finished that did they turn to ID40 Streaming performance��.at which point they tried Streaming to the ID40 and couldn�t understand why there was a noticeable difference in performance

So they returned to CD replay and found that this was also now affected��..so they scratched their heads and tried to figure out the difference��and the only change (as the ID40 was already in the 808 during CD replay development programme) was that there was a Catx cable now connected to the 808��..disconnecting it returned the CD Replay to the high level previously experienced

After lots of discussion and the use internal probes & sensors within the 808, they concluded that it was RFI getting into the 808 via the Catx cable��and they then began to figure out ways to eliminate that

They tried several known materials and combinations and amounts��..and found the right combination��and also found that there was an optimum amount of filter��.too much filter also caused issues

As a result, the Ruby 808 shipped with an ID40 card, but also with a modified Speakerlink cable that had an approx 3" by 1" diameter "Podule" of Ferrite based material, as Meridian found that using this Ferrite Podule returning Streaming performance to the high level expected

Subsequently, Meridian figured out a way to incorporate the same benefits of this Podule by incorporating some extra components within the 'new" ID41 card.......and all these changes were geared towards reducing RFI getting into the 808 or 861 from the network cable

So again, the Ethernet Data being received by the ID40 and ID41 was identical.......the difference was that reducing the RFI / EMI entering 808 allowed for the Digital Engine and Digital Output cards of the 808 to perform better and effect a better conversion to LPCM......with the end result being a Digital Output with lower Jitter levels