8. Case study #1: a small subwoofer

Some Background on this project

At the end of 2016, Parts Express (PE) announced a call for members of their 2017 Speaker Builder Design Team (SBDT).  The SBDT members were required to develop at least three designs ranging in complexity from “easy”, using pre-assembled cabinets, to “unlimited”, where there were no design restrictions, and the members had to provide write-ups on their designs that were suitable for the PE Project Gallery.  In exchange, PE provided funding for up to $300 for each design, partial funding over that threshold, plus additional PE credits.  It was a good deal, so I became a member of the team.

The Audiodevelopers Reborn website grew out of that SBDT effort, as it quickly became clear that the projects I proposed for the SBDT were too involved to be adequately described in the PE Project Gallery.  So most of the case studies on this site started out as PE SBDT projects, and the other articles provided the background needed to understand the microprocessor code, DSP design, networking issues and user interface details.

My original approach for the SBDT projects was to develop a set of designs that led to an active WiFi system like the Sonos/Heos/Homepod/etc speakers.  Sonos calls their speakers the “Play” series, so I outlined a series of 4 designs called “acts” that resulted in my version of the “Play”.  That’s why my SBDT projects were proposed as a “play with 4 acts”.  Act 1 is the subwoofer that started this series.

Since the SBDT projects were suppose to start with a design using a pre-assembled cabinet, I selected the 1 cuft Dayton Audio B-REX removable/replaceable baffle enclosure as the “chassis”.  The initial design submitted for the PE Project Gallery used a 100W Yung plate amp.  That writeup is at this link:  Act 1 write-up.  The PE write-up references some optional modifications to the plate amp that are described in another page on this website in the Projects section.

The Act 2 project submitted to PE described a DSP-based replacement for the Yung amp.  Some additional details are provided for this  6-channel plate amp in case study #2 (Article 8).  This case study also describes the satellite speakers that were written up in the PE Act 3 project.  This case study was originally supposed to be the Act 4 project, using DSP processing to replace the Yung amplifier bass boost features and extending the bass response using an Analog Devices bass enhancement algorithm.  However, there were still lots of “gaps” in the design, as there was a lot of software involved that wasn’t very well explained, and there weren’t any instructions on how to download the code into the plate amp.  Also, it was taking longer than I expected to finish the code for the Bass Enhancement algorithm.  So the PE Act 4 project instead became a write-up on the software, and the DSP-based subwoofer was proposed as a “Curtain-Call” project.

Unfortunately, the Act 4 write-up didn’t fit well in the PE Project Gallery template, and PE elected not to publish the write-up.  As a result, the software write-up got its own page here on Audiodevelopers:  it is Article 12.  And the Bass Enhancement software is now working.  So although the order got disrupted we can finally finish off this play in this case study.  Case Study #1 is actually the last design effort in this project, but it’s too hard to rearrange all of these pages, so please just ignore the #1 in the title.

Overview

The figure below shows the completed system at a high level.  As already noted, this is a 1 cuft box with a plate amp on the back with the electronics.  There is a Nextion touchscreen LCD display mounted on the front panel for controlling the DSP parameters, but you can also use a cell phone app to control the DSP with the Bluetooth interface.  The primary path for audio is the antenna that connects to your wireless network.  The subwoofer includes a pair of 5-1/4″ long-throw subwoofer drivers, each powered by a separate amp.  There are two Speakon connectors on the back panel that allow connecting the speakers of your choice.  Since we want to be able to connect different speakers to this subwoofer, the software includes the ability to set up two different DSP settings that can be recalled from EEPROM memory.  The DSP settings are described in Article #12.

Those two W5-1138 woofers and 1 cuft cabinet are fine for computer speakers or small rooms, however, the response drops off rather quickly below 60Hz unless some bass boost is applied.  The article on the Yung Plate Amp Mods shows that a 6db boost at 35Hz extends the response nicely down to 30Hz with a flat response.  Although there is not an enormous amount of bass due to the smallish cone size, what’s there is natural sounding and very effective at filling in for small satellite speakers on the desktop.  So we need to make sure this bass boost is available in the replacement for the Yung amp.  We will also look at another approach for enhancing the bass response in a following section.

Bass Boost

Since the Act 1 subwoofer provided bass boost with both a rumble filter and an MFBP peaking filter, our updated version with the 6-channel plate amp will need to provide the same filtering capability.  But we will also add an additional algorithm for enhancing the bass, using the Analog Devices SuperBass algorithm for the ADAU1701 DSP.

The rumble and peaking filters are easily implemented using existing code modules developed previously for this project.  The rumble filter is simply a two-pole high pass filter with variable Q.  With Q values over .71, the rumble filter provides some boost, and this is how most plate amps provide boost:  with a rumble filter using a Q between 1.5 and 2.  The high Q results in some peaking, to boost the bass response at the filter cutoff frequency by about 4 to 6 dB.  To implement this filter, we simply need to allocate a shared biquad and specify a high pass filter with a gain of 1 and a frequency and Q selected by the user interface.  The code to implement a high pass filter at 30 Hz with a Q of 1.5 is listed below:

filter.Freq_center = 30.0;
filter.Q = 1.5;
filter.Gain = 1;
if (BE.Rumble_filter_enabled == true) filter.filter_type = Two_Pole_HP;
else filter.filter_type = None;
filter.biquad_num = 10; 		//Use biquad #10 (Shared 11)
ADAU1701_mute(true);			//mute so there won't be any popping noises
filter_calc();				//calculate the biquad coefficients
delay(200); 				//allow filter to settle
ADAU1701_mute(false);			//unmute

The code uses a structure called “filter” with those 4 parameters:  Freq_center, Q, Gain, filter_type, and biquad_num, which is an index to a table of addresses for the shared biquads.  After filling in the values in the structure, we mute the DSP and call the filter_calc routine.  The filter_calc routine calculates the biquad coefficients using the bilinear transform equations that are published in the DSP cookbook and many other online locations.  The same routine formats the floating point coefficients into the 28-bit hex format used by the ADAU1701, and it writes the formatted coefficient data to the ADAU1701 Parameter RAM.

The actual code is more complex because we need to get the values from the HCI system, but this simple code illustrates the key concepts.   The peaking filter is implemented using a peaking filter with a fixed Q of 1 and variable gain, and the code is similar to that used for the rumble filter.  There is also a variable that is used to determine whether the rumble, peaking or SuperBass is enabled, and this variable is controlled by a button on the LCD display.  In the picture below, the button is shown in the mode where both the rumble and peaking filter are selected.

It’s worth noting that the HCI system only allows pre-selected frequencies and a limited number of values for the Q and the gain, but that the filter code itself isn’t limited to those values.  That is, the underlying routines to calculate the ADAU1701 parameters allows using any floating point values as input.  The current design uses tables to specify the allowable HCI values and it translates those HCI values to floating point or directly to 28-bit hex values using tables or simple algorithms.  But if the developer can come up with an alternate way of specifying the input, they could use the underlying code to calculate filters at any frequency/Q/gain combination.

Bass Enhancement

SuperBass is a “psychoacoustic” bass enhancement algorithm that creates the impression of low frequency content by adding harmonics of the low frequencies.  According to Analog Devices:  The Superbass block is a bass enhancement algorithm specifically designed to compensate for the poor low end response of small speakers by using psychoacoustic principles to improve the perceived bass response.”  We aren’t going to address how this algorithm works in this article, but a search on “Psychoacoustic Bass Enhancement” will yield some technical articles on this class of algorithm.  This article by Samsung provides some details on how this algorithm is probably implemented in the ADAU1701:  http://cseweb.ucsd.edu/~marora/files/papers/13868.pdf

The SuperBass algorithm is available in the SigmaStudio development tool, and we simply drag that component into our ADAU1701 schematic and connect it to the subwoofer channel.  When we compile the project, the code will appear in the exported files.  We process the compiler output using the ASD tools described in Article #12, and move the generated files to the Arduino folder.  Two files are generated:  the code tables with the Program RAM and Parameter RAM data, and the cell map.  The code tables are used to load the ADAU1701 at reset, and the cell map tells us the location of each biquad and the start of the SuperBass parameters.

The SuperBass algorithm has three parameters:  the cutoff frequency, the intensity of the bass effect, and the gain, which is the amount of bass boost applied below the cutoff frequency.   When the compiler generates the Parameter RAM data, it uses the current settings for these parameters.  In order to use different cutoff frequencies and intensities and gains, we need to build some tables that have the values we want, and we need to map these values to the settings in the HCI.  This takes some time because we need to use SigmaStudio to generate the parameters for all of the settings we have available in our HCI, and then put that data into tables for the Arduino code.  Since each frequency requires 36 bytes of data and we have decided to allow 18 frequencies in the HCI, the parameter table for the frequencies is 36 * 18 = 648 bytes long.  We have no idea what these 36 bytes of data are for, exactly, or how the algorithm generates this data, so our only option is to have SigmaStudio generate the data for each frequency setting, and we copy each set of values into our code.  The intensity and gain parameters are simply values from .1 to 3, and we can either create the data algorithmically or have SigmaStudio generate the values for us, and we put those values in a lookup table.

So whenever we select a different frequency or intensity level for the SuperBass algorithm from the LCD display or cell phone app, the micro looks up the pre-calculated values in the tables and then writes that data to the right location in the parameter RAM.  So when the frequency changes, the micro looks up the right 36 bytes of data and writes that data to sequential locations in the Parameter RAM.  Notice that this approach, using the microprocessor to load and control the ADAU1701,  is much more flexible and convenient than using the EEPROM/self-boot approach.  We don’t need to use SigmaStudio and an EEPROM programmer to test different SuperBass parameters:  we simply specify our selection with the LCD display or cell phone app and the micro does the rest.

Some Observations

First, SuperBass really works as advertised, and there is a lot of potential for this algorithm in many applications. I’ve been playing with different types of music, and it is clear that the algorithm works better with some types of music than others. But for many types of popular music, the effect is very satisfying–it gives the impression of a lot more bass, without any noticeable artifacts.

Second, what’s really impressive is that it “feels” like there is more bass, even though the cone is moving less.  That means that you can combine the SuperBass with “real” bass boost, and achieve a very satisfying bass enhancement, and that there is a lot of potential for getting “acceptable” bass from smaller drivers.

Third, having the parameters adjustable from a user interface is essential for experimenting with the SuperBass algorithm, and combining this feature with bass boost greatly helps the DIY experimenter.   Having this flexibility allows testing many different types of subwoofers with different types of music.  I haven’t had a chance to do as much testing as I would like to, but it is clear that there are many combinations of bass enhancement and boost and music types and volume settings to explore.  And having a nice user interface is going to make that discovery effort a lot of fun rather than drudgery.

Fourth, the SuperBass algorithm is “big”, as it takes up a lot of the processing resources in the ADAU1701 (it’s over 400 words of program data, out of a total of 1024).  After adding this algorithm, I had to pare back some of the biquads in the SigmaStudio design so that the compiled program would “fit” in the program memory.  The ADAU1701 program does just about everything I would like it to, but there is no additional program memory to add limiters or other features.

Conclusion

With the bass boost and enhancement features, our subwoofer now provides all of the features of a conventional subwoofer plate amp, plus has a potent stereo 3-way active crossover with individual amps for external woofers and tweeters.  It also has a 9-band equalizer plus some additional filters to tweak the response for just about any speakers we would want to use.  Plus we have WiFi audio, Internet radio, music collection playback, and multi-room routing.  We’ve got a DIY version of a high-end stereo Sonos Play system, but with more output and potentially better quality drivers.   So there is a lot here to enjoy.

Of course, good things like this usually aren’t free.  The project required many hundreds of hours of engineering time and even the construction was time consuming.  Also, this was not a low-cost design–it’s one of those projects where you don’t want to think about how much you’ve spent along the way.  But now that a prototype is done, with software that is mostly working, we can start looking ahead at how to use all of this code to build potent cost-effective active speakers that can be built quickly.

There is still one more article that is needed before we wrap up this project, and that will address how to “tune” the speakers using measurement tools and the provided software.  That article will be coming soon.