App is using hardcoded 2 channels for input which will result in increased latency

[dturner]

There is a bug in Android O (internal id 66967812) which means that requesting a stereo input stream may result in a non-FAST track, resulting in increased latency on Android O devices.

Checking the logcat output on an Android O device should verify this.

Solution/workaround: Request only a single (mono) channel input stream.

Thanks to philburk@ for pointing this out.

Thank you for the info. Is there any news about the grouped input/output callbacks?

[dturner]

I just fixed this issue in the AAudio echo sample here: googlearchive/android-audio-high-performance@d269d62

This is almost certainly the cause of the high round-trip latency being reported by this app on Android O.

Not sure what you mean by grouped input/output callbacks? Are you referring to synchronous I/O? If so, this is not supported yet. Best practice is to perform input stream reads during the output stream callback (see the echo sample for code).

No, the grouped input/output callbacks are a different thing. I already explained this multiple times, over Twitter, in email and also here in GitHub. But let's do this again:

Previously, input and output callbacks monotonically followed each other: input, output, input, output, ...

Currently, input and output callbacks are coming in this order: input, input, input, input, output, output, output, output, input, input, input, input, ...

The size of the input/output groups changes between 3 and 5.

[dturner]

Sorry I have no idea why that behaviour has changed, you are welcome to look at the Android source to investigate: http://androidxref.com/.

My advice is rather than having an input stream callback, perform a non-blocking read from the output stream callback, then you won't have this issue.

Yes, we are doing non-blocking read just like you describe, with AAudio.
But I'm talking about OpenSL ES here. It's latency is significantly higher, negatively impacting all pro audio apps.

Using mono input for AAudio reduced the round-trip audio latency to 38 ms (built-in mic/speaker) and 21 ms (loopback) on the Nexus 6P. These values are just slightly higher than OpenSL ES on Android 7. Meaning that AAudio provides no latency benefit yet, on this device.

[dturner]

Please raise a separate issue for the "i/o callback grouping", talking about two different issues on the same thread is confusing.

For the 21ms value - is that lower than it was without using the mono input?

Yes, much better, 57/40 became 38/21 (built-in/loopback).
Still not 33/17 though.

I'm not sure opening an issue here. Is this the appropriate place for it? The issue is not in the latency measurement app, but in Android.

[dturner]

OK I strongly suggest the following course of action if you want this fixed:

• Create a simple test app with source code available on github which reproduces the issue
• File an issue with clear steps to reproduce the issue at https://issuetracker.google.com/issues?q=componentid:192705%2B
• Send a link to the issue to me and I will raise internally.

FYI it's only those apps which rely on real-time audio monitoring which would be affected by this issue. That's still a big deal, just saying it's not all pro audio apps.

Hi Don,

As you state, "it's a big deal" and big deal is within Android, not Superpowered.

As such, this is clearly an issue that the Android audio team should want to fix -- since you're on the team, and know about the issue, by all means.

Given how our earlier issues were handled, we're not very motivated to create an issue and also a test application. We already spent a lot of time and energy with this.

We've also sent our findings on multiple channels, via GitHub, email and Twitter DM. Unfortunately, we're not able to do significantly more at this moment -- we are small, Google is big.

[dturner]

"...and know about the issue" - The reason for asking you to submit that information in a bug report is because I don't know enough about the issue.

Here's some immediate questions I have:

• What is the impact of having 4 input buffer callbacks followed by 4 output buffer callbacks? Presumably increased latency. If so, by how much?
• Is there a way of avoiding this problem by using non-blocking reads inside the output buffer callback, rather than having 2 separate callbacks?

I already mentioned a couple of times that non-blocking reads inside the output buffer callback is not possible with OpenSL ES. It's only possible with AAudio, and we are doing exactly that.

Please find all of our findings here: http://superpowered.com/android-audio-latency-problem-just-got-worse

We provided tons of information and analysis via several channels in the past few weeks. We hope that turning them to the public will help your team getting the resources and attention for a proper fix, just like it happened in the past with the "10 ms problem" article.