In commit c859b4a we introduced support for Google’s Oboe. Oboe is a C++ library for building low latency high-performance audio apps on Android. It supports API 16 onwards (99% devices). Under the hood, Oboe uses OpenSL ES on API 16-26 and AAudio from API 27 (Android 8.1) onwards. AAudio introduces further audio performance improvements such as exclusive audio mode. When using Oboe, developers don’t have to code separately for OpenSL ES and AAudio, since Oboe intelligently picks the correct audio implementation at runtime.

Oboe is currently in developer preview and is expected to be released in near future. This preview allows for early access and evaluation for developers targeting Android platform. To enable Oboe in JUCE, simply download Oboe repository from https://github.com/google/oboe , then in Projucer set JUCE_USE_ANDROID_OBOE to Enabled and set the path to the repository in Android exporter:

Screen Shot 2018-03-07 at 15.53.28.png 1650×354 52.9 KB Screen Shot 2018-03-07 at 15.54.17.png 1642×98 11 KB

We are super curious to hear about your experience with using Oboe in JUCE. Since it is in developer preview, any feedback & bug reports will allow us to make it better for you.

So this basically works on any C++ layer things in the past.

What about something that uses AudioTrack (Java) right now but is actually using C++ level audio DSP, I am calling down to C++ to fill the AudioTrack’s buffer, how could I change that to use this framework?

I know not quite related to JUCE but almost is since I was thinking about using JUCE for the GUI(in future apps) and bridge the audio layer with C++.

EDIT : For some reason when I wrote this I thought this was from a Google engineer, thus my post is slanted that way. If you don’t want to answer that is fine.

This feature is targeted to people using JUCE’s audio APIs, rather than directly talking to OS APIs. I.e. at the end of the day JUCE’s AudioProcessor::processBlock (AudioBuffer<float>& buffer, MidiBuffer& midiMessages) will be called for your audio processing class, same as for any other platform and underlying audio device type. In other words, existing JUCE devs don’t have to do anything special to use Oboe (besides small Projucer project settings but even these will go away in final release of Oboe).

The main rationale behind using Oboe is that we are expecting improvements to audio performance on Android (which has been lacking compared to iOS) 8.1 or above, because Google is actively working on underlying AAudio implementation. In other words, we would expect anyone using JUCE for writing audio apps and considering supporting Android to be interested in checking JUCE’s Oboe support out.

Yeah I get that.

I use Caustic’s sound engine which basically generates a buffer that I need to feed into the OS somewhere.

Right now I use AudioTrack in Java. But the fact remains that getting a buffer is getting a buffer(from a sequencer/synthesizer DSP framework) and if I can plugin into JUCE to send that buffer using Oboe, then I do not have to worry about all the things Oboe abstracts.

So I guess I really just answered my own question backwards.

I’m trying to understand what are the implications of the “developer preview” qualifier here. I guess this has at least two potential implications:

the API can be unstable

developers can’t ship apps using this library while it’s in preview mode

I’m very new to Android development, and I have an iOS app to port to Android, with a shipping deadline this summer. Although I can deal with API changes, I can’t risk to start development with Oboe if I can’t ship the product in time. Are there such shipping limitations? And if so, is there some firm timeline for how long such limitations would hold?

Thanks

Yes, Oboe API may change requiring us to modify JUCE implementation, but it would very likely affect only internals, keeping the existing public JUCE API the same. In the worst case JUCE API changes will be minimal.

There may be also bugs in Oboe that will have to be fixed before final release. The version we tried on Android 8.1 preview seemed rather stable though. We would not recommend using Oboe in app releases yet, because even though it may work well, subsequent Oboe API changes may be incompatible with your app. Once Oboe is released, we’d expect the API to be stable. No firm release deadlines are known to us, it should be sooner than later, given that we have a preview available for a few months already.

You can always switch between Oboe and OpenSL ES (the latter is the default, until Oboe is explicitly enabled) in JUCE. Depending on your situation later on, you can decide whether you want to run with Oboe, if it gets released before your app release, or with OpenSL ES. All it takes is one switch in Projucer. Until then, if time permits, you could compare the two and assess which one works better for you.

So JUCE should make you worry less about this meaning your code should pretty much be written once.
If you need low latency you can set your manifest to or Play store listing to be limited to some devices.

The less nice thing as @adamski mentioned is:

adamski:

even so, those devices that have been designed with audio performance in mind.

From what I’ve heard on the ADC talk on Android,
They’re working with manufactures. but they can do whatever they want. There are many Chinese phones, I do hope they’ll also cope.

Though, If JUCE would like to take the Oboe concept one step further, I’d try allowing a link to Samsung’s Audio API also. so JUCE would decide which path is best not only AOSP/Oboe style but would migrate all under the hood for best user experience.

So let me understand where we are at with latency (Please keep in mind, I’m the producer and not the developer):

With this new addition to Juce, it makes it easier to be able to do a single click and build for low latency Android. But what @adamski is saying is that these low latency drivers will only work for the newest devices and only Pro Audio Devices.

Can anyone explain specifically, which devices this low latency code works on?