Every once in a while I look at the web statistics for this site to see what pages are most popular, and I’m surprised at how many hits there are for this article. A lot of the other pages are referenced in posts on the PE board or diyAudio, and I understand when there are hits for those pages. But this page was never referenced anywhere else, so it appears that there is some real interest in this topic. However, I left this article blank for the last few years, as I had stopped work on the Active Speaker Design (ASD) program when it became clear that it needed to move in a different direction. I don’t have a replacement for ASD yet, but I have a clearer idea how it needs to evolve, and that is what this article is about.
BTW, ASD has only been released “informally”, as a way of getting feedback to improve the product. There has never been a released version, although you can download an archived version of the tool at www.audiodevelopers.com/Software/ASD/setup.exe.
ASD History
Active Speaker Designer started out as an Excel Visual Basic macro program application back in 2006 or so, as a way of modeling the TAS3004 and STA328 DSP’s. I needed a program to go from a target response, such as a 2-way 4th order crossover at a specific frequency, to the register-level coefficient data that these chips required to implement that response. TI had the very cool Automatic Loudspeaker Equalization (ALE) program for the TAS3004 that generated the coefficients, and they offered a proprietary “paddle board” for the printer port that could be used to program the EEPROM that held the DSP code. I started to write a variant of ALE using an Excel spreadsheet and Visual Basic macros. I could generate the coefficient data and even program the EEPROM from Excel using FTDI USB serial drivers. The Excel program could even open up “FRD” response files, and it allowed the user to tweak the crossovers to get achieve a target response and then program the DSP. The DSP board required a microprocessor on the board to receive the USB data and format it. The spreadsheet approach was “clunky”, but it worked.
Around 2008 I started to re-write the Excel program using .NET, which at the time still didn’t have a built-in charting program or even a complex math library. But I purchased a charting program for .NET and adapted a complex math library available online and started to redo that Excel code using VB.NET, which was rapidly evolving to be a credible programming language. I developed the code for programming the TAS3004, and then added functionality to program the STA328 chip, which I was using for some small 2.1 amplifier/DSP boards. It was relatively easy to add a completely different DSP, even though hardware was totally different, as all of the differences were isolated to a single file that took care of formatting the data and loading the device. So initially, the program was designed to be “DSP agnostic” and accommodate a wide range of DSP’s from different vendors.
As I started to flesh out the program and add features, it became clear that VB.NET was a very capable platform for interacting with the hardware and that the program could expand in many directions. I began to think about how the program could become a full-featured speaker design program, with tools for modeling the enclosure and baffle diffraction, and that tracked the workflow for active speaker design. Here is an early snapshot of the top-level form that shows the overall functionality plus the approach to workflow-tracking (the checkboxes):
A major milestone in ASD development was the addition of the Woofer Box model, which was an adaptation of Jeff Bagby’s Woofer Box and Circuit Designer (WBCD). This started out as a collaborative effort of several members on the Parts Express message board who shared an interest in transitioning the WBCD program from Excel to .NET. Unfortunately, collaborative software efforts rarely accomplish much until one person decides to do all the work, so I sat down with many pieces of paper trying to document the “program flow” in Jeff’s Excel program. Unfortunately, there is no easy way to convert from an Excel spreadsheet with macros to a real programming language, and the final result was essentially a compete re-write, and it would have been much easier to go directly from the equations in the Benson textbook to a new program. When it came time to implement a baffle response model, I didn’t use Jeff’s Response Modeler–I implemented a completely new program and wrote the ray-tracing equations “from scratch”.
The current ASD program opening menu is shown below:
All of the modules except the Room/Car module work , and the program supports boards with the ADAU1701 chip along with the STA328, STA309a, and the now obsolete TAS3004. There are some unfinished issues with making the program work properly with up to six channels of DSP, as a couple of the original modules were designed to support only three channels. But with some additional work, this program could provide a complete math model of the driver, cabinet, DSP and amps to accurately predict the response and to control the DSP in real time. That is, as the modeled response is updated on the PC screen, the formatted data is sent across the USB interface to the target device. All of the control is in real time: as the user changes the Crossover or EQ or volume level, the DSP and associated devices are updated immediately.
ASD Becomes Unnecessary (?)
What sets ASD apart is the real time control of the DSP hardware. The modules labeled “Amps” and “Amp/DSP Control” and “DSP” provide a standard way of modeling just about any DSP board and its unique hardware. The output of the Amp/DSP module is low-level “register data” that is formatted into a serial stream and sent across a USB interface, and then converted back to binary data in the DSP board. The USB communication is “transparent”, in that the code in the Amp/DSP modules writes to addresses on the I2C bus as though there was no serial link between the PC and the DSP board. Similarly, the ASD DSP module calculates the coefficient data for the biquads and sends the data via the USB port to memory locations on the DSP board.
My original concept for the DSP boards for active speakers was to use a relatively simple microprocessor to provide that USB interface and the translation from USB serial data to chip-level communications. And for that paradigm, the ASD program as originally conceived was essential. ASD provided all of the “smarts” to do the bilinear transform to calculate biquad coefficients and “knew” which registers got written to for volume or other changes. There were just a few command types. The “A” command set the chip I2C address, and the “M” command specified the register location and the number of bytes and the data to be written to that register.
However, as the microprocessors became more powerful, I started to put more of the smarts into the DSP board. Now, I send a high-level command like the “F” command (for a filter), which defines the type of filter and its parameters. The microprocessor then decodes that command and performs the math for the bilinear transform to calculate the biquad coefficients. The microprocessor then formats the coefficient data and writes it to the right I2C addresses or registers. So instead of the PC doing the heavy-lifting, with knowledge of register addresses and coefficient calculations and number formats, all of that detailed chip-specific work is done in the microprocessor on the DSP board.
The benefit of using this higher-level interface is that I can control the DSP from a cell phone or tablet without using a PC running ASD. I’ve changed the USB interface to Bluetooth and/or WiFi, using the MQTT protocol. That’s a nice step forward for those hooked on their portable devices. But the down side of this change is that I no longer have a way to model the overall system. But I’m not convinced anyone really needs to model the drivers, cabinet, DSP and amps all in one application, as you can achieve the same end by modeling the cabinet components separately and by working interactively with measurement equipment with the finished cabinet. Since the DSP is so easily tweaked in real time, the need to model the entire system on the PC pretty much goes away.
I still might continue ASD in some form, but it has become a large and complex program, and I am becoming less inclined to work on it. It shares most of its components with two other programs, the Passive Speaker Designer (PSD), and a somewhat simpler version, PSD-Lite. PSD and PSD-Lite have similar functionality as ASD except the DSP modules are replaced by a module that allows passive crossover design. Maintaining that commonality across multiple programs seems like a good idea, but that commonality makes changes more difficult, as any modifications in the shared components need to be tested in all of the programs.
The Future of ASD
All of the DSP boards I’ve made can still be programmed using the low-level interface, but eventually this low-level interface will go away. At that point, ASD will need to support the higher level commands that are documented in the article on the Arduino Code Overview. This change will have a significant impact on ASD, and currently I have no plans to make those changes. ASD is a formidable amount of software, and as already noted, maintaining the code for other variants can be tedious. Also, it relies on what is now an obsolete database–the Microsoft “Compact Edition” SQL database for T-S data (the Thiele-Small driver parameters). The same database is used in the Passive Speaker Designer to keep track of passive components such as inductors, capacitors and resistors, so updating the database will be a significant effort. As a result, I’m not sure that I want to continue supporting these programs in their current form.
However, there are some new applications for this code that I find exciting. One of those is a “small speaker optimizer” that determines the optimal filters needed to extend the low frequencies for small sealed or passive radiator systems such as those found in modern commercial WiFi speakers. For a fixed amplifier size and desired output, the optimizer finds the best combination of low frequency filters to achieve extended response in a small cabinet. A prototype of the optimizer has been developed, but a lot more refinement is needed. A new project is underway that will use this optimizer–it is a 3-way monitor stand for a computer, with 2 very small subwoofers (2-1/2″) and two passive radiators.
This optimizer module will try out a different approach for the T-S Database, as it will simply allow the user to copy and paste the data from www.loudspeakerdatabase.com. The ASD T-S database was built from the PE selection guide, the defunct www.thiele-small.com database and the MCM product pages. While it was a good resource at one time, the ASD database has become obsolete, and it is time for a different approach.
Another direction for ASD is to make some of the DSP tools available as separate programs. For example, ASD provides tools to import the system files from SigmaStudio and output the cell information and the ADAU1701 program from a given SigmaStudio design. That tool as a stand-alone program would greatly facilitate the code development for the microprocessor on the DSP, as that microprocessor needs to know the addresses of the processing blocks or cells, and it needs to load the DSP with code at power-on and reset. It would be nice to have a version of this program that works with either SigmaStudio (Analog Devices) or TI’s PurePath studio, so that DSP devices from either vendor would be supported. Right now, the only way to generate the Arduino code referenced in these pages is to use the tools in ASD.
I’ve put a lot of time into development of the ASD/PSD/PSD-Lite tools, and I don’t like the idea of “walking away” from this work. But there are still other ways that the ASD code can be adapted for new uses, and I’m sure that this work will find new life in some other form in the future.
Last updated: Sept 15, 2019