Arduino-based ADAU1701 ("miniDSP")

[neildavis]

I had posted on this topic previously, but right now the search function won't allow me to find it.

I finished a second iteration of the board, and it works, and the software is moving along. You can listen to it and change filters in real time by sending commands from a .NET program via the USB interface on the Arduino Redboard -- it's pretty cool. The board has a number of stuffing options, but the basic active crossover circuitry doesn't take too many parts -- it only takes a couple of beers (and magnifying glasses) to assemble it.

There's still a lot of code required to make this board a flexible crossover for a stand-alone 2.1 amp (without the PC). The goal is to have a set of canned crossover frequencies and slopes that you can select from an LCD display or that bank of switches. There's a lot of programming required to make that happen, so it's still a ways out. But I wanted to point it out because it's a board that some people might be interested in using, or it might be something you would like to contribute to. The board and Arduino code will be open source.

[ani_101]

sounds fun...

[dlr]

Which. Net language are you using?

dlr

[neildavis]

Which. Net language are you using?

dlr

The Active Speaker Designer code (ASD) was an outgrowth of old VB code written for Excel to control the TAS3004 DSP. I stuck with VB.NET forms, but I started to translate some of the pieces to C#.NET WPF. That's going to be a long time-consuming process because there are many things I would like to change in the user interface. Honestly, I don't know how far I would get before I give up . The actual translation from VB.Net to C# is fairly easy--I just use that Telerik translator, and it usually does a good job of converting the code. But it's the user interface redesign that makes the effort difficult.

There is a screen shot below that shows the integration of the ADAU1701 DSP with the code. You can specify the overall system architecture, map DSP flows to system channels and read in the measurement data for each driver. Then you can interactively design the crossover and EQ and send the Parameter to the ADAU1701 in real time via the USB interface. That all works, although there is still a lot of refinement needed to finish off broken and/or unfinished code and to get rid of bugs. I've also got a nice debugger now that reads back the Parameter RAM from the ADAU1701 with labels that show the corresponding variables in the code. The debugger window is shown in the lower right..

The .NET code sends commands to the Arduino board, and all of the code to interpret and execute those commands is in C, using the Arduino 1.6.6 development tool. The next phase of code development will allow using the Arduino as the host without the PC commands. Right now the Arduino CPU loads the ADAU1701 code from its own program memory, so I've got a lot of the "difficult" code working. But there is a lot left to do.

[hongrn]

I'll be all over this when you have a working model. Thanks Neil.

[Millstonemike]

What are the audio signal in/outputs to the board - line level audio? If so, with the advent of low cost chip amps coupled with SMPS and your board there could be the next era in bi/tri-amped active speakers. On the back would be signal in, power in and USB interfaces or updating with a PC (in lieu of screen on every speaker). How different is your board from a miniDSP board (from an usage point of view).

[donradick]

Hmm.... VERY interesting.
I know I am "smd" soldering disadvantaged. Maybe interested in a finished board.

[neildavis]

What are the audio signal in/outputs to the board - line level audio? If so, with the advent of low cost chip amps coupled with SMPS and your board there could be the next era in bi/tri-amped active speakers. On the back would be signal in, power in and USB interfaces or updating with a PC (in lieu of screen on every speaker). How different is your board from a miniDSP board (from an usage point of view).

This board was primarily designed for experimenting...it's got some extra features not needed for a production product, and it's missing some features that you would want in a production product. For example, it's got the pads and wiring for an SRC4382 receiver chip. That's on there because I wanted to see whether an Arduino could keep up with the data from the User bits in an SPDIF audio stream. But that chip is expensive and probably not needed for most applications of the board. Another example is the output reconstruction filters. I deleted them from the board because the intended application of this prototype was the crossover for small class D amplifiers. Most Class D amplifiers have low pass filters on the input, so I didn't want to bother with those extra SMD parts. But on a production board you would want those components, plus some additional amplification on the output side and probably a USB isolator to prevent ground loop noise when the board is tied to the computer.

In other respects, the board is just the reference circuit for the ADAU1701 DSP from the Analog Devices datasheet. And that's all the miniDSP is, really...just the ADI reference circuit plus a micro to load the program and parameters into the chip. 2V in and 1V out, according to the spec sheet. So the real difference between this board and the miniDSP board is the software for the micro. For this version of the board I'm using my code written for the Arduino CPU (ATmega328) that will be open source, whereas the miniDSP code is proprietary. So the boards are comparable, but this one will be "open", which is an important difference for those who like to modify hardware or software. You will be able to use the schematic to modify the circuit and make your own boards and you can use the code to change the programming. At least, that is the goal. Unfortunately, open source efforts take a lot of time to document and support, and I can't spend the time that's needed to ensure that this is "fully open". So this project will only be open if someone offers to help.

The biggest difference between this and the miniDSP is the host software that is used to set up the board. The obvious difference is that the miniDSP host software uses nicely polished graphically rich code, whereas mine is clunky forms. But mine is much better for designing loudspeakers, as you can import loudspeaker measurements, design the box and model baffle effects, and interactively design the crossover. And mine allows using the full capability of the ADAU1701. The DSP design starts with a DSP architecture definition in SigmaStudio, and currently I'm using a DSP architecture that provides 8 channels of DSP with 8 biquads per channel, plus another 8 shared biquads. There are volume controls for each channel, and several "feet" of delay for each channel. That's a very powerful architecture that uses about 7/8 of the chip's program space. But if you wanted to change the architecture or use some of ADI's DSP modules, you could make the changes in SigmaStudio and then generate the header files for the .NET program and the Arduino code. The tools to process the SigmaStudio output files are built into my ASD software.

There's another interesting difference between my ASD software and the miniDSP host code: mine isn't dedicated to the ADAU1701. In fact, most of my code was written for the DSP in the STA308a and STA328 chips, and it also supports the now-defunct TAS3004 chip. But the goal is to eventually support other DSP chips such as the new TI codecs, the TI amplifier chips with DSP and even the DCX2496. That's probably not of interest to anyone who just wants a working low-cost digital crossover, but it helps explain why I don't want to spent too much time supporting just this one board design.

[neildavis]

Hmm.... VERY interesting.
I know I am "smd" soldering disadvantaged. Maybe interested in a finished board.

Back in the early 80's, when SMD's were first becoming popular, I'd visit the assembly area in our company and the guy who ran the area said he had no problem with SMD parts. He had a lot of technicians who would assemble the boards all by hand, just using fine-tip soldering irons. So I tried it myself, and, yep, it's not that hard. I use a 40-year old Weller iron with a long conical tip, stainless steel tweezers, a magnifying head loupe that my wife thinks is sexy, and lots of solder wick. All of the small parts on this board are 0805, which are fairly easy to deal with. The 48-pin flat pack is the hardest chip to solder, but I always leave an open area in the ground plane under those chips so I can shine a flashlight through the back of the board and inspect all of the joints. Really, it's not that hard. I've got a hot air solder station and solder paste in the refrigerator, but this board was so easy I just did everything with my old iron.

I bought enough parts for 5 boards and just built the one to make sure it would work. I didn't buy enough connectors, but sent away for more this morning. So maybe I'll have a few extra finished boards...

[donradick]

The project is def sounding more interesting and feasible.
If it expands beyond a few of us, we could do a Kickstarter.

As you were explaining the functionality and how the pieces worked together, something in me really dug it.
So what OS is the board running? I thought the .NET stuff was all Win32 or possibly Linux code?

[neildavis]

So what OS is the board running? I thought the .NET stuff was all Win32 or possibly Linux code?

The board is developed using the Arduino IDE, which initializes the micro and provides a simple executive loop. In this loop there is a check to see whether new data has come in from the USB interface, the "keyboard" (4 arrow keys and a select button), the SIP switches on the board, the IR receiver, or from the User data in the SPDIF stream. So it's a very simple executive that just looks for changes from the user or from a limited number of devices. There is nothing complex enough going on in the micro to justify a real operating system, and it doesn't have the horsepower to run one anyway. These are $3 8-bit micros with a total of 2K of RAM.

All of the "smarts" will be done in the .NET host or else will be pre-calculated and set in tables for look-up. For example, the .NET host can use a graphical interface to calculate filter coefficients for the ADAU1701, and then it sends the coefficients as strings in the format needed by the ADAU1701. Or, the user can change a filter type or frequency from a limited menu of choices using the on-board SIP switch or the LCD display, and the micro will look up the pre-calculated coefficients in a table and send that data to ADAU1701. But in either case, the micro doesn't perform the floating-point math to calculate the coefficients. Keeping the filter calculations "outside" the micro greatly simplifies the Arduino code, as there is no time-consuming and resource-heavy number crunching to overload the micro. That way, the simple executive loop is always responsive. There could be some real benefits from doing all of the filter calculations in the micro, but you would want to use a micro that was much faster and that had more buffer space--that's more of a Raspberry Pi type of project than an Arduino version.

The host doesn't have to be a .NET program--that's just what I used. Any host that can send data across the USB interface would be fine. But the host side code needs to be aware of the organization of the ADAU1701 and how the code for the ADAU1701 has been designed, so there is a lot of "control" code on the host side that isn't what many programmers are accustomed to seeing. The interface to the Arduino board is designed to expose the ADAU1701 as a set of I2C subaddresses, and it is up to the host program to determine what data goes in which address. The host sends command strings that specify the length of the string, the I2C subaddress, and the data. This command format is documented in the Arduino code, and there is a help file in the .NET code that describes the format with examples.

There are also some high-level commands supported by the Arduino: Master Volume, Channel Volume, Delay, Input, and Filter Spec, which will allow selecting IIR filters and frequencies from a set of pre-calculated values. These commands could come from the USB interface or the SPDIF User channel if you had a preamp that supported sending user data along with the audio via SPDIF (hmmm...and I just happen to have one of those).

This project by itself isn't earth-shaking enough to justify a Kickstarter effort, but it could certainly open up a lot of new possibilities for someone who wanted to design active speakers on a budget, or who just wanted to understand how all of this DSP/micro stuff works. Having an open board design and an open software design in the micro allows a lot of customization, so it's an interesting project for the DIY community. It's definitely a nice project for someone who wants a closer look at DSP and micros but didn't want to waste many months climbing a steep learning curve. But this isn't going to be a big commercial success unless someone has a much better vision for this project than I do.

[lowpolyjoe]

Very cool project.

[neildavis]

Big Update. All of the "hard stuff" for the local controller software is working. You can now "dial-a-crossover" and listen to the changes in real time. This version of the software supports 5 crossover types: BW1, BW3, LR2, LR4 and LR8. And there are seven frequencies: 1200Hz, 1600, 2000, 2400, 2800, 3200 and 3600. You can move through the menu and the crossover changes instantly, with no pops or clicks. It was a big step forward, as programming the ADAU1701 using pre-calculated tables and the safeload registers is some tricky code. Also, the master volume works.

There are several other menu items that still need to get implemented, but it is "more of the same". There is input selection, channel volume trims, delay for each channel, BSC (8 frequencies with 6 1-db steps), and EQ (9 frequencies and 11 steps).

When this is done, it will be a fairly nice general-purpose Arduino controller that will work with any ADAU1701 board: miniDSP, the board shown in the original post, or any board that someone wants to build. Just provide power and the two I2C lines and this controller will manage the ADAU1701.

The code also supports a rotary encoder. I don't know yet whether there will be enough memory left to add the IR remote control, but it probably will work OK. These coefficient tables are taking up a lot of space.

[Silver1omo]

Sweet, that looks really good.

[neildavis]

Sweet, that looks really good.

Thanks. What's really impressive is how inexpensive this stuff is. I think all of the parts for the DSP board are around $20, and it only takes about one hour to assemble the board. The CPU is $20 and the display board is less than $10, so this a lot of capability for a fairly low price.

The ADAU1701 can be configured in many ways, but the load I'm using is 4 channels with 8 biquads per channel, plus delay for each channel, plus 8 shared biquads for overall EQ. That's a lot of DSP horsepower for such a low price.