This page describes how to design the Android app to control the DSP, and it outlines other methods for controlling the DSP. It doesn’t discuss all of the details of the Android app, because that app is due for a major upgrade and the current build package is not an appropriate foundation for a new implementation. However, the screen layouts could still be used as a good model and there is a lot of reusable code that could be lifted from the existing Java modules.
Android Software
The zipped file of the Java source is at this link. The zipped file of the layouts is at this link. This code was originally written in Java for Android 4, back in the “Ice Cream Sandwich” days. Although the code has been modified many times and it still works fine on my Android 16 Pixel 8 and on the Samsung A14 phone, it hasn’t been tested on any other devices. There are many warnings from the compiler about violations of current programming conventions, and way too many overrides to get around the current Bluetooth security issues. There are better foundations for updating this code, so this section is only going to show the screen captures from a working app and leave the task of building a new app to the reader. The zipped file of Java sources contains all of the code, so there is plenty of proven logic that can be reworked into a new app.
If you really want to try this app, you can download the APK file at this link. It’s not signed or available on Playstore, but you can download the APK file and use the developer mode to create a debug key. Once you install and run the app, you will need to pair with the Bluetooth server (in the line array) using your phone’s settings. Then, add the permissions to the app manually, as the code currently doesn’t support the Bluetooth scan and permissions dialogues. Once the Bluetooth pairing and bonding is complete, you should be able to connect to the server running on the ESP32. You only need to go these steps once, as the app will work fine after bonding and setting the permissions.
Update, 2/20/2026: I tried opening up the Android app on a fresh install of Android Studio (Panda 1) on another computer. After some thrashing to update Gradle and sync the files, the code worked fine and I was able to install it on a different phone. I used the zipped files at this link. You can usually buy a decent prepaid phone like the Samsung A14 or A15 at Walmart for $40-$50, so this is a viable way to have a dedicated Bluetooth remote control for your line array project.
Using the App
As noted in the section on the Arduino software, the state of the DSP is saved by the Arduino MCU, so when the Android app is first invoked, it doesn’t know what information to display for each menu item. For example, the snippets below show what the Volume Trim and Delay page looks like both before and after the app connects via Bluetooth. Instead of the placeholder “BUTTON”, the fields are populated with the values received from the MCU. So, the first step in using the app is to connect to the Arduino via Bluetooth. As show below, there is a Bluetooth option in the Navigation Drawer, and you will need to select the right device from the menu that pops up. Once the connection is established, the “Connect” button will turn green and the returned values from the Arduino will start showing up. As noted previously, the Bluetooth bonding and permissions are not currently controlled programmatically. I expect the Bluetooth connection sequence to get updated someday in the future, but it is not high on my own priority list at this time.
Main Menu
The menu items on the main page include the main volume and the Input. The main activity uses the Navigation Drawer to hide the submenus. The right side of the image below is the screenshot of the expanded menu.
Vol/Delay and Crossover
This line array design is configured as a 3-way system, so the Channel Volume/Delay and Crossover pages are somewhat sparse. These layouts were derived from a 5-way ADAU1466 design which had a lot more information on the page.
Curvature and Speaker Select
The curvature page takes advantage of the Android drawing capabilities. It uses the values returned from the Arduino MCU to paint different sized dots on the screen. The Speaker Select menu items allow testing each driver in the array individually or in groups.
Bass Enhancement and DSP-generated Signals
The Bass Enhancement menu items allow selecting different peaking and rumble filters to emulate the response of many plate amps. For the ADAU1701 DSP designs, this menu also allowed selecting the Analog Devices Super Bass (or Phat Bass) algorithm, along with the Dynamic Bass algorithm. This menu page hasn’t been updated for the ADAU1466-based line array design, so the screenshot is from a different Android app. The screenshot on the right is for controlling the Signal Sources that are available in SigmaStudio. These sources were described in this post.
EQ and Custom Filters
The 10-band Equalizer is a simple design that works fine but should eventually be updated using the Android drawing capability. The Custom Filters allow selecting any common filter type and there are many menu items for each parameter to choose from. For example, there are 43 frequencies that the user can pick from for tailoring the tweeter response. The Custom Filters screenshot is actually from another project that is a 5-way design, as I haven’t yet implemented the 3-way line array version.
Other HCI Software (IoT)
As should be evident by now, it is fairly easy to build an HCI device for the Arduino MCU. You simply need to send the serial commands specified here, either via Bluetooth BLE or a simple terminal emulation program. In some of the very early active speaker designs, I even used Excel and Visual Basic code with an FTDI driver on the PC to send out the serial data. I have also used some free Bluetooth BLE/UART apps on the cell phone to send those serial commands. And, of course, you can send those commands using the serial monitor in the Arduino IDE.
A more interesting approach to controlling the DSP is using a WiFi connection with an “Internet of Things” (IoT) app. You can set up your own MQTT broker on a PC in your house to send the data from a PC or cell phone app, and there are Arduino MQTT libraries that manage getting the data to and from the broker. However, if you want to be able to control your line array DSP via the Internet from any location, you will need to use a cloud-based IoT broker. I have tried using the free IoT brokers from Hive, and Amazon (AWS), and they work fine if you only want to control a couple of basic features such as master volume or the input switching. However, these free versions only allow using a couple of variables, and if you want to control all of the features of the line array, you will need to purchase a subscription.
Probably the easiest way to implement WiFi IoT control is to subscribe to Arduino Cloud. Their prices are very reasonable for small projects (I’m using the $24/year plan). However, I quickly exceeded my allotment of variables for that plan, and I couldn’t find an easy way out of that limitation with spending a lot more money on a different subscription. The Dashboard that I was using to control the line array is shown below. The “Messenger” block near at the bottom allowed me to send any command string I wanted without exceeding the 10-variable limit, but that turned out to be way too clumsy. Also, these IoT libraries are quite large, and I was having to choose between Bluetooth BLE or IoT, or else I would have to use an MCU with more memory (such as the ESP32-S3).
A very nice feature of the Arduino Cloud is that you can use a built-in tool to generate a cell phone app to control your line array–either for Android or IOS. The downside of that feature is that the app looks “clunky”, as all of the controls are large and have to fit on a “coarse” grid. Somebody might want to experiment more with this user interface and maybe achieve a more satisfying result, but I decided to abandon this approach in favor of the native Android app.
The Arduino sketch software to respond to the Arduino Cloud broker is currently excluded from the Arduino design by renaming it from Arduino_IOT.ino to Arduino_IOT.inox. That renamed file is in the download link in Part 2. The IoT interface doesn’t use the serial commands, as each variable is assigned a callback that transfers program control when the variable is updated. Once the callback is in control, the code updates the MCU HCI state and calls the appropriate ADAU1466_cmd routine. There are also some library files and some code that have been commented out in the main file. If that code is restored, this IoT HCI should start working. Imagine…driving down the highway, tweaking the line array settings from your car. Pretty useless, eh?