Once the 3.20 branch lands, Android audio (at least on calls) will regress. Upstream did a major refactoring on the OpenSL ES Android sound driver in <https://code.google.com/p/webrtc/source/detail?r=3040>. After this landed, someone noticed that recording quality was unusably worse, and filed <http://code.google.com/p/webrtc/issues/detail?id=1119>. The maintainer admitted that there appeared to be two significant problems, WONTFIXed the bug, and reverted upstream to default to JNI (high latency) rather than OpenSL ES. This seems like a bizarre decision, and the reasoning for it wasn't really given in the bug. From what I can tell, the person who filed the bug just backed out the refactoring in their own fork. We could potentially do that too. Or we could talk to upstream about getting this unhorked.

I do think we want to escalate this upstream. If we go OpenSL and they go JNI we risk that OpenSL bugs/regressions in new Android releases cripple us. By the way, what do you think about this: http://music.columbia.edu/pipermail/portaudio/2010-December/011140.html If this is correct and Android OpenSL is really just a wrapper around the JNI, that would be revealing wrt the upstream decision. Wonder if the source is available.

From Issue 3434 Low-latency audio "Android 4.2 improves support for low-latency audio playback, starting from the improvements made in Android 4.1 release for audio output latency using OpenSL ES, Soundpool and tone generator APIs. These improvements depend on hardware support — devices that offer these low-latency audio features can advertise their support to apps through a hardware feature constant. New AudioManager APIs are provided to query the native audio sample rate and buffer size, for use on devices which claim this feature." Also very interesting: http://createdigitalmusic.com/2012/07/android-high-performance-audio-in-4-1-and-what-it-means-plus-libpd-goodness-today/

For what it's worth, $ANDROID_NDK_ROOT/docs/opensles has some documentation about exactly what parts of OpenSL ES Android does and doesn't implement, as well as clues to their roadmap. The master copy is at <https://android.googlesource.com/platform/ndk.git/+/master/docs/opensles/index.html>.

I think we want to target a fix for this by Firefox 24. We can reassess as we get closer to Fx24. This fix is definitely needed for the first release of WebRTC on Firefox for Android.

This patch puts us back to the OpenSL driver that's in the alder branch. I'm not sure I noticed an improvement in my testing (horrible quality in both cases), so I'm going to dig a bit further before I r? and land this.

We no longer have any problems with the new WebRTC stack and are using patched OpenSLES codepaths for input, and libcubeb for output, so going to mark this as WORKSFORME.