I am happy to announce that the OpenSL components of libpd are now official; I recently merged them into the master branches of libpd and Pd for Android.
When I wrote up my reasoning behind the OpenSL support of libpd in June, I thought I was done, but then, due to the number of devices and Android versions out there, it took me a while to test the new code to my satisfaction. That turned out to be most fortunate indeed, because the appearance of Android 4.2 in November introduced two major changes. First, it changed the timing requirements of the buffer queue callbacks, requiring a complete revision of my take on threading in the native OpenSL library. Second, it introduced a new Java API for querying audio capabilities of the device.
The first change is entirely under the hood and does not affect the public API of libpd or Pd for Android. The second change, however, is both good news and bad news. It’s good news because it takes the guesswork out of the configuration of OpenSL. Readers who looked at the original version of my OpenSL library will be relieved to see that the awkward heuristics for choosing buffer sizes are gone. The bad news is that the new capabilities are only available in Java, so that it is no longer possible to have a neat, self-contained native library for streaming audio with OpenSL. Instead, any streaming OpenSL library will have to consist of a native component and an auxiliary Java component that configures the native component.
Moreover, the new Java API calls require an application context. As far as I know, there is no good way to statically obtain the current context, and so it is impossible to implicitly query audio capabilities in static initializers (please correct me if I’m wrong). Rather, the AudioParameters class needs to be explicitly initialized once an application context is available.
In other words, this change does affect the public API of Pd for Android, albeit in a fairly minor way. Here are the most important points:
- The AudioParameters class takes advantage of new features of Android 4.2 when available, but it remains backward compatible with older Android versions as well, all the way back to Android 1.5.
- Existing code will continue to work as before; if AudioParameters isn’t explicitly initialized, it will initialize itself with safe default parameters.
- The default parameters are perfectly fine, unless you are targeting the new low-latency features of recent Nexus devices.
- PdService now initializes AudioParameters when it is created, so there’s no need to change anything if you use PdService and only access AudioParameters after PdService binds to your activity.
- If you want to use low-latency features and you don’t want to use PdService, then you need to explicitly call
AudioParameters.init(this);early in the life of your activity, e.g., in the
onCreatemethod. It is perfectly safe to call
initmore than once.
Proper documentation of this and other changes will follow soon. Stay tuned!