[haloxt]

Squeezebox loads the data into ram, so it's not real-time, and a computer can't degrade its performance.

 

[Dynobot]

Quote:

 

I'm not able to wrap my head around this topic. Data is transported as 0/1 wrapped in TCP packets. And these 0/1 are then sorted in correct order by the software in the TCP receiver. If one packet is lost it will be resent so they do not necessarily hit the destination in the same order they was originally sent. When they are all there then they are stuffed into a FIO buffer before they are clocked to a receiver with it's own FIFO and then clocked to the DAC and/or S/DIF logic. I would think all the reclocking of data would take TCP/IP transport out of the equation? The protocol in use are way smarter than me and my ears. Think about it, all our online banking relay on this protocol. Only thing that I can think of that could harm this are memory buffer in the receiver that are to small to handle delay on the network. But that I would expect we would hear as dropouts.

Yes I realize that in the event of a packet being lost it will be resent.  However by the very nature of the TCP process jitter can not be avoided.
 
This is what Cisco Systems says about Jitter in handling packets over the IP
 

What causes Jitter?

Jitter is generally caused by congestion in the IP network. The congestion can occur either at the router interfaces or in a provider or carrier network if the circuit has not been provisioned correctly.

 

The easiest and best place to start looking for jitter is at the router interfaces since you have direct control over this portion of the circuit. How you track down the source of the jitter depends greatly on the encapsulation and type of link where the jitter happens. Typically, ATM circuits do not experience jitter when configured correctly due to the constant cell rate involved. This gives a very consistent latency. If jitter is seen in an ATM environment, examination of the ATM configuration is necessary. When ATM works correctly (no dropped cells), you can expect jitter to be a non-issue. In Point-to-Point Protocol (PPP) encapsulation, jitter is almost always due to serialization delay. This can easily be managed with Link Fragmentation and Interleaving on the PPP link. The nature of PPP means that PPP endpoints talk directly to each other, without a network of switches between them. This is so that the network administrator has control over all interfaces involved.
 

Conclusion:

Jitter is a variation in packet latency for voice packets. The DSPs inside the router can make up for some jitter, but can be overcome by excessive jitter. This results in poor voice quality. The cause of jitter is that a packet gets queued or delayed somewhere in the circuit, where there was no delay or queueing for other packets. This causes a variation in latency. Jitter can be caused both by router misconfiguration and by PVC misconfiguration by the carrier or provider.
 
In summary:
 
Don't just assume you can send data from point-A to point-B through your router without jitter, measures need to be taken to make sure this is not a problem.  In many homes you have numerous computers connected to a single router with all sorts of traffic load.  The router will handle your music data like any other data be it voice data, internet traffic or games unless you can configure the router to handle the data in a way to avoid bottlenecks and dropped/resent packets.
 
Recommend if you must use S-box then buy a separate router just for your music and configure it properly.

 

[notThinking]

True, but this is not jitter in the audio domain. When Cisco talks about poor audio quality my guess they are talking about dropouts with UDP packets. Audio-data we transport with better audio gear are wrapped in the TCP packets where audio data is only a small part of the content and data packets are completely out of audio time domain where audio jitter has it's roots. Not until data is extracted from its container and sorted in its right order and leave the FIFO can audio jitter come to play. In the same order as we have to balance our bank account before we pay our bills data from the TCP stack has to be sorted before any audio circuit will ever see the datastream.
As I see it only logic way to look at this is to consider the CPU doing the TCP unwrapping and clocking to the digital receiver the same way we look at CD transport. How the CD was produced is not part of our jitter issues. Laser unit and all parts from there to S/SPIF out can be pron to jitter.

 

[Dynobot]

Okay, good points guys....haloxt and notThinking.  I concede to your reasoning concerning jitter.

 

[Parafeed]

Quote:

Back to the topic, SqueezeCenter [processes] the audio data on a computer then sends it out to a device like the Squeezebox.  If you think that this process can occur on a computer without any effects from the computer contaminating the data you are crazy.

Please stop posting this drivel! It's drivel, absolute drivel!

 

[Parafeed]

Quote:

Recommend if you must use S-box then buy a separate router just for your music and configure it properly.

Oh give over. There is no need for a separate network or router. A buffer underrun once in a blue moon and that's with my son maxing out the wireless most of the time with his Xbox Live account. That's the whole point of having the RAM (input/decode) buffer on the device!

 

[Dynobot]

Here comes the Town Lunatic ranting and raving after the discussion has ended.
 
Its over, you Lose Again!
 
Haha

 

[.Sup]

Here we say: the smart ones stop first

 

[Parafeed]

Quote:

Its over, you Lose Again!

Sorry, I keep forgetting that I need to unlearn everything I've learnt and kneel at the alter of Dynobot to be enlightened out of my loser way of thinking.

 

[Dynobot]

Quote:

Here we say: the smart ones stop first

Guess that would be me....

 

[Dynobot]

On a lighter note.
 
Anyone else around here using Tube preamps or amps with their AGD Dac?
 
Granted the Roc/Ref5 combo sounds great, but mating the Ref7 with tubes is to die for...highly recommended.

 

[Parafeed]

For the benefit of others, (someone just asked me in private to justify my comments rather than just yell at Dynobot)......
 
A little common sense and maths goes a long way. Do you need a separate router for your Squeezebox?
 
Assuming you're running a G wireless connection, with a semi-decent router and > 80% signal strength, in the real world you should be approaching, (if not exceeding) 20Mbits/sec. Uncompressed 16/44.1 requires approx 1.4Mbits/sec and flac approx. 0.7Mbits/sec. Then factor in a 10 second buffer (uncompressed 16/44.1) in the SB hardware. Then apply common sense. 
 
If you're experiencing a lot of buffer underruns or rebuffering then drop me a PM and I'll guide you through a more thorough investigation rather than just throwing a separate network/router into the mix.

 

[Dynobot]

 
 
Below is a link to a thread talking about the Transporter Jitter specs from two different sources.  One source tests the product using full frequency while the other tests the product only at 1Khz.  It appears when you test only at 1Khz jitter numbers are outstanding, but full frequency tells a different story.
 
http://forums.slimdevices.com/showthread.php?t=84999
 
Full frequency is around 1000ps jitter.
 
1Khz narrow band test is around 235ps jitter.
 
Follow the links and read the info for yourselves.....
 
Reading another thread at the Lavry site it appears that a Sony CD Players jitter was 147ps jitter
 
http://www.lavryengineering.com/lavry_forum/viewtopic.php?f=1&t=137&start=0

 

[IPodPJ]

Who here said anything about using the Transporter's DAC?  We are talking about it being used as a transport.  And yes, it has cheap oscillators which is why they need to be replaced.

 

[Dynobot]

Those measurements are digital out not analog.