Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Systems 621, 121 and 421

Jitter does not alter the bits, it's an error in the time domain.


The sparkles are noise from errors in transmission -- which btw is added noise.



Overall, a higher gauge cable or signal booster will eliminate dropouts/sparkles, but could that be described as "improving image quality", especially over short cable runs? I wouldn't call it that.[/quote]

Removing an artifact of transmission (sparkles == errant bits in the display) isn't improving image quality? Hmmm. You have a curious definition of improving then.



Yet you get sparkles (data corruption) and you got dropouts (usually a synch error). That's in between working and not working.

Sure using packets help, but HDMI goes only "half the way" since unlike computer connections HDMI has no feedback if the packet reaches its destination uncompromized or not.

Tommy:

In a real time system, it's a bit difficult to work feedback in

Okaaay, how does one improve the picture by dejittering it?


But that's not the same as interference we get from a 3rd party source such as we have in cable, component, etc? It's missing data, not an actual alteration of the signal per se due to additions to the signal. This is an actual malfunction is it not?


But what is there to improve over short cable runs, or a cable that isn't defective? Under "normal" cable lengths, and not using a broken cable, what is there to improve? Please correct me if I am wrong, but won't the received signal be perfect as long as there is no problem with the cable? And aren't those imperfections showing up more like obvious errors than distortion or resolution loss?

Do you equate sparkles and dropouts in HDMI to the kind of noise interference and signal degradation/resolution loss you get over component, or some other analog video signal? You get sparkles, or you don't. You get dropouts or you don't. What is being improved if there are no transmission problems?

Funny, but I thought either one of the links below was appropriate around now

Hilary

The Full Monty

John,

"Jitter does not alter the bits, it's an error in the time domain. "

Both really. The error in the time domain can causes bit transitions to be mis-interpreted. That is a bit error.

Shawn

Surely it depends on the bit-rate vs. the jitter rate. For SPDIF audio, jitter is orders of magnitude smaller than the bit rate and the only place it matters is at the DAC. HDMI may be different.

Nonetheless the intention was to try and evaluate one of the features of the HD621 by comparing it with existing Meridian kit to see if there were any real benefits: reducing video jitter.

VK,

Jitter does not have a rate, per se. Jitter "magnitude" and the potential for bit errors is independent of the data rate. There is also a jitter "frequency" component which impacts clock-data recovery circuits, potentially resulting in bit errors.

However, based on my past hardware design experience, my guess is that the overall bit-error-rate (BER) in a digital audio system is exceedingly low and that any audible affect of jitter occurs entirely in the DAC. That is, when the digital audio is converted from the time domain to the frequency domain.

Dan

Meridian can't afford to be accused of contributing to problems in the HDMI chain. For that reason alone, I think Meridian is obligated to produce HDMI equipment that outputs a re-conditioned HDMI signal. It's just something they have to do. Whether or not video jitter is visible, I'm not sure.

(Warning... long and probably boring post alert......)

In a basic system the only place that matters for jitter is at the DAC. If jitter isn't causing bit mis-interpreting problems there then jitter isn't a problem in the system. That is a basic system though

However, in a more complex system we have another place that bit values are being interpreted... at the DSPs. Jitter at the DSP can also be a problem. If a DSP mis-interprets a bit transition due to jitter then that bad bit is taken as 'good data' and will propagate through the rest of the system.

To understand why timing errors can cause bit errors you have to look at how the data is passed internally in a device. For PCM audio there are basically 4 seperate lines for 2 channel PCM audio. 3 of them are clocks, one is the actual serial audio data for both channels. The serial audio data is always 32bits long per sample per channel. That 32bits is up to 24 audio data bits and 8 pre-amble data bits.

You have a master clock that runs at some rate relative to the sampling rate of the audio. Typically 128xfS,256xfS, 384xfs...etc...etc.

You have a bit clock that transitions for each possible bit location on the serial audio line. Because each word of audio is 32 bits long and there are 2 words (left/right channels) per sample this clock always runs at 64x the sampling rate.

You have a left/right clock which transitions high/low depending upon if the current sample is for the left or right channel. This clock transitions every 32 bits or said another way this clock runs at the sampling rate of the audio.

All the clocks do is transition from high to low then from low to high that is usually +5v or +3.3V to 0V.

Lastly you have the serial data line. This has 32 bits per sample per channel for PCM. 24 bits of audio data and 8 bits of pre-amble data. Where the MSB/LSB audio data is contained within that 32bit is basically defined by which format it is using... Left Justified (MSB at the first bit after a L/R clock transition), Right Justified (LSB at the last bit before L/R clock transition) or I2S which is basically the audio data sort of center justified within the 32bits. The format also defines if L/R Clock is high for left or right. The serial data line being high is a 1, being low is a 0.

Why timing errors between the clocks can cause bit errors is as follows

We know that on the serial data line the bit clock transitions from high to low on one bit on the serial line and then from low to high on the next bit on the serial data line. A DAC or DSP simply looks to see if the serial data voltage is high or low each time the bit clock transitions from high to low or back. If the serial data is high you have a 1, if it is low you have a 0. That is how the value of the bit is determined.

As a very simple example what happens if the bit clock isn't quite stable relative to the serial data? By not being stable I mean its transitions speed up or slow down relative to when the serial data line transitions per bit. Now the bit clock might transition from high to low but the serial data line hasn't yet started that transition.... the receiving end mis-interprets the value of that bit.

To add complexity the transitions from high to low on the clocks and the serial data line don't happen perfectly. There is a brief instant in time when the could be anything between the two states while the data or clock it is in transition from high to low or back. All sorts of things can skew these transitions to make them less square... simple frequency response on the line (inductance rolling off the square waves), capacitance keeping the transitions in their former state, noise on the lines blurring the transition...etc...etc. If those transitions are skewed enough between the clocks and the serial data you can again have the same situation of the receiving end (DSP or DAC) mis-reading the value of a bit.

Shawn

Hi Shawn,

Everything you've stated is technically correct, but I'll add my perspective on it as a former hardware engineer...

In the situation you've described, with the clock(s) and data separated, jitter is an easily managed timing error in the system.

While the word and left/right indicators are labeled as "clocks", they're really just another piece of data. The only signal that matters as a clock is the "master clock". The validity of the word and left/right "clocks" relative to the master clock is the same as the serial data.

The validity of the "data" relative to the master clock all gets summed up and specified by Setup and Hold times. Setup specifies the amount of time prior to the master clock edge transition that the data must be stable, while Hold specifies the amount of time after the master clock edge transition that the data must remain stable.

Setup and Hold timing calculations within a digital system are reasonably straight-forward and fairly easy to manage and check. The uncertainty in the clock, used to make these calculations, includes both clock skew (timing path differences between the clock and data lines) and jitter. In such a situation, while jitter is a consideration in the timing calculation, it's usually not a significant factor.

Now, all of this changes significantly when the data and clock are combined into a single signal and the receiving device must recover both a clock and data from the line.

Dan

ps - sorry, I'm only helping to take this thread even further off the original topic and will refrain form further postings in this vein in this thread...