New low-cost DSP platform in development

[TSB]

Ah, someone managed to get it working. That’s cool! So there is some hope after all!


The chips are not the problem with HDCP, getting a decryption key is.

Indeed. To add some context: You need to become a HDMI adoptor (IIRC 5k$ per year + some per unit cost, see link below) and do official HDMI certification in a authorized test center (cost in thousands of $ as well - for each run - trust me you will fail a few times with completely new solution).

What are the Licensing Costs Associated with HDMI?

HDMI is great, but there’s a lot of confusion about the licensing fees associated with it. We’ve created a quick reference guide to alleviate this confusion.

www.symmetryelectronics.com

Authorized Test Centers (ATC)

ATC is a test facility that has been authorized to perform HDMI Compliance Testing. HDMI 2.1a

www.hdmi.org

Believe me when I tell you there is a reason no such open HDMI implementation exists and you will not do it as a side project for your DSP.

 

[antcollinet]

From web: […] AES/EBU uses ten times the signal level of SPDIF, meaning it can tolerate more loss in long cables and if a receiver circuit has been optimised for AES/EBU it will work better as SPDIF will be at the lower limits (too much noise). […]

This is all physical/hardware transport layer, not data protocol. We know that Toslink and Spdif coax are fundamentally different in the hardware implementation. The data protocol is still the same.

 

[bachatero]

The chips are not the problem with HDCP, getting a decryption key is.

I can't find any evidence of this. It looks like audio specifically isn't encrypted because it's "just" a SPDIF/IEC signal and whatever is in that signal could be stereo, Dolby, or DTS. So, that would explain the presence of super cheap generic HDMI audio extractors.

 

[voodooless]

It looks like audio specifically isn't encrypted because it's "just" a SPDIF/IEC signal and whatever is in that signal could be stereo, Dolby, or DTS. So, that would explain the presence of super cheap generic HDMI audio extractors.

HDCP also covers audio encryption. The fact that you get SPDIF-level output is exactly because of the licensing. It goes up to stereo, 48 kHz sampling, or bitstream formats that work over SPDIF. Analog outputs are often not restricted that way, so offer 7.1 LPCM up to high-res sample rates (if the device supports that). This is all just a licensing thing, and some things cost more than others. It covers the whole product, not just the chips inside of it. Some devices deviate from this. Some might just pay more licensing money, while others use compromised keys and sell illegal devices with features that are not permitted, again others might only work with non-HDCP streams, and just don't tell you in the specs. It's a wild west out there You must imagine that the licensing cost per device isn't very high, something in the order of 5 to 15 $ cents. The 10K or so annual free isn't a big deal if you sell plenty of those cheap devices. Nevermind that many of those cheap devices have almost the same inserts, so you can share the annual cost over lots of designs.

The best bet to make this actually work is to just get one of those extractors that offers 7.1 analog audio output, and has separate DAC chips to do that. Now you can just tap the I2S lines to the DAC(s), and get access to full high-res 7.1 LPCM.

 

[bachatero]

I don't know if you understand. It's a common scenario that some device gives a black screen but you can still hear stuff, because HDCP only affects video in HDMI and the audio goes untouched. HDMI licensing only matters about using the HDMI logo and "HDMI certified" and has absolutely nada to do with actual compatibility.

 

[voodooless]

HDMI licensing only matters about using the HDMI logo and "HDMI certified" and has absolutely nada to do with actual compatibility.

We’re not talking about HDMI licensing. We’re talking about HDCP licensing. They are separate things. You can create HDMI devices with the HDMI logo, completely without HDCP. It just means that you cannot do much with a most of modern content.

Just read the actual license agreement:

https://www.digital-cp.com/sites/default/files/licenses/HDCP%20License%20Agreement_March%2014%202024--FOR%20REVIEW%20ONLY.pdf

From Exhibit C, article 3.3 an on…

 

[bachatero]

That license agreement says the following: "3.3.2.3 IEC60958 Audio Content may be passed: To IEC-60958 or IEC 61937 where SCMS information is properly set and transmitted as 'Copy-never'." It literally never says anything about it being required to be encrypted, just a couple of limitations on the content itself that don't matter to us.

 

[voodooless]

That license agreement says the following: "3.3.2.3 IEC60958 Audio Content may be passed: To IEC-60958 or IEC 61937 where SCMS information is properly set and transmitted as 'Copy-never'." It literally never says anything about it being required to be encrypted, just a couple of limitations on the content itself that don't matter to us.

The standard is called HDCP: high bandwidth digital content protection. The license tells you what you can extract from the encrypted stream in what circumstances. “May be passed” here means what the device in question can output from a HDCP encrypted stream. Session 3.3.2 specifically talks about “decrypted HDCP content” as does 3.3.1.1:

Presentation Devices may output the audio portions of Decrypted HDCP Content that is Audiovisual Content in (a) analog form shall be limited to 1.5 times normal speed, unless the pitch is corrected to the pitch at normal speed. Except for the requirement just described, sound quality of analog outputs is not restricted in any way; or (b) digital form in either compressed audio format or in Linear PCM format in which the transmitted information is sampled at no more than the equivalent of 48 kHz and no more than 16 bits per channel

What follows to give more specifics on this.

 

[bachatero]

That's exactly what I said, the devices decrypting HDCP (TVs) provide the audio to you straight up because the only limitations on audio are boring ones that don't matter to us.

 

[Cogito]

I'm really looking forward to the results on this, despite the fact that much of the techno-babble on this thread is way over my head. Of course, I won't purchase until Amir gives his recommendation first

 

[voodooless]

That's exactly what I said, the devices decrypting HDCP (TVs) provide the audio to you straight up because the only limitations on audio are boring ones that don't matter to us.

The device that terminates the HDMI cable must do the decryption, unless you grab the digital audio from the TV, in which case it is the termination device itself. If you want your DSP to receive digital audio over HDMI, either via eARC or normal, you are bound by the HDCP encryption, and your DSP device will need to do the decryption in some way or another. And if you want multichannel, you will need to jump though some extra hoops. So it seems that that Khadas board can do HDCP decryption to provide digital audio to Linux user land. That is actually pretty cool, but we have literally a single short post describing that it worked. If you can find something similar for a RISC-V board, and figure out how to make it work reliably, you’re in business. Though I doubt it’s exactly according to the license agreement.. but for DIY, it’s probably nothing to worry about.

 

[somebodyelse]

So it seems that that Khadas board can do HDCP decryption to provide digital audio to Linux user land. That is actually pretty cool, but we have literally a single short post describing that it worked.

That post was about receiving eARC PCM 7.1 from a TV. It's not clear that HDCP was involved. The Khadas wiki covers enabling eARC reception, but not the 'magic numbers' to announce format support for 7.1 so only works with the default 2.0 minimum requirement. There's a similar post covering the iMX8MP, again apparently with defaults and without whatever's needed to reach 7.1 PCM etc.

HDMI video capture is covered in the wiki for the VIM4 but it doesn't cover audio. I think I've seen other examples capturing the audio part from an alsa device, but I don't remember anything about setting up the supported formats. Again there's no mention of HDCP. I think there are other boards with similar capabilities, but I haven't gone looking for the details.

 

[voodooless]

That post was about receiving eARC PCM 7.1 from a TV. It's not clear that HDCP was involved.

No it’s not, which is too bad. But given that most content is encrypted, there is a good chance.

I also have a board somewhere with HDMI input, but sadly it’s currently bricked

 

[bachatero]

Sorry to make another hardware hype post, but I got some more in and soldered the headers! We now have 3 candidates for DACs: the PCM5102, UDA1334A, and CS344C. There is also the PCM1808 ADC and a few TRS breakout boards along with optical connectors.

 

[Tell]

I'm really looking forward to the results on this, despite the fact that much of the techno-babble on this thread is way over my head. Of course, I won't purchase until Amir gives his recommendation first

If it has the features I want and the price is okay I'll buy it no matter what Amirs recommendation is

 

[bachatero]

Got some bad news, it's going to be a long (but maybe fun) road ahead unless I receive some help.

Here's how each part of this project is so far:

-> core library: in progress, almost ready
-> compiler: in progress, not ready yet
-> assembler*: not started yet
-> DSP library: not started yet
-> web panel: not started yet
-> hardware OS: not started yet
-> hardware package: in progress, not ready yet
*as a replacement for the one built into GCC

I spent a full 8 hours today researching the "hardware OS" portion and it looks like it's going to involve custom crafting a special Linux build just like you do with other embedded Linux setups. Actually, this whole thing is going to span ALL the software disciplines. Anybody interested in lending a hand?

 

[jbags]

I am very interested in this project. However I have no programming skills. I’m a pretty good cook but that’s not much help here.

 

[bachatero]

I am very interested in this project. However I have no programming skills. I’m a pretty good cook but that’s not much help here.

Thank you I'm glad to know there is actual interest in this because there are simply no comparable options on the market at all.

 

[EJ3]

Thank you I'm glad to know there is actual interest in this because there are simply no comparable options on the market at all.

Another interested party here: unfortunately also with ZERO programing skills. My apron for when I am grilling has a skull & crossed bones on it with the statement:
"Beware! Death from within!" So my cooking is questionable, too.

 

[somebodyelse]

I spent a full 8 hours today researching the "hardware OS" portion and it looks like it's going to involve custom crafting a special Linux build just like you do with other embedded Linux setups. Actually, this whole thing is going to span ALL the software disciplines. Anybody interested in lending a hand?

Starting with that duo-buildroot-sdk-v2 and following into the host-tools repo it uses, plus a few others under milkv-duo, the general lack of documentation and license files isn't encouraging. https://milkv.io/docs/duo/getting-started/buildroot-sdk is a lot more useful, with https://buildroot.org/ for upstream docs. If you're looking at making this something non-technical people can use reliably you should probably look at an A/B update process like RAUC. There's an example for Pi CM4, 4 & 5 integrating RAUC with Buildroot. I've not checked whether any of these keep the rootfs read-only, but I would hope so for reliability.