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
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.
Google Search
|
Meridian Systems
|
Meridian Streaming
|
Restaurant
|
WiKi
|
Duncan's Meridian Info
|
Board Rules
|
Restaurant Rules
