Kudos to Amir

[DonH50]

I am not sure where you are going with that, nor if it is relevant to this thread... I think I have some threads in the technical forum on interconnects' bandwidth, skin effect, impact on jitter (ISI), and so forth. IIRC, the wires inside an HDMI cable are not that much smaller than a standard coax center conductor. For typical interconnections I do not think it matters; the S/PDIF interface is better by design, not much to do with the cable. AES links are even better, again by design (look at the AES standard compared to HDMI) and due to the balanced system.

All IMO - Don

 

[NorthStar]

If you think my post wasn't clear enough, and it is not relevant to this thread, then I am extremely sorry.

 

[amirm]

HDMI has separate clock so in theory it is superior to S/PDIF. Alas, what screws it up is that the receiver must deal with the high-speed video circuits and decoding of the same as audio is embedded in the unused portion of video scan lines. So there is just too much signal "whaling" away to keep things quiet in such devices. The only box that did well on HDMI was the the Mark Levinson processor.

 

[NorthStar]

Exactly; there are 19 tiny wires inside a digital HDMI cable, and each one of them for its specific duty, including video.

A digital coaxial one (S/PDIF) doesn't deal with all that traffic; only/strictly digital audio.

Jitter still exists at both ends of these audio transfers (in products like CD players, Blu-ray players, A/V receivers, Pre/pros, Surround Sound Processors, Separate DACs, etc.).
Both type of connections contain jitter, more or less, depending of the product's manufacturer audio/video circuit implementation. ...And in combination with other audio/video products from other electronic manufacturers.

Some manufacturers (Meridian, Denon, Linn, Pioneer Elite, ...) use their own proprietary audio signal transmission connection, in order to eliminate jitter. But we all knew that already, I'm just reiterating it (not everyone has read all the tech stuff here at WBF).

That article, it deals with jitter, from different electronic products, right?
...Different types of jitter and various causes?

 

[ack]

^ Seems a bit harsh. I know plenty of very competent technical folk who would say a number of commonly-cited artifacts are inaudible at the levels of most modern electronics. And very few who would ever use the word "never".

Perhaps they would say that some artifacts are inaudible below a _certain level_??? I will buy that. But inaudible under any circumstances (as Ethan's original post would have us believe)? No, that doesn't sound right to me at all.

 

[Gregadd]

1. It does not exist.
2.If it does exist it is inaudible.
3.If it does exist,and it is audible,it is subject to the"masking effect."
1 for 3

 

[DonH50]

If you think my post wasn't clear enough, and it is not relevant to this thread, then I am extremely sorry.

Hmmm... What I get for writing tired after a long day. I meant it literally; I was not sure what you were looking for, and was not sure if it fit in this thread. I only skimmed the thread and looking back realize how harsh/obnoxious I sounded myself, sorry!

Amir, while the benefit of a separate clock line is debatable, would you care to discuss what in the protocols themselves might make one or the other better in terms of jitter (or anything else)? Data encoding and such that could lead to lower/higher jitter, BER, etc. I don't know the standards off-hand and a quick summary might be useful (?)

 

[jkeny]

1. It does not exist.
2.If it does exist it is inaudible.
3.If it does exist,and it is audible,it is subject to the"masking effect."
1 for 3

You forgot point 4
4. If it is audible, your belief system will dictate that you deny it anyway!

 

[DonH50]

You guys need to get out more...

 

[Ethan Winer]

^ Seems a bit harsh. I know plenty of very competent technical folk who would say a number of commonly-cited artifacts are inaudible at the levels of most modern electronics. And very few who would ever use the word "never".

No kidding, especially since what I actually said was "[Amir] even explained why it's not necessarily audible."

But inaudible under any circumstances (as Ethan's original post would have us believe)?

You too should read what I actually wrote.

--Ethan

 

[jkeny]

No kidding, especially since what I actually said was "[Amir] even explained why it's not necessarily audible."

You said "while jitter is real I don't think it's actually an audible problem. Son of a gun, Amir came to the same conclusion in this article, and he even explained why it's not necessarily audible (masking of nearby frequencies)." No Amir didn't come to the same conclusion. So let me ask you - is your position now that jitter MAY be audible as Amir stated?

You too should read what I actually wrote so everyone can read it.

hat's why I quoted exactly what you wrote. Seems fairly clear to me - "while jitter is real I don't think it's actually an audible problem." No mention of possibility in this statement. So, under what circumstances do you now claim it might be audible? Please avoid a politician's answer & state your position clearly

 

[Orb]

JKenny just to add as totally agree,
and I guess for Ethan that also means Paul Miller does not what he is talking about reporting various types of jitter and how it is audible (depending upon the behaviour-trait involved of course)
Cheers
Orb

 

[Ron Party]

You forgot point 4
4. If it is audible, your belief system will dictate that you deny it anyway!

And, in the exercise of being complete, point 5:

If it is not audible, your belief system will dictate that you claim it is audible anyway!

 

[microstrip]

I belong to the great majority of WBF members who are not readers of Widescreen Review magazine. IMHO, as some points of the article are being debated it would be nice to have a brief summary written by the author. Amir, would you mind doing it? And it would be nice if you could tell us if the article includes any test on the audibility of jitter or it is just a technical paper analyzing jitter measurements.

 

[ack]

No kidding, especially since what I actually said was "[Amir] even explained why it's not necessarily audible."



You too should read what I actually wrote.

--Ethan

Oh trust me, I read stuff very carefully. You said exactly: I don't think it's actually an audible problem. Son of a gun, Amir came to the same conclusion in this article
Nowhere in there is a phrase "not necessarily audible".

 

[amirm]

Amir, while the benefit of a separate clock line is debatable, would you care to discuss what in the protocols themselves might make one or the other better in terms of jitter (or anything else)? Data encoding and such that could lead to lower/higher jitter, BER, etc. I don't know the standards off-hand and a quick summary might be useful (?)

The separate clock eliminates data dependent jitter that can be caused on S/PDIF. Outside of that, yes, it doesn't necessarily make things better or worse.

I don't think the problem has anything to do with the protocol. It simply is the case that to get audio, you have to decode and process everything that comes over HDMI. This lights up a ton of circuits in the receiver. That creates lot of coupling opportunities in the receiver to the DAC. I saw two manifestations of this:

1. Low frequency noise. This was random noise bleeding into the clock circuits at frequencies up to a few Khz but mostly clustered below 1 Khz. I take this as being the sum total of a ton of circuits doing whatever they are doing, appearing at the end as random noise over DAC clock.

2. Correlated noise at specific frequencies of tens of Hz. I thought I would be able to correlate it to video refresh rate and such but could not reach that conclusion. Either way, there are activities/timed events on at the receiver at these regular intervals and they would show up on the DAC clock.

The identical device over S/PDIF would have far lower levels of both. The noise would almost disappear and the correlated jitter spikes would vary and be at much reduced levels.

Especially problematic was that you could corrupt S/PDIF performance if you just plugged the HDMI cable in! Mind you, the noise level would be far lower than if you used HDMI as the input but clearly the HDMI cable was coupling the source and destination electrically and causing noise to bleed into the receiver even when you were using the cleaner S/PDIF input. Or alternatively, maybe the input HDMI receiver is running even if that input is not selected and some of its activities bleed into the rest of the system.

Note that one implementation, the Mark Levinson Processor, managed to keep HDMI noise almost completely out of the way. So we could say that the "protocol" is no the problem as it can be implemented well. Then again, the notion of slaving audio to video in all cases and hence forcing the system to deal with video seems wrong. There could have been a data channel that worked independent of video.

 

[amirm]

I belong to the great majority of WBF members who are not readers of Widescreen Review magazine. IMHO, as some points of the article are being debated it would be nice to have a brief summary written by the author. Amir, would you mind doing it? And it would be nice if you could tell us if the article includes any test on the audibility of jitter or it is just a technical paper analyzing jitter measurements.

I will work on uploading the full article in the next couple of days. Reformatting in HTML takes some time as does processing the images for web (the ones in the article are high resolution due to requirement for print).

Quick one line summary is that HDMI causes far more jitter. But in the set of devices I tested, for the most part they were below masking thresholds. So while the measurements look really ugly for HDMI, based on general assessment they are not as alarming as they look. That said, I did not test every device or even the ones I tested under all conditions. I believe that the source actually infuses some of the distortions into the target (I showed evidence of mine doing it in the article) and hence the point of not generalizing that all HDMI jitter is harmless.

 

[jkeny]

Amir, I think you should now clarify the noisefloor issue as it is directly related to audibility. The grass that is seen on the FFT graphs you presented are NOT the noise floor, right? These figures need to be adjusted according to the FFT bin size used on each measurement. Can you adjust these results, lest people incorrectly interpret your graphs as below your -120dB audibility threshold?

Edit: Just to be clear

Dynamic Range/Noise Floor: The FFT process is full of mysteries. When you start getting some figures in dbSPL they can look more than a tad weird. In particular you expect silence (all zero input) to be -96 dbSPL (the dynamic range of a 16 bit sample is 0 to -96 db using the simplistic rule of thumb of 6 db per bit). When you play silence you may be seeing well in excess of this value -120 db or even higher. The FFT pushes down the noise floor (or increases the dynamic range) by a factor of 10 * log10(fft size/2). So for an FFT size of 2048 this adds ~30 db, giving a noise floor for silence of -126 db.

This really needs to be cleared up before talk about masking threshold & audibility? Amir, can you state what the bin size used in each of your FFTs & what the above calc gives for the "actual" noise floor?

 

[Ronm1]

A belated thumbs up, Amir. Always look forward to an issue with an article of yours.

 

[Gregadd]

Believe or not I saw this thread as quite a concession by Ethan. He has been much more moderate of late.
His statement that designers should aim for more than borderline acceptable performance imo represents progress. See OP.