2 Replies Latest reply on Oct 23, 2013 9:08 AM by ohookins

    Digging deeper into "Waiting for next frame"

    ohookins Level 1

      I'm trying to diagnose why my Flash app takes very long to start playing audio through a NetStream. Looking at my IDE profiler, network traffic dumps and tracing in the code itself, there is around 500ms unaccounted for, even when streaming from an AMS server running on my local machine.


      I've managed to capture the following from Scout:



      As you can see, in this frame where the playback starts, there is a whole lot of unaccounted inactive time attributed to "waiting for next frame", and as a result the frame rate (left at the default 24fps) drops to 1.3fps. A few things I've been reading on the web don't add up:

      - active time spent in code is almost nothing

      - CPU load is almost nothing (there was nothing else running)

      - based on network traffic dumps, it is the client that is hanging during this period waiting to send a request to the server, not the other way around

      - very little memory and object utiisation, same for garbage collection

      - the code involved in setting up a NetConnection and NetStream leaves very little room to screw it up (around 3 calls in total), which leaves me wondering what could possibly be going wrong here.


      Any advice for diagnosing why the app seems to be pausing here?


      EDIT: Here's the FLM file - http://cl.ly/1R3g3c3P2L20

        • 1. Re: Digging deeper into "Waiting for next frame"
          Michael J.A. Smith Adobe Employee

          I think you've answered your own question here: http://forums.adobe.com/message/5776745. I don't know enough about the RTMP implementation to offer any helpful suggestions, but if you want to file a bug report, you can do so here: https://bugbase.adobe.com/.


          From your FLM, I can make a couple of general comments:


          1) Framerate and frames only matter if you're actually using them - since in your case, you don't seem to have any timers listening for ENTER_FRAME, nor are you doing any rendering, it's meaningless to complain about the "waiting for next frame" time. I suspect (although I'm not entirely sure) that Flash Player has an optimization to throttle the frame ticker, if nothing is listening to it. The first delay in connecting to your server could be an artifact of this, since you say that it works fine if you increase the size of the swf to have non-zero dimensions.


          2) Make sure you use a release SWF for performance testing - debug SWFs (as in your case) have significantly worse performance, because of all the extra debug information and processing that happens.

          • 2. Re: Digging deeper into "Waiting for next frame"
            ohookins Level 1

            Thanks for your reply, Michael.


            Regarding debug SWF, in my testing I can reproduce both the worst-case performance and "regular" performance with the same debug SWF so I don't think that is playing a factor here. So right now I'm treating it as just a bug.


            I've filed a bug report so we'll see where that leads.