[megabyzus]

Hi.


My question, as someone ignorant to HDMI and its peripheral technologies, is regarding what causes a certain malfunction and why this is a problem in the first place. I am not asking for troubleshooting of my system. I just want to learn about possible causes as pertinent to HDMI technology. I have a particular AVR that has the regular slew of HDMI inputs in the back and two HDMI outputs in the front. I am 'passing through my cable box signal to my HDTV via the avr. When I have enabled pass through on the unit and it is in stand by (off), every once in a while when I turn on my HDTV and cable box, instead of the normal audio/video ,the screen floats with a 'no signal' message. The problem goes away once the unit is un/replugged. As part of my research into this problem, I have noticed similar, if not identical issues, across various brands.


I just purchased this unit recently and it is my first avr that uses HDMI as a standard in/out mechanism. Now to my questions:


- why does the unit go back to normal after power off/on? Why does the HDMI connection work after power recycling? This is the most important question because, to me, 'pass through' means what it means: Pass Through=The AVR is simply connecting the HDMI in to the HDMI out without interference. Obviously not. What's up with that??

- Why would pass through fail on it's own as the unit has been sitting in stand by and what are the possible causes?

- Why is HDMI more sensitive to these malfunctions than previous connection technologies such as video composite or digital in/out technologies?

- This seems to be a problem that goes beyond a single manufacturer as I've seen. Is this true?


Any insight will be greatly appreciated and thank you for your patience!

 

[Joe Fernand]

When you require a diagnostic tool costing anything from 4.5K USD and upwards (for a portable solution – x10 for a full desktop solution) you know there is more to HDMI than simply a ‘PassThru’ connection!

http://www.quantumdata.com/products/index.asp


There are so many variables at play in your system it’s impossible to say for sure where the problem lies!


Joe


PS And add HDCP and E-EDID to yoru research!

 

[alk3997]

It's good to break-down the problem by looking at what HDMI is and is not. HDMI was designed as a *secure* method for transmitting uncompressed video and audio from component to component. The emphasis on secure was intentional since many people in the content-owner camp were paranoid about people stealing their high quality HD connection (not realizing, of course, that most real pirates don't really care about image quality - hence the camcorder footage that shows up as a bootleg).


It was also designed for point-to-point source-to-sink distribution. I'm sure someone thought about an AVR switching between sources but it sure wasn't a priority. Also at the time HDMI came out, the maximum (at that time) speeds were pushing the available chipsets. There were multiple reports of overheating HDMI chipsets at the time.


The way HDMI works is with a series of handshakes. One of the handshakes, called the EDID, allows the sink (the destination) to tell the source what capabilities the sink has. This allows the source to only send out a signal that is compatible with the sink. If you are just doing point-to-point communications then this is easy. Also remember that due to the original HDMI limitations, the system was designed to only send out one video and one audio stream at any time. So, you can't, for instance, send out a stereo *and* a multichannel audio output at the same time. It can only be stereo *or* (really xor) multichannel.


Another handshake was the copy protection of HDCP. This is designed to encrypt the signal going out on the wire. The source and sink have unique keys and then exchange a continuous set of keys during transmissions which allow the transmission to be secure (except, of course, that the keys have been compromised). The expected result of invalid keys is to have no picture or audio.


That brings us to bit errors. I've often felt the engineers and lawyers that designed the original HDMI standard were very optimistic people. They actually believed that HDMI would work most of the time. So when it doesn't, it doesn't do it gracefully. Now some of that is the copy protection paranoia but some is just because the methods for telling the customer that something is wrong is very poor.


When you introduce bit errors into the equation, that could result in an EDID handshake that indicates the sink can only accept a source type that doesn't exist (due to the bit errors generating an invalid signal) or it could be an HDCP handshake that said you do not have a valid sink (trustworthy sink). Or it could be that the picture data is so error-prone that it can't be de-encrypted.


Of course bad firmware can do all of the things that bit errors can do. If the firmware can't understand one of the handshakes then the result can be the same as if the source or sink was reading error-prone data. For whatever reason cable STB manufacturers seem to have the most problems getting their firmware correct (even satellite boxes, on average, seem to have better firmware).


Now throw in a matrix switch or AVR, where the source is going to multiple sinks and you have where HDMI is today. Luckily the chipsets and firmware are improving. The level of complaints for simple setups seem to be going down over the years. Now people are getting more complex setups (Denon now offers multi-zone over HDMI, for instance) which is going to push HDMI to new problems.


There used to be a thread about what we would like to see in HDMI in the future. My choices would be:


1) Multiple audio streams (optional) - send both a multichannel and stereo at the same time, which would solve most of the current matrix switcher problems people have

2) A more robust error detection system - if the EDID is in error indicate that on the display. If it's an HDCP problem show that. If there are too many bit errors to tell, show that. Of course then you would have to make sure the firmware was telling the truth.


Add in what Joe said earlier and I think you'll have an answer to your questions.

 

[megabyzus]

So is it correct that the problem I described is not unique to a particular manufacturer's negligence and is not uncommon in other manufacturers?

 

[alk3997]

Negligence would be a strong word given that the CE industry, as a whole, seems to have issues with making error-free firmware. Also some problems can be attributed to user errors (using the wrong cable for the transmission length) and some can be attributed to the system working as it was designed (having incompatible sinks results in no data). So, I don't know how to answer your question in a yes or no manner. However, these things do no seem to be unique to a single chipset manufacturer (remember the chipset may not come from the manufacturer of the component).

 

[megabyzus]

So basically, considering my HDMI pass through drops once or twice a week and I need to recycle the avr's power, it doesn't warrant returning the AVR since other manufacturers may have similar if not identical problems. I just wanted to make sure this is not some egregious problem with the unit or the manufacturer (which from the sounds of it, it is not) since it's the first time I bought a new receiver in 20 years and I wanted to get a good handle on the state of affairs. I hope the manufacturer will eventually fix this problem although I am not sure if they have even officially acknowledged it. I think this may be less because of simply poor customer service and more with them either thinking "well we're not alone in this" or they're trying to come up with a firmware fix. I think I will keep the unit with y fingers crossed and hope for a fix downstream.


I hope my thinking is ok. And thank you both for your insight and patience.

 

[alk3997]

OK, now that I understand your question...The biggest problem you'll have is that this is an interface. So either side of the interface could be wrong or neither (they both follow the spec but the spec wasn't good enough). It also means that either side of the interface could change and the issue would go away. So is it a problem with a cable box or the AVR? Neither or both.


In the past we've seen AVR manufacturers generate new firmware that magically fixes handshaking problems. So that's a possibility.


However, in the meantime what you want to do is to disable anything in HDMI that could be causing this problem. First disable anything to do with HDMI CEC. That will eliminate control signals from the HDMI data. Second disable "deep color" or anything related to 36-bit color. Deep color greatly increases the bandwidth and only sends additional color data that your TV/screen could also handle. There are no discs that have deep color data included, so it doesn't buy you anything and could introduce bit errors.


Make sure when you disable a feature, you check for it in the source, the AVR and the sink. Disabling one should result in no one using it, but it doesn't work that way in reality and handshaking still occurs to determine that the other device has something disabled.


If you are still getting the errors, try setting everything to 1080i and see if that causes the problem to go away. Remember to set your AVR to "native" resolution (no upscaling) since the AVRs can take 1080i signals and convert to 1080p.


There's a lot going on, and sometimes you have to change the variables to narrow down the source of the problem. Hopefully you'll find whatever is causing bit errors or bypass the part of firmware that is causing the problem.

 

[Colm]



Quote:
Originally Posted by megabyzus  /t/1420508/hdmi-curious-dropped-pas...hat-are-the-reasons-behind-this#post_22223948


- why does the unit go back to normal after power off/on?

Because the devices recognize that they have to renegotiate the connection. The sink (TV) sends the source (BD/PS3/computer/etc.) its E-EDID which contains information about its capabilities. The source uses this information to determine what resolution, refresh rate, color depth, etc. to transmit.

Quote:
- Why would pass through fail on it's own as the unit has been sitting in stand by and what are the possible causes?

Who knows? Lots of possibilities. It sounds like the timing when the AVR is in pass-through mode is marginal. Like Joe said, it will cost you big bucks to find out exactly why. FWIW the order you power things on may make a difference.

Quote:
- Why is HDMI more sensitive to these malfunctions than previous connection technologies such as video composite or digital in/out technologies?

With previous technologies, the source just sent whatever it wanted and it was up to the sink to deal with it. There was no handshaking. With HDMI, the source sends the "best" picture possible that the sink can handle based on its E-EDID. The sink has to recognize the request for the E-EDID and send it. Any device between the sink and the source needs to accurately forward on the entire E-EDID. And it all has to happen within a specified amount of time.

Quote:
- This seems to be a problem that goes beyond a single manufacturer as I've seen. Is this true?!

Yes. My guess is that it is a bigger problem in system with equipment from different manufacturers.


One thing that may be relevant that you haven't mentioned is the length and gauge of your HDMI cables.

 

[megabyzus]

My HDMI Cable specs are: 6ft 28AWG High Speed HDMI Cable With Ethernet w/ Ferrite Cores - Black


I don't think the cable is the problem since I have read this issue exists across various HDMI 'qualities' and reasonable lengths (usually under 7-8 ft).