Surround decoder for encoded digital audio (AC3, DTS, AAC) with Beagle Bone Black

(Almost) finished project. Digital 7.1 audio decoder for DTS, AC3, AAC, and all that FFmpeg will decode and fits on a TOSLINK bandwidth.

IMG_0024_640.JPG


IMG_0018_640.JPG


lcd.jpg


IMG_0021_640.JPG


IMG_0022_640.JPG


Sources and design (all GPL v2):


Project page, to be expanded
 
  • Like
Reactions: 1 user
I'm just considering this myself as well, running this between my tv and a soundbar I want to build.

One question, any particular reason you didn't use the pocketbeagle? From what I can tell it's cheaper but still has access to the MCASP on the chip for in/out and is the same processor.
 
I wasn't aware of the Pocket Beagle. Did it even exist at the time? But for me it doesn't matter, because I had ample space.

I'd like to add a note BTW, that this solution doesn't work well for devices connected with HDMI to your TV. At least not my Panasonic Vierra. Audio passthrough just doesn't work, and all connected devices just output stereo PCM. It seems to be a DRM/HDCP thing; the TV tells the source device what to output in.

I'm still confused about it though, because this states that all the TVs they tested can pass through.
 
Pocketbeagle came out late 2017 I believe. For me I'm just considering cost, $25 vs $50.

I thankfully don't have any hdmi sources connected to the TV. Well, a blu-ray player we never use as we go to the theater. I mostly want it so I can get an actual center channel. My girlfriend loves her soap operas and watches them on the Hulu tv app, so this will work great. Can output from the app through toslink, pull out the L/C/R and EQ from there.

Do you have any notes on resource utilization? I'd imagine it's quite lite.
 
Given the finishes I did to it, $25 wouldn't have made difference :)

I don't fully recall the resource use, but I think it was about 30% or so (if memory serves, that is about the same as playing an MP3 on a Pentium 100). I configured it to run my decoder software with real-time scheduling, because it was sensitive to skips. I never really understood why, because the whole audio system was driven by an external clock, so all output and input should have been impossible to desynchronize.
 
This sounds great, and I want to know more!

On the project page you write that the S/PDIF signal is received by a DIR9001. I don’t quite understand that, as I thought the DIR9001 can just receive 2 Channel PCM of S/PDIF and gives out i2s.

The DIR9001 has an AUDIO output pin, which is high or low depending on whether it sees PCM or encoded data.

Very Nice! Can you please add schematics in PDF-format on the project page? So that readers can get an overview picture without installing Eagle? :)

I could, but the project page needs a lot more that I haven't gotten around to yet. Allow me some time, and I'll see if I can manage something.

So, you receive the signal, process it in the BeagleBone and then output the individual channels through their DACs?

In a nutshell, yes. Depending on the aforementioned AUDIO pin, I just write bytes to the sound device, or use ffmpeg to decode it.
 
Allow me some time, and I'll see if I can manage something

Sorted it. Latest version of KiCad can import Eagle directly. A schematic says more than 1k words :)

So, basically the setup is that you receive S/PDIF and feed into a DIR9001 to get I2S. That signal is fed into the Beagle where it is decoded (AC3/DTS) and the result is output to a 8-ch DAC.

This answers the question I had earlier. I guess I could use your design and have digital outputs instead.

You use I2C to select what DAC to output to. Neat!

I think that you would do the community a great service if you were to amend the instructions for the software so that those of us who do not speak Linux with complete fluency could follow :)

PDF Schematic attached
 

Attachments

  • Schematic.pdf
    279.1 KB · Views: 151
So, basically the setup is that you receive S/PDIF and feed into a DIR9001 to get I2S. That signal is fed into the Beagle where it is decoded (AC3/DTS) and the result is output to a 8-ch DAC.

Ffmpeg autodetects the codec, so AAC should also work. Unfortunately, DTS True HD and Dolby Atmos and stuff require more bandwidth than s/pdif offers, so that's off the table (although I smell a new project coming, if not for ******** HDCP ).

You use I2C to select what DAC to output to. Neat!

This is pretty common in DAC world. Sound cards do it internally to control volume, muting, anti-pop, sample rate, etc. Because of SOCs (system on a chip) ARM systems emerging, ALSA designed ALSA-SOC that allows direct interfacing of DACs through I²S+I²C, without drivers having to re-code the same DAC in slightly different ways.

I think that you would do the community a great service if you were to amend the instructions for the software so that those of us who do not speak Linux with complete fluency could follow :)

I made the designs public because I indeed want to help people out, but I did realize it unfortunately isn't so plug-and-play. For instance, the ALSA-SOC layer imposes restrictions that the hardware doesn't have, so I hacked a driver that will never be accepted for inclusion in the kernel.

At this point I think knowing how to cross-compile software and drivers is somewhat unavoidable. I have an image file of the EMMC with the software installed that anybody is welcome to use, but that requires my exact schematic.

And here it comes, another stupid question.

I think think this project invokes a lot of questions, it's fine :). I also invite you to look at the git history on Github of both the schematic and code. I like explaining the 'why' in git history, and what I learn.

In the schematic there is one i2s data line to the dac.
Why not 4 data lines? The BBB is able to output 4 i2s data.

The pins can only be muxed in certain ways, and there was no way I could use 4 data lines. I needed pins for two master clock in, frame clock in/out, bit clock in/out, data lines, etc.

It's a theoretical bummer, because I now use time multiplexing, and therefore need the 512 times clock recovery option on the DIR9001. That makes the maximum sample rate 48 kHz. I haven't been hit by it yet, but HD audio is off the table from the start (although I don't believe in HD distribution of audio).

And what is the EEPROM used for? Doesn't BeagleBone have plenty of storage?

The beagle bone 'cape' manager scans a certain I²c port for autodetection of device ID for automatic driver loading and reading pin mux settings for checking compatibility with other cape boards.

I know I know, you're updating the project page, patience people.

The original post was a year ago, so that shows how fast I am :). I'm actually working on instructions for the cross compilation of ARM source; already quite some work.
 
Last edited:
The issue with HDMI connection to the TV causing S/PDIF to default to PCM? I ran into that problem when I got an HDMI upscaling Sony DVD player (DVP-NS75H); there was a setting in the player to fix that.

Regarding True HD and DTS MA, I would go over to the dark side and buy a used AVR. Just beware of early HDMI receivers that only pass-through or only do DD/DTS/PCM; look for the TrueHD and DTS MA on the front panel. $100 could find one on a local ad site, though I've occasionally seen them much cheaper at thrift stores.
 
The problem with getting I2S output from a used/hacked AVR is mainly pertains to detecting changes in the audio format (Lj / Rj / I2S), bit depth, sample rate and oversampling ratio. However, if these parameters are static or if your downstream equipment is able to auto-detect the same, then you could just pull out the I2S from the relevant pins or TPs (if they exist) of the DAC chip used.

The same applies to hacking a graphic card's DAC.