Oboe support

[Ant1r]

This switches the audio driver to Oboe.
Fixes #47, fixes #66, fixes #89.

Added:

• the native interface to Oboe, including buffer size conversion between Pd and Oboe, separately for input and output (since Oboe can provide less input samples than output ones, mainly on start), and the API to select input and output audio devices.
• the java glue needed to load the oboe native lib, and to allow selecting the input and output audio devices from the
  preference screen (that's pretty cool actually, you can chose between the different mikes if any, or select between e.g usb audio card, device speaker or device headphones).

The first part could have been targeted to libpd instead; actually it will always be possible to do it later, if someone really insists to.
But I doubt it is useful to have code in a repo, that you cannot even compile and test from within this repo...
And as Dan said in libpd/libpd#284 (comment):

we can split up maintenance a bit better so each platform sits with someone actually using it

[joebowbeer]

Next steps?

Test the .aar artifact?

Bump the version to create a new SNAPSHOT?

Thoughts on adding diffplug/spotless to enforce a style on the java and cpp code?

[joebowbeer]

Suggested change

	if(!mPlayStream) return;
	if (!mPlayStream) return;

[joebowbeer]

Remove extraneous whitespace?

[Ant1r]

I'm all OK for diffplug/spotless, you're welcome to it :-)

I'm currently testing the aar on PdDroidParty.

Like with other pd-for-android demos, there's the problem of the initial native lib loading:
by default, the libpd's PdBase loads pdnativeopensl. For PdBase to switch to pdnativeoboe, the default PdBaseLoader needs to be replaced by a custom one (this is currently implemented by the static PdAudio.setupNativeLoader() method).

The problem is:
how to ensure PdAudio.setupNativeLoader() is loaded before any call to a PdBase method?

• In PdTest, the first PdBase-dependent is PdPreferences.initPreferences(), so I've added a call to PdAudio.setupNativeLoader() at the beginning of PdPreferences.initPreferences().
• ScenePlayer doesn't use PdPreference, and first runs PdService, so I've protected PdService.onCreate() in the same way (note that ScenePlayer currently crashes anyway, because of permission issues).
• In CircleOfFifths, yet another situation: PdPreferences is not used, nor is PdService. PdAudio.initAudio() is called directly, so I've protected it in the same manner...

Now I'm testing PdDroidParty, and it's yet a new one! The first call is PdBase.versionString()... So currently, PdDroidParty loads pdnativeopensl, and crashes because PdAudio can't find the new native jni API.
The fix is easy (call PdAudio.setupNativeLoader() in the creator of PdParty's first activity), but I think it's a dirty hack as it stands.

So I see 3 possible solutions:

• we find a way to ensure setupNativeLoader() is called before Java loads the PdBase class, would someone know one?
• we decide to introduce a new PdAndroidInit() that we make clear that is must be called at the very start of the app
• I change my mind and finally replace OpenSL by Oboe upstream in libpd...

What do you think?

[joebowbeer]

My take away from the conversation in libpd was:

For now, yes, oboe code could be added to an "oboe" folder, similar to openssl~

I think it's best to pursue that path and refactor later, or accelerate the refactor and add oboe after the refactor.

Unless someone knows a transparent way to ensure setupNativeLoader is called.

Changing the way init is done (PdAndroidInit) would be a major (v2) change. Not necessarily a bad thing.

[Ant1r]

I think it's best to pursue that path

sorry I'm sure what you mean, do you mean you'd prefer the new oboe native lib to go to libpd?

[joebowbeer]

I think it's best to pursue that path

sorry I'm sure what you mean, do you mean you'd prefer the new oboe native lib to go to libpd?

libpd is the proven approach and seemed to be what everyone (else) was suggesting.

[Ant1r]

ok no problem, I'll do it like this.
I'm closing for now.