<figure><img src="image_1.png" /></figure>

HAL
open science

Linux Audio on Android

Victor Zappi

► To cite this version:

Victor Zappi. Linux Audio on Android. Proceedings of the 19th Linux Audio Conference, Jun 2025, Lyon, France. hal-05096046

HAL Id: hal-05096046

https://hal.science/hal-05096046v1

Submitted on 3 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# LINUX AUDIO ON ANDROID

Victor Zappi

College of Arts, Media and Design

Northeastern University, US

v.zappi@northeastern.edu

## ABSTRACT

Although Android is based on the Linux kernel, conventional development practices force real-time audio code to pass through multiple layers of the Android framework, resulting in high complexity and limited performance. In this paper, I demonstrate a workflow that treats Android devices as if they were standard embedded Linux boards, thereby bypassing much of the Android audio stack and gaining near-direct access to ALSA drivers in the kernel. I explain the key steps, including the need for rooting the phone, identifying hardware routing paths and cross-compiling native C++ code, and show how all these elements are conveniently streamlined by the open-source LDSP environment. This allows developers to work with minimal overhead and fully exploit hardware capabilities, even on older devices. Through benchmarks on several phone models, ranging from legacy phones to recent flagships, I briefly show that this approach yields substantial gains in performance compared to the typical Android app model, focusing on the case of oscillator polyphony and real-time analog effect emulation. Finally, I situate these findings in broader discussions of hacking, appropriation and e-waste reduction, illustrating how reimagining Android phones as embedded Linux audio platforms can unlock new pathways for sustainable, high-performance and readily accessible music technology.

## 1. INTRODUCTION

Android is widely recognized as a mobile operating system, yet it fundamentally builds on a fork of the Linux kernel for each release. The practice began in 2008, when the first Android phone (the HTC Dream) shipped with a modified version of the Linux 2.6.25 kernel<fnref n="1" />. The modifications addressed the particular needs of mobile devices, most notably power management, limited memory, security and specialized inter-process communication. Over time, efforts such as the Android Generic Kernel Image project<fnref n="2" />, introduced in 2020, have sought to bring Android's kernels even closer to mainline Linux, although certain patches and development branches remain to accommodate device-specific requirements.

Despite these lingering differences, Android and Linux share many core components, one of which is the audio subsystem. Since Android 2.3, this subsystem has relied on ALSA drivers—just as numerous embedded Linux boards do—forming the technical foundation for high-performance audio processing [1, 2]. In addition, most Android devices employ ARM-based system-on-chips (SoCs), the same architecture frequently found in embedded Linux boards (e.g., Raspberry Pi, BeagleBone Black, Orange Pi). Consequently, it is reasonable to expect that native C++ audio applications can be developed on Android in a manner analogous to embedded Linux systems, namely by cross-compiling a single binary for direct command-line execution.

In practice, however, Android imposes a different paradigm for application development. The platform is designed around “apps” running under the Android runtime, complemented by libraries and Java/Ktorin application program interfaces (APIs). This workflow has proven successful in the domain of mobile computing<fnref n="3" /> [3], as it delivers a streamlined user experience with robust security, for example through sandboxing each app under a unique user identity. However, the additional layers of abstraction make development quite challenging [4, 3] and introduce a significant performance overhead, especially in areas such as audio processing and user interaction [5, 6]. This impact is further compounded by the complexity of the development process. Because Google designates Android Studio as the official environment for Android app development<fnref n="4" />, most production workflows gravitate toward it, which in practice limits developers’ flexibility to adopt other solutions. Given that modern smartphones are among the fastest-evolving technological platforms—each new model offering more powerful CPUs and specialized accelerators [7]—it becomes compelling to explore development approaches that harness this raw performance more directly, much like the efficient, low-level development practiced in embedded Linux systems.

To address these issues, I developed LDSP, an open-source environment that enables developers to build, deploy and test low-level audio applications directly on Android devices using native C++ code. LDSP allows a workflow resembling that of embedded Linux boards: cross-compile a single C++ binary, run it from the command line and interact directly with the audio drivers. This toolkit leverages TinyALSA<fnref n="5" />, the same audio library commonly used by original equipment manufacturers (OEMs), giving direct access to the underlying audio system and Android sensor data. It also provides support for communication protocols such as MIDI and OSC, alongside a host of relevant libraries and example projects. Since LDSP depends on device modifications (such as rooting and specific configurations) accompanying documentation and scripts are provided to streamline this “hacking” process.

In this paper, I describe the architecture of LDSP and how it interfaces with Android’s audio system, highlighting where its workflow diverges from traditional embedded Linux approaches. I emphasize the notion of “low-level C++” to underscore two key distinctions: (1) the generated native binary operates outside the typical Android app model (in which C++ code is wrapped in higher-level Android components), and (2) communication with the hardware drivers is as direct as possible, bypassing multiple layers of the Android framework. In addition to these technical contributions, I place LDSP in a broader context of design and philosophical inquiry. Specifically, I explore how hacking Android’s internals not only yields performance benefits but also engages with questions of appropriation, openness and critical design, suggesting that reclaiming control over closed, black-boxed systems can serve as a creative and sociocultural act.

<footnote n="1">¹https://android.googlesource.com/platform/vendor/htc/dream-open/%2B/la7ffe0f7552f4d3875685d2c15ccdc526134cca/kernel.version</footnote>

<footnote n="2">²https://source.android.com/docs/core/architecture/kernel/generic-kernel-image</footnote>

<footnote n="3">³At the time of writing, Android is the largest player worldwide in the mobile market (Statcounter Global Stats, Mobile Operating System Market Share Worldwide, April 2025).</footnote>

<footnote n="4">⁴https://developer.android.com/studio/intro</footnote>

<footnote n="5">⁵https://github.com/tinyalsa/tinyalsa</footnote>
## 2. RELATED WORK

Multiple projects have sought to repurpose Android phones as platforms for real-time audio processing and musical interaction. One early endeavor is *Nexus*, which exclusively relies on web technologies to deliver a browser-based framework for designing mobile graphical user interfaces and controlling audio processes [8]. Another notable project, *MoMuPlat*, builds on Pure Data (Pd) and *libpd* to facilitate audio synthesis and signal processing on Android devices, allowing users to run existing Pd patches through a customized mobile interface [9]. In both of these environments, graphical user interfaces (GUIs) are either manually scripted (via HTML or JSON) or generated procedurally, and ultimately interface with Android's built-in Java/Kotlin layer for rendering.

Of these mobile audio efforts, *faust2api* is perhaps the most comprehensive, featuring a toolchain to generate optimized Android apps that integrate both Faust's signal-processing code and device-specific capabilities such as sensor access [6]. Graphical interfaces for real-time user interaction, along with access to built-in sensors, transducers and mechanical resonances of handheld devices are supported by *faust2api*, which compiles Faust programs into a standard mobile application structure.

Despite these innovations, existing frameworks inherit substantial overhead and latency from Android's audio stack. Even "native" code in C++ or Faust must traverse multiple layers before reaching the driver: the application framework, Android's mixer and a HAL [3]. Each layer can introduce buffering, scheduling, or format conversion, elevating CPU load and compromising timing precision, factors that prove especially restrictive on older devices [6]. While Google's *Exclusive Mode* in the AAudio API offers a partial bypass of these layers, it remains limited to newer phones (Android 8.0 or above) and may not address the needs of interactive audio applications that demand minimal latency and maximum flexibility. Hence, although these environments have broadened the scope of mobile music making, the inherent constraints of the Android ecosystem continue to challenge developers seeking high performance on a wide range of devices.

## 3. ANDROID LOW-LEVEL C++ DEVELOPMENT

Android's deep ties to the Linux kernel enable a development workflow reminiscent of embedded Linux systems. In theory, one can cross-compile a standard ELF (Executable and Linkable Format) binary on a host machine, transfer it to an Android device and run it for testing or debugging. The file system structure on Android accommodates shell scripts (though not necessarily with Bash) and it includes many familiar shell commands, even if certain utilities are missing or differ slightly from common desktop distributions.

A key requirement for low-level development is a proper toolchain consisting of a cross-compiler, linker, system libraries (including the C standard library) and, optionally, debugging tools. While one might assume that a generic ARM Linux cross-compiler would suffice, the Android runtime and its sysroot differ from those of typical embedded Linux boards. Thus, the *Android NDK* (Native Development Kit) is commonly used. It bundles toolchains for all Android versions still supported by Google at the time of each NDK release (which means older devices are compatible with older NDKs). It also provides CMake "toolchain files," which seamlessly configure builds by generating build scripts for *Ninja*<fnref n="6" />—requiring that both CMake and *Ninja* be installed on the host system.

Moving binaries to an Android device and running them typically does not involve the usual workflow based on the secure shell protocol found on most embedded boards. While so-

lutions such as Termux<fnref n="7" /> provide partial secure shell functionality, the Android Debug Bridge (ADB) is the official, universally supported mechanism. ADB has been part of the Android Open Source Project (AOSP) since 2007 and is available as a command-line tool on all major desktop operating systems<fnref n="8" />. It communicates with the ADB daemon pre-installed on every Android device, allowing users to push and pull files, open a shell and perform various debugging tasks over USB or Wi-Fi. By default, the shell user on Android is heavily restricted, lacking a conventional home directory. However, the path `/data/local/tmp` is fully writable and binaries stored there can be executed without root privileges. Consequently, combining the Android NDK (for cross-compilation) with ADB (for deployment and shell access) creates a robust pipeline for low-level C++ development on virtually any Android phone, all without rooting or third-party package managers.

## 4. LOW-LEVEL AUDIO AND THE NEED FOR HACKING

While it is somewhat straightforward to run a generic native binary on Android, obtaining truly low-level access to the audio subsystem poses additional challenges. By default, the Android shell user lacks the necessary permissions to open the hardware device nodes that handle audio I/O. In practical terms, any attempt to use TinyALSA—e.g., by calling `pcm_open()`—will fail, since the underlying sound devices are off-limits for security and privacy reasons.

To circumvent this restriction, Android apps rely on the privileged *audioserver* process, a system service that centrally manages all audio streams and has direct access to device drivers via TinyALSA. However, developers aiming to communicate with audio hardware at a lower level, outside the conventional app paradigm, need to run their binaries with elevated privileges. The simplest approach is to *root* the device and run the executable as the superuser. Once *root* access is obtained, the audio device nodes become directly accessible and all driver-level calls succeed.

Superuser privileges offer additional benefits as well. They enable direct access to input events (e.g., touchscreen and buttons) and to various kernel subsystems such as notification LEDs or vibration motors, which are typically out of reach for unprivileged users. Furthermore, *root* access permits fine-grained control over performance-related parameters, including real-time priorities and CPU frequency scaling, ensuring that audio applications can run optimally with minimal latency. In essence, this "hacking" step is essential for achieving the same level of low-level control commonly available in embedded Linux workflows, where unrestricted *root* privileges are routinely employed to ensure high-performance audio (notable examples are Bela [10] and systems leveraging *Jack*<fnref n="9" />).

### 4.1. Hardware Mixer: Linux vs. Android

While the steps described above are sufficient to run low-level audio applications on embedded Linux boards, Android introduces an additional challenge related to hardware routing. Modern SoC designs for smartphones typically include an audio codec equipped with a hardware mixer. This mixer routes various inputs and outputs (e.g., headphones versus speakers, long- versus short-range microphones) and allows the adjustment of corresponding gain levels from user space. However, the specifics of this hardware routing are closely tied to each codec's unique feature set and operational logic<fnref n="10" />.

<footnote n="7">⁷https://termux.dev/en/</footnote>

<footnote n="8">⁸https://developer.android.com/tools/adb</footnote>

<footnote n="9">⁹https://jackaudio.org/faq/linux rt config.</footnote>

<footnote>html</footnote>

<footnote n="10">¹⁰https://www.kernel.org/doc/html/v4.19/sound/soc/overview.html</footnote>

<footnote n="6">⁶https://ninja-build.org/</footnote>
On most embedded Linux boards, including the Raspberry Pi and the BeagleBone Black, the kernel driver abstracts these hardware details<fnref n="11" />. When user code requests operations (like switching from a built-in microphone to a line input or adjusting a channel's gain), the driver consults a *device tree* file that specifies how to translate the request into hardware-dependent controls. In contrast, Android omits such a device-tree-based approach for audio, placing the onus on user-space code to handle the hardware mixer directly. More precisely, the mixer is configured via two key components:

* `mixer_paths.xml`, a loosely standardized XML file that enumerates all controls for the SoC's codec and defines valid routing paths, input/output options and level settings.

* An *audio HAL*, an OEM-compiled static library that links against TinyALSA and handles all operations on the audio codec<fnref n="12" />, including configuring the mixer. In particular, it parses the controls defined in `mixer_paths.xml` and translates user requests into commands tailored for the underlying hardware.

This approach makes low-level audio handling on Android more fragmented than on standard embedded Linux systems. Whereas the latter rely on a kernel-based mixer abstraction and a coherent device tree, Android devices use a user-space model that can vary significantly between manufacturers and hardware revisions.

## 4.2. Mixer Configuration

The first requirement for routing audio in a low-level native binary is access to the `mixer_paths.xml` file, whose location can vary by device. Once located, its contents must be parsed at runtime so that user-level routing requests can be mapped to the corresponding low-level controls, akin to what the audio HAL does. In particular, `mixer_paths.xml` organizes controls into container elements identified by a `name` attribute. Each user request typically corresponds to one such element, which can itself include one or more controls.

<figure><img src="image_3.png" /><figcaption>Figure 1: Generic playback routing configuration. Highlighted in red is the sound device opened in user code via the ALSA driver, whose output is routed to the phone's built-in speaker via mixer controls.</figcaption></figure>

On most Android phones, the full playback route can be established via two requests only, referencing two distinct container elements in the XML:

* One XML element that routes the output stream of the chosen sound device into the mixer; it typically contains a single control, referencing the ALSA string identifier for an internal sound device (e.g., "MultiMedia1"). Modern

smartphones often feature multiple such internal devices for different scenarios, like voice, media or VoIP. We refer to this particular control as the *device activation*.

* Another XML element configures the routing of the mixer to a physical destination (like built-in speaker or headphones), along with any necessary enable switches and gain levels. We refer to this element as the *path*.

Figure 1 illustrates a playback routing configuration, while Figure 2 displays the two XML elements—extracted from an Android phone's `mixer_paths.xml`—that are essential for this configuration. Equivalent container elements exist for capture routing, while the overall number of elements (and their names) depends on the SoC's available sound devices, sources and destinations. In the Android framework, the audio HAL is preconfigured by the OEM with the names of the XML elements that contain the mixer controls. When a user routing request is received, the HAL matches the request with the appropriate XML element name, uses the name to retrieve the corresponding controls from `mixer_paths.xml` and then executes these controls on the hardware. Unfortunately, there is no universal naming standard and, while the `mixer_paths.xml` format loosely follows AOSP guidelines, each vendor's implementation can differ.

<figure><img src="image_4.png" /><figcaption>Figure 2: XML elements used in a Motorola phone to set up the route shown in Figure 1. The single control contained in the top element performs the “device activation;” in blue is highlighted the ALSA string identifier of the sound device activated by this control and opened in user code.</figcaption></figure>

Hence, to configure a full-duplex audio route, a native application must know at least:

* The general format of the device activation controls needed for playback and capture, together with the ALSA string identifiers for the chosen sound devices.

* The names of at least one playback path and one capture path, used to finalize the routing on each side.

Both pieces of information can be obtained by examining `mixer_paths.xml` on a target device. These final steps complete the minimal requirements for building, deploying and running a C++ low-level audio application on Android, as implemented in LDSP.

# 5. LDSP ENVIRONMENT

The LDSP environment comprises two main components: a C++ framework built around a TinyALSA-based audio engine and a supporting infrastructure of tools for building, deploying and debugging, as well as for assisting with the hacking process. The C++ framework is designed to host user code and facilitate the rapid prototyping of interactive audio applications, while the supporting infrastructure streamlines the technical steps needed to get these applications running on target devices.

## 5.1. C++ Framework

At the heart of the C++ framework is a full-duplex audio engine that communicates directly with the ALSA subsystem in

<footnote n="11">¹¹https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/simple-card.txt</footnote>

<footnote n="12">¹²Google provides a reference design for the audio HAL in the AOSP, but each OEM often modifies or extends it to accommodate specific hardware features and optimizations.</footnote>
the kernel. This engine is organized as a CMake project and adopts a code structure similar to that of Bela. User code is integrated by supplying at least one "render" file that implements the three main functions of the LDSP API. These functions are: `setup()`, which is invoked at the beginning of execution; `render()`, which serves as the real-time audio callback function; and `cleanup()`, which is called just before the application terminates. In addition to the engine, the framework incorporates a broad set of libraries for both audio and control tasks, including: sample loading, filtering, FFT, MIDI, OSC and serial/Arduino integration. It also grants access to all sensors exposed by the Android NDK via `libandroid`, the same ones accessible to ordinary Android apps. Moreover, the framework provides functionality to read touchscreen events, monitor volume and power buttons and control hardware features such as the flashlight, vibration motor and screen state. Several example projects accompany the framework to illustrate common usage patterns and demonstrate how its programming interface can be adapted to diverse use cases.

Beyond these higher-level components, the LDSP framework offers full run-time control of audio parameters for both capture and playback, including the selection of the sound device, period size, sample format, sample rate and number of channels. Furthermore, it supports routing each application to any of the physical sources and destinations available in the codec, while also accommodating external audio interfaces connected over USB. Low-level system performance settings are similarly exposed: the audio thread can be elevated to the highest real-time priority, with secondary tasks (e.g., sensor readings) assigned lower, though still real-time, priorities. Additionally, the CPU governor can be switched to *performance mode* (forcing the maximum clock rate) when the application starts and restored to defaults upon exit, and it is possible to adjust the CPU affinity of the audio thread. In other words, the engine encapsulates most of the capabilities of a generic audio HAL (including mixer routing—more on this in the next subsection), along with additional performance-related features that are not available on Android due to its restricted, sandboxed environment.

To enable such deep system-level adjustments, applications built with LDSP must be run with superuser privileges. As noted in Section 4, rooting the device is specifically required in order to gain direct access to kernel submodules such as audio and touchscreen events, configure scheduling priorities and modify CPU performance settings. Moreover, from Android 8 onward, root access is also necessary to retrieve sensor data via `libandroid`.

Finally, to support more advanced audio workflows and interactive control scenarios, LDSP integrates real-time inference frameworks—namely *RTNeural* [11] and *ONNX*<fnref n="13" />—thereby enabling advanced machine-learning pipelines to run directly on the device. Alongside these inference engines, LDSP provides a lightweight C++ webserver library that serves as the backend for a web-based GUI (see next subsection) and can also be repurposed in user code for other network-related features.

## 5.2. Supporting Infrastructure

LDSP provides a main script (available as both a Bash and a Batch file) that manages the full development workflow on the host machine. By specifying the paths to the Android NDK and to the user's LDSP project to build, this script generates build instructions via CMake and Ninja, transfers the resulting binary (along with any required resources) to the target device, and can run or stop it on demand. The latter is done as root, to grant the needed superuser privileges. It also installs on the phone the LLDB server included in the Android NDK and configures it for remote debugging through ADB, allowing developers to attach a local debugger on the host side. Crucially, neither the script nor

the LDSP framework itself is tied to any specific development environment or operating system, freeing developers from the typical reliance on Android Studio. Instead, one can use any preferred editor or integrated development environment.

Beyond user-managed resources (like audio files, pretrained neural models or other files placed in the user project folder on the host machine), the script deploys a JSON hardware configuration file containing essential information for correct run-time behavior. In particular, this file specifies the location of `mixer_paths.xml`, identifies the device activation controls for both playback and capture, and names the paths for playback (speaker, headphones and handset) and capture (built-in microphone, line-input, handset microphone) scenarios. It may also include optional entries for more complex routing scenarios or to define default audio parameters like period size, channel count and sound device identifier. Because these details vary across different phone and tablet models, LDSP ships with a collection of pre-configured hardware files for tested devices and a template for defining new ones. To aid in creating or extending these configurations, additional shell scripts are provided; they help developers with tasks like the discovery of the exact path to `mixer_paths.xml`, the enumeration of ALSA device identifiers and the determination of valid parameter settings for both playback and capture. Collectively, these tools guide the hacking process, allowing LDSP to be adapted to a wide range of previously untested Android devices.

LDSP also provides a minimal set of web assets (HTML, JavaScript and CSS) that are deployed onto the target device. These assets are served by the lightweight C++ webserver included in the framework, which launches automatically when the audio application starts. By default, they form a basic example of a front-end interface that can be easily replaced or extended with a custom GUI built using standard web technologies or libraries such as `p5.js`.<fnref n="14" /> Communication between the client-side GUI and the audio engine occurs through simple HTTP or WebSocket requests, allowing real-time control over parameters, visualization of sensor data, and interactive musical experimentation. This design closely follows the paradigm established by Bela, but is entirely self-contained on the Android device. Users connect to the device's IP address and designated port, gaining immediate access to the hosted interface. As a result, LDSP offers a cohesive, out-of-the-box solution for both low-level audio processing and intuitive front-end interactivity.

## 6. DISCUSSION

LDSP was created with the goal of hacking Android's audio infrastructure to achieve better performance for real-time, interactive applications, such as musical instruments and sound installations. By exposing low-level system capabilities and bypassing standard app-model constraints, LDSP harnesses the raw processing power of mobile devices in creative ways that are not normally envisioned by platform designers. In design and human-computer interaction (HCI), this style of hacking has often been described as a form of appropriation, particularly in artistic contexts [12, 13]. Here, appropriation refers to a deliberate reworking of a technology to deviate from its "proper" or expected uses, thereby democratizing design and injecting personal creativity into otherwise closed systems. This perspective resonates with established HCI theories of designing for appropriation, which encourage systems to be flexible enough for users to adapt them in unanticipated ways [14]. It also connects to broader ideas around intentional versus hidden affordances [15], illustrating how technologies might be co-opted for novel ends that lie well beyond the initial design brief.

By focusing on hacking Android's underlying mechanisms and use cases, LDSP operates at the intersection of design, engineering, and sociology—disciplines that increasingly converge

<footnote n="13">¹³https://github.com/microsoft/onnxruntime.gi</footnote>

<footnote n="14">¹⁴https://p5js.org/</footnote>
in the analysis of how devices and infrastructures shape daily experiences. Through its low-level approach, LDSP challenges conventional frameworks and paves the way for broader discussions on appropriation, sustainability and access. In the remainder of this section, these themes will be explored, situating technical performance within both HCI and cultural contexts.

## 6.1. Hacking a Tool vs. Hacking a System

In much of the literature on hacking and appropriation, “hacking a tool” often entails modifying or repurposing a specific object or technology [16, 17, 12]. Circuit-bending a toy keyboard for creative sound output, for instance, is emblematic of hacking as a hands-on manipulation of a discrete artifact. In contrast, “hacking a system” intervenes in a more expansive socio-technical infrastructure by bending or circumventing the rules governing how that infrastructure is meant to operate [18, 19]. This includes everything from subverting artificial intelligence models to exploiting software platforms in ways never originally intended, sometimes simply for playful or artistic goals [20].

In the case of LDSP, hacking a system is precisely what is happening. Rather than altering a single phone model or a particular piece of hardware, we can work within Android's intricate layers of security and abstraction to reshape the platform's behavior for more direct, performance-critical audio tasks. Notably, Android's heavy sandboxing and standardized frameworks were not designed with hacking or appropriation in mind; rather, they aim to enforce consistent user experiences and strong protections for security and—allegedly—privacy [21]. By circumventing these restrictions to unlock advanced audio capabilities, LDSP does more than provide a technical workaround. It uncovers and recontextualizes inner mechanisms of a globally pervasive operating system, illustrating how design constraints and engineering decisions can be challenged and reimagined.

Such an approach aligns with the spirit of the *Critical Engineering Manifesto* [22], which posits that any sufficiently complex technological system—from consumer software to communication infrastructure—“should be considered a potential target for dissection and modification,” both to question the power structures embedded in these systems and to regain agency over them. This stance resonates with Latour’s notion of the “black box,” wherein technologies become opaque over time, obscuring the political and social forces that shaped them [23]. By systematically “breaking open” Android’s layers and rewriting its internal workflows, LDSP exemplifies hacking as a method of inquiry and reflection. In doing so, it reframes hacking from a mere technical exploit to a critical design practice that surfaces how everyday tools function and empowers users to reshape them for novel creative ends.

## 6.2. Is the Effort Worth It? Performance Gains and Broader Implications

Design theorist Scott Burnham describes “design hacking” as a resourceful, user-driven practice that steps in when commercial products and systems fail to meet specific needs [24]. Rather than dismissing older or underutilized devices as obsolete, hacking refashions them into new tools that fill gaps in the creative landscape. The LDSP environment squarely aligns with this ethos, as its very premise is to repurpose hardware in unconventional ways. Yet one might ask whether this effort is truly worth it. Two recent studies suggest it is.

In [25], we tested LDSP on phones released between 2014 and 2018 by running large banks of oscillators—an archetypal benchmark for audio synthesis. We compared LDSP’s native approach to an equivalent “modern” Android audio app built with Java/Kotlin and C++. Across six phone models, LDSP consistently achieved higher oscillator counts and lower latencies, sometimes doubling or even tripling the maximum achievable polyphony. This substantial performance boost can transform

both recent and outdated phones into potent audio processors for musical instruments, sound installations, or other interactive sonic projects.

A second study focused on *neural* audio processing, an area in which even embedded devices can struggle to meet real-time deadlines [26]. Using LDSP to bypass standard Android buffering and security layers, we tested a set of neural models trained to emulate analog effects (two guitar distortions and a compressor) on phones dating from 2014 to 2022 [27]. The results demonstrate that LDSP can run these models in real time on surprisingly old phones, rivaling or surpassing performance on newer devices when confined to the conventional Android stack. Crucially, the direct, low-level access also grants developers far more control over buffer sizing, scheduling and system priorities, further optimizing the neural inference pipelines.

These findings confirm the profound payoff for those willing to navigate Android's deeper layers. By investing time in rooting devices and configuring the custom LDSP environment, users unlock performance levels otherwise inaccessible through typical Android app workflows. In doing so, they also challenge the notion of “proper” use encouraged by commercial platforms and mass-production cycles, reinforcing hacking as a potent form of creative, resourceful design.

## 6.3. From Rapid Prototyping to Sustainable Futures

A key appeal of hacking Android at the system level is the ability to rapidly prototype complex audio applications without being bound by the standard framework's restrictions. In the context of low-level development, this translates into a more direct pipeline from concept to implementation, allowing designers to iterate faster and fine-tune performance-critical components. Much like the tradition of hands-on, do-it-yourself instrument building in circuit bending and open-hardware communities [28], LDSP applies an exploratory and self-sufficient approach to smartphones, providing developers with an instantly available hardware testbed for sonic experimentation. By removing the overhead of multiple buffering layers, audio-thread scheduling and curated app distribution, it fosters an environment in which iterative design can happen both autonomously and with fine-grained control over performance.

Yet the significance of LDSP and similar approaches extends well beyond convenience, into the domain of technological democratization. Many creatives around the globe lack the resources or stable supply chains to obtain specialized audio boards and embedded platforms. In Latin America, for instance, import tariffs and high shipping costs place widely-touted digital musical instrument hardware out of financial reach [29]. Repurposing the smartphones already on hand is a step towards leveling the playing field, enabling artists, students and researchers in underserved regions to harness modern digital signal processing and sensor capabilities.

Equally pressing is the prospect of preservation and sustainability. As Dorigatti and Masu note [28], circuit bending's very roots trace back to a response against rapid technological obsolescence, transforming “discarded” devices into new creative canvases. In the same spirit, LDSP fosters an *upcycling* paradigm. By enabling native C++ audio applications on older or unwanted Android phones, it diverts them from the e-waste stream and grants them a second life as fully programmable audio engines. This approach not only rescues valuable hardware from landfills but also reveals new paths for environmental stewardship—particularly crucial in regions disproportionately affected by the negative externalities of technological consumption. Seen in this light, hacking Android becomes an active resistance against planned obsolescence; it reframes the phone as an enduring, flexible musical instrument rather than a disposable commodity, thereby challenging the prevailing assumption that cutting-edge musical systems always require newly manufactured hardware.
## 7. CONCLUSIONS

In this work, I have demonstrated that it is indeed possible to develop low-level C++ audio applications on Android devices as if they were standard embedded Linux boards. I analyzed in detail the key similarities and differences between the two platforms, and showed how the LDSP environment conveniently streamlines all the components necessary for a complete workflow. LDSP offers a powerful alternative to the conventional Android app model by transforming Android phones—ranging from legacy devices running Android 2.3 to the latest releases<fnref n="15" />— into flexible, low-level Linux audio platforms. Through its straightforward native C++ workflow, LDSP provides both an efficient audio engine (built atop TinyALSA) and seamless integration with hardware features like sensors, touchscreen and notification LEDs. Beyond C++, it also supports Pd patches via libpd, enabling for the harnessing of a wide variety of established creative coding paradigms. In doing so, it effectively narrows the gap between consumer mobile hardware and specialized Linux audio boards, significantly expanding the scope of what can be accomplished on everyday smartphones.

Naturally, limitations persist. Older phones that deviate from AOSP standards may not fully support LDSP's reverse-engineered audio stack and performance characteristics vary drastically according to device-specific hardware (e.g., CPU clock speed, memory, touchscreen refresh rate). Additionally, camera-based features are not yet available, as incorporating further HALs requires extensive reverse-engineering work. Nonetheless, benchmarks showcased in this paper and in earlier studies demonstrate LDSP's ability to deliver substantial gains in real-time performance, unlocking applications such as polyphonic synth engines, neural audio effects and sensor-rich interactive systems on hardware that would otherwise be constrained by Android's app framework.

Looking ahead, LDSP's feature set continues to grow through community-driven development. Ongoing efforts include the integration of performance-optimized libraries (such as parallelized FFTs), the addition of real-time visualization tools like a software oscilloscope and improvements to documentation for both developers and end users. Planned future work also includes an open-source Android Studio project that embeds the LDSP audio engine as a native .so library, allowing it to serve as a drop-in replacement for AAudio inside ordinary Java/Ktlin apps and thereby realizing a true "Linux audio backend" within conventional Android workflows.

By facilitating immediate, low-level access to ALSA drivers, the framework reimagines mobile hardware as a full-fledged audio workstation, with compelling implications for resource-limited environments and upcycling initiatives. Moreover, it underscores how hacking and appropriation can push beyond the boundaries of typical Android development, transforming mainstream devices into sustainable, high-performance solutions for music technologists worldwide. The environment is freely available for download at https://github.com/victorzappi/LDSP.

## 8. REFERENCES

[1] James William Topliss, Victor Zappi, Andrew McPherson, et al., "Latency performance for real-time audio on beatable black," in Proceedings of the Linux Audio Conference, LAC, 2014.

[2] Luca Vignati, Stefano Zambon, and Luca Turchet, "A comparison of real-time linux-based architectures for embedded musical applications," Journal of the Audio Engineering Society, vol. 70, no. 1/2, pp. 83-93, 2022.

[3] Alessio Balsini, Tommaso Cucinotta, Luca Abeni, Joel Fernandes, Phil Burk, Patrick Bellasi, and Morten Rasmussen, "Energy-efficient low-latency audio on android," Journal of Systems and Software, vol. 152, pp. 182-195, 2019.

[4] Rudi Villing, Victor Lazzarini, Dawid Czesak, Sean O'Leary, and Joseph Timoney, "Approaches for constant audio latency on android," in Proceedings of the International Conference on Digital Audio Effects, DAFx, 2015.

[5] Topi Kaaresoja and Stephen Brewster, "Feedback is... late: measuring multimodal delays in mobile device touchscreen interaction," in International Conference on Multimodal Interfaces and the Workshop on Machine Learning for Multimodal Interaction, 2010, pp. 1-8.

[6] Romain Michon, Yann Orlarey, Stéphane Letz, Dominique Fober, and Catinca Dumitrascu, "Mobile music with the faust programming language," in Perception, Representations, Image, Sound, Music: 14th International Symposium, CMMR 2019, Marseille, France, October 14-18, 2019, Revised Selected Papers, 2021, pp. 307-318.

[7] Andrey Ignatov, Radu Timofte, William Chou, Ke Wang, Max Wu, Tim Hartley, and Luc Van Gool, "Ai benchmark: Running deep neural networks on android smartphones," in Proceedings of the European Conference on Computer Vision (ECCV) Workshops, 2018, pp. 0-0.

[8] Benjamin Taylor, Jesse T Allison, William Conlin, Yemin Oh, and Daniel Holmes, "Simplified expressive mobile development with nexusui, nexusup, and nexusdrop.," in NIME 2014, 2014, pp. 257-262.

[9] Daniel Iglesia and Iglesia Intermedia, "The mobility is the message: The development and uses of mobmuplat," in Pure Data Conference (PdCon16). New York, 2016.

[10] Andrew McPherson, "Bela: An embedded platform for low-latency feedback control of sound," The Journal of the Acoustical Society of America, vol. 141, no. 5, pp. 3618-3618, 2017.

[11] Jatin Chowdhury, "Rtneural: Fast neural inferencing for real-time systems," arXiv preprint arXiv:2106.03037, 2021.

[12] Victor Zappi and Andrew McPherson, "Hackable instruments: supporting appropriation and modification in digital musical interaction," Frontiers in ICT, vol. 5, pp. 26, 2018.

[13] Isabel Li, Ace S Chen, Eric Rawn, Shm Garanganao Almeda, Bjoern Hartmann, and Jingyi Li, "Reimagining misuse as creative practice: Impressions and implications of usage norms on digital artists," in Proceedings of the ACM CHI conference on Human Factors in Computing System, 2025.

[14] Alan Dix, "Designing for appropriation," in Proceedings of HCI 2007 The 21st British HCI Group Annual Conference University of Lancaster, UK. BCS Learning & Development, 2007.

[15] Victor Zappi and Andrew McPherson, "Dimensionality and appropriation in digital musical instrument design," in Proceedings of the International Conference on New Interfaces for Musical Expression. Citeseer, 2014, pp. 455-460.

[16] Daniela Rosner and Jonathan Bean, "Learning from Limited Hacking: I'm not one to decoupage a tabletop and call it a day.," in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2009, pp. 419-422.

[17] Nicolas Collins, *Handmade electronic music: the art of hardware hacking*, Routledge, 2009.

<footnote n="15">¹⁵At the time of writing, the newest Android version is 15</footnote>
[18] Linda Maria Jessica Kronman, “Hacking surveillance cameras, tricking ai and disputing biases: Artistic critiques of machine vision,” *Open Library of Humanities*, vol. 1, 10 2023.

[19] Jennifer Gradecki, “The art index as art,” *Visual Resources*, vol. 34, no. 1-2, pp. 65–92, 2018.

[20] Golan Levin, Scott Gibbons, and Gregory Shakar, “Dial-tones: A telesymphony,” Live concert performance using audience mobile phones as instruments, 2001, Premiered at Ars Electronica Festival, Linz, Austria.

[21] Chuan Yan, Mark Huasong Meng, Fuman Xie, and Guang-dong Bai, “Investigating documented privacy changes in android os,” *Proceedings of the ACM on Software Engineering*, vol. 1, no. FSE, pp. 2701–2724, 2024.

[22] Julian Oliver, Gordan Savičić, and Danja Vasiliev, “The critical engineering manifesto,” https://criticalengineering.org, 2011, Accessed March 28, 2025.

[23] Bruno Latour, “Science in action: How to follow scientists and engineers through society,” *Harvard UP*, 1987.

[24] Scott Burnham, *Design Hacking: Resourceful Innovation and Sustainable Self-Reliance*, VRMNTR, 2019.

[25] Victor Zappi and Carla Sophie Tapparo, “Upcycling android phones into embedded audio platforms,” in *Proceed-

ings of the International Conference on Digital Audio Effects*, 2023.

[26] Teresa Pelinski, Rodrigo Diaz, Adan L. Benito Temprano, and Andrew McPherson, “Pipeline for recording datasets and running neural networks on the bela embedded hardware platform,” in *Proceedings of the International Conference on New Interfaces for Musical Expression*, Miguel Ortiz and Adnan Marquez-Borbon, Eds., Mexico City, Mexico, May 2023, pp. 160–166.

[27] Jason Hoopes, Brooke Chalmers, and Victor Zappi, “Neural audio processing on android phones,” in *Proceedings of the International Conference on Digital Audio Effects*, 2024.

[28] Enrico Dorigatti and Raul Masu, “Circuit bending and environmental sustainability: Current situation and steps forward,” in *NIME 2022*, 2022.

[29] Juan Pablo Martinez Avila, João Tragtenberg, Filipe Calegario, Ximena Alarcon, Laddy Patricia Cadavid Hinojosa, Isabela Corintha, Teodoro Dannemann, Javier Jaimovich, Adnan Marquez-Borbon, Martin Matus Lerner, et al., “Being (a) part of nime: Embracing latin american perspectives,” in *NIME 2022. PubPub*, 2022.