Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Systems SB Touch

Ian, all this is correct, but doesn't really address the point at issue which is whether the file type being transferred over the ethernet affects the input jitter to SB or ID40 (which obviously it doesn't because you can't even define jitter for asynchronous transfer whether it is under TCP or UDP - jitter doesn't exist till you have a synchronous - ie clocked - bitstream). TCP versus UDP can obviously affect dropped packets, buffer under-run etc on a dodgy network, but the effect of that is dropouts not degraded SQ. I have been careful throughout to point out that I am assuming sufficient processing power and bandwidth to avoid drop-outs, dropped packets, buffer under-run etc. AFAIK it's TCP except for MP3 BTW, so TCP for both PCM and FLAC.

Carl, that's exactly as I understand it.

Why you addressing ME. Ronnie dragged it up and I said I don't know what you meant for sure by it. What I said is I could see someone misreading it AND DID. But to be honest I still think someone could put spin on your statement above. Some folks manage to find crevices and misread things. To make it absolutely clear I would include WAV as another asynchronous lossless format. I like to reserve the term "PCM" for when it's clocked out of the internal ID40 memory or out over SPDIF in a SB memory. In otherwords PCM == Synchronous and FLAC/WAV == Asynchronous. Because WAV should not be thought of as "PCM" (that's my own pet pieve), just a file format for storing samples (just like FLAC). When it gets down to non packet based protocal then I like to call it PCM (raw 16bit samples). It helps keep you head on straight. PCM goes over busses, SPDIF etc. WAV, FLAC goes over ethernet.

The reason I said someone, might read it wrong is because you lumped the magic word FLAC just before jitter. Not a good idea.

Just say as you did here "any other asynchronous lossless format" (which includes WAV and FLAC) and makes NO DIFFERENCE jitter, ID40 could work with either.

I also quoted parts of your original post as what I believe your intent was and said that was correct "allows it to buffer".

It was Ronnies misinterpretation I was addressing. And the possible outside chance he was right in what HE thought you were trying say. He was incorrect and I suspected you understood how things work. And he just misread it when he saw FALC and jitter in the same sentence.

Totally agree here. TCP or UDP doesn't matter. You can have higher level protocals of your own that use UDP just as robustly as TCP. UDP is just less overhead. But if a packet is lost a client can just ask for it again. As long as it stays ahead (keeps buffer from underruning) it's all fine and still jitterless. In small networks, in a home for example, UDP rarely fails.

UDP is usually used for regular, non critical "Status and Monitoring". Nice and light weight. Like what song it playing might be broadcasted once a second. If a "status" is lost. No big deal, another ones is coming. "DATA" us usally TCP. But can go over UDP with a good design.

@Carl
I can only apologise that your post has been Extrapolated and Spun to meet someone's else's agenda

As should be obvious, I included your post for another reason I will get to in a second

@George
Yet again, it's incredibly obvious that you haven't read a single thing that I've written, or that Carl has written, except thru your own self-serving filter

hecd wrote earlier

As well as including the fact that other Dealers had posted the same thing, I offered Carl's response on the subject, and even highlighted the relevant parts

Of course, I said NOTHING about Carl's post saying that it somehow confirmed that "sending a FLAC reduced Jitter" (which of course is how you've been MISREPRESENTING my posts as being)

Here again is how I positioned Carl's post earlier today......Why not take the time to read it this time

[/quote]

I apoligize. I didn't realize you were only making the point that ID40 used FLAC. I didn't realize you dropped the argument over effect of FLAC vs WAV over ethernet and risks to jitter. I thought it was yet another post on that debate (you, I and hecd went many posts on that I thought it was just yet another, especially where it has FLAC and jitter yet again in the same sentence). Again sorry you were just stating your reference of the use of FLAC in ID40.

Yes. That protocol is called TCP No point reinventing the wheel.

As for small home networks, I think you would be surprised what people expect from their networks now a days, multiple AV streams, disc shadowing/backups etc all things used in a typical Sooloos network and some other networks . What do you think is happening exactly when the words 'buffering' appear on a device? You can build a really fast network that can continuously handle a high load requiring low latency, but we are talking about consumer devices here installed by consumers who may simply run the devices as wireless, peo or through the router supplied by their ISP. Meridian themselves recommend connecting Sooloos to its own router because they appreciate that Sooloos may be susceptible to network load. I can even remember one post on here talking about removing Sooloos from internet benefiting sound quality.

I was forgetting about WiFi when I said UDP rarely fails at home I also try to reserve wifi for only portable devices only. But yeah the probability of lost packets over wifi is much higher.