Skip navigation
Currently Being Moderated

Best settings for Audio + play() latency

May 6, 2011 11:20 AM

Can anyone reccomend the best audio settings/audio export settings to use for game sound effects in android and/or iOS.

I have done a little bit of experimenting, but not sure on the best to use yet.

 

my concerns are performance, size, and of delay when calling play()

 

The delay when calling play() is still very present for me on android.I have tried many settings, wavs and mp3s. Hopefuly i am doing something wrong here...

 
Replies
  • Currently Being Moderated
    May 7, 2011 9:35 PM   in reply to boat5

    Have mp3 as an external file with the minimum of 64kbps

     
    |
    Mark as:
  • Currently Being Moderated
    May 17, 2011 2:25 PM   in reply to relaxatraja

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    May 17, 2011 10:22 PM   in reply to boat5

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    May 17, 2011 11:54 PM   in reply to relaxatraja

    The key difference is Android. The Android OS has a built in latency that can be up to one second long. Typically it seems that sounds happen half a second late. Not sure if that will be improved in future Android OS.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 2:28 AM   in reply to Colin Holgate

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 5:43 AM   in reply to EarwigTC

    Here is nearly two years of debate about audio latency issues in Android, nothing to do with AIR:

     

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

     

    Here's an article talking about the latency difference between iPad and Android:

     

    http://www.androidannoyances.com/post/38

     

    That article only goes as far as Android 2.3. I have an Android 3.01 tablet at work, I'll test how that does later. Can you suggest any, preferably free, native Android app that requires fast responding audio?

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 7:08 AM   in reply to Colin Holgate

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 7:13 AM   in reply to EarwigTC

    I'll try that Dillo Hills Lite and let you know how it goes, and your test file.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 7:14 AM   in reply to EarwigTC

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

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 8:36 AM   in reply to EarwigTC

    Here you go...

     

    Dillo Hills sound is very slow to respond, but I think it may be that the sound is triggered after the visual effect of going to the next menu.

     

    Your test APK plays the sound sooner than Dillo Hills does, by a long way, on the first playing of the sound. On subsequent plays the sound is laggy, like it is in Dillo Hills.

     

    Trying the swf, or the FLA, has the opposite situation, the sound is late the first time, then instant after that.

     

    On my iPad it's a similar situation, longer delay for the first play, and then almost instant from then on.

     

    So, the longer delay on subsequent plays seems wrong, but the delay of the first play of the sound is comparible, or better, than native Android apps.

     

    I'll make sure the authorities know about the subsequent delay issue.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 8:50 AM   in reply to Colin Holgate

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 7:17 PM   in reply to boat5

    When I talked about the FLA and SFW, I meant on my Mac, and the first time it plays a sound is slightly delayed compared to subsequent plays. You have to pay attention though, the difference is only slight.

     

    I haven't heard back from questions I've asked, but I read things in public Adobe postings that could hint at some hope. Blogs and conference talks by the Flash team have talked about improved garbage collection in Flash Player 10.3, AIR 2.7, and the Incubator builds. See here:

     

    http://labs.adobe.com/technologies/flashplatformruntimes/incubator/

     

    and here:

     

    http://sonnati.wordpress.com/2011/04/20/more-informations-about-flash- player-11-air-2-7-and-above/

     

    Garbage collection is exactly the kind of thing that could lead to delayed audio, and you can imagine that it could explain why the first time a sound plays there is less lag, as there's no garbage to collect.

     

    So, I would stop worrying too much about audio lag until AIR 2.7 is released. I don't know when that will be, but other public statements from Adobe employees have suggested it's within the next six weeks.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 7:56 PM   in reply to Colin Holgate

        Yeah, that's my plan.  It would be nice to at least know they're looking at it.  If it isn't useable in a couple months, I'll arrive at the fish-or-cut-bait moment, and will have to abandon AIR for Android as "not ready for prime time", and go native across all platforms.  Sad.  Especially since the bit blitting and other stuff all works great.

     
    |
    Mark as:
  • Currently Being Moderated
    May 19, 2011 8:41 PM   in reply to EarwigTC

    Can I point to your test files as part of a bug report that the AIR team would look at?

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2011 6:06 AM   in reply to Colin Holgate

    Yes, I'll leave it up.  Are you submitting at bugbase.adobe.com?  I was going to do one this weekend but won't if you're already on it.

     
    |
    Mark as:
  • Currently Being Moderated
    May 20, 2011 6:27 AM   in reply to EarwigTC

    I logged it, not there, but somewhere good.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 14, 2011 9:00 PM   in reply to Colin Holgate

    Hi

    You will be pleased to know that AIR 2.7 is released, seehttp://blogs.adobe.com/flashplayer/2011/06/adobe-air-2-7-now-available -ios-apps-4x-faster.html. We have fixed the speex delay issue for iOS to an extent. If you are developing on iOS, please try the new SDK and let us know if the fix works for you.

     

    Thanks,

    Sanika

    AIR team

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 14, 2011 11:07 PM   in reply to sanika Kulshreshtha

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 19, 2011 8:49 AM   in reply to boat5

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 19, 2011 9:07 AM   in reply to Jack Freudenheim

    I checked the bug I reported exactly a month ago, and it is still listed as unverified. I've asked if the bug report could be moved to somewhere that it might be seen.

     

    Meanwhile, could you not perfect your app for iOS, and then either Android will have improved by then, and you ship the app for both, or it hasn't improved, and you just make your fortune off of the iOS version?

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 6:25 AM   in reply to Colin Holgate

    Hi Colin,

    Could you post the bug number here?

     

    Also, has anybody tried it on iOS?

     

    Thanks,

    Sanika

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 6:40 AM   in reply to sanika Kulshreshtha
    I'm hoping to try it today, once I get my developer membership  authorized by apple ($99 - yuck!) and I'll post my results to this thread.

    Jack
     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 6:46 AM   in reply to sanika Kulshreshtha

    The bug number is #2877303. Audio on iOS works well.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 7:01 AM   in reply to Colin Holgate

    Given that the sole reason I'm testing AIR mobile development is for the cross-platform development time savings, I have no reason to use it for a single platform.  I think there's an over-focus on iOS packager right now.  If it becomes the only mobile platform that runs this stuff effectively, serious developers will just do native iOS development, because what's the point in tolerating all the overhead otherwise?

     

    I'm shelving it until either audio works on Android or AIR for Windows Mobile blows me away.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 7:17 AM   in reply to EarwigTC

    Other non-native tools also get audio lag on Android, and the forums for people doing native Android apps have some lengthy debates about the audio latency issues. So, you may have a long wait!

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 7:35 AM   in reply to Colin Holgate

    Those discussions are about ultra-low latency for things like music processing applications.  My performance tests in java with the SDK have been great.  AIR has failed to achieve even a level of casual usability where a human perceives the sound as happening at about the same time as another event.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 20, 2011 7:47 AM   in reply to EarwigTC

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

     

    We are working on this, but Android audio is a really hard  problem. Android audio is currently just terrible so we don't have much  to work with. You just need to Google it to see for yourself.

    http://code.google.com/p/android/issues/detail?id=3434
    http://kile.stravaganza.org/blog/post/android-audio-api-sucks
    http://www.badlogicgames.com/wordpress/?p=1315
    http://groups.google.com/group/android-ndk/browse_thread/thread/29f88a 99...
    http://mindtherobot.com/blog/555/android-audio-problems-hidden-limitat io...
    http://music.columbia.edu/pipermail/portaudio/2010-December/011146.htm l

    That said, I just pushed some new changes to the Android OpenAL  backend today that try to improve the latency. This needs to be tested  by all of you to make sure it doesn't break things in other ways.

    We are investigating OpenSL ES as a new backend to OpenAL, but it  requires Android 2.3+. But early word on the internet is that the  performance is still terrible. I suspect that we will need to wait for  hardware makers to get their act together as well to take advantage of  OpenSL ES.

     

    We've got to hope that adobe can fix this problem for us - I was very psyched to do a music-oriented cross-platform app in AIR.

     

    Jack

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 1, 2011 3:21 PM   in reply to boat5

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 24, 2012 11:27 AM   in reply to boat5

    Count us in. We're seeing pretty bad sound latency on Nook and Kindle Fire too.

     
    |
    Mark as:
  • Currently Being Moderated
    May 4, 2013 2:49 AM   in reply to boat5

    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.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points