relaxatraja, you can confirm you have acceptable levels of latency?  What Android device and what version of Android?  I have tested this with countless sounds and phones, and have a half second latency on every sound after the first that plays.

I do attachments in the packager for iphone for external mp3 and use sound class within my main fla. Not faced any issues on delay.

I don't mean to sound snide, but obviously the difference is Android, and obviously the AIR player (not Android itself) is the problem, since native sound works great.  My questions remain:

- No workarounds yet?  With the number of people claiming to have 'released' software for Android, I expected that someone had found one, but that doesn't seem to be the case.  Every one I've found suffers this problem.

- No word from Adobe on cause or correction?

This basically keeps AIR for Android in the realm of 'toy' instead of legitimate platform.  Wish I'd known it before I'd started an implementation.

Those discussions seem to pertain to ultra-low latency, near-real-time sound, like music creation.  The AIR problem that I, boat5 and others see is like this: it plays the sound in a timely enough fashion (not ultra-low, but certainly well under 100ms) the first time it's play()ed, then subsequent playing of ANY sound has a very long (around 400-500ms on my tests) delay before playing.  'Latency' probably isn't even a good term, since it's a truly massive delay.  Wait several (maybe 15 or 20) seconds before calling any play()s again, and it will once more play quickly... but just once, then delayed again.

The best test is to simply make a tiny button-that-plays-a-sound AIR app and load it up on an Android device.  It demonstrates the issue on my Droid 2/Froyo nicely.  It happens whether using the standard object model, or a more game-like looping of the ENTER_FRAME event.  Here's one I did in CS5 that you can use to test.

I've downloaded several AIR-based games, and see the problem in all of them.  The most recent one I downloaded is a Tiny Wings clone called "Dillo Hills LITE".  Click an item in the main menu, and the corresponding sound plays a half second late, after the button animation has already finished.

Compiling a simple sound-playing native app does not have this first-sound-fast/later-sounds-slow problem, and needless to say you can download hundreds of native apps with timely sound.  I don't really see how this could be caused by anything but AIR.

Tested on a handful of phones, from 2.1 to 2.3.  I have not yet tested on tablets or 3, so I'm interested to know what you find.

Sorry, typo, not tested on 2.1.  I don't believe AIR player runs on 2.1.

Thanks.  Since Dillo Hills plays the background music first, I'm sure that's counting as the first 'on time' sound, and the effects then lag.

A slow first time would make more sense in the world of Flash and memory, and is easy to cope with.  The later delays are not.  Most of us don't need a 15ms response, we just need it to be fast enough to not look unprofessional.

Let me know who I can contact to help keep the pressure up.

Just updated to 2.7.0.1948 player on my Droid 2 and there is no change at all in the audio performance.  The problem does not appear to have been corrected on Android.  I will pull down the SDK tomorrow and compile with 2.7, but I am not hopeful.

I'm having the same problem and it will stop me from using Flash Builder to develop a music-oriented application.

Is there any progress on this?

I just looked at the Corona forum and found this, which doesn't bode well:

Just to put in a current two cents: this is happening still. Hope someone addresses it as it makes any sort of game - or for that matter any UI - pretty amateurish looking/sounding. I am using Flash CS5.5 and Air for Android and running the app on a Galaxy Tab 10.1 with Air 2.7.1.1961. I see terible delays in sound effects playing. Like more than 1/4 second delay on a sound effect tied to a button press. And even worse on the in game FX.

Any word on a possible fix any time soon?

Let's be clear:

1) There is "acceptable" latency of the order of half a sec or so ( often less ), which according to the post by Holgate, #7 above, is an issue with -- some versions of ( ? ) -- Android ( not Air specifically ).

2) Then, there is unacceptable delay, which appears to be specific to Air on some Android devices ( particularly Nook Color and Kindle Fire ), where a sound will sometimes play in near sync ( with "normal" Android latency ), and sometimes with a delay of SEVERAL SECONDS ( like 5 or 10, in one of my apps! ), which apparently has something to do with garbage collection ( Holgate post #14, above ).

I can confirm that the unacceptable delay has NOT been fixed as of Air 3.6, testing on Nook Color and Kindle Fire, though it is fine ( no delay ) on the Nexus One.

As pointed out in another forum, playing all your sounds in a silent loop, will prevent sounds from being garbage collected, and will eliminate the delay issue whenever you play a sound, like so:

private function initSounds():void

{

     var silentSndXF:SoundTransform = new SoundTransform( 0 );

     _sound01.play( 0, int.MAX_VALUE, silentSndXF );

     _sound02.play( 0, int.MAX_VALUE, silentSndXF );

     _sound03.play( 0, int.MAX_VALUE, silentSndXF );

     // Note: int.MAX_VALUE is about 2 billion, so even a very short "click" sound of 1/20

     // of a sec would play for 3 years or so -- if the app was never closed !!

}

private function onButtonClick( evt:MouseEvent ):void

{

     _sound01.play();

}

This hack eliminated the severe delay I was getting on Nook Color and Kindle Fire ( several seconds for some sounds, in some situations ), leaving me with the "regular", acceptable Android latency.