I'm jumping in, very, very, very late... sorry. I'm subscribing to this whole forum now. ;)
So, Pd for Android is available now, thanks to Peter Brinkmann; I sort of looked over his shoulder -- I'd say helped, but more like cheerled? -- which means I'm in the process over the next two or three weeks of writing more extensive documentation.
If you want to try it:
Damien, you should for sure have a look at it. Next on my plate is working out how to turn it into a Processing library. My general inkling is that on desktop and Android it means different things.
First, on Android: Android most certainly does not now, and will not ever support JavaSound. What it does have is an API that's similar to JavaSound ... or any similar Java API. It's Java only, and it ain't terribly sophisticated, but it does work. And there are some advantages to Android, like new handsets and tablets with HDMI that give you handheld multichannel output support, which is pretty darned cool, I think.
The best documentation on the developer side is here:
libpd is significant to Processing for Android for two reasons.
Firstly, it will often be more convenient to simply use Pd for audio as a background service called from the P5 for Android activity and skip over Processing itself, which I think we can do. As you know, musicians love them some Pd.
Secondly, it's a good model for how to build something that can talk to the Java-based audio library used by Android.
Android does not currently allow native code access to its audio engine. Input and output are provided solely through android.media.*, and audio is handled behind the scenes by (private) native JNI code called AudioFlinger, which in turn talks to whatever driver has been provided by the handset vendor. That last part is critical -- the source of a lot of sound problems on Android has been sub-par vendor drivers, prompting Google to try to establish better standards for the devices they certify. (By better, apparently, we're talking 40-50ms latencies, so don't expect desktop performance even in future devices -- and yes, that means some devices behaving in the 150ms range, etc. Nasty stuff. Developers have in turn blamed Java, probably because of being burned by JavaSound, but my understanding is that it's actually device vendor driver implementations and chipset inconsistencies at the root of the problem.)
Anyway, I'm rambling. What you need to know is, what pdlib does -- and what Processing or minim for Android would need to do -- is simply to pass buffers to Android's preferred Java objects:
android.media.AudioRecord
-- for input and output, respectively.
You can check out Pd's code here:
I wouldn't try to implement this without first trying to adapt Peter's code, because he worked through a lot of weird potential issues (which you'll see in comments in the code).
Adapting Minim based on this template would be relatively easy. You just replace JavaSound calls with the class above.
What I need to do next is take libpd and try making it work as a desktop library, which would mean doing exactly the reverse -- presumably either writing a new JavaSound class, or just hitching a ride on Minim's JavaSound output (since it's a core library).
The intention of libpd was to do just this: we took on Android first, as it's actually the harder problem, and now adapting to embedding the library in something like desktop Java is comparatively simple.
Hope this is helpful. I'll try to follow up with a sample of libpd with Processing on Android if I can make them work together. :)
Peter (Kirn)
