IssueTracker

[Comment deleted]

Yes! I was looking to code something like the Korg DS-10 for Google Android.
People are wanting good music applications. I will be satisfied for the moment if
there is a low-latency event-based API allowing us to pass small packets of PCM audio
to the hardware without going through the software mixer. Something like Steinberg
ASIO or JACK. The current music apps in the Android Market are suffering latency
issues due to the lack of such an interface.

Nothing happening with this problem. I wonder if someone from the Open Embedded
Software Foundation would lead the push; perhaps by defining a standard and very
simple API.
http://www.oesf.org

Here Here painter! Look at this article from 2007, its been available on iphone 4EVA!

http://www.tuaw.com/2007/08/06/iphone-coding-recording-audio/

My recomendation for a fix is simply to allow /dev/msm_pcm_out)  to move away from its permission of:
AID_SYSTEM,AID_AUDIO   so that applications can actually record the pcm stream. Let's catch up to iphone 2007
Shall we??

Hi hunterp,
Thanks for the input. That is something to look into, but I don´t think your
suggestion alone makes Android competitive. Please see the requirements list in this
Bug Report.

Have you seen the AudioRecord in the android API? It gives you control down to the byte-level. But the problem
is that it records from the MIC, not from the raw PCM buffer. So, with a music making app like my: What's Shakin'  
app, a user-generated music sample can only be captured via microphone, and the difference in sound quality is
night and day.

Playback speed using any implementation would be greatly desired as well.  This should
be possible by finely changing the sample rate.

I find it strange that the original poster felt that JACK was not low-latency enough.
I had understood that that was it's number 1 goal.  I am not disputing the claim, but
in order to better understand the requirement, I want to understand the details.

@hunterp, can you explain what you mean by from the raw PCM buffer vs MIC.

[Comment deleted]

[Comment deleted]

@mcharlesr  What I mean is that we can currently record the audio of a phone call, or the audio from the
microphone, but I cannot directly record the audio from my android application What's Shakin' for example. My
application is a musical app, where the users create their own music. Or the ADC2 winner Rhythm guitar. In
order for apps like these to record audio, only the microphone is available, and the sound quality of this is very
low compared to directly capturing the audio off the PCM buffer eg /dev/msm_pcm_out for example.

With only 15 starred developers, I am trying to raise awareness, and made a post on
the android-ndk google group.
http://groups.google.com/group/android-ndk/browse_thread/thread/acab8976bba1d504

If the android team could add the audio ndk support that I think is important for
marketplace applications, then perhaps it would connect to the AudioFlinger, or to
the AudioHardwareInterface.
http://www.kandroid.org/android_pdk/audio_sub_system.html

But can the requirements listed in this bug report be implemented with connection to
these software layers?

We've been running Pd (http://puredata.info) realtime audio on embedded Linux for
years, and on much weaker hardware than Android will ever target (1st Gen iPod,
anyone?  80MHz armv4!).  The Linux kernel has two good APIs for this, OSS and ALSA.
While they are not as good as JACK, one of them is already in place in Android itself
(I'm guessing ALSA is used by Android).  Google just needs to give us access.  The
100+ ms latency of the JNI interface is not good enough.  It needs to be < 20ms.

The audio apps are huge on the iPhone, why not let us do the same and better for Android?

From reading some of the comments, I think another requirement needs to be added.
h) Register for Callback function to indicate when real-time is missed. Perhaps, then
a restart procedure needs to be defined.

Yeah, this is one of the largest faults of the Android and should be at the top of
the Google teams fix list. Its an absolute show-stopper for anyone who wants to deal
with either complex DSP (like codecs for instance) or wants to port any of the
excelent libraries out there.

It suck to have to tell a client that "Yes, this will work on the Symbian, WinCE
phones and iPhone, but your stiff out of luck on the Android because porting your lib
isnt actually possible because of the high latency and lacklustre performance of
going through the android java stack for low level audio

Another vote for this issue because of synchronous play and record. My application is
a shot timer that rings a buzzer and starts recording the time (by counting audio
samples) from the buzzer when shots are recorded. For this to be usable in a
competitive environment I have to know exactly how the stream of input audio relates
to when the buzzer is actually rendered to the output device (starting
recording/playback synchronously ala Java sound) in order to ensure fair and
consistent timing.

I'd like this ability too. Look at all the music apps available on the iPhone.

The issue as I understand it from conversations on the NDK list has been concern that
there's not a standard API for audio support as provided by Android device makers.

Specifically, if you look at the PDK description:
http://www.kandroid.org/android_pdk/audio_sub_system.html

ALSA actually is specified as the "standard" API but as a "partner-specific
proprietary blocks." It seems to me that the devices are not being specified clearly
enough for this support to be standard. At the same time, has any device manufacturer
used kernel drivers *other than* ALSA?

I believe that specifically ALSA-based support would address this defect.

For me, it all comes down to this:

The camera capture API uses message passing for entire YUV frames - this is crazy,
shared memory and eventfd or something should be used instead.

And for contrast, the audio uses message passing, but doesn't queue more than one!
You have to eat it damn fast, and often - through no fault of your own - you miss it.
 What a lot of people want is for AudioRecord, but with small buffers that queue up
of GSM or AMR audio.

I'm using AudioRecord because I can do AMR in my user thread at substantially lower
CPU than asking for AMR from the media stack.  Ask MediaRecorder for an AMR stream,
and it takes like 40% CPU on all the 500Mhz phones.  Completely crazy.  Go figure?!?!?!

Also, the lifetime of real resources in java is ineffective.  If you forget to
release a camera or mic... ouch.  Its not robust and can make the phone unusable
until the next reboot (try taking a call if someone hasn't released the mic).

I believe there needs to be standardization in at least two places.
i) a new audio hardware adaptation layer, which connects the Linux kernel to the
audio interface chip
ii) audio APIs for the NDK, perhaps connecting to the AudioHardwareInterface

The design of i) and ii) should support the requirements listed in this bug report,
a) through h).
I believe that porting PC code like ALSA is not good enough. Android will never be a
strong audio PLATFORM without a good standardized solution to this bug report.

No, you don't need to replace ALSA. ALSA works on mobile devices with a lot less
power than the current lowest-end Android device. If the Android Project thinks they
have to replace ALSA, we'll never get workable audio -- never, ever. Worse, device
vendors would have to write new drivers.

This is a defect report for missing functionality. Android is based on the Linux
kernel in order to take advantage of standards on the Linux kernel.

You could provide NDK support *today* that connects into the ALSA API. It'll do what
you're asking.

In the meantime, the current status quo is unacceptable for providing all but the
most basic audio input and output functionality.

Agreed with painter, but what about threading/real time priority? Audio processes
should ideally be isolated from delays/cpu spikes incurred by Dalvik maintenance
activities, e.g. GC, JIT. Ideally it would be possible to spawn an entire new native
process/thread with higher priority, which could talk directly to the Audio APIs. I'm
not sure how this would work with the ANI/JNI.

I agree with Peter - there doesn't seem to be any reason to replace ALSA. Having NDK
ALSA support would provide the desired low-latency audio services to Android and it
exists.

But what does it mean that ALSA is specified as a "partner-specific proprietary block"?

Yeah, I should have read painter's post more carefully. ALSA is fine, but we need NDK
access.

The problem with ALSA, is i don't think it supports all the listed requirements of a)
through h). Instead of just porting PC code, the requirements must be considered.

From spacestation9, yes threading is very important. This is discussed in
requirements g) and h).

I'm not sure the above list is realistic as "requirements" for a defect report. ALSA
is a very full-functioning API, though; you're going to get most of what you need.
Asking Android for real-time kernel support is neither feasible nor necessary for the
majority of usage cases.

What we're really asking for is NDK audio input and audio output support for ALSA.
This will cover most of these bases. You can schedule a native JNI thread; that's a
separate process. That's how the support works now. The problem is, using messaging
to pass data from Java to native threads or being limited exclusively to Google's
provided Java APIs is insufficient for many applications.

Peterkirn has good points, but in addition to adding NDK audio input and audio output
support, I am hoping for performance that is competitive. This is the reason for the
requirements list.

If there is anyone from the Google Android team listening, I am Mountain View local.
I would be happy to demonstrate my app on a competitor's PLATFORM and then explain
why it is impossible on Google Android.
Then it should be clear why the points of this bug are important, and porting linux
PC audio drivers is not sufficient.

I'm sorry, painter, I think you're ignorant of the quality and functionality of the
ALSA API. They're drivers for the Linux kernel, not "Linux PC." ALSA can give you
what you want. Performance is competitive; I don't know what the basis for your
complaint is. And incidentally, if by competitor you mean Apple, they're using "PC"
drivers, too -- it's still the Core Audio output stack. ALSA is also widely used on
other embedded devices that need high-quality, low-latency audio.

The only thing that's ideally needed is direct access to the ALSA driver from the
NDK. In the meantime, there are workarounds, but it does make sense as a feature
request for the NDK.

Peterkirn,
Thanks for the input. If ALSA supplies the functions a) through h), that would be great!

Strictly speaking, this isn't a defect. It's an enhancement. If possible, you may
want to reclassify it as such as that may help it get attention.

I created the bug, but someone else assigned the Type, Priority, and Component.
I agree its an enhancement, but I don't know how to change that.

+1 would love access to the media libraries with the NDK and in particular the audio

I want OpenAL!

[Comment deleted]

Now with the ipad A LOT of companies are building realtime low latency audio
applications for the iPhone OS.

(a few examples by a leading magazine:
http://futuremusic.com/blog/2010/04/05/music-audio-apps-debut-with-apple-ipad/
)

The bigger multitouchscreens are like heaven for music producers or djs.

Now that android devices with bigger multitouchscreens are coming out, we really
really need this so very very much.

PLZ

I am sad to announce that I have switched my development platform to the
iPod/iPhone/iPad. I have a strong preference for Android, but the minimal round-trip
delay for audio processing in my Nexus One is 350ms while I can get 15ms with Apple
hardware.

Sorry.

If the terrible Android audio support improves some day, I'll be back.

Joachim

I have also hit a brick wall in trying to develop a real time audio application of a kind that is already available and
enjoyed by many on the iPhone. The varying and excessive latency, the lack of information about hardware
latency, and the resulting inability to synchronize have made this app virtually impossible.

I don't want to develop for Apple's platform, but as of right now there are absolutely no other options.

I have not heard of any progress on issues a)-i) in this report.
But, it seems we need to add a new issue based on recent developments here:
http://createdigitalmusic.com/2010/04/14/apple-ipad-may-support-usb-audio-interfaces-via-camera-accessory-kit/

j) USB digital audio input/audio support

Wish i had found out about this issue before i started soldering an custom guitar
passthrough headset plug. I guess the only effect i'd be able to achieve is and "echo"
if add a few more wires... -_-

According to notes taken at IO's "Advanced Android audio techniques" session, the plan to provide an OpenSL ES
API for this purpose. Too bad it didn't make it into Froyo.
https://wave.google.com/wave/#restored:wave:googlewave.com!w%252B3kgmObZwQ

Thanks p155off for documenting this important development.

I browsed the OpenSL ES spec and I don't see any specification for real-time low latency audio with synchronous
play and record. Did I miss something?

Same here, I did look at this 569 pages OpenSL spec. I'm really confused.

Why can't there be a simple callback based api? One would simply register a callback
of the kind:

void process(short *input, short *output, int nframes);

Hi Olivier,
I agree with you. A simple synchronous play and record callback would be great.
Separate play/record callbacks would also be OK, as long as the spec is clear about
synchronization, and performance.

My feeling is this Bug can not be solved now because there is no leadership pushing
low latency real-time audio performance for Marketplace Apps; in the mix of Google,
Linux, Android, chip companies, and ODMs. What we have now is what ever was lying
around during this mash-up.

Although you can go through libmedia (unsupported from native though) with AudioTrack and AudioRecord, a simple loopback test has shown me that the best you get is about 150 ms latency (108 ms for playback and 46 ms for recording, on a G2 dev phone) which was unfortunate.

Hi Daniel.akerud,

could you tell me how you measured the loopback delay and what a G2 is?

I have measured the loopback delay on a Nexus One as follows:
knocking on the table -> ear-phone-mic in -> fetching the samples with minimal buffer size -> out to earphone speakers.
I then recoded both the original knock and the output of the earphones on a computer. The earphone microphone, the earphone speaker and the computer microphone were taped quite close together (<1 cm).

With this setup, I measured 350 ms.

Joachim

Oh, I just called the ->latency() methods on AudioTrack and AudioRecord C++ interfaces, and just assumed they were telling the truth =)

Very disturbed that this issue has been open so long given the importance of low latency audio to gaming. The removal of javax.sound from the platform has made many things tricky that should be trivial.

Mark (and others) - my read is that this "issue" describes a symptom, not  a cause. "Low latency audio" isn't something that can just happen. It's an interaction of the platform and handset-specific firmware drivers.

In fact, if this issue were ever *not* open, there would be a problem. ;) It's an ongoing issue, trying to do low-latency audio.

If someone wants to break this issue into more descriptive, specific, actionable issues, I'd absolutely be game. javax.sound has problems (and platform inconsistencies) of its own, and I certainly wouldn't gripe about that.

Descriptive, specific, actionable issues. OK. I'm a game developer, and I was trying to get low latency audio working for a music-focused game, but these points are critical for really a good game user experience as well.

1. Provide an API to disable most background processes on Android: Anything that isn't an alarm that needs to fire or a phone call that needs to come in should simply not happen until our app says it's OK. And alarms and phone calls should also be able to be explicitly disabled, for that matter; if I'm recording something with my phone, callers can go to voice mail. It is completely and totally unacceptable to be playing a game and have it hiccup because some email program has decided it's time to download messages--and if you're recording audio, it's even worse. Games should expect to be interrupted by phone calls or alarms, though.

If task switching is fast enough on ARM processors, then simply allowing us to create threads with high priority to handle sound and game updates might be sufficient on the game side, though to really be clean on the sound side you potentially need a low enough latency that sharing the processor is pretty much not reasonable.

2. Provide (at a minimum) very low-level access to the sound API, directly from C++. The entire application should be able to run without even waking up a Java thread. Java is great for some things, but if you want clean speed, you need to get it out of the way.

Currently the application can run until it needs to present the screen or receive input from the keyboard/screen, and that MIGHT be close enough, as long as we can guarantee that the GC never, ever runs during critical periods. And with code that simply presents the screen and sleeps, that might be reasonable. A simple NDK-available "present" call and some low-level keyboard/screen event access APIs would prevent the JVM from ever needing to wake up, and that would be even better.

#2 obviously needs details (what do the APIs look like?), but it sounds like Google is already planning on adding OpenSL with NDK access, so at least that part of the decision seems to have been made. If it's not carved in stone, though, I'd say it looks like vast overkill. That said, I haven't seen anyone come up with a strong argument against OpenSL (other than the fact that, by being complicated, it will take longer for it to be in our hands).

For the audio toys I can imagine, I'd want to be able to run fast enough that I could use no more than 40ms of buffer (about 3500 samples in stereo), whereas AudioTrack seems to require 4000-8000 samples as a minimum buffer size, depending on hardware. And filling that AudioTrack minimum buffer (decompressing from OGG using Tremor) in a tight loop with basically nothing else happening but a few calls from Java to native still hiccups. And above the requests are down to 5ms of buffer (256 samples). I don't see how you could achieve the latter at all without keeping the entire thread native and shutting down almost everything else.

Is this what you're looking for? Or do you need more details? On a related note, has the decision to use OpenSL already been made, or should people potentially be lobbying for specific other APIs?

I think if we had the ability to 1. Request most of Android's computing resources, and 2. Eliminate as much of Java from the picture as possible, then this wouldn't be an open, ongoing issue, because it would just work. It's only an ongoing issue because it doesn't work, and it's nowhere close to working at present.

Not sure if this feature request is going anywhere, but....I've made a small feature request that is part of the direction that the android audio platform should be going:

http://code.google.com/p/android/issues/detail?id=9913

As the developer of a leading iPhone music making app, I also feel that the high audio latency is a show stopper for any useful audio application on the Android platform.  My application is cross platform and ready to port over, but regrettably until this situation is improved it's not worth doing.

A hard realtime callback which may be set to fire on every 5 or 10ms of audio would be great.  If it allowed synchronous audio input capture as well as output, that would be even better.

As a developer of music sequencing software ( MUSICtm / MTV Music Generator / eJay ) this is the ONLY thing stopping a move onto Android. We NEED some priority action on this... :O/

Sequencers can easily be written even with the high latency - the real problem of the latency is that if you ask AudioTrack for its min buffer size at 44100Khz Stereo, you will get 16384 samples. That's about 371ms delay.

If we could just lower this min buffer size to something better (10ms :) ) you could perform much better. I'm not sure why it's so high right now anyway. I'm sure the hardware could do better than this.

I've got one of the top selling music apps on Android and it would be nice though if you go ahead and make an app with pads or with keyboard that it can actually respond quickly instead of such a large buffer (even STATIC mode AudioTracks have too much buffer it feels like )

I agree with nikolatesla20, if AudioTrack could use small buffers and provide low latency, a lot could be achieved while comprehensive solutions like OpenSL are being contemplated. I'd like to see this addressed in the next release, and bundled with a couple of example programs. If good example programs were provided for AudioTrack usage, I'm betting that the developers would have discovered how difficult it is to do some things that should be very simple. You would think that you could read a wav file, and play it via AudioTrack, with not more than a few lines of code. Not the case, when we lost javax.sound, we lost all the library routines that understood how to decode .wav, .mp3, etc files into sample buffers.

Something like a two pad drum machine would be a good vehicle for shaking out audio latency issues in a compelling way.

This is a real issue on my HTC Desire aswell! The music app I have paid for has latency issues aswell! what the heck? hopefully changes are on their way!

seriously, nobody in a position to actually do something about audio
latency and API completeness is going to be reading this...

apart from latency, I think there also needs to be a way to cancel out audio feedback so that the sound from the speakers don't loop back into the mic resulting in a nasty sounding screech, this happens to me especially when sample rates are high.

Seems to me that as far as feedback between phone mic and speakers goes, that you need to address this the standard way by changing the relative geometry of mic and speakers. Probably by using the miniplug audio out on the phone to drive external speakers. Also, I would think that feedback is more affected by bit depth than sampling rate. Otherwise, there are feedback canceling devices used in PA systems, but I'm not sure how effectively real-time such algorithms would run on a phone.

Bit depth won't affect feedback; why would it? Sampling rate probably will - if the Nyquist frequency is below the feedback frequency then of course you won't get any.

Some kind of adaptive notch filter should be able to stop feedback, or you can do something fancy like measuring the impulse response of the system and subtracting the feedback part of the signal. I don't think it should be part of Android though.

I wonder what this means:

google "Android 2.2 Compatibility Definition". Section "6.3 Audio Latency".

In the end of the section:
"Note: while the requirements outlined above are stated as "SHOULD" for Android 2.2, the Compatibility Definition for a future version is planned to
change these to "MUST". That is, these requirements are optional in Android 2.2 but will be required by a future version. Existing and new devices
that run Android 2.2 Android are very strongly encouraged to meet these requirements in Android 2.2, or they will not be able to attain Android
compatibility when upgraded to the future version."

That is an interesting spec;
http://static.googleusercontent.com/external_content/untrusted_dlcp/source.android.com/en/us/compatibility/android-2.2-cdd.pdf

I strongly encourage the designers to improve the spec, because they describe; "Many classes of applications rely on short latencies, to achieve real-time effects such sound effects or VOIP communication".

But, the listed specs of 45 ms continuous output latency and 50 ms continuous input latency are not good enough for they applications they have described!
These performance specs are not competitive with other platforms.
Even a 20 MHz micro-controller can do better.

The continuous input latency absolutely must be less than 10 ms, and the continuous output latency absolutely must be less than 10ms.

painter...@g No one can hear my voice during calls. Droid has been flashed to cricket with gettho web. (free). Works great. Mic is not working o suPpose.  Installed your mic app. Same problem exist qith ot enabled. This is a commpn probplem with criccket service but is usually an easy fix . Bu restarting and pulling battery.  I am sure you. Can explain how to fix. And o lpve learning aboit the android codes.  It is fascinating to me.altho it mostly Greek. If u will, please send me a quick fix file ,app or download. Goin nuts. I have to put down my tools to type constantly. Cant get sheiyt dun like this. Thanks for the time.   Sincerely , Joel.( deadbreed1212@yahoo.com) or ( deadbreed1212@gm

Apologies for the noise all, Joel's off-topic post here is most likely my fault. I put a link to this bug in the about page of my microphone app, explaining that this is the reason for the delay.

I'll remove it in the next release and be more careful about where I link from in future *sigh*

As a sequencer dev, I feel I should voice my disagreement with the statement that ~300ms latencies are acceptable for a sequencer. A quick search found this page for your reference: http://www.pdmusic.org/text/017.txt. Particularly if one's sequencer includes some kind of audio synthesis, even a timely note sequence would be rendered useless by the synth.

Regardless, as a musician and supporter of Open Source, I'd very much like to see this issue fixed.

Guys we need more stars here. If you have an app on the market, please tell your users to come and star this issue whenever they ask for a new feature that needs low latency.

@oliver: It's the applications that don't exist on Android that need this feature the most. People simply won't release the app if it sucks with bad latency.

That's where I am -- I wanted to do a music rhythm game, and when I determined that it simply wouldn't be possible to even have a reliable KNOWN latency, much less a consistent latency over the course of a 4 minute song (it seems to lose about 10-20ms every few seconds -- by the end of a song, it would be WAY off!).

The Guitar Hero app on Android sucks, for example -- it doesn't even get the latency correct even at the start of the song.

And more serious music apps like sequencers would be a joke with any more than 10-20ms of constant, predictable latency. I'd love to have something like that on Android, but there's no way I'm going to even consider writing an app in that category until we have reliable, low latency on a large number of devices.

What I'd ask for, from Google, is more transparency on issues like this. We have 200+ developers (as of this writing) who need this feature, and yet we haven't heard from Google in months -- possibly over a year now? There's no bug owner; as far as we can tell it's being completely ignored, and that feels very, very frustrating. Especially knowing that any fix that DOES come out at this point will likely be in (at best) Android 3.0, which means another 1-2 years of propagation delay before any new features exist on enough handsets to be relevant.

There are rumors of work being done on OpenAL, but I haven't seen that verified. Please can we get an update of some kind?

I echo the sentiments. Also note; even after the spec mentioned in comment 65 is fixed, it will still be several years before developers could release low latency audio apps because of all the devices out there will poor firmware performance.

Any news on this?

No news is bad news when it comes to issues that need to be looked at...

GOOGLE SUCK. HOW CAN THE IPHONE BE A BETTER DEV PLATFORM THAN ANDROID?

Come on, Google! Get the ball rolling on updating Android to address this issue! I'm a music producer and would love to use my phone on the road for music creation! Please get this fixed ASAP! I was saddened to see how horrible the music apps perform on Android. It almost makes me want to switch over to the iPhone. I don't want to because Android is an awesome platform, but I might have no choice if this issue isn't addressed. Music is my life, and I'm going to where I can create lag and stress free music!

Please, Google. Do something about this soon. Just look at how many posts are in this thread! Don't sleep on us!

Im shocked about the latency, we should all complain at HTC and other manufacturers about that, they have a bigger lobby. I have a six year old HTC himalaya with wm2003 that has faster audio!

Google, we need much better audio latency for running audio applications. There exists too much latency to make audio applications worth using.

The most worrying bit about this bug is that there's a major lack of
official recognition or direction w.r.t to this bug when this does
affect users and developers in a most decisive way.

I don't know what you're talking about. The word is currently that OpenSL support will fill this need. It's disappointing that such support is unlikely to be backported to existing handsets given that nobody's suggested it will be, but such is life.

Until support arrives I'm going to keep my star on this bug, but don't say there's no plan... there certainly is one.

OpenSL is planned, which gives us an native API (at least that's what it SEEMS like it will give us).

But there are no latency guarantees in OpenSL according to the above message, and according to my own (somewhat limited) research. So getting an assurance that OpenSL will actually fill the need as outlined above would be nice. We can already get spooling audio with terrible latency; if OpenSL comes along and gives us the same thing with a few more bells and whistles bolted on, that won't help at all.

The OpenSL specs looks neat but it sounds more like a huge do-it-all multimedia subsystem. In the diagrams at the OpenSL site there is no direct connection from the application to the driver or the to hardware and when I see how Phonon, PulseAudio, gstreamer, ESD, aRts etc handle low latency audio on desktop linux then I fear that realtime audio will not have any priority for OpenSL. I hope that I'm wrong, though.

What is so wrong with a simple please_fill_this_buffer() callback?

@ToddMWorth

Yes latency is acceptable is the sequencer is entirely programmable. It only becomes a negative factor if the user is trying to play "live" in some way. Once you push "Play" on the sequencer, the initial latency is only the time it takes to start playing - after that it just keeps the buffer full.

For now I would suggest that those who want to build sequencers and programmable music apps can entirely do so without problems, my apps both work fine and have perfect timing even with the latency - but they are both "program" only (drum machine and loop sequencer). There isn't any real "live" playing involved.

For live play we need to get down into the 10-20msec latency range. This is only needed for users who want to play the drums live or manipulate parameters in real time. But I think a large range of audio apps are still possible even now - don't wait to write it! Just try it out.


-niko

@nikolatesla20

While it's great that there are sequencer apps out there already, the limitation of not being able to play live along side of the sequencer is such a hindrance;  When I produce I like to be able to play a riff/pattern/etc. live alongside what's already tracked/sequenced.  If that functionality isn't there, then it makes sequencing much more cumbersome and it takes away from the whole creative process.  

Needless to say, low-latency is such a must-have IMHO...  why this issue hasn't even gained much traction is such a boggle to me.

Hey Google.

http://gizmodo.com/5681868/ipads-and-iphones-to-get-midi-support-with-ios-42

I'm still holding out, but it would be nice to do things like this (yes, I relize tablet != phone, but the point stands).

Well, if Android-phones in general would enable the USB host hardware a lot
of cool addon-hardware would be enabled, or possible... (Like USB attached
soundcards that wouid kick the built in crap's A**..)

I agree with you don.juanton. You all probably have seen these:
http://www.youtube.com/watch?v=3-bLOc1qnMM
http://sven.killig.de/android/N1/2.2/usb_host/

I'm going to experiment with these as soon as I have time for it :p
Hopefully that stuff will get in to the Android release soon.

This really needs to be addressed. Why is the status still set to "New"? People have been commenting on this since 2009!
Make sure to star this issue so it will gain support.

We really need to spread the word on this one. I don't think Android users realise what they are missing out on. There is so much lost potential.

Maybe some bloggers should be informed about it? AndroidTapp, androidcentral, Chrome OS site... and if not those, then maybe apple insider or some other enemy camp site ;)

Not yet knowing quite enough about the issue could it be that the feature is difficult or impossible to implement in the way that the phone / data sync features are not affected (due to a high real time requirement for the quality audio recording / processing)

If so for me it would be enough to enable these features in aeroplane mode only (I would not like to get interrupted by a phone call while for example recording a track anyway)

Yes it does appear to be too difficult (for Google :p). Seems easy enough for Apple though!

The problem seems more to be that Google can not respond to this issue. If
it's difficult or impossible (under current circumstances), why not
acknowledge that?

How does the new Windows Phone7 compete in this area?

The XNA environment is fine for games (at least on XBox and Win) but can it handle reliable low latency audio on a mobile device?

Ofcourse what one might do to get this thing going on would be to send a patch against the current public Android branch and see if it gets to the new release

http://source.android.com/source/submit-patches.html

aapo: In theory, yes. In practice, no-one is going to spend time working on this feature when the probable outcome is that Google will reject it because they either don't agree with the design or because they have have secretly started their own implementation.

Google would need to say "We aren't working on this feature, and won't be for the next 6 months. If you implement it like <this>, and have good quality code then we will accept it." But Google never talk about their plans so that's not going to happen.

There is lots of good discussion here. I would like to summarize.
A) The Android hardware and firmware has very poor real-time audio performance, making the android platform non-competitive for music and VoIP apps.
B) The current spec list suggested performance, which is still not good enough (as per comment 65)
http://static.googleusercontent.com/external_content/untrusted_dlcp/source.android.com/en/us/compatibility/android-2.2-cdd.pdf
C) The vendor mashup makes this problem hard to solve by open source developers; we need Google leadership
D) There are some interesting related bugs developers should star, regarding USB audio; Bug 36905235, and Bug 36922874

Low latency audio support is a must for comsumer focused devices like Android. Games, interactive apps, music apps are a big part of todays phone use.

Let's get this fixed or at least give us an idea when to expect low level audio api's.

Android specs should recommend <25ms and REQUIRE <100ms audio latency. This isn't just for music apps or games (although it's unforgiveable that you can't even make a decently satisfying bubble-wrap-popping garbage-app on a device with a 1GHz CPU); if you tap a button and the click sound plays half a second later, it makes the whole platform and device seem shoddy.

Painter... thanks for a great info about the issue. Starred and commented on both. There was a great comment on the http://code.google.com/p/android/issues/detail?id=738 stating that the USB host support would make Android a iPhone killer.

Would give a limb for some solid, low-latency audio support. Am deeply frustrated by how excellent Android is in basically every area, but completely useless when it comes to aiding or enhancing my music possibilities, when compared to the iPhone I sometimes wish I had...

https://twitter.com/ID_AA_Carmack/status/29204671827

Hi there, John Carmack. If you're reading this, you must have started "taking a stab". Why not leave a comment.. or, just say something in public about it, it'll be on all the tech blogs and this issue might finally get some exposure (and attention, or at least acknowledgment, from google)

I'm also a developer of a sequencing/remixing app for iOS, Symbian, and Linux (myRMX).  I was asked by our investors to look at an Android port and was surprised to find the same old Java audio latency problems still in Android 2.2.

1) What do the media codecs/players use on Android?  I'm sure none of the codecs run in the VM and there doesn't seem to be huge audio sync issues with movie playback.  (Assuming players aren't shunting video through the VM, which would be terribly inefficient.)

2) ALSA in NDK would be a good start.  Our app uses ALSA on Linux and latency was very low on old 206MHz ARM-based Motorola handsets - lower than on the latest Symbian or iOS devices.

3) 350ms in not acceptable for a real-time sequencer.  Poster must have been thinking 35ms.  At 88 BMP, 350ms is more than an 8th note.

Java/VMs aren't designed for low-latency real-time code execution but for user-input-constrained code execution.  The NDK is a nice piece to allow real-time media-rich Android apps (like games) to compete with native platforms like Apple, Nokia, Samsung, and Windows.  Audio is as important as graphics and OpenGL certainly isn't running inside the VM.

Today Dan Galpin at GDD2010 in Moscow said that OpenSL support coming

Until that suggested OpenSL solution finally arrives, what is currently the best solution to achieve the lowest audio latancy? Accessing libmedia.so directly, or would a package using this approach be rejected from being published on the Android market? Is there some appropriate header file for accessing limedia.so somewhere? Because I cant fine one in the NDK.

YES.  The req specs listed overlap those for basic signals apps;
sampling oscilloscope app, electronics signal analyzer app, etc...

Any idea if there is a support for low latency audio in 2.3???

Android 2.3 gingerbread out. At 1:09 in the introduction video (http://www.engadget.com/2010/12/06/android-2-3-sdk-revealed-gingerbread-improvements-called-out/)  "Open API for low latency audio"

IS THIS IT?!?!!?

Looks like we might finally get what we have been wanting for so long! Android 2.3 appears to have low-latency audio support! Let's hope it's at least < or = to 12ms, which is the most acceptable, for me anyways

[Comment deleted]

http://developer.android.com/sdk/android-2.3-highlights.html mentions

Open API for native audio

The platform provides a software implementation of Khronos OpenSL ES, a standard API that gives applications access to powerful audio controls and effects from native code. Applications can use the API to manage audio devices and control audio input, output, and processing directly from native code

From the OpenSL docs in the new NDK:

"As OpenSL ES is a native C API, non-Dalvik application threads which call OpenSL ES have no Dalvik-related overhead such as garbage collection pauses. However, there is no additional performance benefit to the use of OpenSL ES other than this. In particular, use of OpenSL ES does not result in lower audio latency, higher scheduling priority, etc. than what the platform generally provides."

So, waiting to hear from anyone testing on a 2.3 device, but sounds like OpenSL on Android doesn't attempt to address this issue. What does it address, anyway? If latency is the same, we're kind of in the same boat, unless it was JNI causing all the issues to begin with, which seems unlikely

Under "Target applications" in (http://www.khronos.org/opensles/):
"-Multimedia interactive applications (Mixers, composers, DJ apps)"

Seems like on the API side things are OK? Now if I only knew if my Nexus One has the required low latency HW?! I'm not sure but seems to me that this should bring the latency down at least _some_ from the horrid 200-500ms range...

Is there a test app that a non-dev could run to report on audio latency? If someone could wrap something up as an APK then we should be able to get this tested by someone with 2.3 pretty soon.

I'm not sure if the ndk sample app native-audio could be used for that (probably not)

Anyway I'm trying to wrap something up to get some idea of the round trip audio latency (recording -> output)

I almost have first version ready but I'm unable to get the audio input when executing my native code in emulator (actually the native-audio sample app has the same problem)

Hello Guys,

don't get impressed by Gingerbread. As noted above, the docs mention that OpenSL doesn't bring any performance improvement.

But most importantly, the current Compatibility Definition Document (CDD, section 5.3) defines low latency as 45ms:
http://source.android.com/compatibility/android-2.3-cdd.pdf

I don't know how they ended up saying "high latency" = "low latency", but they did.

There is currently a thread on android-ndk where this is being discussed:
http://groups.google.com/group/android-ndk/browse_frm/thread/1744088af0924ed9

Please come on share your thoughts on this thread.

as a pro music production company in hollywood, i just came back from the NAMM show and there were a hundreds of I-os apps shown and few for android. and every software designer says that the sdk and latency issue with android is holding them back from porting their apps. what is the status of google fixing this.

I would say that low latency in real terms should be really stated at 7 or 8ms and not over. I know we are on mobile platform but in pro sound env (e.g. computing and sound engineering) "low latency" is a latency that shouldn't be heard... 7ms is a good one I think.
Of course you need a good audio chip, system, driver and... NDK.

I develop music production apps for iOS.  If I were selfish, I would want Google to keep egregiously floundering as they have been with low latency audio.  It is MUCH easier to focus on one platform and I feel comfortable to develop for iOS exclusively thanks to this colossal lack of foresight.  The CoreAudio team at Apple knows what they are doing and soon Google will be 3 or more years behind.  It is entirely possible that the Android team just doesn't understand this issue at all -- this is sad -- it doesn't just effect the music production market, it has an adverse effect on the obviously larger gaming market as well.  I won't speak about VoiP markets, as Android carriers probably would like to see them fail.

Update: The latest NDK r5 was released with the new OpenSL ES API, see http://android-developers.blogspot.com/2011/01/gingerbread-ndk-awesomeness.html

Looks like "low-latency" 45ms audio support is "optional" for 2.3 devices.  CCD says at some point the requirements will change from "SHOULD" to "MUST", possibly Android Honeycomb/3.0.  Rumor is Android 3.0 will require a minimum 1GHz dual-core CPU (and probably a car battery).

I don't always want to have to carry around my tascam dp-004. It would be cool if Android would fix this latency problem to increase utility of the phone.

[Comment deleted]

Hi, I own a Samsung Galaxy S that seems to perform terribly when it comes to low latency capabilities, but I tried out a guitar-hero-like application called "rock band" on that same device, and surprisingly the latency problem wasn't noticeable anymore. On the contrary, the touch response was very accurate.
I don't know if this information will be usefull to developers, I'm just a "average" Android user ;).

Modern smart-phones are full of sensors. The microphone is one, and many apps could use it real time, or combine it into sensor fusion.

Android should support real time audio processing inbound and outbound.

I was about to get a Galaxy S until I decided to look into audio apps vs. an iphone. Looks like I'm getting an iphone. Audio trumps the awesome gmail integration in my books.

I'm a dedicated Android guy, but with things like this I will be FORCED like a gun to my head to end up buying an Ipad for all the great audio software from the likes of IK multimedias amplitube, etc..

All the developers I talk with tell me they would love to start porting but there hands are tied.

As an android user, musician, and developer, I would love to have low latency audio, but I have to agree with comment 125 for now.

Until audio latency is fixed buying an Android tablet is a waste of money. I decided I'm getting an iPad 2 instead

Ridiculous how long this is taking, I doubt it will ever happen though if I am honest

I am a musician, and was on the fence with Android until I found out about this issue.  An official response is needed from Google such that developers can make an educated decision on whether or not they will port/design applications for android or potentially submit a patch.  My own adoption of the platform is pending on the resolution of this issue.

Can't believe that we are still talking about this. I hate iOS, but they have this nailed. I also believe that Google is wrong to assume that this is just a bunch of music and game weenies getting cranky. I believe the whole system speed and responsiveness of Android is affected. Played with a xoom today. Not even close to a gen-1 ipad in scrolling,  interface speed and pinch-to-zoom. Again, I HATE the whole Apple thing.

I am beginning to think that Android might have some built-in weakness here. If so, it is very sad.

If Google ever want Android to be widely seen as anything but a cheap second place to "cool guys", they need to fix this. It doesn't just affect you audio types, it wrecks the whole perception of the platform. A mistake always made by techie types is that this is a niche market, most people don't care. What they are missing is that artists and musicians (even wanna-be musicians) are the tastemakers in modern society. What they use is seen as 'cool', and when they complain about stuff, even if it's only effecting them, the rest of us listen and perceive it as a weakness.

We are developing a training application for reading a foreign language that requires us to synchronize the highlighting of text with sound playback. We have mp3 files to work with. We are having a devil of a time getting this to work. In addition to latency problems, there are severe discrepancies (multiple seconds) between the actual sound playback and the reported position of the playback in MediaPlayer, with value returned from getCurrentPosition() always lagging the actual sound. The problem seems to be worse the larger the mp3 file.

Without proper sound support...

Wait, everything's been said.  +1 to everything above.

Android needs beter audio support, plain and simple, if it ever wants to compete with Apple.

I have been trying to get some of the (more well known) Android sites to take a look at this issue, but I haven't received any replies from them. I was hoping that they would be able to lend a bigger voice to all of our frustrations with the latency issue. I also produce music and would love to use my Android phone as another means to be creative. I'm afraid that my patience has reached its end. I will be looking at WP7 as my next phone unless they have the same issue. I really dont want an iPhone...

I don't understand much about devs requests or audio latency and stuff like that.

But if you have been able to do this app in iOs, and people on Android are able to do this http://bit.ly/glppUm and this http://bit.ly/hcJbms, well then I'm pretty sure you could make something very good on Android as well... It could be not as good as iOs version, but it would be the best app on Android Market, you would make people happy, and yourself with with profits...  

yeAH please make this fixed for Android

Im switching from android to iOs because of this, and im shure im not the first.

ibelieveinoneworld,
Please see what Comment 70 said.

I am developing a free music game similar to the one in arcade for players in the forum of that game, and suffering the same problem. Even SoundPool is used the latency is at least 300ms, which is unacceptable for most of the players.

To all the marketing people,
Making a bad quality game or app just make negative effect to the product or even its team or company, or even Android phones. Selling a broken game which can not be fixed due to such issue does not satisfy the customers, because music game players are usually sensitive to the latency. This negative image may even turn the production team/constomers to iOS. So please fix the issue. Sorry for my poor English.

As many of the other posters I'm in the process of benchmarking my app that uses input and output simultaneously just to find out that the delay is too big compared to other platforms where similar apps are possible.. Too bad, have to start a blog to post about this..

Here is a link to an article in Computer Music delving into the glaring audio issues with Android: http://www.magarena.com/Will-Android-Ever-Become-Viable-for-Music-Making-9712/. So there is some press...

There's a huge anti-Apple movement, hence the big shift over to Android. Sadly, the latency issues are preventing music makers from getting the most out phones that are easily on par with the iPhone. Please fix this issue!

As someone who wants to deploy studio-grade sound processing on Android, and who does this stuff all the time in my studio, I have to say that the 12ms "acceptable latency" target is *way* too high. On Android-class hardware, the appropriate low-latency goal for direct-connected hardware is more like 1ms or 2ms.

For comparison, PC- and Mac-based systems presently see 3ms audio latencies routinely for firewire-connected devices. Roughly 2ms of that delay is down in the firewire link layer. On the same systems, PCI audio solutions from people like RME and Motu routinely provided 0.7ms to 1ms delay for somewhere around 48 simultaneous 96Khz audio channels. Yes, 96Khz, not 48Khz or 44.1Khz. The newer PCIe-based solutions can do more.

So if we are talking about Mic-to-speaker delays of 30-45ms in Gingerbread-class handsets, that's *ridiculous*. Even at 10ms, we're talking about readily user-noticeable delays.

For within-system (i.e. software-only) channels, the limiting factors here are bad software interfaces, high kernel-imposed interrupt latency, and low-performance context switching.

BTW, the firewire latency figures I mention aren't just on *modern* PCs. They were achievable on the original Core 2 Duos - devices with comparable processing power and considerably higher interrupt latencies than Gingerbread-class machines today - and they were achievable on Windows XP, where the real-time scheduling capabilities weren't that great. Win Vista was a low-latency disaster, but Win7 is adequate from my experience. Linux with suitable low-latency patches is noticeably better than any of these.

Now some might argue - perhaps correctly - that these issues are why the forthcoming Korg Kronos adopted a linux-on-realtime-microkernel design. It's an open question whether the linux low-latency patches might have been enough.

And it's also fair to note that Google already faces an overwhelming kernel patch management problem, so there are engineering challenges in anything that needs further kernel digressions.

But in the end it doesn't matter. If good audio can't be done on Android - including both reasonable latency and reasonable coordination of game sound to game video - that's a significant disadvantage in the market.

Now if only we could reliably obtain decent floating-point performance out of the ARM family...

Just want to echo the above statement and mention that providing for the option of a delay as low as possible is important particularly for music production applications. Even a sub 2ms latency can be noticeable depending on the situation. Consider a singer wearing headphones, and you want an app to add real-time reverb to him so he can hear his own singing with reverb added. Even at around 1.45ms of delay (64 sample buffer at 44.1kHz sampling rate), he might notice overlapping sound and a metallic/robotic effect.

One of the most compelling applications for me in the tablet environment is music production.  The lack of acceptable low-latency audio support (with no comment from Google on the future of this) is making it pretty likely that I'll return my Xoom and get an iPad. Which sucks, because I otherwise prefer the Android ecosystem.

We should start using the #issue3434 hash tag on Twitter.

I recently started on a project work.  I can't give details but step one was proof of concept, low latency audio on android device.  As the last 145 comments have explained everything I will just reiterate.  A very small lapse by Google which has pigeon holed a small portion of the market into Apple's domain.  In my case it prevents us from moving forward on this project which would have netted them a small 10+ tablet sales (meh right) and a few software engineers loving the Android platform (the real loss).

I think if Google wants to be the future they need to start listening to all the nit picking.  This issue as many others should have some attention by now, nearing the two year old mark I see.

I must say I'm somewhat disappointed that this hasn't been addressed yet. We're looking to develop a music analysis application for tablets and are currently looking at minimum buffers for recording of at least 90msecs from HoneyComb tablets.
Anyone looking at hitting ALSA directly (going around the current NDK/SDK)?

I agree with just about everything posted here.  Audio apps on Android are stymied by this problem.  Come on Google, sort it out.  Not everyone is interested in pointless 3D maps and speech conversion technology.

Is this thread monitored by google? My assumptiion is that yes it is?

If not, as a community, how do we get more focus on this? Less individuals and more larger group !?

I've got an iphone, I've got a galaxy tab, I'm going to have to get an ipad.

Is this thread monitored by google? My assumptiion is that yes it is?

If not, as a community, how do we get more focus on this? Less individuals and more larger group !?

I've got an iphone, I've got a galaxy tab, I'm going to have to get an ipad.

One lost android sale here. I have to buy an Ipad2 as the Android tabs are better in every way apart from Music apps. I want to play with music apps in my downtime on my Tablet and only Apple lets me do that properly. I hate Apple. I hate giving them money and yet here I am buying an Ipad

The OpenSL ES web site states:

Target Applications:
- Gaming
- Multimedia interactive applications (Mixers, composers, DJ apps)
- Interactive audio
- 3D audio
- [...]

Well, looking at the current state of Android even on higher ended devices I'd say: Target failed completely.

Why is the priority of this defect only 'medium' when it should have be 'critical' right from the beginning and why has it been this way for almost two years since this issue was started?

I agree with all of these comments, and Adam (#152) you summed it up perfectly :) - exactly where i am at...

Interesting to note that this thread is still marked as 'New' and not 'Reviewed' even after 2 years - Anyone know how to push the priority of this issue and get it reviewed and raise its visibility with Google?

There is a little 'Vote' star next to this thread and the more people that click it, the higher its rating goes... How about an effort from everyone on here to try and drive clicks (and hence the number of Votes) up ?! Maybe that will help ?!

I am developing mobile audio applications and I have to say have been thoroughly turned off Android with this latency issue. The only things I can release on Android are non-realtime post-processing tools.

I'll be (sadly) Apple only for now.

Please sort this out, Google. I look at the latency I get under Linux with el-cheapo intel cards (<5 ms) under Alsa or Jack and wonder where this huge latency is coming from.

Has anyone tried to experimental improve performance in a modified build of android?  That would be of limited deployment utility, but it might be a way to nudge the issue along.

The EE Times Issue 36906447 May 16 2011 discusses the audio latency problem in Android.

Google "aims to rewrite parts of the core scheduler to improve audio latency, which it admits is not up to the level of Apple's iOS".
According to David Sparks technical lead for media frameworks; "We hope to do something in Ice Cream Sandwich to address the audio latency problem. Some drivers and chip sets can add a hundred miliseconds of latency today. But we know we also have problems in how we schedule low-latency audio tasks; that's our biggest issue."

With Ice Cream Sandwich scheduled for 4Q, maybe Android Market Apps can use real time audio some time next year.

I've been itching to release a music app that I originally developed on the 2008 iPod Touch (min iDevice audio buffer is 6ms). 4 years is a long time to wait, but better late than never.

Two years after this issue was first started, my DesireHD still need 54.4ms of latency @44.1kHz/16bits/2ch for continuous playing, this is plain ridiculous.
I also own an Acer n50 Premium PDA and there are 7/8ms latency @22050Hz/16bits/2ch, Android should at least catch up to that, no excuses.
It's ignoble for Google to define 45ms as low-latency, but being this issue still in the "New" state it's quite acknowledging they never addressed the REAL issue, that is, simulated intervention at its finest as per the "Open API for low latency audio" video-scam in comment #107.

And really, if according to David Sparks "Some drivers and chip sets can add a hundred miliseconds of latency today" then the CDD shall specify to adopt some exotic alien-based technology, the same we can usually find in iPhones and iPods *today*.

I want to believe.

Like a lot of commenters, I wanted to develop a real time audio app but was put off by the latency problem. Unlike the above commenters, I actually did it anyway. Whether that a smart long term investment or stupid decision is an open question. Latency really is a big problem for my app, which does real-time pitch correction and vocoding. One positive thing I did learn is that you can do heavy DSP in Java on the better phones. Vocoding requires at least four FFTs per frame (if you do spectral envelope computation via the cepstral domain), and the better models can handle that.

I wrote up my experience developing the app in a blog post at http://jazarimusic.com/2011/06/audio-on-android-a-developers-perspective/. I also write about the atrociously bad frequency response of the built-in mic on the N1, which is something every audio dev should be aware of.

If you want to try the app, it's called Voloco and it's free (since I'm making almost nothing on it, consider this a warning as much as a plug).

I agree this issue is vital (as a user and developer on the Android platform). The current state (or lack of) low latency audio support also makes me (strongly) consider buying an iPad instead of an Android device. I am fond of Anroid, its platform, strategy, openness and Android development, but in the music production app section there are litteraly no Android apps that even mimic the functionality of low latency iOS apps. They say it is 'addressed' in Ice Cream Sandwich, but I hope they do more than that. Real high performance <7ms audio latency and simultaneous playback and recording is a must considering the many successful music/audio applications sold on 'the other platform'. This also means making strong(er) demands towards tablet (and phone) manufacturers/designers in terms of reducing hardware latency to meet real-time standards and implementing good quality audio inputs/outputs. Or making the possibility of real-time audio extension devices (via USB) possible.

My next phone will probably be an iPhone mainly due to this issue.  Nuff said?!?!

[Comment deleted]

Gentlemen,
To put this is to some kind of perspective on what and what cant be done.
I've been programming about 35 years, been there done that to such a point that I became disenfranchised knowing that computers over the years could be doing much more than they do. I usually point to my knees where I felt the current state of computer technology was and then my shoulders in where it should be. To give you a an aha moment... your computer doesnt do anything unless you push a key or push that mouse around. Email is about the only thing that is set to be automatic at a user level. Why?
I gave up programming about 12 years ago after serving a long stint writing high and low level audio programs for the broadcast radio industry.  I developed a satellite automation system that allowed the station to be unmanned and DJ to be who knows where. Interestingly I bowed out when Clear Channel started buying stations.
The applications I developed where run in a DOS based environment with 200mhz machines as the minimum when I started.  The programs were written multi-threaded, which a lot of tedious programming was created. With DOS , a 200mhz machine I was able to switch audio streams (start and stop) based on various inputs always less than 6ms.  It meant no matter what the user or the program was doing I had to check the status often enough to respond and get that new audio playing in less than 6ms.
So its not a matter of hardware speed obviously. This was 20 years ago when I finished that application.
Android and its marketing have gotten me excited once again as I realize the implications for computing. In fact I have told many people I haven't been this excited since I brought home a C-64 and sat with it on my bed programming financial software realizing that computers are going to be everywhere. This of course was many decades ago. I am now inspired enough to dedicate the rest of my life to drag computing a little higher than where I think it should be.
As one of the early adopters of C programming(the language I programmed in the longest), didnt know a lick of JAVA and I dove right into the Android OS and a handful Android devices and tablets. Having changed OS's 9 times and calling the Android Java  my thirteenth "language" in my lifetime I knew the grind ahead of me which was made easier (somewhat) by the years of learning new OS and languages. Computers themselves arnt doing anything much different than they done all my life.  Still got to push them around to make them do anything. My first app of course is going to be audio related seeing that I could build on my nearest experience in the radio industry.  
It has been a horrible frustrating experience finding no example code snippets to make an API go in the google reference area. The API themselves dont have when they where first implemented. For example getSessionID is a 2.3 and my target is 2.2 as shown by Google chart on which version is currently the most popular. Took me a couple of hours to find that snippet out. I noticed right away the audio delay start up problem. Under 2.2 I dont have a sessionId when I use audioTrack() which is the only one I can use because of precise dynamically generated sound waves and soundsample greater than 1 meg.
 No I havent been at programming to long under Android and lot of frustration comes from that and that I have to spend hours searching on the internet for some example that is only a few lines useful. Finding this thread that dates back almost two years begging for a very basic "play now /record now" feature is disheartening. I am sure the problem will eventually be addressed but seeing the IDE and the excitement at the recent google gathering of the UI click a drag feature added to eclipse leads me to believe that the System Programmers at Google are missing the point somewhere. I told my wife I can create a input form and connect it to a database or play a video off the web with less than 10 minutes 'coding'.  But to  get the battery voltage (which should be a system variable) or do any manipulation of all the various peripheral attributes becomes a search on how do I get or do regular application programming that isnt video playback, or filing out forms? I strongly feel that Google themselves have been caught short sighted when releasing Android and as such has problems coming to grips in prioritization.  Look how tablets are handled on the Android Market... what a device without a phone number? There are some of us who can see the great potential in Android and have and will devote considerable amount of time from our lives to nudge the ball along.
Google please dont get caught up in believing that watching video or "social media" are new.  I spent some time recently discussing with my son that Facebook/twitter and social media is no different than what was available in the telephone BBS days. Instead of checking who replied to your comment 3 or 4 times a day we now can do it 50 times a day. Isnt twitter slow speed IRC?  Sorry for the "old grey programmer ranting" but Android has me excited and lets pay attention to the getting the audio part of Android correct quick. It is our second most important sense we have - hearing. I hope the Google team is hearing me. Audio now.
rr

I am another frustated musician, owner of a GalaxyS2 for one week. This is a brilliant platform, using Audio specs much worse than my Nokia N73 using Symbian. It's simply ridiculous... Please Google! please...

Bought an iPad 2 and am so disappointed by the idea of having a device which is so restricted and crippled. Even no GPS in the Wifi version (without any clear notes of that anywhere while buying), not even a possibility to use a bluetooth GPS module, because the O/S is crippled. And go on and on... It's a shame, and that only for simple fact that Android cannot keep up with the audio latency and developers are afraid to support the hardware fragmentation. Come on Google, fix this, make sure hardware manufacturers implement this correctly, win back the developers and you will have your winner system back in business (and me as a happy 'customer').

I am also one of the many who wrote a real time audio app but can't release it due to the *huge* latency. I just can't seem to find a good excuse for it. If the hardware is up to it then the software should as well. Is there any chance for this to get fixed faster?

What are acceptable latencies for realtime audio? Not in specific use cases, but in average?

And what needs to happen on the Android platform to get realtime audio?

Android 2.3 now supports native access to audio APIs (via OpenSL) for low latency applications. With this feature: android.hardware.audio.low_latency

How low on latencies can you go now with OpenSL?


For the developers developing on Realtime audio in Android. Come with suggestions on what you think there needs to happen in the API.

It could work great for the quality of the Android platform to intergrate realtime audio. Those apps are popular on iOS as well. But it has also high potential.

replay gain PLEASE!!!

[Comment deleted]