TOPIC:

Well, the AVR Key did not help. It preserves HDCP on the audio output port if it was present at the input (and of course, preserves it at the video output port).

HDFury had said that they could provide custom firmware to disable HDCP if I could provide paperwork claiming that I am either (a) the copyright holder, or (b) had permission of the copyright holder to remove HDCP. Sadly, that is not the case: I am seeking to remove HDCP that was added to an HDMI A/V signal that didn't have it, but had it added by the miniDSP nanoAVR that I own. I suppose I could argue that adding HDCP with equipment I own made it a compilation work of a bunch of bits and therefore I DID have copyright over the encrypted video, but somehow I think that would not wash (generally because the change was transformative and reversable and not an artistic compilation in the same way a directory might be).

HDFury did note however that they could provide firmware to remove HDCP from their equipment that processed resolutions no higher than 1080p. A Dr. HDMI EDID emulator would fit the bill. Do I really want to spend ANOTHER $100 to try? I've asked them to clarify that they can actually do this.

In the mean time I am resigned to using a mediocre HDMI 7.1 analog audio extractor and unbalanced to balanced level shifter to get to pro audio levels to drive my Crown amps.

This experience has been incredibly frustrating and expensive. I never thought miniDSP would add HDCP in a link where it was not originally present. Besides all the 3G SDI gear I bought, I ended up getting an EDID emulator, HDFury AVR Key, and ultimately HDMI to analog audio extractor (rendering the 3G SDI gear useless).

At least miniDSP knows about the issue. We'll see if they can and will fix it.

Thanks for the updates. This situation sounds frustrating indeed. I hope miniDSP can help to resolve it.

Jim wrote:

Thanks for the updates. This situation sounds frustrating indeed. I hope miniDSP can help to resolve it.

It is extremely frustrating. I have spent a lot of time and money to get to this point. Of all the contingencies I had planned for (and risks I took), I never thought that a product would add HDCP where it was not present before (though I can see how this might seem to make sense to the manufacturer - if you always apply it, you don't have to worry about forgetting to and getting sued under the DMCA in the U.S.).

It doesn't help that everyone seems to be secretive about HDCP. All anyone is willing to say is that their equipment is "compliant". All that means is that it will not breach the security of an established, HDCP encrypted, connection. It says nothing about what it does with unencrypted input.

Given all the restrictions about only processing LPCM audio over HDMI, I had presumed that the nanoAVRs were oblivious to HDCP -- they wouldn't process it or deal with encrypted video. In hindsight this was silly of me -- it would really restrict what they could process. Nevertheless, I found my Oppo BDP-103D would not request an HDCP handshake out it's secondary "audio" HDMI port, which purports to send audio (LPCM, if set to decode other formats in the player) with unencrypted video or black. I verified this by connecting it directly to an HDMI to SDI converter (which is oblivious to HDCP and will not negotiate it). It worked! It even worked when I routed the output of a nanoAVR (which always negotiates HDCP on its output), through the Oppo BDP-103D via the front panel HDMI connection. So, I knew HDCP was being stripped out the "audio" HDMI port of the Oppo. I thought I was home free, but connecting the nanoAVR (either HD or DL) between the audio HDMI output of the Oppo to the HDMI input of the HDMI to SDI converter proved to not work because the nanoAVR insisted on negotiating HDCP on its output.

I didn't suspect HDCP at first. Who would insist on encrypting an unecrypted HDMI signal? Oh no! I suspected an EDID mismatch: maybe the nanoAVR was negotiating 50 Hz or 59.94 Hz with the HDMI to SDI converter, but 60 Hz with it's source. And, I know it does not scale, or convert frame rates. So, I got an EDID emulator, to make sure what the nanoAVR negotiated with the HDMI to SDI converter would be supported with the source. By playing with it I could see that the nanoAVR reported to the source the EDID presented by the equipment connected to its output. The nanoAVR should wait to see which video mode the source selects and then use that with whatever is connected to its output, and not negotiate them separately (since it does not scale or do frame rate conversion). At first I thought it did it wrong and there was a bug. At this point I contacted miniDSP to report my problem and what I had done to solve it.

MiniDSP was responsive, sent me a link to download logging software, and I quickly sent them a log and got a verdict: the nanoAVR was looking for an HDCP chip in the HDMI to SDI converter. It still didn't click that it was trying to negotiate HDCP. Why? The input was not encrypted? O.K. So I figured I'd get an HDCP complient HDMI splitter to add after the nanoAVR: it would show the presence of an HDCP transceiver, but as the handshake would not be completed (an erroneous assumption on my part), it would not seek to negotiate HDCP on it's output. Ah! But, the nanoAVR DID want to negotiate HDCP on it's output, and was happy to do so, with either the splitter, or a TV. The nanoAVR logs showed it got past the point where it was stuck waiting for an HDCP transceiver response, and I got video and processed audio out of it, protected unfortunately by HDCP. I reran several tests to be sure my source was not encrypted and the nanoAVR was encrypting on output.

Correspondence with miniDSP confirmed that they are, in fact, "HDCP 1.4 compliant". O.K. But what the @#[email protected]#[email protected]$ does that mean exactly: do you encrypt on output even if you got an unencrypted signal on input? "We're HDCP compliant".

In desperation I purchased an HDFury AVRKey. This is a device to split an HDMI signal into video and audio HDMI signals. I naively thought that it would leave HDCP in place through the video link, and remove it on the audio link. After all, it sends black video out the audio HDMI port. It works primarily to combine the audio EDID components from the audio HDMI port with the video EDID components from the video HDMI port. I thought that it would act like the Oppo BDP-103D: encrypted video and unencrypted audio. Sadly, no.

HDFury has confirmed that I (a) needed to strip HDCP from the audio, that they could provide firmware to do this, but either only for video resolutions of 1080p or less or upon receipt of a letter stating I was either the copyright owner of the material, or had permission of the copyright holder, for resolutions above 1080p. I was not going to lie. But, I was hopeful, thinking since I was dealing with 1080p just to carry the audio (I could even go to 720p if I had to), I could get said firmware. Well, no: the 1080p referred to the maximum resolution supported by the device and not the resolution I was actually using. (The AVRKey supports up to 4k60 4:4:4 HDR).

So, I went looking for an HDFury product that capped out at 1080p in hopes of getting HDCP stripping firmware for it. The Dr. HDMI! This is an EDID emulator that maxes out at 1080p. I suggested it, with appropriate firmware, to HDFury, but they pointed out that it has no need to decrypt as it just does HDCP passthrough, and only manages EDID. Duh!. They suggested the Splitter 4k or Splitter 4k pro, which are just HDMI splitters. I think they scale so they have to decrypt and reencrypt HDCP, I remain a bit confused because they do handle resolutions above 1080p. The Splitter also combines EDIDs from audio and video devices so I am not sure how it differs from the AVRKey. In any case, HDFury said the Splitter 4k or Splitter 4k pro would work, with custom firmware. I am still wondering how that is consistent with their statement that no paperwork is needed for units limited to 1080p. Perhaps the custom firmware limits the Splitter to 1080p.

By this point, I have started hedging my bets. When I bought the HDMI splitter (I also ordered another "cheap" one that is purported to erroneously strip HDCP, but I have my doubts) I also bought an HDMI to 4x2ch analog deembedder. It's a cheap ByteCC model that gets questionable reviews. I really don't want to go that route: I have no idea how good it is, and I will likely need to raise the levels to pro audio with something like an Aphex 228 ($400-$500 new but around $150 used). Still, there are better units that do the same thing: Crestron HD-XSP, for example. Over $2k new but available for $750 used.

I have also found another HDMI to SDI converter that is supposed to sink HDCP (SDI does not support HDCP -- it is strictly a video format, there is no DDC bus to carry EDID or negotiate HDCP over). Their tech support refused to discuss anything HDCP but pointed out that it would work to connect equipment known to apply HDCP on output to SDI networks. Of course, connect might just mean "the plugs fit"). Still, there have been several reviews that it does strip HDCP, and the sales web site has large friendly letters indicating it is not sold to remove HDCP for copying. It is sold so HDMI sources can display on SDI monitors. So, I think they are using the interoperability exceptions of the DMCA to sell the thing. Impulsively, I bought one. ($150... on sale... and $35 shipping 'cause I want it soon).

So, between this quasi-legal HDMI to SDI converter that sinks HDCP, HDFury providing magic firmware for one of their units to strip HDCP, miniDSP stopping encrypting unencrypted data, or my being resigned to go HDMI to analog audio, I have a few possibilities to tame this. I am hoping the new HDMI to SDI converter does the trick, at least until miniDSP changes their firmware to not encrypt unencrypted video.

By now you are probably wondering why I want to go the SDI route so badly. The reason is simple: I don't want to spend $2500 for an AVR that supports Dirac Live when I can just use a miniDSP box for a fraction of the cost and feed it LPCM audio. SDI carries video (3G SDI to 1080p60) and up to 16 channels of 48 Khz 24 bit audio. On a single coax cable. Equipment to embed or deembed audio in an SDI signal is relatively cheap, both in balanced pro analog and AES/EBU digital flavors. Like $65 to $150 to convert HDMI to SDI, $195 to extract 4 analog or digital audio signals, and $200 or so to convert 2 AES/EBU to 4 analog audio signals (or vice versa).

This weekend I plan to try this shady HDMI to SDI converter, and if it does not work, fall back to using the ByteCC HDMI to 8ch analog audio converter. Then wait to see if miniDSP fixes this bug.

For the benefit of those who do not know the details of HDCP and EDID and how they are negotiated, and what is SDI, I thought I'd offer a short tutorial. It will also explain why quality cables matter.

An HDMI cable carries several signals: four each of three wire (shielded, twisted pair) internal cables for each of the the three video color signals (RGB or YCbCr, or any one of several color formats) and a video clocking signal, 5VDC and HPD (hot plug detect) to detect when something is plugged/unplugged into the end of a cable, HEAC+ for audio return channel and half of 100 Mb/s ethernet (HPD is the other end of this ethernet signal, differential; and common mode with HEAC+ to carry return audio referenced to ground: so HPD to +5V indicates connection, differential pair between HDP and HEAC+is full-duplex ethernet using a duplexer (bidirectional signals on one pair of wires), and HPD and HEAC+ both referenced to ground for audio return), CEC (a one wire shared bus, referenced to ground, for consumer electronic control (so your TV turns on and switches to the Bluray player when you turn it on)), ground for HPD, CEC, and HEAC, and finally two lines for DDC (display device control). It is DDC that is interesting.

DDC is basically a long I2C bus (inter-intergrated-circuit). I2C is designed to run at 100 kHz, 400 kHz, or 3.4 MHz, or 5.0 MHz , and is a bidirectional bus designed for interconnecting integrated circuits. It is limited to a load capacitance of 400 pF. And this is where the trouble begins. DDC extends this to 700 pF. Still not very much. Cable capacitance increases linearly with cable length and this is the number one reason why long HDMI cables cause trouble: the DDC bus. By contrast 3G SDI carries 1080p60 at 2.97 GHz over a single coax cable at anywhere from 177 to 510 feet, depending on the cable. Oh, and with 16 48 kHz 24 bit audio audio channels. I2C was never intended to be used over long cables, but rather within and between printed circuit boards. Then someone had an idea... and DDC was born. In the early days, with short cables from computer monitors to computers, it wasn't so bad. But, these days, with long HDMI cable runs to projectors and what not, it can cause trouble.

So, what is this DDC bus used for? EDID and HDCP. You can see where things go south if you push DDC to its limits.

I2C (and thus DDC) works by one of many masters starting an exchange by addressing a slave, clocking on one line, and serializing the slave address on the other. It's an open-drain pull up bus, so if two masters start at the same time, all but one will use collusion detection to back off. After the device address, comes a read/write bit, address of the register within the chip, and clocking of data either in or out of it for however many bits are necessary. Then the bus goes quiet and another exchange can begin by the same or a different master.

EDID is simply a data block that an A/V source can read to learn about the capabilities of a sink device. EDID emulators provide whatever EDID you program into them instead of that provided by the sink. In their most basic form, they remember what the sink provides and hide the fact that it may have been turned off or unplugged (remember that HPD hot plug detect?). In more advanced forms, you can effectively force the source to send a particular signal. HDMI A/V splitters combine EDIDs from, say, a display device, and audio device, to send the displays video capabilities and audio devices audio capabilities to the source. An EDID emulator will not help if the cable is too long however (though some have DDC signal cleanup hardware that can help). There are devices that JUST fake out HPD or clean up the DDC signal without affecting EDID.

HDCP is more complex: it is actually a several message protocol carried over DDC. The "chip" and "register" addresses are well defined. BTW: HDCP and EDID can be managed over physical layers other than DDC, though this is rare. HDCP 2.0, in particular has a locality provision, requiring responses with 7 ms, so you don't negotiate an encrypted connection between New Jersey and Uzbekistan tunnelled through the internet.

SDI. SDI is how video is carried around in production studios and on location. There are SDI cameras, monitors, recorders, etc. Its elegance is that it is a single coax cable (as opposed to 4 shielded twisted pair, and five other lines for HDMI for a total of 17 wires), with locking BNC connectors that don't fall out, and capable of supporting a 1080p60 signal from 177 to over 500 feet, depending on the cable. There are audio embedders and deembedders that can add, replace, and pull off audio from an SDI cable (with pass through for the video): in balanced pro audio +24dbU 0DBFS levels or AES/EBU digital levels. There is no concept of HDCP, so HDMI to SDI converters tend to not have HDCP transceivers. (But, of course, someone has to send a clip from a Blueray on a broadcast TV program, and has permission, so HDCP sinking HDMI to SDI converters are rumoured to exist. No: Blackmagic does not make them. I don't think AJA does either).

Now, in my application I am only concerned about using SDI to carry audio, simply because it is so cheap to get it to and from the damn single coax cable. Like with HDMI you need some video because the audio is carried in the horizontal and vertical sync intervals (present, because, you know, someone might want to drive a CRT). But it can be black.

There are levels of SDI: SDI, HD-SDI, 3G SDI, 6G SDI, and 12G SDI. HD-SDI could carry 1080i, and there was equipment that used two such cables to carry 1080p. 3G SDI can carry 1080p (three different ways: A, B split (a mux of what would have been two HD-SDI cables), B sequenced (two different 1080i programs)). 6G SDI carries up to 4k30 and 12G SDI carries up to 4k60. There are ways of carrying 12G SDI over four 3G SDI cables (as well as fibre optic links, as it approaches 12 GHz).

The really annoying thing? IIRC, HDCP only applies to the video portion of the HDMI signal, not the control or data island periods, which are in the sync intervals. Audio is sent on a data island. MiniDSP could simply send black if they can't negotiate HDCP with the downstream device.

Update: HDFury sent me custom firmware to try on my AVR Key. I am hoping it will not encrypt the audio HDMI port. I will try it this weekend.

Further research tells me that HDCP only encrypts the video portion of an HDMI signal: audio is sent on "audio islands" in the horizontal sync interval (yes, there is a h.sync and v.sync interval to accommodate CRTs, basically pixels beyond 1920 horizontally and 1080 vertically in a 1080p signal). While a source can refuse to send audio if it can't negotiate HDCP, once HDCP is negotiated, audio is sent unencrypted and can be just "picked off". So, a change to send audio unencumbered on an "audio" HDMI port (with, say, black video), does not strike me as any kind of DMCA violation.

Also, with regard to my confusion over HDFury's statements that they will disable HDCP only on devices capable of 1080p or less, but offering to do it in their Splitter 4k device, I think they meant devices capable of HDMI 1.4 only and not HDMI 2.0 (implying HDCP 2.2). I received the following message:

"the splitter 4k and splitter 4k pro do not do 4k with hdcp 2.x devices. They only work for 4k within the limits of a [email protected] signal only device. So no [email protected]"

I think they mean to write HDMI 1.4 when they write [email protected] HDMI 1.4 can certainly accommodate [email protected] but not [email protected] I expect the native language of most of their devs is not English so communication is a bit slow (and I speak neither Mandarin nor Cantonese) and it's impressive that they can use English at all for which I am grateful. More importantly HDMI 2.0 REQUIRES HDCP 2.2.

So I think they meant to write that they are willing to strip HDCP 1.2 without paperwork but not 2.2.

In any case, If I can get an unencumbered 7.1ch 48 kHz audio on the secondary port unencumbered by HDCP I shall be very happy. I must be the only person who wants to use SDI to move audio around without video.

I also received one of these to try:

www.hdtvsupply.com/hdmi-to-hd-sdi-converter.html

rhollan wrote:

I also received one of these to try:

www.hdtvsupply.com/hdmi-to-hd-sdi-converter.html

SUCCESS!

This unit successfully negotiated HDCP on the HDMI port and I successfully pulled 48 kHz audio out the SDI side via an SDI to AES/EBU and AES/EBU to analog converter. I did note that I could not get picture or video if I subsequently sent the SDI signal through an SDI to HDMI converter. As the most common reason for doing this would be to defeat HDCP I wonder if there is some anti-circumvention mechanism introduced into the SDI signal that makes such transformations problematic (and keep the pro-HDCP police at bay). In any case, I have my audio!

Do note that neither Blackmagic nor AJA HDMI to SDI converters will negotiate HDCP, probably as their way of not running afoul of the HDCP police.

The AVR Key firmware arrived but did not help. The release notes made it look like it was just a regular update to the latest version.


Time to complete the theatre.

Been starting to put all the equipment back together: Nvidia Shield into Oppo 103D into minidsp nanoAVR HD into nanoAVR DL into HDTV Supply HDMI to SDI converter into SDI to 4x AES/EBU audio extractor into two of 2x AES/EBU to balanced audio into Crown and Outlaw amps driving speakers, and dual subs.

I found in testing that the AES/EBU to Balanced converters wanted an SDI sync, so I feed the SDI signal through from the HDMI to SDI converter into each of them. A bit of a pain since AES/EBU digital audio is self-clocking.

Since I have four speakers in the back, I ran the following cables covered by a raceway from the front to the back of the room: 2x AES/EBU, SDI video (for sync), and a quad cable remote control line for the Crown XLS 1002 amps in the back: when the control pair into the amp is shorted, it remains off, even when powered on. So I ran two pairs back to a relay switched by a 12V DC power brick when the system is turned on. The second dual AES/EBU to quad balanced analog audio converter is in the back, close to the wall-mounted connecter for the in-wall surround speakers.

I thought of having that second digital to analog audio converter in the front, with dual amps, and just run speaker level cables through the raceway to the back, but decided I wanted as little equipment visible in the front of the room as possible: The Nvidia Shield, Oppo, Crown and Outlaw amps are visible and the various converters remain hidden.

Now, the Blackmagic SDI to Audio converters can produce either four sets of two channel AES/EBU digital audio or four balanced analog audio outputs. I was just wary of the DACs in them so I chose to get the AJA ADA-4 converters but they sure make for a rat's nest of cabling. The Blackmagic converters, in analog output mode, allow for trim of the analog levels, which may prove useful, so I plan to try it, and if they work well, get another one, and scrap the use of the ADA ADA-4s.

I still haven't heard if miniDSP plans to provide firmware to send unencrypted HDMI signals out of the nanoAVR if they receive an unencrypted input, but it is a bit early. I would like an answer one way or other though, even though it might take a while to implement.

The possibility of using digital audio signals to drive miniDSP plate amps for the surround channels is interesting but I am not about to replace the Crowns yet.