Really?
Sure. If you read the article on the Arduino software, you would see that the “input” to the code controlling the ADAU1701 is just simple string messages. And by adding a $5 “HC06” Bluetooth interface board, these strings can come from a cell phone, tablet or PC app that hosts the user interface.
Unfortunately, I’m not an Android or IOS programmer, and I wasn’t in the mood to climb those learning curves just to implement a relatively simple Android application. However, there is an development tool called App Inventor that has enough capability to implement the simple controls I needed for the DSP. App Inventor was originally developed by Google and is now sponsored and maintained by MIT. It was targeted for smart high school students, and it uses simple forms and graphical blocks that implement the code. I was a fairly good high school student, so this development tool looked promising. Next spring (2018) there is supposed to be an IOS version that will use the same “code” and target either Android or iPhones.
This article describes the Android app, provides all of the links needed to download the app, and describes how a programmer with Android or IOS expertise could easily build their own professional-looking cell phone app. There’s not a lot of code in this app, and the code is mostly relatively simple event handlers to send out strings when buttons are pushed.
This article also includes a short tutorial on using this application to “tweak” some active speakers. The author hopes that someone else will provide a more detailed tutorial that starts with driver and baffle measurements and walks the designer through the fun process of configuring the DSP from a cell phone.
The “Screens”
The user interface mimics the interface using the Nextion LCD display. There are 6 pages, or screens, that group related functions. Each of those screens is described in the next section.
Home
The Home screen has the main volume control, a mute button, and button to initiate the Bluetooth connection. It also has some buttons to save two interface settings, although these are not fully implemented. Right now the A and B buttons select between two sets of interface settings, but the actual data doesn’t get updated instantly–it only gets updated when the associated screen is displayed. I want to change this to a “quick A/B” feature that will load the stored Parameter RAM data instantly, but I need to make sure there is enough EEPROM space in the micro to do this.
At the bottom of the Home screen are the navigation buttons that bring up the other screens in the user interface.
Volume and Delay
The Volume and Delay screen provides up to 10dB attenuation for each of the three stereo channels (Tweeter, Woofer and Sub). The Nextion display allows setting the volume levels for the left and right speakers individually, but I wanted to save some space on the cell phone app, so the left and right channels are paired. This screen also has the delay for the woofer and tweeter to adjust the “z-offset” for tweaking the crossover. The delay is in increments of about .5 inches, corresponding to the 48KHz sample rate.
There are 11 volume levels (1dB increments) and 12 delay levels (from .28″ to 6″). Tapping the button advances to the next value in a look-up table in the Arduino code. However, if you do a “long-click”, it will go to the previous value in the table. When the end of the table is reached, the interface wraps-around to the first entry in the table. The wrap-around and ability to go back and forth makes this button-driven interface reasonably easy to use.
The main volume control is available on all of the screens.
Crossover
Here’s one of the exciting features: the crossover. There are 6 crossover types (None, B-W 1, B-W 3, L-R 2, L-R 4, L-R 8), and 7 frequencies for the Woofer-Tweeter crossover (1200, 1600, 2000, 2400, 2800, 3200, 3600). If you need a bigger selection, just change the tables in the Arduino code to have as many selections as you like. This cell phone app doesn’t know how many options there are or what they are–it just selects either the next or the previous value in the table and it displays the strings that it gets from the Arduino code.
The filter coefficient calculations for the crossover are done in the Arduino, and they are “almost” instantaneous, even for the 8-pole Linkwitz-Riley crossover. There was an earlier version of the 3-way DSP board that used an 8-bit micro to do the floating point math for the bilinear transform that resulted in a noticeable delay. However, the 32-bit processor on the teensy3.2 board updates the biquad coefficients in near-real-time.
Each of the crossovers also includes a “polarity switch” to compensate for the phase shifts of the higher order filters.
This screen also includes the baffle step compensation filter. This filter is a implemented as a single-pole shelf filter. There are 8 BSC frequencies ranging from 300Hz to 1KHz, and 7 gain settings from 0dB to +6dB.
Bass Enhancement
There are 3 types of bass enhancement available in the DSP configuration for this project. First, there is the conventional “Rumble” filter that you would find on just about any subwoofer plate amp. This is implemented as a two-pole high pass filter, where the “Q” can be adjusted to provide a boost at the cutoff frequency. There are 6 Q values and 9 frequencies to choose from, and again, these values can be easily changed in the Arduino code.
The second type of bass enhancement is a peaking filter that can be placed at any of those same frequencies, with a gain ranging from 0 to 6. This filter emulates the boost filter that is used in the Yung plate amps. The “Mode” control allows using this filter along with the Rumble filter, or separately.
The final bass enhancement mode uses the Analog Devices SuperBass algorithm. This algorithm is a psychoacoustic bass enhancement effect that works a lot better than you might expect, by adding harmonics of the dominant bass frequency to give the “impression” of deep bass without excessive cone movement. It’s a cool feature to have, especially for applications using smaller bass drivers.
This feature also highlights the benefit of using a local user interface and real-time control of the ADAU1701. The user can quickly evaluate the SuperBass algorithm and turn it on or off for different types of music as needed. However, if you are only using SigmaStudio with a programming board, this evaluation process is clumsy and frustrating.
EQ
The DSP load includes a nine-band equalizer, with gain settings ranging from -10dB to +10db in 2dB increments. This is fun to use, and it can compensate for room effects or can be part of the final crossover tweaking.
Custom Filters
Hmm–this screen is interesting, and it turns out to be extremely useful for tweaking loudspeaker designs. In addition to the crossover, BSC and EQ filters, there are two “extra” shared filters that affect the entire response. Also, there is an “extra” stereo filter for each of the three channels: Tweeter, Woofer and Sub. Each of these filters can be any one of 11 types: One_Pole_LP, One_Pole_HP, Two_Pole_LP, Two_Pole_HP, LP_Shelf, HP_Shelf, Bandpass, Notch, Peaking, All_Pass, or None.
Also, these filters can be set a lot of different frequency values. The shared filters have 87 different frequencies to choose from, and there are about 45 tweeter and woofer frequency options. The large number of frequency options makes selection of the filters a big cumbersome, but it also allows fine-tuning the DSP to achieve whatever response the designer needs.
The screenshot below shows randomly selected filter types and some of the available options. This screen does not show a useful combination of filter parameters–it’s just for illustration. This screen is where a detailed tutorial would be helpful, to show how the skilled designer can achieve those final tweaks that make the speaker response more satisfying.
The “Code”
App Inventor uses graphical blocks that “snap” together to implement the functionality. Here’s a small sample that changes the Rumble Filter frequency. The blocks on the left invoke the Bluetooth client to send a text string when the user clicks that button. The text string is described in Article 12 in the Arduino software overview. The “K” code is the Bass Enhancement group of functions; “00” is the Rumble Filter frequency sub-function, and “FF” is the value that moves forward in the HCI table. The blocks on the right are for the long click. The first two fields are the same, but the value of “FE” results in selecting the previous value from the table. As you can imagine, there are a lot of these blocks to respond to all of the buttons in the user interface.
Unfortunately, a lot of the blocks end up working around the limitations of the App Inventor development environment. For example, App Inventor supports multiple screens. However, whenever you change screens, it disconnects any Bluetooth sessions associated with that screen, so I wasn’t able to take advantage of the multiple screen capability built into App Inventor. Instead, I had to use “virtual” screens, which are implemented by turning on and off various tables and buttons. Stupidly enough, about 1/4 of the blocks in the app are dedicated to this virtual screen functionality.
Another deficiency of the App Inventor environment is limited control over the serial data transfers. One of the most difficult problems to debug was when the App Inventor code was overrunning the input buffer of the Bluetooth adapter on the DSP board. The only way I was able to fix this was to use semaphores in the “clock” loop that sent the data in small “chunks” and waited until they were processed. As you can imagine, the blocks for this work-around are not at all intuitive. I had the same problem for processing the responses from the Arduino for each command–I couldn’t just wait for a specific response from the Arduino, or else the app would stop working. So all of the responses from the Arduino are handled in the “clock” loop.
One of the advanced features of the App Inventor that came in handy was the tinydB database that implements local storage for the slider data. I never figured out how to update the slider position from the Arduino without causing another event from the slider. I know a simple way to get around this problem in Visual Studio (check for focus), but I got stumped using slider controls in App Inventor. So I saved the state of the slider position in the tinydB database, and used that data to position the slider. That’s the only local storage in the mobile app–just to “jump start” the slider position for the master volume and EQ sliders. Using the tinydB database makes the code look unnecessarily complex, but maybe there is a better way to initialize those sliders.
But even with those quirks, the App Inventor did a reasonably good job of making a useful user interface for the DSP board, and the coding went quickly. It doesn’t look very professional, but it gets the job done. And all of the information needed to re-implement the design with more advanced tools is in those blocks–it shouldn’t take someone with Android or IOS programming skills much effort to convert this design.
Downloading and Installing the App
There are two ways to download the user interface into your phone. The app is currently in the Google Playstore as a Beta release, but it will be released in the next few days. Just download it like any other app. You won’t be able to control an ADAU1701 DSP board unless you have one of those, but I’m working on getting some more of those built :). You should be able to look at the various screens without the Bluetooth connection, but none of the buttons will do anything useful, and the data displayed on the buttons will just be the default text.
But the better way to download the code into your phone is to use the App Inventor tool. You have to use Chrome for this tool to work. Go to this URL: http://ai2.appinventor.mit.edu and once you see the opening screen, select “Gallery” from the menu. Search for audiodevelopersdsp. Then load that project and you will be able to see the designer and the code blocks. Select “build” from the menu and select the QR code option. When the QR code finally appears (it may take a minute or two), take a picture of it and follow the link. Download the code, allow it to install, and then run it. Not only will you have the code installed on your phone, you will have the source data to play with in your browser. You can change colors, move things around, add dirty pictures for the background, or make whatever customizations you desire.
There are no restrictions on using this code, so feel free to modify it and publish it under your own name with or without attribution. In fact, I would really like to see someone make a more professional looking version of this software using the native Android, IOS or Visual Studio (Xamarin) tools. Make sure you read article 12 (Arduino Code Overview), as there are tables that list all of the strings used in the serial interface, and the article also describes the data that is sent in response to the command strings. This information is up-to-date as of 12/15/2017.
2019 Updates
There are two major developments since this article was written. First, there is now a “native” Android app written using Android Studio that is much more robust and nicer looking. It also supports WiFi control rather than just Bluetooth, which has some important impacts. Second, the App Inventor team has entered the iOS compiler into beta development, so in a couple of months, this controller code should be available for iPhones. These new developments are described in the following paragraphs.
The App Inventor program described in this article had some “issues” with the online compiler around update 162 or so, where they introduced two methods for building the code. The new method was required for publishing code at the Playstore, but it also required the use of some newer controls that didn’t fit on all screens. So if I wanted to publish this code, I was going to have to make extensive revisions to the user interface to move things around and resize the controls. That looked daunting, so I started to re-write the Android app using Android Studio. However, in recent months the App Inventor team found ways to make the older controls compatible with Playstore requirements, and the original design compiles just as it did before. So what is in the Playstore–including all of the source code–still works.
In the meantime, the App Inventor iOS program has matured to where it is now in beta testing. The Blog of Feb 15, 2019 indicates that the iOS tools will likely be available in the summer of 2019. So the App Inventor code described in this article should also work on those Apple devices. The code in the microprocessor for the DSP was also updated so that it is “buffer-oriented” rather than “character-oriented”, and those improvements should ensure that the iOS code works with the DSP in the same way as the Android code.
The “native” Android app is much nicer. It uses the Navigation View component to partition the code into pages, with a Bluetooth Service that is accessible from all pages. There are even some graphs that display the response for the crossover and Bass Enhancement modules:
But the most interesting update for the native Android version is the transition to WiFi control of the DSP, using the MQTT IOT protocol. Most of this code has been tested, but it will require re-hosting the DSP control code on a ESP32 micro instead of the teensy3.2. That transition will happen in the next hardware iteration for the DSP board. The WiFi version will allow channel pairing and remote operations that can’t be done easily with the Bluetooth interface. This version will also allow reducing the hardware cost of the DSP board.