AVS › AVS Forum › Display Devices › Ultra Hi-End HT Gear ($20,000+) › How high is the jitter level on HDMI vs S/PDIF on a High-End Processor?
New Posts  All Forums:Forum Nav:

How high is the jitter level on HDMI vs S/PDIF on a High-End Processor? - Page 3

post #61 of 164
It was a good read. A pity that Julian Dunn isn't around to offer up comments. I wonder if one could identify an Ayre product from an OPPO in a level matched scenario.
post #62 of 164
Agreed. There's more work that ought to be done to identify the reason for the discrepencies, and while the discussion is nice, at some point the participants ought to do the work necessary to clarify matters and maybe consult a higher authority. Sometimes it all seems like talking about toasters.
post #63 of 164
Real toastaphiles swear by the old toasters where you had to open the entire side of the toaster to insert the bread, then monitor it so that the toast didn't burn. They were a pain but if you set them up just right they definitely had more warmth and 'bread of life'. They knock the stuffing out of the new ones with digital timers, which make the toast taste like stairsteps or something.
post #64 of 164
Digitally-timed toast have no soul.

--Andre
post #65 of 164
Thought it might be time to recount some recent listening that I had been meaning to do for a long time, and its bearing (and confusion) on jitter. I built up a big pile of kit recently, and can test many different configurations. Firstly I compared spdif, toslink, i-link and hdmi interfaces when playing CDs. The first two were quite similar, and the differences were more of character than quality. I knew that i-link would be a big step up, and so it was.

HDMI was the interesting one for me, as before now, I hadn't had an amp that accepted it. I heard people say it wasn't as good as spdif, but this didn't prepare me for how bad it was. It was very disappointing, as one connection would have been so convenient; but it won't do. Difficult to say what it was doing wrong, but it just sounded a mess, and easily worse than everything else. It was difficult to keep the differences in perspective, as many manufacturers and consumers presumably think that audio over HDMI is the best they can get, yet it was hard to think of anything good to say about, or even continue listening.

Then I tried playing Blu-ray LPCM soundtracks over HDMI, and compared analogue and down-converted spdif connections. That might seem like an unequal comparison, as LPCM was 24 bit/48kHz, but my experience above suggested that HDMI itself may be the quality bottleneck. Where spdif sounds better when carrying the very same 16/44.1 stereo audio bits, I can only assume that hdmi has too much noise, jitter or interference to recover the audio faithfully. And that would also apply to HD audio.

Well, no. LPCM over HDMI simply blew spdif out of the water. I was kind of hoping that spdif might have been close, and then I could justify selling the HDMI receiver that I didn't really want to keep. But I simply couldn't turn my back on the difference that was available for the want of an interface. While I willingly rubbished HDMI with stereo, I wouldn't do that with spdif here, as it still sounded fine in isolation. There wasn't much wrong, it was just that LPCM was just so much more transparent. I even hoped that my Sony BDP-S1 might have decent analogue outputs, and I compared them. While they were a bit better than spdif - smoother, sharper, cleaner and a bit brighter - the difference wasn't great, and the gap to HDMI was still considerable.

Since the HDMI amp also has an i-link input, I have a straightforward way forwards, but this has now asked many new questions about how the different digital audio interfaces work (or don't). Looks like it's not a simple subject.

Nick
post #66 of 164
Sighted comparisons all, right?



You do realize that you could have -- and quite likely were -- been imagining every 'heard' difference, right?
post #67 of 164
Yes, I could indeed have been imagining that there was a difference between lossy compressed audio and uncompressed 24 bit LPCM audio.

Nick
post #68 of 164
Just ran across this thread... and a question occurs to me.

Several people have suggested that HDMI jitter is a big issue with PCM over HDMI -- but not an issue at all with lossless compression bitstream signals like Dolby True HD.

Is that true?
post #69 of 164
Quote:
Originally Posted by nathan_h View Post

Several people have suggested that HDMI jitter is a big issue with PCM over HDMI -- but not an issue at all with lossless compression bitstream signals like Dolby True HD.

Is that true?

Yes, bitstream is immune to jitter. A very thorough but easy to understand explanation here.

Sanjay
post #70 of 164
Great link. Thanks!
post #71 of 164
It's a nice link, but I don't agree with it. No matter whether you're receiving bitstream info or PCM over an HDMI link, your DAC clock is still tied to timing recovered from the HDMI input. It is that clock recovery process that is the source of jitter being "transmitted" over the HDMI link. Furthermore, that jitter is independent of the audio format, because the clock rate of the HDMI input is determined by the video bandwidth required---the audio is stuffed into the blanking interval.

Of course, decoding a compressed bitstream requires a certain amount of buffering---buffering that mitigate the jitter from the clock recovery process. But of course, you can also buffer a PCM signal to get the same benefit.
post #72 of 164
"Of course, decoding a compressed bitstream requires a certain amount of buffering---buffering that mitigate the jitter from the clock recovery process. But of course, you can also buffer a PCM signal to get the same benefit."

PCM is going to end up being buffered anyway do to the HDCP decoding. Plus almost any device that is taking in PCM over HDMI is going to be passing the PCM through DSPs which will likely buffer the data on their inputs as well.

Shawn
post #73 of 164
One of the issues I have with Amir's description is that he seems to say that the moment you do any buffering, input jitter is completely eliminated. That's simply not the case. The amount of buffering matters, too: the more buffering you do the more you can safely filter the recovered clock, and the more jitter you can eliminate. (Put another way, you want the PLL to track really slowly.) If the buffer is too short, then there is a chance that it can underflow during a period of time when the HDMI clock is running slower than the DAC clock.

Now, it might be the case that you reach the point of diminishing returns really fast---but that just establishes my point (and yours) in a different way. If it only takes a little bit of buffering to effectively clean up a jittery HDMI clock, then it's going to be trivial to eliminate jitter no matter what format the audio is in. Buffering memory is cheap---certainly cheaper than decoding logic for these newer compressed formats.
post #74 of 164
There are more sources of jitter than just the input clock. There are also many ways of abusing the input clock so that your output, even if buffered, is still dependent on it. A while ago jheoaustin posted a link to a datasheet for a DD/DTS decoder DSP chip whose output clock was tied to the input clock.

--Andre
post #75 of 164
Quote:


There are more sources of jitter than just the input clock.

The input clock and the DAC's own clock. What else?
Quote:


a DD/DTS decoder DSP chip whose output clock was tied to the input clock.

Yow.
post #76 of 164
Quote:
Originally Posted by Michael Grant View Post

One of the issues I have with Amir's description is that he seems to say that the moment you do any buffering, input jitter is completely eliminated.

May be a semantic difference, but it seemed more like he was saying that the moment you compress the signal, jitter is completely eliminated. Granted that it will have to be buffered upon playback, but his point was that the compression step itself makes the signal lose any sense of real-world timing. From then on it's like transfering packets of computer data rather than a time based signal. Yes/no?

Sanjay
post #77 of 164
I just can't accept that interpretation, no. Data is data is data, whether it is compressed or not. Even with LPCM you're transferring packets of computer data.

Timing is not stored mysteriously inside the bits of data themselves; it is a separate component of the information being delivered. The "location" of that timing information is in the physical HDMI or S/PDIF signal---and that location identical with bitstream data than it is with LPCM data. The recovery method is effectively the same in both cases, and relies on some amount of buffering.

My point ought to be even more clear with HDMI than with S/PDIF. For HDMI, the audio data is divided into packets and slipped into the blanking interval of each video frame. The timing information is recovered from the overall HDMI signal. The implication is that the timing for the audio stream is actually recovered from the video signal! And that is the case no matter what audio codec is being used.
post #78 of 164
Here's a quote from a HiddenWires article about audio over HDMI:
Quote:


The performance of any digital audio system depends on accurate clocking. Any errors in clock accuracy are measured as jitter - the higher the jitter the less accurate the signal and, typically, the poorer the resulting sound quality. Using current implementations, HDMI audio appears to have a relatively poor jitter performance meaning that, although mainstream consumers will find the resulting sound quality rather good, it is unlikely to satisfy audiophiles. A number of manufacturers intend to cure this issue by developing better clock recovery techniques, so in time, the problem should be resolved.

Nothing new here really, I just wanted to emphasize that the timing for audio comes from standard clock recovery methods. There are a variety of approaches to clock recovery, differentiated in part on the portion of the signal stream you're sampling to tune your VCO.
post #79 of 164
Quote:
Originally Posted by Michael Grant View Post

The input clock and the DAC's own clock. What else?

The DAC's output clock was the one I was mainly thinking about, but I meant that there are many ways of affecting that clock besides relating it somehow to the input clock. For example, bad power supply design, EMI noise, bad PCB layout, etc. IOW, even if you had zero input jitter, the DAC's clock can still be affected by many other things.

--Andre
post #80 of 164
That's fair. In fact, as implementations like the Benchmark DAC seem to show, it is possible to practically eliminate input clock jitter from serious consideration, leaving only those secondary factors you state. There may be some practical difficulties in doing good clock recovery with HDMI, but I imagine they will be licked soon enough (if not already).
post #81 of 164
Although I can't offer any technical info but it's a fascinating read so far - my experience with an Oppo 980H feeding a Panasonic SA-XR57 digital amp receiver is that HDMI is superior over SPDIF for two channel listening - more nuances/emotion in the music. (it's easy to switch back & forth with the remote between the connections, so easier to spot subtle diffs)

Is this a reduction in jitter? Is it a bad implementation of SPDIF in Oppo or Panasonic? I don't know the answer but hdmi sounds better!

However, I don't think blanket statements can be made about hdmi Vs spdif as it's very much determined by implementation of each

Any other experiences?
post #82 of 164
Quote:


My point ought to be even more clear with HDMI than with S/PDIF. For HDMI, the audio data is divided into packets and slipped into the blanking interval of each video frame. The timing information is recovered from the overall HDMI signal. The implication is that the timing for the audio stream is actually recovered from the video signal! And that is the case no matter what audio codec is being used.

Could not agree with you more Michael Grant. There is so much mis information online about how bitstreaming over HDMI eliminates jitter, I am glad to see that someone else has picked up on the fact that the audio is stored in the blanking interval of the video stream, and that if jitter is infact occuring, it would be happening to audio stream(the entire stream i general including the video) before it even reached the receiver for processing.
post #83 of 164
I don't agree with Amir's article either. I know what he's trying to say, but I don't think he's completely correct. I certainly didn't like his last line either regarding home theater in a box; again...I know what he's trying to say but in practice he's off the mark.
post #84 of 164
Quote:
Originally Posted by Chu Gai View Post

It was a good read. A pity that Julian Dunn isn't around to offer up comments. I wonder if one could identify an Ayre product from an OPPO in a level matched scenario.

The problem with this comparison is that a difference in sound may not necessarily be related to jitter. As you are aware, some high-end brands like to impart a house sound to their electronics, moreover, some electronics high-end electronics eschew sensible engineering choices in favor of high-end audio's vision of sensible design. I can't comment on Ayre's products from any of these perspectives, just noting that any difference in sound may be there by design, by omission, or due to jitter.
post #85 of 164
I see what you're saying, Raul, when you're talking about digital interconnections there are far less opportunities to impart a house sound. With a digital interconnection you've got bits and jitter. I don't know of anyone purposefully injecting jitter to create a "house sound", so that means if someone wants to mess with the signal they have to alter the bits. And what high-end unit is going to intentionally do that? I mean, at worst they might rely on different implementations of codecs that deviate from bit-perfect in different ways.
post #86 of 164
Any purpose-built high end 'house sound' in a digital player -- like, say, the wacky ones that eschew antimaging filters -- would show up in bench tests measurements long before the need to check for jitter.
post #87 of 164
Quote:
Originally Posted by Michael Grant View Post

I see what you're saying, Raul, when you're talking about digital interconnections there are far less opportunities to impart a house sound.

Yeah, when he wrote about comparing them I was thinking about them as stand alone players (thus allowing for creation of the house sound in the DAC stage), I missed his point.

PS But then again, I would imagine a stand alone player would have no issue with jitter, so wrong on both ends
post #88 of 164
Quote:
Originally Posted by Michael Osadciw View Post

I don't agree with Amir's article either. I know what he's trying to say, but I don't think he's completely correct. I certainly didn't like his last line either regarding home theater in a box; again...I know what he's trying to say but in practice he's off the mark.

He's definitely not. He talks of only jitter added due to an interface. Let's not forget that single box CD players have different amounts of jitter as well. So when he says "high quality proprietary connections internally" he is making a big presumption.

We'll grappling with the issue for quite some time yet I suspect. One day it will low enough that we somehow nearly all agree that it is of a magnitude that it is inaudible. I wonder when that day will come.
post #89 of 164
I dont understand why there is so much discussion over jitter. Hear it or not there are high end processors out with HDMI that totally eliminate it.
post #90 of 164
Quote:
Originally Posted by vancouver View Post

I dont understand why there is so much discussion over jitter. Hear it or not there are high end processors out with HDMI that totally eliminate it.

Au Contrare
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Ultra Hi-End HT Gear ($20,000+)
AVS › AVS Forum › Display Devices › Ultra Hi-End HT Gear ($20,000+) › How high is the jitter level on HDMI vs S/PDIF on a High-End Processor?