What is HDMI Jitter Reduction?

[Cpt.America]

What is HDMI Jitter Reduction? I did a search through the web, but cant find any description of what it actually is, and is this something that is needed in a home theater receiver?

Cpt.

 

[fmw]

No, don't spend any time worrying about it. Jitter is simply a measure of the difference in timing between two ends of a digital connection. It is measured in picoseconds. That means there isn't enough to cause anything noticeable in your system. Even 10's of milliseconds wouldn't matter.

 

[Cpt.America]

Thanks fmw... i wont worry about that feature then appreciate it.

 

[OttoMatic]

Jitter is simply a measure of the difference in timing between two ends of a digital connection.

Well, it's not so much a difference between the two ends as it is between samples, and it's about phase and clocking issues. It's a measure of the signal's eye diagram (which is ultimately analog), and the methods used to recreate (either well or not) the clock signal. The Wiki article isn't bad.

It is measured in picoseconds. That means there isn't enough to cause anything noticeable in your system.

Just because something is small doesn't mean it's necessarily unimportant. The scale of measurement is driven by the sample rate.

Even 10's of milliseconds wouldn't matter.

At a sampling rate of 44.1khz, a CD's signal is sampled every 22.6 microseconds. I think that if you were experiencing jitter in the "10's of milliseconds" it most surely would matter. Higher sampling rates will be more susceptible to such jitter (assuming all else is equal and the jitter measurement remains static).

Now, all that said, most electronic components today should be engineered well enough either have very little (no?) jitter or handle it in the event that it occurs. You probably don't have to worry about it. However, if a product offers a jitter reduction circuit, it probably won't hurt to have it.

Good luck!

 

[fmw]

My apologies for trying to keep things simple for the OP.

In the recording world we worry about something called latency. It is the time required for data to get through the computer system. As an example, if latency is high, overdubbing is a problem because what is heard while monitoring and what is recorded are separated by a time lag. This problem is far, far, far worse than jitter because jitter is only a playback phenomenon.

Latency figures in the 10's of milliseconds are not normally a problem. As an example, my own computer based recording system suffers from an 11 ms latency and there is no audible effect at all on overdubbing or playing and hearing midi input.

So please help me understand why you think ms figures would be an issue with clock jitter? I don't see the logic in it.

 

[OttoMatic]

My apologies for trying to keep things simple for the OP.

No problem with keeping things simple. I just thought that some of the discussion wasn't quite accurate.

In the recording world we worry about something called latency.

Fine, but latency (or what I might call "group delay") is not the same as jitter. I'm not sure what this has to do with the discussion.

So please help me understand why you think ms figures would be an issue with clock jitter? I don't see the logic in it.

Jitter affects clocking and sampling. If samples should be taken every ~22 microseconds (for 44.1 kHz CD), then having jitter mess with the signal by milliseconds will hose your sampling, and thereby, your samples. If your samples are wrong, the data is wrong, the music is wrong (or whatever it is you're sampling). It's been a while since I've really been involved in this type of thing, and I don't claim to be an expert. Check out the Wiki link I provided -- it's pretty good.

 

[fmw]

No problem with keeping things simple. I just thought that some of the discussion wasn't quite accurate.



Fine, but latency (or what I might call "group delay") is not the same as jitter. I'm not sure what this has to do with the discussion.

Latency is audible. Jitter is not. It was a comparison of relative time frames.

Jitter affects clocking and sampling. If samples should be taken every ~22 microseconds (for 44.1 kHz CD), then having jitter mess with the signal by milliseconds will hose your sampling, and thereby, your samples. If your samples are wrong, the data is wrong, the music is wrong (or whatever it is you're sampling). It's been a while since I've really been involved in this type of thing, and I don't claim to be an expert. Check out the Wiki link I provided -- it's pretty good.

Sampling is something that is done at recording time, not at playback time. We're talking about HDMI jitter. It has nothing to do with sampling. As I mentioned above it deals only with playback.

 

[MidnightSensi]

 

[OttoMatic]

Latency is audible. Jitter is not. It was a comparison of relative time frames.

Jitter will be audible if it's bad enough.

Sampling is something that is done at recording time, not at playback time. We're talking about HDMI jitter. It has nothing to do with sampling. As I mentioned above it deals only with playback.

I'm talking about jitter in general.

Although a signal (whether audio or HDMI) is digital, it's transmitted in the analog domain. To process, trasmit and perform digital to analog conversion on such signals, they are sampled at their clock frequency and latched into whatever device is at the receive end. Have a look at the eye diagram in the Wiki link, and you will see its tilt due to jitter -- that's an analog signal that's going to be sampled as some point, at which it will again be digital. If that sampling occurs at the wrong time, the data will be wrong.

I don't mean to be a jerk about this, but it does have to do with sampling, and sampling definitely occurs at playback, as well as recording (though they are different processes, to be precise).

 

[MDS]

OttoMatic is on the money but this kind of stuff is very hard to visualize if you aren't overly familiar with digital systems or how a 'digital' signal is modulated.

In a nutshell, the timing affects the receiving ends notion of how to interpet the data as either a zero or a one. If the timing is way off (milliseconds as Otto has mentioned) the interpretation of the data is also going to be way off.

My super simplistic example of jitter that I have described a few times is this:
You are communicating with a friend using a flashlight and morse code and you agree beforehand that a .5 second pulse of light is a zero and a 1 second pulse is a one (That after all is the kind of thing specifications define).

Now if your friend is sending S.O.S it should be .5, 1, .5 but what if it is way off and you think the second pulse was .75 seconds? Is that a zero that was too long or a one that was too short? Now I agree that Jitter in most digital systems (especially audio) is a total non-issue, but in some circumstances it can be problematic and Otto is just trying to say that a large amount of jitter is a big problem. With audio equipment, you don't get a large amount of jitter so the debate is much-ado about nothing.

Latency is a different beast. For example, your hard drive exhibits a small amount of latency (on the order of milliseconds). When the device driver requests a certain piece of data, it takes the drive a few milliseconds to locate that data and start sending it back. That is more or less a 'delay' in fetching the data and not something that affects the interpretation of the data itself.

 

[fmw]

OK, milliseconds of jitter would be audible. Thanks. About a decade ago I spent about a day and a half with a group of audiophiles figuring out how to measure jitter and testing for audibility. We did get the measurements done. We couldn't find any audibility. Has anything changed since then? Has anybody encountered audible jitter in an HDMI connection or any other since that time?

 

[mtrycrafts]

So please help me understand why you think ms figures would be an issue with clock jitter? I don't see the logic in it.

Jitter is audible at a much lower time than that 10ms you brought up:

http://www.jstage.jst.go.jp/article/ast/26/1/50/_pdf

this shows that at 250ns was not audible, but that seems to be the level above which some listeners will hear jitter caused distortions.

This also supports that above paper also:

Benjamin, Eric and Gannon, Benjamin ' Theoretical and Audible Effects of Jitter on Digital Audio Quality,' 105th AES Convention, 1998, Print 4826.

 

[mtrycrafts]

Fine, but latency (or what I might call "group delay") is not the same as jitter. I'm not sure what this has to do with the discussion.

.

Isn't group delay, at least in analog signal transmission, the time of arrival of the different signals frequencies, the highs would get there later, due to skin effect caused impedance. How would that happen in a digital signal transmission where you are sending a stream of digital, timed signals?

 

[OttoMatic]

Isn't group delay, at least in analog signal transmission, the time of arrival of the different signals frequencies, the highs would get there later, due to skin effect caused impedance. How would that happen in a digital signal transmission where you are sending a stream of digital, timed signals?

I think of group delay as a rather straightforward delay of whatever signal to get through a system. However, in Googling around a bit just now, perhaps I've simplified it too far. You're probably right, but I admit that I'm not that familiar with the underlying theory, so I'll just leave it at that. I'll retract my use of "group delay" and just call it a processing delay or a general latency.

Thanks for the info -- maybe during a bout of insomnia, I'll research it further (seriously).

 

[jcilforever]

Basically it deals with signal timing "on-board jitter reduction circuitry corrects signal timing errors so you always experience the sharpest picture, richest color, and highest resolution sound."