HDMI: Good, Bad or Indifferent

Posted by: Mr Underhill on 11 October 2011

 

James n started a thread wrt the new Linn DSM players where HDMI inputs were mentioned.

Rather then hijack James' thread I thought I'd start a new one.

My comment was:


I am far from convinced. I tend to think of HDMI as digital scart, and while I accept that it can shift large amounts of data, I read about all sorts of HDCP issues.

Was HDMI bought in, in part, to try and raise the cost of entry by the large electronics companies?

My hope is for the continuing progress of DRM free HiDef downloads.

If HDMI can then be used as a transmission medium sans HDCP that might be convenient, although I suspect a large lawsuit would be threatened.

But, I'm open to being educated, if there is some intrinsic advantages that HDMI offers over other methodologies .......?

Likesmusic:

So, a pre-amp that you can stream to, plug analogue sources into, plug digital sources into including tv, with balanced and unbalanced outputs .. one box .. who would want that ..!


Simon-in-Suffolk:

Hi, well HDMI provides a synchronous high capacity bit stream which clearly has advantages over a synchronous formats such as spdif. The audio bit streams include hidef LPCM and the interface can also carry Ethernet.
Simon

Hook:

Hi Simon -

I understand the advantage of HDMI's higher capacity when it comes to delivering multi-channel.   But given these new Linn's are stereo components, are they really gaining anything from it?

It will be interesting to read reviews of how these new Linn products sound.



....I'm cooking up a response, what do you think?

M

Posted on: 11 October 2011 by likesmusic

I think the HDMI connectivity is only a small part of the DSM offering - the whole Linn mind-set seems to have been liberated - "whatever you want to connect and play. you can connect and play".  I do wonder though if there mightn't be some sneaky possibilities with SACDs and HDMI and an appropriate player.

Posted on: 11 October 2011 by DavidDever

For what it's worth, the Devialet D-Premier also features HDMI–but no RJ-45 connection for Ethernet....

 

Keep in mind that it is possible to render LPCM at the head end (Blu-ray player) from hi-res sources, and that fold-down to stereo can also be accomplished at this stage (or, a stereo soundtrack explicitly selected).

Posted on: 11 October 2011 by Mr Underhill

 

It seems to me that HDMI is an interface that offers options and solutions that still need to be well engineered, and frequently aren't.


I believe that HDMI was developed by hardware manufactures to gain them hidef content, that otherwise would be denied them, how? HDCP; which itself must be an overhead.

Personally I happily live with HDMI for AV uses, and recently only just persuaded myself NOT to ditch my Naim AV2 in favour of an Onkyo, in part due to its HDMI switching. Why did I stick? Sound quality.

 

Do I feel some great uplift at the thought of HDMI being used to deliver audio? No.

Does it solve jitter? No.

Simon, I have read nothing that persuades me that HDMI is practically better at handling jitter issues - having read a fair few threads on a number of fora. But I claim no technical expertise, just an interested curiosity. In a few threads some HiFi News figures were quoted for a variety of AV Receivers showing consistently lower jitter figures for spdif when compared to HDMI. Now there was some debate over the figures, including the 'fact' that there is no standard measure for jitter!

Does synchronous audio over HDMI offer an immediate or essential advantage? I don't believe so. Especially in my case where I am getting files from a network source! But even in the case of BluRay, I have lost all interest in using this as a serious audio source. As for HiDef surround sound, I was so deeply unimpressed by what was delivered by DVD-Audio and SACD that I have happily run home to momma - stereo.

Routing TCP/IP over HDMI - IF you have the more recently specced hardware and cables. But I can see why Simon is thinking it could be used to advantage.

HDMI seems to me to be almost an encapsulation of the factors that caused Naim issues with AV: licence fees; complexity; high entry cost; and a fast moving 'standard'.


Likesmusic,

I can see that having a pre-amp where you can plug all your sources is attractive. That said I am happy keeping my video and audio signal seperate, and have read about, and experienced, a number of HDMI handshaking difficulties.

I can also see that it may assist with DSD ...but, I would like to see the development of an AUDIO standard, if we really must go down some form of encrypted HiDef channel, rather than try and make the most of a standard that is mostly aimed at video.


The quality of replay I am getting from digital now is great, and my hopes are that we can get companies to produce more good quality DRM free HiDef downloads.


M

Posted on: 11 October 2011 by Simon-in-Suffolk
Mr Underhill, HDMI is a synchronous interface. It is clocked. Spdif isn't, therefore sender and receiver clocks drift in and out of phase, the clock has to be recovered. Because of this with SPDIF you tend to have separate send and receive clocks. There is much complexity and white papers on how to recover low jitter signals from SPDIF.
A synchronous signal, with a master clock allows different techniques and the master sender clock synchronises the rest of the system. Therefore all the jitter introduced SPDIF is removed. Is there still jitter from the master clock, yes but that is less and easier to control. The benefit of synchronous digital transfer is used by Naim internally using i2s. hDMI allows a consumer way of achieving this over longer distances. This is progress and makes for a more robust and flexible digital interface.
I can absolutely assure you there is a way to measure jitter, and is often put into legal contracts in my line of work. Anyone who says otherwise is quite frankly talking out of their bottom. (jitter is measured in time). Finally don't confuse digital bit stream time domain jitter with the inter packet timing on an Ethernet. With TCP  and to some extent UDP there is no relationship at all.

Simon
Posted on: 11 October 2011 by likesmusic

Mr Underhill  - noone at Linn is forcing you to use HDMI if you don't want to - there are more than enough alternative digital inputs on the DSM products for you to use if you prefer. Not to mention some analogue ones. And ethernet. 

Posted on: 11 October 2011 by Mr Underhill

Likesmusic,

 

Thanks - my aim is to understand why some people view HDMI as a potential step forward. I can understand that a well implimented interface can forward audio, be it spdif, usb, aes or HDMI - but the inference of some posts I have read on the site is that HDMI innately offers some advantage; which I think is what Simon is pointing at.

 

Hopefully any product will be judged on its merits, regardless of the technology used - although I am sure we can all think of examples where this has NOT been the case.

 

Simon,

 

I understand the point you are making with respect to the synchronisity of HDMI, I am presuming that this is an advantage in a system where a transport and DAC, for instance, are designed to take advantage of a common time source, such as dCS - although they do not use HDMI?

 

Charles Hansen, owner of Ayre, from a thread at Audio Asylum:

And what's even more important is that there is no standard way to measure jitter. So there is NO WAY to compare jitter numbers made by different manufacturers and/or magazines. Even the jitter numbers that John Atkinson publishes in Stereophile differ radically from those published in Hi-Fi News, even though they both use the Miller Audio Research measurement system.

 

T. Loesch, another designer:

Why do you not specify jitter using the common (ppm) "parts per million" reference?

CD clock crystals are often promoted using a measure that specifies the difference of the actual frequency from the nominal frequency, usually specified as the deviation in ppm (parts per million). It should be noted that this specification has no bearing whatsoever on the jitter in CD players as it is a purely static measurement.

Phase noise in the clock is the primary cause of jitter. No reliable and standardised protocol exists to measure and specify jitter in a form that makes measurements comparable. AMR as a result, has chosen not to publish a specific number that would not be reliably comparable to the numbers published by others. Rest assured that the CD-77 offers one of the lowest levels of phase noise of any CD player produced.


This would not preclude you from drawing up a contract with some agreed measurement for jitter. Just clouds the waters for us punters when trying to compare readings for jitter from different sources.

 

 

I am concerned with your statements when I then read figures such as this post on another site:

 


"Except that the current implementations of HDMI have much higher jitter figures than SPDIF. In the Feb 2009 edition of the Hi-fi News magazine Paul Miller measured the following jitter results for a few A/V amplifiers:

Denon AVR-3803A
---------------
SPDIF: 560psec
HDMI: 3700psec

Onkyo TX-NR906
---------------
SPDIF: 470psec
HDMI: 3860psec

Pioneer SC-LX81
---------------
SPDIF: 37psec
HDMI: 50psec

Yamaha RX-V3900
---------------
SPDIF: 183psec
HDMI: 7660psec

And no, those figures for the Pioneer aren't typos - it just shows what can be done when implemented correctly! Unfortunately the Denon and Onkyo amps were rated to sound the best, but I believe that had more to do with their amplifier sections than the jitter and pre-amplifier/processor sections."



I'll go and do some more reading before asking some questions.


M

Posted on: 11 October 2011 by Simon-in-Suffolk
Hi I am not sure what Mr Hansen is possibly referring to, I'd be interested to understand what engineering background he has and what his motivation is. Any way a typical manual of jitter measurement is here

http://www.pericom.com/pdf/applications/AB036.pdf

There is no magic, and is used industry ( certainly in my work ) for defining regulation of spacing of regular pulses or frames in terms of variation of the central or edge of the pulse or frame. This variation is measured in time.

No this brings me to your jitter measurements, what are you referring to here, is this the recovered bit PCM bit streams, sample streams? If it is is certainly points a not very optimised or accurate master clock or poor implementation  in these implementations.

Simon
Posted on: 11 October 2011 by Mr Underhill
Originally Posted by Simon-in-Suffolk:

No this brings me to your jitter measurements, what are you referring to here, is this the recovered bit PCM bit streams, sample streams? If it is is certainly points a not very optimised or accurate master clock or poor implementation  in these implementations.

Simon

Good questions - which is why I'm reading.

 

I'll get back to you.

 

M

Posted on: 11 October 2011 by Mr Underhill

Simon,

 

With respect to Mr Hansen, there are numerous interviews of someone who appears to be a well considered HiFi designer, and Ayre have a first rate rep in digital engineering. In a brief search I was unable to determine what his engineering qualifications are, although it would appear his first degree is in Physics.

 

WRT the jitter measurements:

 

These are available from Paul Millers' site. An example for the DENON mentioned above is here:

 

http://www.milleraudioresearch...n_avr3808a_lpcm.html

 

You will need to register for the username & password. I am sure the technical details will mean more to you than me.

 

 

Still reading......

 

M

Posted on: 11 October 2011 by Hook

Guys -

 

I do not know where the dividing line between HDMI and HDCP is, but clearly there are issues from an end user home theater perspective.

 

Changing channels is not instantaneous.  The handshaking is often error prone -- my cable box occasionally tells me that I have not subscribed to certain channels.  I flip back to last channel and forward once more, and viola, I am magically certified again.   Fairly mild problems I know, but I need only search on "hdmi handshake" to read an endless list of more serious problems:   screens going blank, systems only working correctly if components turned on in a specific order, etc..

 

I asked earlier what the advantage for stereo audio would be, and I read Simon's description of HDMI synchronous data transfer, and its potential advantages over S/PDIF.   But Mr. U has countered with many measurements of systems that actually do worse over HDMI versus S/PDIF.  Theory and reality not quite coinciding?

 

So I guess the question I have now is:  given the buffering/re-clocking architecture of the Naim DAC, hasn't Naim improved S/PDIF to the point where HDMI would have nothing to add beyond what we are already getting?  Naim claims that DAC is adding zero S/PDIF-related jitter to our digital streams.  How could we do better than that with HDMI?  Or would there be new benefits from an HDMI architecture (e.g., reduced processing requirements resulting in lower noise perhaps)?

 

Again, my real concern is that the music industry is trying to make a new power play through HDMI/HDCP.  All my music was legitimately purchased, so the idea of buggy entitlement protocols occasionally popping up -- maybe in the middle of a song -- and turning off the music definitely makes me think twice.  I say:  Listen free or die!  

 

Interesting topic -- thanks for starting it up Mr. U!

 

Hook

Posted on: 11 October 2011 by DavidDever

With regard to Charlie Hansen's remarks about the Miller analyzer–it would be curious to see which set of measurements (Stereophile or HFNRR) consistently provide the lower readings. As long as the order of magnitude is the same, some issues might be related to power supply / mains frequency etc.

 

Interestingly enough, many of the Ayre digital products (except for the Blu-ray player) are based on Pioneer designs at the front end–any additional gains in performance are ultimately the result of component selection, power supply and output stage design, as well as mechanical design.

Posted on: 11 October 2011 by NickSeattle

Thank you, Hook, for helping me with the worry that if I buy an nDAC in the near future, I need not necessarily envy those who, a little later, buy the e.g. "nDAC2" with some form of HDMI enhancement.

 

Nick

Posted on: 11 October 2011 by Simon-in-Suffolk
Hook, good summary. The early SPDIF were not very great, so Mr U s quoted measures may point to early HDMI or basic chipsets implementations. I am travelling at present so have not registered into the registered with the quoted site. However a synchronous source does as you can require a simpler design, providing lower noise in the receiver. However this doesn't mean implementations are automatically better, it means the implementations have the potential of being better (like Naim with SPDIF).
Reading the HDMi spec I don't see that you have to use HDCP so that could be a red herring.
I do like the idea of HDMI being a bus mechanism that can carry other info between devices, such as automation and control, simplifying connections, and possible issues of multiple connections.

I am still curious aboyut the remark of Jitter (specifically clock jitter) it is such an established consideration within serial digital signals... And engineering. I can only assume he has a specific commercial motivation to say what he does, unless it's taken out of context he sounds a quack.

The hifi industry does seem to harbour them, the more I look at it.

Now if Mr Hansen is saying the digital time domain jitter can be mitigated when transformed to the frequency domain  by oversampling and other techniques which are arguably inaudible then that is different, and has legs IMO, but that is different than saying there is no way of measuring jitter.
At the end of the day all digital jitter is time domain noise. As a DSP engineer knows when transform noise between domains, it remains. Ie time to frequency, it just manifests differently ie from phase to frequency. Through DSP (oversampling) one can increase the sample frequency, and therefore reduce the noise power in the frequency range of the original signal.
Again this may be going off topic, but as you can probably detect being an engineer, I do get frustrated by people who perhaps should know denouncing a truism for commercial gain and walking close to the snake oil camp, and unnecessarily confusing the lay person. I have no idea if this was Mr Hansen's intent, but they way he has been quoted it looks possible.
Simon
Posted on: 12 October 2011 by Simon-in-Suffolk
This getting to me now...  :-)
I am really trying to think what on earth Mr Hansen is getting at. Other than the above points that in my hear of hearts no credible engineer would really deny, perhaps what Mr H is referring to is that measuring jitter on a bit stream such as recovered SPDIF does not directly map to sample word jitter, which is the digital noise I was referring to above, since the bits needs recovering and assembled into a sample or value. It's the timing errors of these value impulses which is the jitter that affects the analogue signal. So although there is a relationship between the SPDIF jitter and sample jitter, the relationship is is implementation dependent. In many implementations and minimum chipset solutions in consumer electronics, this sample jitter might not be measurable ( because it's not accessible within the implementation).
There I have done my best to understand what could be meant by the above references...
I am off for a few days now, visiting a client to review signal jitter quality amongst other things. I really wish there was no such thing as jitter or way of measuring it as my life would be a little easier right now ;-)
Simon
Posted on: 12 October 2011 by Mr Underhill

Hi Hook,

 

Like you I think this is an interesting topic with some good grist - and an opportunity for me stop accepting received wisdom, but actually do some research.

 

Trouble is that, having some expertise in other areas, I am fully aware that what appear to be straight forward sentences wrt electronics probably mean something other than the standard english connotations I am likely to give to them.

 

Just had a day of thinking and writing at the factory, so I think I will just turn on the HiFi and relax for the rest of the evening!

 

 

Simon,

 

I actually dropped him an email last night and am keeping my fingers crossed that he might drop in.

 

...and now you've given me more things to look up.

 

M

Posted on: 13 October 2011 by Frank Abela

Until recently (well, last year), all implementations of HDMI suffered huge levels of jitter far higher than the SPDIF connections of the same units. By huge we're talking typically over 3000psec (against under 200psec). However, in the last year we have seen significant advances in this respect and modern units are below typical SDIF values but they're not nullified. So here's my question to Simon-in-Suffolk. Why is this? If the HDMI is synchronous, there shouldn't be any jitter whatsoever, right?

 

HDMI doesn't actually bring any significant benefits to the consumer per se. It's 'just' a digital scart, and it physically suffers from being a poor connector design too -that many cables were never meant to fit into that small a connector, and the connector itself suffers from connection breakage because of the weight of the cables and the lack of a proper secure clip. But HDMI does bring significant benefits to the content manufacturers (i.e. studios and labels) in that it guarantees encrypted transmission of the content. This should mean that all the content remains secure and un-pirate-able. In practice, I'm not sure it hasn't been broken. I guess it also means that if you really did want your SACD player to transmit its DSD stream to a DSD-capable DAC you could use HDMI to do it, but of course, you'd have to have two units that agree to do this - I'm not sure there's a standard for that kind of transmission.

 

Regards,
Frank.
All opinions are my own and do not reflect the opinion of any organisations I work for, except where this is stated explicitly.

Posted on: 13 October 2011 by likesmusic

Hi Res replay from SACD equipped bluray players is definitely a possibility, according to a Linn guy on their forum: "there is some interesting support for SACD playback from a source (Bluray or combo) players which are capable of sending SACD and DVD-A audio over HDMI (HDMI is an approved transmission medium for these formats thanks to its HDCP encryption scheme). There are some limitations, such as SACD bit streams being down-sampled to 176.4k or 88.2k and multi-channel material down-mixed to stereo, however it does give the ability to allow the playback of SACD layers from combo disks which cannot be currently ripped for streamed playback".

Posted on: 13 October 2011 by Simon-in-Suffolk
Hi Frank, well HDMI stll exhibits jitter because there is jitter of the master clock. With HDMI from reading the specification  this clock is called  TMDS clock.  Now the TMDS clock with audio is an integer multiple or divisor of 128*(sample frequency). Now the TMDS clock can be many times higher than that of the sample frequency and so the clock jitter is effectively reduced for each sample. As opposed to SPDIF where the clock is recovered for each bit transition including preambles and padding. Therefore jitter errors are more pronounced from the SPDIF clock recovery as opposed to a synchronous integer division of the TMDS clock with HDMI.
Simon
Posted on: 14 October 2011 by Mr Underhill

Simon,

 

Here is the thread that the quotes above were taken from, adds some meat:

 

http://www.audioasylum.com/cgi...digital&m=131301

 

M

Posted on: 14 October 2011 by likesmusic

The jitter in the HDMI source may not be an issue; given that the DS is a streamer, it will have an ample buffer into which data can be read and out of which it can be clocked uninfluenced by the jitter in the source.

Posted on: 14 October 2011 by Mr Underhill

Likesmusic,

 

How would you make use of a buffer to defeat jitter AND use the HDMI synchronous timing data.

 

M

Posted on: 14 October 2011 by likesmusic

For purely audio sources such as SACD converted to PCM via HDMI a moderate latency would be irrelevant; for ones that need to sync with video Linn engineers on their forum are saying that the DSMs will have variable delays for the audio, all the better to sync with video in practice.  The nDAC reads s/pdif into a buffer to deal with jitter - all I'm suggesting is that the DSMs can do that with both s/pdif and HDMII - the buffer is already there to deal with streamed data. I suppose in the unlikely event you wanted to delay the video more than the audio, you'd need to buffer the video too, but with most current display devices it is the audio that needs delayed in any case.

Posted on: 14 October 2011 by Mr Underhill

Likesmusic,

 

Let me expand my question - so you shoot me down in flames!

 

As you say Naim, and a number of other companies, use a buffer to handle the DAC input jitter.

 

I thought Simon's point with HDMI (and I'm thinking purely in terms of audio) was that it could pass synchronous timing info, so that the timing between the source and the DAC could be locked.

 

In this sense aren't the use of the HDMI timing info and the use of a buffer mutually incompatible?

 

M

Posted on: 14 October 2011 by Mr Underhill

Some interesting posts by Mr Hansen on HDMI and other interfaces:

 

http://www.avsforum.com/avs-vb...02&postcount=596

http://www.avsforum.com/avs-vb...96&postcount=587

http://www.avsforum.com/avs-vb...60&postcount=575

http://www.avsforum.com/avs-vb...69&postcount=566

http://www.avsforum.com/avs-vb...92&postcount=551

http://www.avsforum.com/avs-vb...61&postcount=546

 

and

 

http://www.avsforum.com/avs-vb...48&postcount=486

More on meaningless jitter numbers.

 

M

Posted on: 14 October 2011 by Simon-in-Suffolk
Mr Underhill, with HDMi the clocks between sender and sink (term used with HDMI) can be locked or more likely phase lock looped. Therefore either way jitter or drift depending on approach will pass through to the sink. Buffering and reclocking the samples  does make sense, but this introduces delay, and using a Phase locked loop sink clock  jitter drift (low frequency jitter) is more likely to be impactful and so the buffer in the sink would need to be relatively  large. With audio this might not necessarily be an issue, but for AV or lip sync reasons this would need to be carefully considered.
Interesting issues and early days, it will be interesting how things develop with hidef audio  2 channel on HDMI.
One thing for sure with HDMI is bit level jitter is eliminated ( this is what the synchronous clocking does) unlike SPDIF, but sample jitter still needs managing.
Simon