Adding post-DSP SPDIF outputs to AVRs

[Weeb Labs]

Greetings!

I thought it might be fun to share details of a current project, which involves modifying AVRs with post-DSP SPDIF outputs. This effectively turns any AVR into a fully digital audio processor with room correction, subwoofer crossover/time alignment and EQ functionality.

The potential applications are numerous and I am in the process of producing a rather elaborate video that should enable anybody with moderate DIY electronics experience to perform this modification.

The modification itself is fairly straightforward and entails hijacking the front channel I2S output which runs between the unit's DSP and DAC. A readily available WM8804 board can then be used to obtain a stereo coaxial SPDIF output for those channels.

I expect to complete production of the video guide within a few weeks. These photos were taken during a quick test, to ensure that my script did not omit any relevant detail. The procedure is applicable to almost any AVR, with pin locations and channel pairings being the only significant variables.

This is a cheap, used Denon AVR-2807. It was manufactured in 2006 and was one of the first Denon units to include Audyssey MultiEQ.

The thought had also occurred to me that the AD IC would be fairly easy to control via I2C for arbitrary DSP. Perhaps I'll look into that soon!

 

[mansr]

I thought it might be fun to share details of a current project, which involves modifying AVRs with post-DSP SPDIF outputs. This effectively turns any AVR into a fully digital audio processor with room correction, subwoofer crossover/time alignment and EQ functionality.

I've had the same thought but never got around to actually doing it. Does that AVR have digital volume control? Otherwise the Audyssey volume-dependent EQ will be hard to use, should you like that feature.

The thought had also occurred to me that the AD IC would be fairly easy to control via I2C for arbitrary DSP. Perhaps I'll look into that soon!

The ADV7401 seen in the photo is a video digitiser and format converter. It won't be of any use for audio processing.

 

[Weeb Labs]

I've had the same thought but never got around to actually doing it. Does that AVR have digital volume control? Otherwise the Audyssey volume-dependent EQ will be hard to use, should you like that feature.

The volume control implementation is something of a hybrid. Master volume control is analog up to unity gain, which is 82%. Beyond that point, the DSP's digital output is raised beyond 0dB, which causes the clipping noted by Amir in his reviews. Relative channel levels set by Audyssey are digital attenuation.

The SPDIF outputs are fixed level with regard to master volume, so the downstream DAC(s) requires volume control. I use a PGA4311UA for this purpose, as it is highly linear, readily available and offers four channels. Ideal for 2.1 or 2.2 configurations, if you'd rather not control volume via the source.

Another workaround is to adjust the Source Level setting for a given input. That is effectively a digital master volume control, although slightly inconvenient to adjust.

IThe ADV7401 seen in the photo is a video digitiser and format converter. It won't be of any use for audio processing.

Not that one; the AD-21366.

 

[mansr]

Not that one; the AD-21366.

That's a SHARC DSP. I don't think you can simply reprogram it over I2C.

 

[Weeb Labs]

That's a SHARC DSP. I don't think you can simply reprogram it over I2C.

It's quite well documented DSP, so I wouldn't anticipate too much of a problem in getting it to talk to Sigma Studio.

 

[mansr]

It's quite well documented DSP, so I wouldn't anticipate too much of a problem in getting it to talk to Sigma Studio.

Sure, writing code for such a chip is straight-forward. Getting the code into the chip as connected in the AVR might be trickier. I'd expect them to have locked it down as much as possible.

 

[Weeb Labs]

Sure, writing code for such a chip is straight-forward. Getting the code into the chip as connected in the AVR might be trickier. I'd expect them to have locked it down as much as possible.

That's the fun of it.

 

[mansr]

That's the fun of it.

Sure, as a puzzle to be solved. If you just want to get on with processing signals, not so much.

Once upon a time, I managed to bypass protections in a Sigma Designs (RIP) chip to access some things that were meant to be hidden. They somehow got wind of it and invited me to their office. In a meeting with someone responsible for those parts of the design, he asked why I'd done. My reply was something along the lines of "because it was there." I never did anything useful with it, though.

 

[maverickronin]

Sure, as a puzzle to be solved. If you just want to get on with processing signals, not so much.

If you want a proper digital out, unencumbered with HDCP then it may be your only choice...

 

[Weeb Labs]

If you want a proper digital out, unencumbered with HDCP then it may be your only choice...

Not at all. The SPDIF output described above is bitstreamed and completely free of HDCP. It has already been decoded.

 

[maverickronin]

Not at all. The SPDIF output described above is bitstreamed and completely free of HDCP. It has already been decoded.

That's what I mean. One needs to hack an AVR like you are doing in order to get a proper digital out after having decoded the HDCP and the various other proprietary formats and that makes the effort worthwhile.

 

[Weeb Labs]

That's what I mean. One needs to hack an AVR like you are doing in order to get a proper digital out after having decoded the HDCP and the various other proprietary formats and that makes the effort worthwhile.

Ah, I see. I thought you were referring to the potential AD hijack, which is what he was talking about.

 

[mansr]

That's what I mean. One needs to hack an AVR like you are doing in order to get a proper digital out after having decoded the HDCP and the various other proprietary formats and that makes the effort worthwhile.

Adding the S/PDIF output is trivial. Hacking the onboard DSP is a lot harder.

 

[Weeb Labs]

On a related note, I'll have to scope the inputs and outputs after work. Should be interesting to compare latency values between the various signal paths.

 

[maverickronin]

Ah, I see. I thought you were referring to the potential AD hijack, which is what he was talking about.

Adding the S/PDIF output is trivial. Hacking the onboard DSP is a lot harder.

Yes. Thar part would definitely be a lot harder.

You probably bypass the need for any outboard DSP that way though.

 

[Weeb Labs]

An early disclaimer?

This was really just captured as audio for the disclaimer screen and never meant to be seen.

 

[Vincentponcet]

@Weeb Labs do you know if there are 8 channels i2s to aes boards ?
We could buy 4, but I expect a single board will be less expensive.

 

[Weeb Labs]

@Weeb Labs do you know if there are 8 channels i2s to aes boards ?
We could buy 4, but I expect a single board will be less expensive.

Not to my knowledge but it would be fairly straightforward to create one. There are also various ADAT encoder ICs capable of taking all four I2S data channels.

 

[mdsimon2]

@Weeb Labs do you know if there are 8 channels i2s to aes boards ?
We could buy 4, but I expect a single board will be less expensive.

When implementing a similar project I did not find any 8 channel boards.

The biggest issue with 8 channel I2S is that these 2 channel WM8804/5 boards require MCLK, BLCK and LRCLK so you need 4 of each but there is often only 1 of each available. Splitting these signals (especially MCLK) is not trivial and requires a clock buffer. I used Ian Canada's McFIFO / McDual but that adds at least 100 ms latency which is not great for audio / video applications.

Would definitely be interested to learn about other options.

Michael

 

[Weeb Labs]

When implementing a similar project I did not find any 8 channel boards.

The biggest issue with 8 channel I2S is that these 2 channel WM8804/5 boards require MCLK, BLCK and LRCLK so you need 4 of each but there is often only 1 of each available. Splitting these signals (especially MCLK) is not trivial and requires a clock buffer. I used Ian Canada's McFIFO / McDual but that adds at least 100 ms latency which is not great for audio / video applications.

Would definitely be interested to learn about other options.

Michael

There shouldn't be any need to buffer the clocks; certainly not for an internally mounted board. They are already paralleled to multiple ICs and the inputs are high impedance.