Oboe: C++ wrapper for Android

There’s a bit of confusion about Oboe, a C++ wrapper that Google released in 2017 and what it does and how it compares to Superpowered Audio. Developers, including Google, sometimes refer to it confusingly as a “library” -- that’s a stretch, given that it’s just wraps two Android APIs.

First things first, Oboe is a wrapper for Android IO. From Google’s own docs:

Oboe is a C++ wrapper that provides an API that closely resembles AAudio. It calls AAudio when it is available, and falls back to OpenSL ES if AAudio is not available.

That’s the entire functionality of Oboe. It helps route audio in and out of Android applications. It doesn’t have any other functionality whatsoever. It’s not a library, it’s a bandaid to help get audio in and out of Android apps because of two main reasons:

• The complex, unfriendly OpenSL ES API
• The well-known Android latency and stability issues with underlying OpenSL ES and AAudio APIs

Bottom line: Oboe won’t help lower latency by itself. It simply chooses which Android API given AAudio or OpenSL, and configures them for the best result.

Oboe for Android vs Superpowered Feature Overview

Oboe doesn’t offer any of the full-suite of sophisticated audio processing features that a 3rd party audio library or audio SDK provides. In Superpowered's case, low-latency, low-power, cross-platform audio players, decoders, Fx, streaming, music analysis and spatialization, all optimized for interactive audio.

Oboe does, indeed, provide Android audio I/O. Again, Oboe does not do any audio processing whatsoever. It only routes audio in and audio out of Android apps and does not improve latency intrinsically.

Superpowered Android Audio I/O

Superpowered has provided a virtually identical Android audio I/O class since 2015 (pre-dating Oboe by 2.5 years) and in that regard, both Oboe and one Superpowered class use the mandated API for audio I/O and do the exact same thing.

Android Audio IO

Audio in and out of an Android app can be thought of as special “pipes” mandated by Google/Android. Superpowered offers these Android specific IO pipes too. But these pipes, whether supplied by Oboe or Superpowered, are inconsequential when it comes to performance and latency.

It is what happens with Android device audio (system space) and inside an Android audio app (user space) -- not as the audio goes in or out -- that determines latency.

Android Audio Engines Analogy

Let's say that your app is a race-car. To get around the Google Play track you need an engine and a muffler. And to enter the race, the race host has decreed that all cars must match the same muffler specs (Android Audio I/O). However, the engines you can attach to that muffler, however, is entirely your choice.

A legal race-ready stock race car then looks like this:

1. Android stock engine (other Android-provided audio APIs).
2. Required stock muffler spec (OpenSL ES or AAudio) <---- the same API required by all apps (can be wrapped by Oboe or other open-source code, such as Superpowered Android Audio I/O)

This is mostly acceptable for apps without interactive audio latency or performance needs (such as Spotify or Slack).

However, there are tens of thousands of apps, including many of the top live audio karaoke, VR, music, games and other audio-based apps (where latency is of prime concern) have set up their race-cars as follows:

1. Super-high performance,low latency engine (Superpowered Audio SDK).
2. Required stock muffler spec (OpenSL ES or AAudio) <---- the same API required by all apps (can be wrapped by Oboe or other open-source code, such as Superpowered Android Audio I/O)

The Android audio team created Oboe because the original OpenSL ES audio API is out-dated, complex and not easy to set up “properly”, while at the same time, the new AAudio API is still not available on most devices. AAudio also had some early versions with serious problems (such as low-latency audio requiring mono input).

Superpowered Audio Engines

Developers and companies come to Superpowered and say:

We want to enter our race-cars (apps) in multiple races (app stores) or off-road (embedded hardware), and the stock audio components don't cut it for us and our users. Can you give us better performance components (lower power, lower latency, consistent APIs) so we can better the user experience that we can use in multiple races simultaneously?

Our answer is: Yes, yes that’s exactly what Superpowered does.