review existing implementation and fix-or-document where realtime blockers exist

[atsushieno]

There is a bunch of points there on what we should avoid in realtime processing on this talk: https://www.youtube.com/watch?v=Q0vrQFyAdWI

This is in general difficult and continuous task. We'll close it once a review iteration is done.

[atsushieno]

related aap-juce issue atsushieno/aap-juce#5

[atsushieno]

With related to this issue, we would need some premise on the scope of this AAP project.

Currently it targets Android 10 devices or later, which kind of implies that only modern devices are in scope. Although there would be cheap devices nowadays and the premise is getting vanished.

So, the README.md should clearly mention that it targets only "capable" devices that supports quality low latency. Even with that it is still unclear if we can achieve basic usability here. I would go for features implemented first though. Arbitrary third-party audio plugins with arbitrary hosts are still good (I believe AudioRoute-SDK already does that though, on its own way).

Google has the basic Android device capability guidelines called CDD (Compatibility Definition Document), which has been updated every time Google releases new versions. The latest (as of writing this) Android 10 CDD mentions Audio Latency (5.6). They are still far behind professional low latency audio requirements, but they are something.

[cbix]

Thanks for the reference! Never heard of AudioRoute and it doesn't look like getting a lot of attention anyway. Also I figured out my latency issues were related to how the Oboe API is being used and the device. With FAUST effect builds I didn't manage to get below 500 ms audio RTT even though it uses Oboe but with the official Oboe samples I got 30 ms on my S5 Duos with AOSP Pie and 90 ms on a Huawei with LineageOS Q. I'll try to fix the Faust Android build target soon and submit a PR and am excited to try your AAP samples as well!

Anyway the Android CDD mentions of latency shouldn't be of any concern for AAP regarding the plugin format. It's mainly relevant for reference implementations of plugin hosts and recommendations for which platform to use if audio latency is important (which for some use cases of AAP it actually isn't).

[atsushieno]

One of the major concern with related to the entire architecture of AAP was NdkBinder. I finally did simple and stupid performance measurement on those plugins I have imported from LV2 and JUCE. mda-lv2 was super fast, and JUCE-based synths are also good enough. I put some results on aap-juce README.

https://github.com/atsushieno/aap-juce#measuring-performance

As long as I measured the turn-around time for those plugins, the average time was like 300-400 microseconds. where synths cost like 1500 milliseconds (it would depend on the device, so only diffs / percentages matter). Not a small increase, but quite acceptable unless hosts keep many plugin connections (I would freeze non-active tracks especially on mobiles).

It would be still worth keeping this issue open (I haven't worked on entire code review), but it wouldn't be a blocking concern for now.

[atsushieno]

The diagram on the last page of the "Binder Communication and Discovery" section on this ABS2013 material mentions blocking ioctl (at (4) and (13)). This is something inevitable on current Android platforms.

... Although it should be quite different from general Linux ioctl (it is binder_ioctl()) the level of concern would be different. mutex_lock and mutex_unlock is indeed everywhere though.

[atsushieno]

closning as per 27102e9.