Brent - "signal loss" in this context is the the loss between what comes in to the AVR and what goes out, right? So, if the AVR is the source of a new signal, then there is no "signal loss" here, per se. That is my point, but no one seems to be addressing it.

Instead of just telling me outright that I am nuts, perhaps you can point out which of the 4 points in my argument is false. To just dismiss my argument by saying "WTF" without indicating where the argument goes wrong just doesn't make any sense to me.

Let me try to make my point another way. Suppose the signal from the source is sent to the AVR over HDMI and then recorded on a harddrive in the AVR. And, at a later point in time, the AVR reads the signal stored on the harddrive back into memory and then sends it out over HDMI to the display.

Can you see in this case that provided the signal arriving at the AVR could be parsed into 0s and 1s then timing imperections, etc., from the this original stream to the AVR would have no bearing on the stream sent from the AVR to the display? It wouldn't matter if the voltage level behind the 0 or 1 was nearly perfect or almost indetecable - in either case, it would be stored on the harddrive as a perfect 0 or 1, and then read back from the harddrive accordingly. (Or, at least, however imperfect the 0 or 1 was stored on the harddrive would be the result of the harddrive circuitry and not the HDMI input circuitry.)

This is the basis of my argument - that just becasue the AVR receives a data stream and then sends it out, that doesn't mean that the AVR is repeating the electrical/voltage/timing anomolies from the input to the output.

Crosen:
As everybody has already said the AVR does NOT create a "NEW" signal, it is not a repeater in the sense that it will take a weak signal, determine if it is a "1" or a "0" and recreate it as an output (some "upper end" product does do this0.
Repeaters that do this (our SR-1 for example) do NOT do anything except read and recreate (see prev. reference to fax or photocopier) they do not change OR understand the encryption/keysets (they are Dumb devices).

Why do you keep insisting that the AVR provides "New Data"?
To the best of my recollection no one has indicated that it is (unless there is an analog to digital conversion done by the AVR).

We (pretty much all here) keep showing you the answers to your questions but you keep rejecting based or a misinterpretation of what you have read online.

You keep insisting that there is (or at least should be) no loss when routing thru an AVR when "ALL" posts to date (including from Mfgr's) tell you otherwise.
I do not know where else to go with this.

At this point I can only suggest that take in one of Jeff Bocciaccios HDMI classes as he might be able to better explain it.

Recording DRM video?
Who,what and why?

Even KScape is hot water why would an AVR do this?



Why do you think that the imperfections would not be recorded?
Unless the recorder had some sort technology (like our SR-1) data is recorded as it is received.




Again why do you think that this is the case?
Of course it is repeating (and adding to) any abnormalities that are in the digital signal.

OK, thank you for asking me a specific question like this to help suss out the issue. The answer to this question is what I tried to explain in my "four points" argument.

In short, I insist the AVR produces "new data" because the stream it sends to the display is using a different set of encryption keys than the stream it receives from the source. The encryption keys are applied to the raw data and transform it from one set of bytes to an entirely different set of bytes. If a pixel in the stream from the source to the AVR was encrypted as 00001111, then it would not by encrypted as 00001111 when it was sent from the AVR to the display. It would be, say, 01010101. Totally different data!

If the byte stream the AVR sends is different from the byte stream it receives, then it is sending a new stream, right???!!!

(Again, I try to explain this more clearly in my "four points" argument.)

If I am incorrect here, please tell me how!?

I at this point have to think that you are referring to DDC data (of which the only thing that the AVR cares about is audio) instead of High Speed (Video) data WHICH IS NOT IN ANY WAY controlled/effected (except and exclusive to internal signal dB loss from the circuit board/path) by the AVR.

The only real effect that the AVR will have on the data steam is to tell the display that the AVR is there and will take the audio and provide EDID for up converted (analog to digital) data.

In short I can only assume that you reject my (and other mfgr's) reality in relation to how HDMI actually works.

It is time to contact HDMI LLC directly and see if they can better answer your questions (good luck on that by the way as they do not seem to want to answer the phone).

I can't imagine why you think I am referring to the DDC data.

Let me ask one simple true or false question: is it true that when the source sends the high speed (tmds) data that includes the video to the AVR, that this stream is encrypted using keys from the source and the AVR?

I assert this statement is true. Do you agree or disagree?

Crosen I would suggest spending some time @ www.avsforum.com you may find a more engaging dialog there...everyone else (especially Brent, who is taking his own personal time and has nothing to gain from being here answering your questions) has tried to assist to the best of their ability and cannot seem to satisfy your desire to be correct nor give you the answers you want.

Perhaps I am being daft. I am certainly being stubborn. But, it is not to the end of being right. It is to the end of resolving what I perceive to be a conflict between the information presented here and everything else I (think I) understand. I would be just as happy to resolve this by seeing the flaw in my argument as I would having my argument affirmed.

That means going through each of the 4 points and explaining where I have made an incorrect assumption or an incorrect logical assertion, or else affirming it is correct.

No one seems willing to indulge me in this request. Instead, they keep chiming in with good intentions but with information that to me seems off point and not responsive to my argument.

You misunderstand the role of what the keys are doing here and you are playing your own fantasy of what is happening. I don't wish to be rude. You need to wipe your mind of what you think you understand, you need to forget your "four points" argument and pay attention to what is happening.

All the keys do in the HDMI chain is unlock a door and allow the data to pass through. This is not cryptologic data where the key is required to decode the data. The key is required to open the door and determine that a valid system is in place so the data can be sent. This is why the HDCP handshake continues after the process has begun and original authentication has been achieved. It way a working system can suddenly fail because the HDCP handshake that asks are you legal fails.

There is a dual process in place. There are authentication process that no one save the HDCP folks control. This process checks that there is a valid system in place. Once this is determined the process that the manufacturers do control takes place. This process involves the transmittal and receipt of audio and video data between source and sink.

Keys are not required to decode this data. Keys are required to determine that the system is legal and data transmission can be sent. It's a simple If else statement. If system=legal then date transmission = enabled else data transmission = disabled

The data is not encrypted and key required to decode it. The keys determine if a legal system and if it is allowable for data transmission to be sent. The moment the key solution = invalid or illegal data transmission stops.

The HDCP authentication is built to allow for an in-line device such as switcher or AVR. Source asks who is listening. Devices that are in the system respond. Source determines via the keys if the system is legal or kosher.

Can the source be tricked? Damned right. JAP's topology sounds like it is using such a scheme to trick the system. JAP claims they have an exemption because they are using IP protocols. Perhaps you are now beginning to understand why some of us have been so curious about their authentication scheme. You seem to understand that source and sink are supposed to control the authentication process. Once source determines that the system is legal data is permitted to pass down the pipe(s). Thus the AVR doesn't need keys to decode the audio and send a separate set of keys for the sink to use to decode the video.

When the AVR announced itself it sent its key to source announcing it as a valid repeater. The sink sent its key back to the source and announced its presence as a valid sink. The keys validate the system and a valid system sets a flag so that data transfer = true. Even as data transfer is taking place the source continues to quarry the system to check that the system chain remains valid. It's system legality that the keys determine. They are not required to decode the data. They are not cyphers without which the data cannot be read.

Alan

Thank you for this response. It does directly address the point I have been trying to make. You are correct that I have the understanding that there is a cryptologic engine here. I can see if this understanding is incorrect that my argument is flawed.

Here's where I am going to test your patience even further. I still do believe the TMDS stream is encrypted! I say this because I have read as much in numerous places including the below white paper from DCP. The excerpt shown is from page 8.

It is possible that I am misunderstanding the paper. Or that I am reading it out of context. Or that the paper is wrong.

I'd much appreciate your thoughts.



[Link: digital-cp.com]

After authentication, the transmitter uses its HDCP cipher engine and the shared session key to create a stream of encrypted data that can only be decrypted by the receiver. The receiver uses its HDCP cipher engine and its copy of the session key to decrypt the content.



EDIT: a more detailed description of the HDCP TMDS encryption is on page 36 of this document from DCP. (I did not read the whole 90 page document, so perhaps I am taking this out of context.)

[Link: digital-cp.com]

HDCP Encryption is applied at the input to the T.M.D.S. Encoder and decryption is applied at the out of the T.M.D.S. Decoder (Figure 3-1).

Crosen,

I respect you for trying to learn more and understand why things work. I understand your argument but as Brent mentioned you are thinking digital but everything boils down to just basic electronics. Forget about the 1s and 0s for a minute that is the data.

A '1' is nothing more than positive voltage and a '0' is no voltage. They are timed so the data is recognized. Whenever you are dealing with voltage there will be amperage, impedance, capacitance, etc.

Because data can be altered and retransmitted does not mean there is a separate circuit between these. All because they go from one chip to the next doesn't mean they are not effected by basic electronic principles. They are still part of the same circuit.

The only way to physically break that circuit is to send something by a medium without conductivity such as wirelessly or fibre. Just like a ground loop could affect every device in your house it is about how well it is isolated. It is all connected somehow!!!

In any system these properites can be measured. In audio you will often see distortion measurements, crosstalk, etc. Same thing with integrated circuits just different measurements. In fact when they build a chip, the number of layers and size of the die will be a factor determining the capacitance of the chip. Between the layers sometimes they use an insulating material to reduce the capacitance, of course this costs more. The more vertical layers helps with capacitance but is more costly to build. The fewer layers the cheaper it is to make.

Basic electronics didn't disappear because of a whole bunch of parts compiled into a chip. Chips have electrical properties as well and is part of their design.

Since you are interested in how things work I think you need to bring it to a more basic level and stop thinking about the data. Hold off on trying to read about HDMI and HDCP that is the data. Do some searches for impedance and capacitance in integrated circuit design and high speed signaling.

This will give you a better understanding of why the problems happen and everything else is just the data.

Hope this helps.

Bob

Ps. TMDS is encrypted and a one way stream. There is no feedback on the TMDS lines that would come from the DDC channel. I think you know that just making sure. It doesn't matter anyway that is just the data:-)

Bob - thank you for continuing this dialog with me. I really do appreciate your participation.

In this case, I feel I understand and have already accounted for your most recent posting. It does not, however, seem to address the point I have been trying to make.  We seem to be talking passed each other.  I know you feel I am missing the point, but I feel it is my point that is being missed.  Such is the nature of communciation, at times.

To help address this and ensure we are talking about the same thing, perhaps you will indulge me in answering a series of single questions. I feel this will lead to resolution of the issue. I'd very much appreciate this indulgence.

You have already answered the initial question: is the TMDS stream from the source to the AVR encrypted? We seem to agree the answer is yes. Good. (Audible Solutions appears to disagree. Perhaps we will hear further from him on this.)

The next question is this: is the stream from the AVR to the display encrypted using a different set of keys than the stream from teh source to the AVR?

If you could please just answer that one question, I would much appreciate it. Please, bear with me. I really feel this will lead to resolution of the apparent conflict.

Great explanation!