[code_duck]

I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread, but not enough. iOS instruments are responsive enough you could play them in concert if desired... on the other hand, I can't even entertain myself with the Android music apps.

Is this just the difference between Java and Obj. C?

[billjings]

Android is all around inhospitable to music apps. The link in a sibling post here is just part of the problem - as far as I can tell, Android has no libraries that are useful for serious A/V work.

On iOS, in the span of a short morning I can hook up a button or slider to send out MIDI messages over WiFi to my MBP and route it to any device I want; I have no idea how to get the equivalent setup on Android. What if I want to decode an mp3 and process the resulting audio? I can tell you two ways on iOS, I know of a vague direction that might work for Android. You have to dive down into the NDK to do it, too. What about compositing video? Well...

Seriously, here is AVFoundation on iOS. This is a high-ish level Obj-C interface for mucking about with AVAssets, which can be audio or video:

http://developer.apple.com/library/mac/#documentation/AVFoun...

This is just a single library dedicated to a single level of abstraction. Video composition, audio mixing, playback control and monitoring... there's a lot going on just here. You've also got CoreMIDI, AudioQueues, AudioUnits/AUGraphs, MusicPlayer... they're not easy to pick up, but they're there and they can do serious work.

Here is what you can do in Java on Android:

http://developer.android.com/reference/android/media/package...

You can play encoded media, you can capture a raw input stream or direct it to an encoded file, you can play raw PCM... that's it. Really. To my knowledge, I'm not exaggerating when I say that - I'd be in debt to whoever proved me wrong, so please do!

For graphics on Android, there's usually something analogous you can get by with. For audio, though, it's just... not there at all.

[aaronblohowiak]

IIRC, you can use OpenSL (which is somewhat like OpenAL) on Android, and that "should" provide you with a lower latency audio feed, but you're right that it isn't anywhere as nice as specifying your PCM format of choice and passing in your block reference to the audio component like you get on iOS.

[anon1385]

It's a known issue and people have been complaining about it for years now: http://code.google.com/p/android/issues/detail?id=3434

[mbell]

There are hacks around it and there have been improvements since I played with the framework. However the hacks are ugly... I wrote a little tiny procedural 'music' app when I first got my Nexus One (android 2.2 i think). This was a workaround for lack of midi support and the latency issue. Anyway, not a shameless plug, its free and no ads, was just a "learn android" thing and was never polished at all. I'll dig out the code and get it up on GitHub if anyone wants to play with it.

[0] https://market.android.com/details?id=xian.bubbles&hl=en

[charliesome]

This was on HN a couple of days ago and it turns out that it's down to the sizes of the sample buffers each OS allocates.

From what I understand, Android will only give an app a large buffer, so when the app starts filling up that buffed, it may take a little while for the 'playhead' (is there a more technical term?) to get around to playing those samples.

On iOS however, an app can request a much smaller sample buffer, so there's less lag time between when an app fills that buffer and when the samples actually get played.