Audio Plugin Framework for Android
There is no widely used audio plugin framework for Android. On Windows and other desktop computers, VST is very popular. On Mac and iOS (including iPadOS) there is AudioUnit. Linux uses LV2 to some extent.
The goal of the AAP is to create a comprehensive standard for audio plugins that will be adopted by the ecosystem of Android applications. The license is a permissive license (MIT). It is designed to be able to connect to other audio plugin specifications like VST3, LV2, CLAP and so on (which doesn’t necessarily mean we write code for it).
On the other hand, it is designed so that the multiplugin SDK can support it. We support JUCE integration, we’ve ported a plugin that uses DPF, and when iPlug2 supports Linux and Android, it will be just as possible. More specifically, the PAA is designed to take advantage of the hosting capabilities of JUCE audio plug-ins and JUCE-based audio plug-ins for the first time.
We have the aap-lv2 and aap-juce repositories that accomplish these goals to some extent. Some plugins from this world are used (to some extent) – for example: mda-lv2, Fluidsynth (as aap-fluidsynth), sfizz, Guitarix in aap-lv2, Dexed, OPNplug, OB-Xd and JUCE AudioPluginHost in aap-juce. Note that there is no support for plugin interface integration yet.
RTA features, characteristics, unique selling points
Android is supported, and that’s a first: no other audio plugin framework manages to do this (except AudioRoute SDK, as far as @atsushieno knows). To make this possible, we have some additional features, which are explained below.
Out-of-process model, between host activity and plug-in services: AAP is designed for the Android platform, which provides a strict separation of the processing space for each application. Indeed, we cannot load random shared libraries from random plugins. Therefore, DAWs must communicate AAPs (host plug-ins) and AAPs (plug-ins) through the IPC mechanism. AAP uses IPC Binder via the NdkBinder API, which was introduced in Android 10. Moreover, the framework makes full use of Android’s shared memory (Ashmem) while processing the audio/MIDI buffer.
Scalability : The extensibility of the plug-in function is guaranteed by the raw pointer data. However, it should not contain function pointers, as the Android platform does not allow them to be called from different applications.
Mainly declarative parameter metadata: like LV2, we expect the res/xml/aap_metadata.xml metadata plugin to describe the ports.
C/C++ and Kotlin are supported: C/C++ is supported for the plugin and hosting, Kotlin for the hosting.
Permissive Licenses : It is published under the MIT license. Similar to LV2 (ISC), as opposed to VST3 or JUCE (GPLv3).
API Instability: Unlike other audio plugin frameworks, we do not offer API stability. Instead, we recommend that you use the APIs of an audio plugin framework or SDK, for example the JUCE or LV2 APIs, and port them to the AAP. AAP will eventually become a stable API, but that is not planned.
Linux Desktop builds : Developing plugins on Android can be boring, so we also provide a way to develop plugins on Linux desktop. It can be extended to Mac and maybe even Windows. It is however meant for development, we do not aim to replace existing plugin frameworks like LV2 or VST3.
How RTAs work: Technical basis
The distribution structure of AAP is simple: the hosts (DAWs) and plugins (tools/effects) can all be delivered as Android apps (via Google Play, etc.) :
AAP host (DAW) developers can use the AAP host API to request and download plug-ins, and then work with the audio data they process.
The AAP (plug-in) developers work as a service and process audio and MIDI messages.
From the point of view of application developers and users, it can be distributed as a MIDI device service. Like Android Native MIDI (introduced in Android 10.0), AAP processes all audio data in its native language (metadata and service requests still run in Dalvik/ART mode).
AAP developers create an audio plugin in native code using the Android NDK, create the metadata of the plugin as an Android XML resource (aap_metadata.xml), and optionally implement org.androidaudioplugin.AudioPluginService, which handles audio plugin connections using the Android SDK, and then aggregates them. The metadata contains information about the developer, ports (if known), and job requirements.
TODO : Plugins and their ports MUST NOT be changed dynamically, at least not at the current stage of specification. We need to seriously reconsider that. This will be mandatory if we support plugin wrappers.
The PAA is similar to what AudioRoute applications do. We attach great importance to the reuse of existing code. (I think they also want to implement plugins in native code, but I’m not sure. The SDK is not updated very often).
GitHub
https://github.com/atsushieno/android-audio-plugin-framework
Related Tags:
android audio apiandroid audio processing libraryandroid audiomanagerandroid audio policy managerandroid audio libraryandroid audio player library,People also search for,Privacy settings,How Search works,android audio api,android audio processing library,android audiomanager,android audio policy manager,android audio library,android audio player library,android audio focus,android-audio-library github
