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

With no disrespect, Ronnie, I really thought you knew better than to even ask that.

It's not better or worse, Jitter does NOT exist over PACKET networking !!!

It's REBUFFERED.

Jitter does not become a problem until you get to synchronous communication.

It's not a problem until you reach brain dead SPDIF.

Think of it this way (which is actually not that far from the truth).

The PC/Mac EMAIL's the Song to the SqueezeBox and THEN the SqueezeBox PLAY's it.

Same thing if I emailed you a FLAC or WAV. No jitter comes into play. It's still a FILE not a Bitstream.

If the message was ENCRYPTED in FLAC, it decrypts it first and then PLAY's it.

It PLAY's it by dumping it into MEMORY and Clocking it out over SPDIF.

That memory is ALWAYS PCM.

This happens no matter HOW it gets there. WIFI, Wired, FLAC, WAV, MP3.

The hardware that clocks it out of the memory is the ONLY thing that effects quality (jitter).

The SPDIF clock doesn't get more nervous or jittery just because the CPU is twiddling it's thumbs or decoding FLAC.

DTS Test is a good test to verify both decoders are not buggy (decodeing on Server vs SqueezeBox).
But I've gone beyond that because DTS can tolerate some errors.
I've recorded it with TASCAM box I have and compared the bits.

Only thing left the quality of clocking which is normally free running from the CPU.

This is why the ID40 on 861v6 is a significant step. The Sooloos EMAIL's the Music FILE to the 861.
And this CRITICAL clock to clock it out of Memory can be a VERY well controled low jitter DAC clock !!!

Sorry this is your sentence, perhaps just poorly written. So please don't jump on my case because I didn't write it. I didn't want folks to think Accurate Rip change sound because that's easily how the sentence can be read. There is enough confusion and misinformation with out adding more. Even if was just an accidental grammer error.


But neither will make a difference but they way it's written you give the impression it was either or both.

About the only change you normally have to make is Disable Volume and that will make a difference.

The rest is Snake Oil. If something changes the DTS Test then it will change what you hear. If it does not change the DTS Test you are not changing the quality of oscillators driving them Memory to SPDIF clocking.

If you want to think I'm pushing my opinion on the effects on the effects of Decoding server or SqueezeBox go ahead. You just got it going and now your the expert.

George
If you can find an earlier post than the one below, describing the potential advantages of using the ID40 in an 861/808, then go right ahead............also numerous other posts about how the ID40 works in the same thread..........no lectures required

As regards the PCM Streaming over Ethernet issue, I was short-handedly referring to PCM generation at the PC, where sometimes people are using NAS boxes and under-powered PC's to do the conversion "on the fly", leading to issues. Likewise the known issues about how the SB devices handle PCM at the Input stages. But these issues have already been covered ad nausea in the SqueezeCentre forums, so I'm just going to leave it there

Just to be clear, I was NOT referring to Jitter generation over the Cable or Wifi Transfer of the Ethernet Packets

You've got to be kidding me. Your post earlier CLEARLY shows you don't understand some things or CLEARLY WAY misspoke. All those issues your disscussing have NOTHING to do with jitter, NOTHING, NADA, ZIP, ZILCH. CPU or Network BANDWIDTH issues YES, JITTER NO.

Perhaps you misspoke, had a few too many beers and do understand but be a man enough to admit you misspoke, mistyped or misundestood. Don't give me this underpowered NAS situation which is B.S.

You put jitter and ethernet in the same sentence. Bzzzzzt.

What you SHOULD have said is running PCM instead of FLAC is more susceptable to BUFFER underrun (not jitter), especially over marginal WIFI.

I'm done. If I see a post in a thread by you. I'm immediately out. I'm tired of playing games.

You're not helping me reach my goal of being off the top poster list at all and I only got 1 hr fiddling in tonight. That really sucks.

Likewise, because I'm just so tired of your attempts at Intimidation and Mis-Quoting. And you do it repeatedly".......even in several posts today

George, I did listen to your fiddle playing and loved it. I hope you and Ronnie will one day be friends again. The beauty of music is that it can bring us together. That is what the Music Industry is about. Peace to you both.

Ronnie and George - please would you resolve this amicably and, if necessary, privately. Thanks.

OT but related to jitter - HDMI has a feature call Audio Rate Control (ARC) that appears to allow a single device to control the flow of data between compatible devices. I assume this helps with regard to buffer underrun(?).

However, I was reading some info published by Paul Miller in HiFi News that appeared to show a link between using HDMI ARC i.e. PQLS in Pio's case and a reduction in the correlated jitter measured. Does this means PCM's susceptibility to buffer underrun has a direct link to correlated jitter ?

Avii

Hi Avii
There are several threads over on the Squeezeserver forums about this very topic, i.e. the issues that can affect the jitter output of the SB / Touch Clients. I had assumed that people had seen these already.

As you know, quite a number of people on here have expressed a desire for Meridian to build their own Network Player and for that to be as close as possible to the Processor / Speakers

Meridian, with the ID40 card for the 861/808, have gone one better than that and put that "Network FLAC File Player" into the Processor itself. Getting the Lossless File (rather than PCM) as near as possible to its eventual Decoding has Jitter minimization advantages over PCM. There's not a lot I like about the whole Sooloos Architecture, but that's certainly one of them

I think it's fair to say that the same principle would hold thru with e.g. SB / Touch / Sonos clients, i.e. let the Client (usually in Rack near the Processor) do the FLAC / ALAC Decoding, rather than letting the (usually) remote server do it

Thanks Ronnie it is was more a general query, hence the OT, about the relationship between things that appear to influence what is lumped under "jitter". I'd like to gain a better understanding the principles that come in to play.

Avii

As I pointed out up-thread any effect on data transfer to the SB client or to the 808.3 is an ethernet versus SPDIF thing, not a PCM versus FLAC thing. Any connection over ethernet is in ethernet packets and jitter is meaningless in that context. Any improvement of ID40 over SPDIF into 808.3 will be because the ID40 takes in asynchronous files (and they will be in some sort of PCM uncompressed format - ID40 cannot, AFAIK, decode FLAC - that's done in C15 or Ensemble) and uses the 808.3 low-jitter clock to create the synchronous stream, whereas SPDIF is a jittery synchronous stream to start with.

Turning now to the SB client, assuming sufficient processing power to run the decoders and transcoders, and sufficient network bandwidth, there should be no difference between decoding in the server and sending PCM or sending some sort of compressed file and decoding in the client. In both cases the file is sent from the server to the client in asynchronous ethernet packets - so no jitter. In both cases the decoding is done using the same binary file. In both cases the client constructs the synchronous data stream using its internal clock. So I have to disagree with your analysis above.

I'm not going to talk about the Squeezecentre any more.....other than to refer to the many threads on the same subject.

Summary: SB Users have found deteriorated sound when PCM Decoding happens at the Server end as opposed to the Client end.......Leading some to speculate that buffer under-runs (or something else) is increasing Jitter levels from the CLient.....including the Hifi News article mentioned above

I don't use it, so I'm going to bow out

As regards the ID40 (and the MS600 for that matter), they are essentially Network Players in that they receive the FLAC file and decode it internally. They take the FLAC file over Ethernet in the same way as the SB / Touch / Sonos clients do and then decode from Lossless to PCM internally. It is NOT "some sort of PCM uncompressed format".

I cannot say for sure if the ID40 Card itself or the 861/808 is doing the FLAC Decode as I never got an answer to that question. The Decode happens internally to the MS600

That information is from Meridian in June / July of this year. Make of it what you may, but Meridian state that this is the inherent advantage of these two products.

It's also the reason why they say that EVEN IN THE SAME ROOM, a C15 to 808/ID40 will sound superior to C15 to 808 via Speakerlink / PCM.

Let me emphazize, I have not done the comparison. Others (like Dollar2 & JSCC above) have and expressed a preference for using the ID40