new plugin manager + aap-lv2 plugin: does not play audio file correctly

[atsushieno]

While aapbarebonepluginsample plays audio file as expected, those effect plugins in aap-lv2-mda fails to play audio file.

[atsushieno]

aap-juce-simple-host + aap-lv2-mda works fine as it used to, so the issue is likely specific to the new plugin manager.

[atsushieno]

aaphostsample still works fine. Is it different when the new UI loads the plugin from within the same app or an external app?

[atsushieno]

same goes for aap-lv2-dragonfly-reverb. Not sure if it also applies to aap-juce plugins (they cannot work with non-JUCE activity).

[atsushieno]

It seems the latest implementation seems to work locally, if I replace the library references in app/build.gradle to the submodules (using the methodology documented at README.md, with the diff gist I have updated a few days ago).

The actual behavioral difference somehow appears at aap::AudioDataSourceNode::setAudioSource() for WTF reason. AudioFileReader.readFrames() from OggAudioFileFormat fails to consume SeekableByteBuffer.

It was discovered through this local patch against androidaudioplugin-manager sources (also logging changes to choc). I was forced to do this ugly logging debugging because if I want to put breakpoints on any code in androidaudioplugin-manager.aar it must be part of the project, and that means, we have a WORKING build without this problem!

HOW COME such a behavioral difference could happen, depending on whether androidaudioplugin.aar is resolved as a project() or Maven package!? I have no idea. Gradle has been bringing in incompatibility and unstability changes and AGP has to follow that, which brings in even more nightmare.

And Android Studio and Jetpack Compose requires fairly recent versions of Gradle i.e. 8.0+, so we have no way to go back to good (okay, "better" to be precise) old versions.

At this state. the only fix I can think of is to make structural changes to all those aap-lv2-XXX plugins to NOT resolve aars from MavenLocal but rather from the project, adding those aap-lv2 and aap-core modules into it. It is ugly, but better than lame not working version.

We really want to dump Gradle, but unfortunately we can't.

[atsushieno]

The issue ^ is now recorded as a new issue. Closing this particular issue for now.

[atsushieno]

Comparing androidaudioplugin-manager.aar from ~/.m2/repository/org/androidaudioplugin/androidaudioplugin-manager/0.8.0/, the native libraries are certainly different:

$  issue-174  ls -l working/lib/arm64-v8a
total 35600
-rw-r--r--  1 atsushi  staff    75584 Jan  1  1981 libaapbarebonepluginsample.so
-rw-r--r--  1 atsushi  staff  4381656 Jan  1  1981 libandroidaudioplugin-manager.so
-rw-r--r--  1 atsushi  staff  9321360 Jan  1  1981 libandroidaudioplugin.so
-rw-r--r--  1 atsushi  staff  1822720 Jan  1  1981 libc++_shared.so
-rw-r--r--  1 atsushi  staff  2620112 Jan  1  1981 liboboe.so
$  issue-174  ls -l problematic/lib/arm64-v8a 
total 16304
-rw-r--r--  1 atsushi  staff    75584 Jan  1  1981 libaapbarebonepluginsample.so
-rw-r--r--  1 atsushi  staff   442896 Jan  1  1981 libandroidaudioplugin-manager.so
-rw-r--r--  1 atsushi  staff  5716576 Jan  1  1981 libandroidaudioplugin.so
-rw-r--r--  1 atsushi  staff  1822720 Jan  1  1981 libc++_shared.so
-rw-r--r--  1 atsushi  staff   280128 Jan  1  1981 liboboe.so

Since they are already different at .aar level, dealing with native libs at app level would not make any difference. Yet, those options on androidaudioplugin-manager/build.gradle.kts did not matter:

• packaging.jniLibs.keepDebugSymbols.add("**/*.so")
• packaging.jniLibs.useLegacyPackaging = true