Audiodevelopers Reborn

Hmmm…what drivers lurk behind that cheap metal grill? And why is the name singular?

One of my goals in these retirement years is to use up or dispose of or somehow repurpose a large stash of boards or electronic equipment that I have accumulated during many years of this speaker-building hobby. I’ve got a lot of DSP boards with different CPU’s and software, and I’ve got lots of drivers and lots of cabinets with drivers in various build stages. One set of drivers that was particularly interesting was a SEAS Excel Millennium tweeter and a 7″ Excel W17EX-001 magnesium cone woofer. My friend Russ had given me these when I was his co-worker, along with a passive radiator that I had already used in a subwoofer project. These drivers were too good to just leave on the shelf, and they were too expensive to buy another set for making a stereo pair. So, what could I do with these?

I had already made a large “Hi-Fi” Bluetooth speaker for a friend’s gathering, by adding a Qualcomm Bluetooth module to a 12″ PA speaker that had been modified with a nice Galaxy Audio midrange and Audax horn tweeter. It had a 200W amp and a ready-made 3-way crossover. The crossover had not been optimized for those drivers, yet it still sounded quite good, and made an easy source of audio that could fill the room nicely. Since this formula seemed to work well, I decided to use the same approach to use these fine SEAS drivers. I also had an Icepower 500ASP amp already mounted in a chassis, so I would have plenty of “oomph” to power this speaker.

Since I am trying to use up parts rather than buy new stuff, a design goal was to keep the remaining components I needed on a tight budget. Also, this speaker is not addressing any new technical challenges, so I tried to keep the design and build time to a minimum.

The Excel magnesium cone woofers require a high-order crossover to suppress the resonances, but I found a nice design at the Troels Gravesen site for these exact same drivers. It uses a whopping 20 components, but I had a large stash of crossover components that I wanted to use up, and this was a worthy cause. I had to unwind a number of coils that I had to get the right values, but it turned out that I only needed to order a few extra resistors and capacitors that came to less than $10 for the lot. I got one of the bare 3-way boards from Parts Express and decided to go all-out ugly with cramming all those parts on the board. I think I nailed the “ugly” pretty good.

PE had some clearance 10″ drivers that were used in some of their subwoofers, and it turned out the 10″ was almost ideal for a smallish (1.7cuft) sealed cabinet. I added a few more crossover parts to make the Troels design a 3-way.

I didn’t want to spent much time making a nice cabinet, so I bought a DJ/PA cabinet with a 12″ woofer from Newark that was on sale for $51. The cabinet is made from low density fiberboard (LDF), which is only several steps up from cardboard in terms of strength and rigidity. But with some generous cross-bracing, I was able to get the cabinet satisfyingly sturdy. I had to fill in the 12″ driver opening with plywood and reinforce the entire front panel with a sheet of plywood but that turned out OK. After cutting out the new 10″ opening, there was plenty of front baffle space for the two Excel drivers. The W17 driver was installed in a 6″ PVC cap stuffed with absorbing material, which worked fine for the 2-pole 250Hz crossover frequency.

I toyed with using a simple QCC3008 Bluetooth module as the primary source but decided to go with a WiFi streamer instead. I had some old WFA28 streamers laying around, but found that Linkplay is selling refurbished Wiim Minis on eBay for $59, so I was able to discard the WFA28’s. I’ve got too many speakers on the 2.4GHz band already, and the Mini can use the 5GHz band, where there are a lot more channels available.

I was thinking about giving this speaker to a neighbor, but after I put on some James Taylor for my wife, she made it clear that we are going to keep this speaker. The Excel drivers are shockingly clear and articulate, and they can absorb that 500W amp without complaining. That 10″ woofer is surprisingly good in this cabinet, and it off-loads the 6.5″ W17 driver so that it can “specialize” in midrange, where it is an amazing speaker.

This is a nice speaker to have for a party or event where you don’t need stereo but want lots of clear high-quality audio. The handles make it easy to move around, and having a potent amp and streamer make it “fun”. Obviously, I failed miserably at clearing out my driver/electronics storage space, as I now have a large party speaker sitting in the same area. But if someone wants to hold a party, we are ready to provide the music.

Update: made a deal with the wife that this will go in her greenhouse, although right now it is in her kitchen area. Since it is not going back in my storage area, it’s more of a success than I thought previously.

Sometimes it’s nice to have a tone or sweep generator or even some white noise to test your speakers. SigmaStudio has a good selection of “sources,” even for the ADAU1701, that don’t require a lot of instructions. I’ve never used them before, but I’m finding them very useful for this next round of active speakers that are starting to take shape. This post describes how those built-in test tools are implemented.

The ADAU1466/SSM3582 boards from the ElectrACC Store at AliExpress have quite a few inputs, but I’m only interested in the Bluetooth, SPDIF and analog sources. Once I got all that basic switching straightened out, I added a “Test” button and a new screen to control the sources:

This feature requires some new SigmaStudio “code” for the sources, along with the code that controls the switching. Here is the new section of SigmaStudio code:

The Mute is just an extra white noise generator that is turned off, and the VCO uses the potentiometer on the ADAU1466/SSM3582 board to control the oscillator frequency.

The ESP32C3 code to control the new blocks is fairly easy to write, as it only requires 3 new commands that reuse a lot of existing code. The new commands are: ADAU1466_Source, ADAU1466_Sine, and ADAU1466_Sweep. The VCO and white noise sources don’t require any software control, so they only need to be selected, without any other CPU control. I’m still working on the Sweep code to get a good combination of range, step size and sweep speed, but it’s coming along. These built-in test sources will be a nice feature to incorporate in all future active speaker designs.

On another topic, I had made a throw-away desktop speaker for testing the dipole compensation, using some cheap $1.29 drivers from MPJA. I’ve had to replace all the drivers because those SSM3582 amps have enough power to completely fry the voice coils when the volume is accidently turned up too high. Even though those amps aren’t rated for high output at 8 ohms, I think they will do fine for desktop speakers or the very efficient Martha speakers.

Overall, I’m still impressed with those ADAU1466/SSM3582 boards. For $120 shipped you get a nice ADAU1452/ADAU1466 DSP, plus Bluetooth and analog input that uses a “decent” PCM1808 ADC chip. You also get SPDIF I/O and 8 very high-quality power amps that can provide moderate power at 4 Ohms. With 2 Ohm loads and a 16V supply, they are rated at 50W each. If you can figure out what to do with all of those amps, these boards can be a lot of fun. These boards are an excellent “deal” for the price.

I think that most speaker builders start thinking about their next projects well before the current one is finished. Sometimes that feels like an attention-deficit problem, but the truth is that it is just a healthy part of the creative process.

While plodding along with the ADAU1466 code for the Marthas, it struck me that those 8-channel SSM3582/ADAU1466 boards could make a very nice desktop amplifier for an active speaker. And since the new code includes support for multi-way dipoles, why not try a desktop dipole? I’m still working on finishing up the Marthas, but I’ve been spending a lot of time thinking about these desktop dipoles.

The 8-channel amp boards are only $115, and that buys you 8 channels of high- quality amplification, plus the ADAU1452 DSP plus SPDIF input, Bluetooth, and decent quality analog input (using the PCM1808 chip). That’s a great start for relatively small investment. The amps on the board aren’t powerful enough for filling a room with sound, especially for a dipole, but they are potent enough for near field listening while sitting at a desk. I’m confident that there is plenty of power for the tweeter, upper midrange and mid-woofer drivers. Fortunately, there are pads on the board that make the I2S signals available for each channel, so it won’t be too hard to add a higher-powered amp for the woofer/subwoofer. I hacked a cheap SPDIF-to-analog board for the subwoofer channel for the Marthas, and the same trick could be used for the woofer channel of these desktop dipoles.

Another reason I’ve been mulling over this new project is that I’ve got some very nice white oak from a tree that we had to take down because it was sending roots into our septic system. So, the project name will probably be the “Antiseptics” or some other reference to that tree. I cut up some nice 22″ log sections for firewood, and I think it will be possible to use some of those pieces to make the baffle.

The baffle will be modeled on the top section of the Linkwitz LX521. The log sections are about 11″ in diameter, and I’d like to make the baffle and stand out of just one piece of wood. My band saw isn’t big enough to slice down the log, so I would need to rough-cut the baffle/stand using a chain saw. And I don’t have access to a large jointer, so I would need to make a router sled to get a reasonably flat face for the baffle. But if I could make those tools work, I think the result would be stunning. I’m probably going to start on these soon, because it is going to take a while for this wood to dry after those rough cuts.

The “Return of the Marthas” is starting to take shape, but it is taking a long time to tailor the existing software. The Marthas take the 3-way Arduino/Android code and make it 5-way, while upgrading from the AUDA1701 to the ADAU1466. Those changes haven’t been a huge technical hurdle, but there are so many tedious details that make the effort a real slog.

The crossover code works, which is a good start. Tapping the buttons on the Android app advances to the next crossover type or the next frequency in the list, and long pressing will return to the previous value in the list. The buttons send out the command codes that are documented in this draft PowerPoint briefing. The Arduino code determines the required filter types and calculates the biquad coefficients, and then puts that data into the ADAU1466 Parameter RAM. All of that code seems to be working properly.

The Android commands are sent using Bluetooth BLE messages. However, the commands can also be sent using MQTT over WiFi. The Android screenshot below shows a quickly implemented interface using the Arduino Cloud tool, with a “Messenger” widget. The command code for a crossover is “F”, and the command “F0704” sets the frequency of the Subwoofer-Woofer crossover to the 4th value in the table, which is 200Hz. Obviously, sending these codes using a messenger widget is not an elegant way to control the DSP, but it works fine for testing. The Arduino IOT code runs on a PC, but the IOT tools can generate an Android or iOS app that mimics the PC layout. So, we finally have a simple path to control high-level DSP functions from an iPhone.

The ESP32 does not allow using Bluetooth and WiFi simultaneously because there is only one RF channel. However, the CPU can receive data on either Bluetooth and WiFi, and as long as you don’t use Bluetooth and MQTT at the same time, it doesn’t get confused. That is, the code can monitor IOT messages and listen for Bluetooth commands, and it will respond to commands from either source.

Next up will be the EQ. I’m switching from a 9-band EQ to 10-band, as 10 bands seems to be more common, and the frequency spacing is a bit more “intuitive”. All of the frequencies and labels and command codes will get changed, both in the Arduino code and the Android app. Again, it won’t be hard, but there is a surprising number of time-consuming edits even for this seemingly simple change.

It’s a slow train, but at least it’s moving.

Finally, some progress with the ADAU1466…

There are quite a few software 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…