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

This shows you still don't understand how things work.

The link between SqueezeServer and SqueezeBox is just like the link between Sooloos Server and ID40. Both twoway packet network based and buffered. NO JITTER. The FLAC vs PCM is a just a FORMAT issue and CPU load issue. It has nothing to do with jitter.

Sooloos could send FLAC or PCM to ID40, it would be the SAME, no jitter.

Jitter does not come into play until it starts getting clocked out sample by sample (LOOOOOONG after WAV vs FLAC has been dealt with).

Having a SqueezeBox near Processor will NEVER be ever close or similar to an ID40. Regardless if it's FLAC or PCM.

Because the SqueezeBox will always be limited to SPDIF communications where the jitter realm kicks in. That jitter realm can be controlled INSIDE the 861v6 and NEVER use more jitter prone SPDIF. SqueezBox will always be stuck with more jitter prone SPDIF.

Again nothing to do with FLAC vs PCM and who decodes to decode it.

If either CPU on server or client is overloaded and asked to decode FLAC when it does not have bandwidth or network is marginal then you will have UNDERRUN. GAPs in play back. That is NOT JITTER.

What you are confusing is a Bitstream in PCM vs a effectively WAV FILE.

SqueezeServer sends a FILE, be it a FLAC, WAV or MP3, no matter what (turns out to be pieces of files but it's a FILE).

Then it converts it to a PCM Bitstream, no matter what it started out as.

The little bit of decoding a WAV vs Decoding FLAC and who decides to do it does not change what happens to the PCM Bitstream which happens LATER and that's when jitter kicks in.

That later step of PCM Bitstream happens inside ID40/861v6. Regardless if it's sent FLAC or PCM.

In fact I suspect ID40 does not decode FLAC. But it does not matter. It does not change anything.

I don't know how you know that. On reflection my statement that the FLAC decode is done in C15 or Ensemble is an assumption. I don't think any of us know whether the FLAC - PCM decode is done in the C15/Ensemble or the ID40. But in any case for the purposes of sound quality, the point is moot since the connection between the source and the ID40 is ethernet and whatever files are sent are sent in asynchronous ethernet packets - ie jitter-free (or strictly speaking jitter-meaningless).

How do you know that Sooloos sends FLAC files rather than decoded uncompressed files on the network?

That is an entirely different question which is what I've been pointing out. Here you are comparing two methods of getting data into the 808.3 - asynchronous ethernet versus synchronous clocked SPDIF or SL. It's got nothing to do with what file types are being transmitted and where they are being decoded to an uncompressed PCM like WAV.

Finally, at least someone else gets it. Good post.

George
I'm just tired of your Lecturing and insults....................as well as your not taking the time to read other people's posts, including mine

I'm not misunderstanding anything

In simple terms, so that you might actually read and attempt to understand................

More than a few people on the SB Forums have found EXACTLY what Rawlander found above (and you insulted him on)........i.e. that Decoding from FLAC to PCM on the Server side resulted in a poorer Sound from the System than when asking the SB Client to Decode

Just as Rawlander has above, they have toggled backwards and forwards and found the same results............SB Client FLAC Decoding >> Server side FLAC to PCM Decoding

Got that so far????

Now again, more than a few have Speculated that this is being caused by sending PCM to the SB Client; and buffer under-runs caused by issues at the Server, resulting in MORE JITTER at the SB Client SPDIF outputs, with knock on effects for the downstream processor and System Performance

The Hifi news article that Avii refers to above refers to a similar issue of higher output jitter, except this time over HDMI

Rawlander and many other others have reported issues with PCM Decode on the Server........your response has been to call him (them) crazy

Whilst you may find that others here tend to back away from your intimidatory rants, you'll find that won't work with me

hecd
This has been covered before in our previous discussions on exactly the same subject

a) A contact at Meridian explained it in that manner to me when I met him at my Dealer back in June. I asked him simply to explain the advantages that the ID40 brought to the party

b) Carl (our Global Mod) had the same thing confirmed to him when he was discussing his purchase of a Control 15 and 861v6

c) Two of the Meridian Dealers who regularly post here said the same thing in different posts

In our August discussions on this very subject, I said that the advantage of the ID40 was that it eliminated Source Jitter at the SPDIF Outputs as well as Processor Input Jitter at the SPDIF Inputs

As you know, you took a different view and specifically said that you would achieve equal performance from your own SB Client over SPDIF into your 808.3. We both know what you subsequently posted after a few listening tests

Take some computer and EE courses. Underruns don't cause or effect jitter.

George has spoken and Rawlander and those on the SB Forums must all bow to his greater knowledge.......What a joke

George..............You seriously have no idea of my qualifications, experience or expertise............until you do, take some Etiquette classes

I'll take some Etiquette if you take the computer classes. Sorry to be so blunt. But you have repeatedly misinformed folks here and it sounds all cool and buzz word like. But it's flat out wrong. Again sorry to be so blunt. I really should be working. The the stuff I should be doing this very minute is loaded with this sort of stuff. Clocks, Jitter, Packet transfers, buffers etc.

I'm sorry Ronnie, but you really are mixing up two different things, viz file types and communication modes. You can send any file type (lossy compressed like MP3, lossless compressed like FLAC, or uncompressed like WAV) packaged in network packets over an ethernet connection. In every single case, whatever the filetype, jitter is not an issue because the data is transmitted asynchronously. It is for this reason that M claims that the ID40 is better than SPDIF/SL as a means of getting data into the 808.3 as the latter is subject to jitter. This is nothing to do with what file type is delivered to the ID40 (provided it is lossless).
Ronnie, I really don't think so. We were talking about whether an ethernet connection to the ID40 which is inherently jitter-free would be superior to an SPDIF connection (ie SB versus Sooloos for my 808.3). (My hypothesis then was that the 808.3 buffering and reclocking would eliminate any jitter arising from the SPDIF link from SB to 808. As it turned out, I do hear a small difference between the SB3 and spinning discs, so I suppose some jitter does make it through the SPDIF input stage. But this has absolutely nothing to do with whether Sooloos sends FLAC or uncompressed files over the network.)

As I understand the various posts, people were putting forward and to some extent confirming the idea that ID40 is a superior input because it is connected by asynchronous jitter-free ethernet packets. I have never heard or read any authoritative source that states that FLAC is the file type transmitted by the Sooloos network from source to server. But even if they have said it, this is moot - ID40/808 will sound the same whether the decoding is done in the source or the ID40, because jitter doesn't start to exist until the ID40 clocks the buffered decoded data onto its bus.

By the way, just to confirm the statement that file type has no bearing on SQ (assuming sufficient processing power and network bandwidth which causes dropouts not jitter), my SB sounds exactly the same regardless of whether I decode on the server or client.

In the same way as I don't broadcast my equipment list, I choose not to broadcast my qualifications or expertise. That you feel you need to, I will leave for others to judge

Now if you wish to talk about "repeatedly misinforming", what about a few of the gems issued by your good self down thru the years

a) That the 861v3 (or v4) does not sound any different than the G68 (despite more than a few here disagreeing)

b) That the Source doesn't matter since all Sources will be performance leveled by the FIFO's in the Processor. Again against a fair number of people here who did report differences between Meridian Spinners as well as recently between the Transporter and SB3 clients. Only the recent consensus that Source Output Jitter, Upsampling and MHR Encryption have an impact ................something some of us have been saying for years now (without necessarily understanding the full implications)

c) That Lossy MP3 is indistinguishable from Lossless or PCM

d) That Apodizing in the HD621 is of no benefit to ANY source.......in spite of the majority of the Poll respondents disagreeing with you (largely depending on the source they were using)

I strongly disagree that I am misinforming anyone, when all I'm suggesting that they (and you) do is to read the information on the SB Forums and decide for themselves. Instead you wish to quell any debate before it even starts...........including shouting Rawlander down and saying his observations were somehow invalid.........treatment that some of us are familiar with in the past when we've chosen to disagree with your various proclamations

My God Man!! I'm surprised you bother with HiFi, at your age your ears must be shot?!






Edit: Image deleted at the request of George, it was a joke that he didn't like. It was meant to lighten the thread a little but obviously my British humour is a little different to our US cousins. Ho hum.

hecd
You continue to say that I'm confusing "file types and communication mode"...........I am not

In the simplest way that I can make it............

a) Rawlander and a good number of others have experienced INFERIOR SOUND when the Server Decode is enabled

b) A good number on SB Forums have speculated that this can only be down to Increased Jitter from the SB Client SPDIF Outputs as everything else remains the same

c) If b) holds up, then they further speculate that as the SB Client is receiving PCM, then something must be happening that is causing the SB Client to have higher Jitter at its OUTPUT

I am not saying that I agree with the conclusions arrived at............but you say that you don't notice any difference..........Rawlander (and others) say that they do..........."Period" as he put it in his post of yesterday