Audiodevelopers Reborn

Finally, some progress with the ADAU1466…

There are quite a few differences between the ADAU1701 and the ADAU1466, so I expected a long and difficult effort to update my ADAU1701 library files for the newer DSP. However, it really wasn’t too difficult, and the problems I ran into were from unexpected differences and some over-reliance on SigmaStudio.

The ADAU1701 code uses a micro to allow controlling the volume, input selection, crossovers, bass enhancements, and EQ from a cell phone app. In order to do that, the code in the micro needs to be able to generate the proper data to control the DSP cells and then be able to write that data in the proper format to the Parameter RAM in the DSP. None of the “upper” layers of the code are affected by the change, and the lowest levels (I2C communications) are identical. The ADAU1701 uses a different number representation: 5.23 versus 8.24 for ADAU1466, but this change was easy enough to implement.

But I ran into a snag with the biquad coefficient loading routine. The biquad coefficients get calculated in the micro using the “Audio Cookbook” equations published by Robert Bristow-Johnson. For the ADAU1701, there are safeload registers for updating the 5 biquad coefficients all at once, to minimize “glitches”. The ADAU1466 also has these safeload registers, but for some mysterious reason the “order” is totally different, and I can’t find any documentation anywhere on the Analog website that explains the “correct” order for the coefficients. In fact, the only documents I could find were for one of the SHARC series, which use an even different order. The normalized coefficients for the ADAU1701 must be loaded in this order: B0, B1, B2, A1, and then A2. The ADAU1466 loads the coefficients in this order: B2, B1, B0, A2 and A1. Get that sequence wrong and you won’t get any output from the ADAU1466. C’mon, ADI…that is just weirdly inconsistent, and you could at least document the coefficient order somewhere.

But the other snag that really cost a lot of debug time was relying on SigmaStudio to set up the clocks. I was able to control the volume just fine, but the biquads seemed to be getting calculated or loaded incorrectly. This didn’t make any sense, until it became clear that it was a clock issue. Somehow the default clock dividers got changed to “0”, so instead of running the DAC at 48K, it was running at 288KHz. I would expect SigmaStudio to be smart enough to know that if you have selected 48KHz sampling, the clock dividers need to be properly set, or at least issue a warning notice that your selected sampling rate is not possible given the current clock ratios. So, lesson learned. Fortunately, the clock dividers are well documented in the datasheet, with default values and two examples. But jeez…who reads the fricking manual when we have this sophisticated software to help us out (not)?

The other major difference of the ADAU1701 and the ADAU1466 is the way the self-boot EEPROM is configured. I never used an EEPROM in any of the board designs on Audiodevelopers, because it was easy to load the ADAU1701 code from the micro. This approach had the nice benefit of not needing a USBi programmer. I just processed the “tx” file generated by the SigmaStudio compiler to create an Arduino “.h” file with the code and loaded the Program RAM at power-on reset using that data. But the ADAU1466 uses two different memory spaces with multiple pages, and there is a lot more code to deal with. For the ADAU1466, it makes more sense to let SigmaStudio program the EEPROM. So, the new designs will require a USBi interface board to program the EEPROM. The biggest “downside” to this approach is that the USBi SPI interface interferes with the I2C interface from the micro, because on the 72-pin devices like the ADAU1466, those signals are shared pins. So, when using the USBi, you need to unplug the micro. You will need to develop and test the SigmaStudio code fairly well before using the micro to control the cells. The 88-pin ADAU1467 does not use the same pins for the slave SPI and I2C signals, so that might be a better choice for future designs.

That’s the end of the gripes. The ADAU1466 is a really nice chip. Having 8 ASRC modules plus SPDIF is great–you can connect anything to the DSP and not worry about synchronizing the clocks. Easy peasy, lemon squeezy, as my wife would say. SigmaStudio hides the complexity of the ASRC–it is really nice to just pick from some high-level menus and hear the audio without having to program a huge number of registers. I’ve used several other ASRC chips, and no other chip is this easy to use. And overall, SigmaStudio is really nice. I’ve used it before for designing the ADAU1701 signal flow but have never used it in “active download” mode. I much prefer controlling the DSP with my cell phone app, but I can certainly understand why DIY’ers would be enthused by SigmaStudio.

There is still a lot of code to update to use the updated libraries, but there don’t seem to be any problems that will require extensive debugging in implementing the next generation designs. The only challenge left is that spring has arrived here in the Maryland mountains, so “software season” is officially over. It’s time to work on those legs that have atrophied over the winter. Progress on software will be slower, but I’ll start ramping up on the cabinet work and maybe get some new board designs completed.

I haven’t posted in a while, as other projects have kept me busy, but it’s time to return to this long journey. These pages have actually covered a lot of territory, but the end goal is still a bit in the distance. And the goal remains the same: developing the hardware and software that we need for easy-to-use and easy-to-DIY multiway active loudspeakers.

The focus of the articles and projects so far has been on 2-way and 3-way designs, where the DSP is an ADAU1701 controlled via a cell phone app. These designs have allowed exploring emerging hardware and newer chip-level systems that are essential building blocks for scalable multi-way active speakers. Also, we now have some reasonably effective software that can be used to take the next steps. Given where we are now, it is possible to map out the next steps in this journey. There will be new articles in the upcoming “Next-Gen” articles to address each of the following areas, starting with an overview of projects to come:

This is a preview of some upcoming projects. First, I’m still interested in a project that requires no custom hardware development, so when I saw the new 4-channel JAB4 DSP/Bluetooth amp from Wondom, I couldn’t resist. I’ve got a JAB4 board running in one of those PGA2311 preamp cases with an ESP32 CPU board for control and a Nextion display. I still need to deal with the auto power-down feature of the JAB4, and I’ve got lots of code to write for the Nextion display, but this is starting to look like a really nice solution for active speakers.

There will also be an end table version using a highly modified case that I ordered from Sam’s for about $50. This Bluetooth end table will be stereo (speakers on both sides) with an active crossover and bass enhancement that you can control from your cell phone. Plus, it will have a wireless charger built in the top. The drivers are ones I’ve been intrigued by for a while: the glass-diaphragm drivers from BDNC (Speaker Drivers – BDNC (Holding) Limited (newbdnc.com). This will go in our greenhouse so my wife can keep her “babies” entertained (she’s got turnips, peas and spinach shoots popping up already).

I’m hoping these projects will move along quickly, as I’m anxious to extend the ADAU1701 libraries to control the ADAU145X/ADAU146X, and I’ve got plans for a second-generation line array amp. We’ve had a lot of snow and many days with temperatures in single digits, and these are all good “software season” projects.

Long time, no publish…but the logjam is finally starting to clear. It took a lot of work to move “to the country”, but the garage is done, the wife’s greenhouse/nursery is mostly done, and electronics projects are starting to show up on the desk again.

I’ve finally got some software that can be used as a basis for new designs–see the updated article on Sharable Code (Finally: Some Shareable Code). This article describes the refactoring effort that has been a stumbling block for over a year now. There are still some additional features I’ll be adding, such as EEPROM support for boards that are hard-wired to selfboot, including the JAB3/4/5 series from Sure. And I need to make sure the software can be extended easily to deal with the newer DSP chips like the ADAU1466 as well as the TI Purepath devices. And I need to block out a design for an updated line array amp with this software base, which will be a good test of the extensibility. So, lots of interesting challenges planned for this winter.

It’s been a long time since the last update, largely due to having to prep our house for sale. But in spite of time spent painting, refinishing floors and replacing cabinets and fixtures, there has been steady software “refactoring” for the ADAU1701 code. As noted in other posts, my engineering background is more hardware and systems than software, and all of the initial code to control the ADAU1701 started out as as assembly language, written for the 68HC08 series microprocessors. Some of these devices only had 256 bytes of RAM to work with, which doesn’t support modern programming practices of modularity, decoupling and code reuse. I had “translated” this assembly code into Arduino C and although it worked, it was difficult to maintain and not something I could share with others.

The code that I was using these past years relied heavily on globally defined structures and enumerations and look-up tables, and refactoring this code into logically layered library calls proved to be much more difficult and time consuming than I expected. But much of this code is now working, and the code is far more maintainable and is “shareable”. I’ll be writing much more about this in the articles, and post updates as this effort is finalized.

I’ve also got a number of new DSP hardware projects lined up, but I’ve been putting them off until this code update is done. This software redesign has been a much bigger challenge than I expected, but I’m at the point where I’m coasting downhill rather than climbing. The house refurbishment is still going to take up most of my time, but even with those chores, I should be able to make more frequent updates on these pages.

I had been using ITEAD studio for PCB’s and I still like that service, but it seemed like the prices were higher last time I got boards, so I decided to go with SEEED Fusion. Wow–these guys are good. I got 10 boards for that ESP-DSP design for $4.90 and splurged for DHL shipping at $20. I put in the order on June 4 and got the boards on June 12. Just a couple of days for production, and then a few more days for reasonably priced shipping from China. This is great service given the price!

That $4.90 price for 10 boards is only for certain sizes and “normal” quality, but it worked out fine for this design. The boards look nice–I’ll see if I can do some debugging in the next week. I’m still amazed at the price. I also re-did the 4-channel amplifier module described in the Fully Modular design since there were some “issues” that I wanted fixed. That board was much more expensive, since it is a 4-layer board with ENIG coating , so a run of 10 was about $60. Maybe if that design works out OK I’ll redesign it for 2 layers and see if I can get the price down to $4.90. But $60 for 4-layer boards with ENIG is still very good.

BTW, the ESP-DSP design is a cell-phone-programmable 2-way stereo or 3-way mono board with up to 8-pole crossovers, 12 bands of EQ, BSC, delay, volume trims and bass enhancement (ADI’s SuperBass). It’s just 2 major modules plus some power supply components, with no SMD parts. It’s easy to build and it’s inexpensive. It should be a nice board with a lot of applications.

But more importantly, the ESP-DSP board is where I’ll try to “finalize” the Arduino code and replace the many files of code with library calls. After working on this code for so many years I finally have a good feel for how to partition it for efficient code reuse. Usually summer isn’t “software season” for me, but everything seems upside-down anymore with this pandemic, so who knows…

Things are moving slowly in Audiodevelopers land, as we are working toward selling our house in Reston VA,  and that means a lot of repairs and refurbishment that keeps me busy and away from electronics.  But I’ve been trying to update this site with new content at least once a week (or more often if people buy me a coffee).

I don’t see much more future for the ADAU1701-based designs, as most of the low-cost possibilities have been explored, either by commercial offerings or designs offered in these page.  It’s time to move on to more capable DSP’s and more connected CPU’s to implement “smarter” active speakers.  That seems to be the right direction for this web site, but the next steps on this path will be big ones.  I’ve got the parts on order for the “Turbo 2×6” board, and once those parts come in I’ll make the board and start on a long overdue effort to refactor the software in a way that will provide a better foundation for future designs.  I’ll address the software refactoring in a later post or dedicated article.

Edited May 30: Hmmm–there still might be one more new ADAU1701 board worth considering before moving on to the ADAU1466 designs:  a “stripped-down” 1X3 board.  This could be useful for embedding in speakers to provide a 2 or 3-way crossover with BSC, EQ and delay.  And it could be used for very small woofers, as it would have the ADI superBass psychoacoustic bass enhancement algorithm, which I already have running on other boards.  I’ll put some more thought into this and see if this board has enough potential applications to make the design effort worthwhile.   If I used a double-sided board with the ADAU1701 “learning board” on one side and the ESP32 on the other side, the board could be small enough to cram into very small enclosures…

I made some updates to the stereo 3-way Part 2 page, and will be adding more in the next few weeks.   However, the next update will be the software page, as I finally made a stand-alone version of the tool to process the SigmaStudio output files.

This tool creates two files needed for the Arduino code:  1) a code file to load the Program RAM and the Parameter RAM, and 2) a “Cell map” that provides a way of referencing the SigmaStudio DSP cells in the code.  I’ll provide details in an upcoming update, but it was important to make this tool available in a stand-alone program as it needs to take on some new functionality for the next designs in the queue.  The old version of the code was buried in the now-ancient ASD program, written in VB.NET.  The new code is in C# and it is much more maintainable.

The new code also has a new feature coming that will create a simple Arduino sketch that can program SigmaStudio code into an ADAU1701 board that has an EEPROM.  So you just need an Arduino host with an I2C connection to the board, and you will have the ability to put the SigmaStudio code into the EEPROM.  This will eliminate the need for the SigmaStudio programming boards.  You just need to point to the output files of the SigmaStudio compiler and the generated Arduino sketch will put the right data in the EEPROM.  None of the designs I have made use the EEPROM, as the CPU loads the ADAU1701, but this will help for other boards or modules that require programming.  This application will be at:  http://www.audiodevelopers.com/Software/Arduino_Tool/setup.exe.

 

Audiodevelopers is a collaborative website to share design ideas, software, hardware and construction tips for active speakers.