<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 02/06/2011 20:26, Mike Oxford wrote:
    <blockquote
      cite="mid:BANLkTi=+YSDT8pmDARrOeGZKXX0EJs1tSg@mail.gmail.com"
      type="cite">
      <div>
        <meta charset="utf-8">
        <div>Can you pin down where you think you're losing the data?
           You state a hard number....where in the chain are you
          measuring?</div>
      </div>
      <div><br>
      </div>
    </blockquote>
    I've been trying to do that for several days but it's really hard to
    track it all the way through in one go because the buffer size
    changes in different stages and its not even multiples, it only
    comes together in fixed size blocks at each end. When I check each
    stage individually I'm failing to find any problem. I see I've lost
    blocks overall but the stage I'm looking at has no breaks in the
    pattern. They all seem to process the data correctly - and most of
    the time the input and output keep pace. There is no code in the
    path that could just junk blocks.<br>
    <blockquote
      cite="mid:BANLkTi=+YSDT8pmDARrOeGZKXX0EJs1tSg@mail.gmail.com"
      type="cite">
      <div>Usually in audio-processing you're going to run into issues
        in two main places; buffer starvation and codec corruption.</div>
      <div>Buffer starvation is pretty self-explanitory -- something in
        the chain cannot keep up, usually due to CPU load, lock
        contention or other data flow interruption.</div>
      <div>Codec corruption happens when the codec tries to use the new
        incoming packets against it's stored run-state.  If </div>
      <div>something happens (out of sequence, null packets, etc) the
        codec will usually do one of two things:  do its best and give
        you corrupted audio or just drop the packet on the floor as if
        it never got it.</div>
      <div><br>
      </div>
    </blockquote>
    This is akin to audio processing but the signal processing is under
    my control so there are no unknowns in the chain.<br>
    <blockquote
      cite="mid:BANLkTi=+YSDT8pmDARrOeGZKXX0EJs1tSg@mail.gmail.com"
      type="cite">
      <div>
      </div>
      <div>One more caveat with audio: output packet size is not usually
        equal to input packet size.  The most codecs do
        lossy-compression.  Just one more thing to check.</div>
      <div><br>
      </div>
    </blockquote>
    I'm using 48k input and output rate for the test. <br>
    <blockquote
      cite="mid:BANLkTi=+YSDT8pmDARrOeGZKXX0EJs1tSg@mail.gmail.com"
      type="cite">
      <div>-mox </div>
      <div><br>
        <div class="gmail_quote">
          On Thu, Jun 2, 2011 at 12:09 PM, Bob Cowdery <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:bob@bobcowdery.plus.com">bob@bobcowdery.plus.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
            0.8ex; border-left: 1px solid rgb(204, 204, 204);
            padding-left: 1ex;">
            Can anyone give me some hints on how to debug this problem.
            I know its a<br>
            long-shot but maybe someone has experience of a similar
            problem.<br>
            <br>
            I have a real-time system that reads from a device using UDP
            and writes<br>
            back to the same device using UDP. The data processing chain
            comprises 6<br>
            processes:<br>
            <br>
            Reader - Decoder - Input to linked-in-driver - output from<br>
            linked-in-driver - Encoder - Writer<br>
            <br>
            With the parameters I'm using I should be writing the same
            number of<br>
            blocks that I am reading. There are sequence numbers on both
            input and<br>
            output blocks. For a while this is what happens, then I
            start to lose<br>
            blocks. I believe in snatches rather than a regular pattern.
            I can<br>
            sometimes hear the disruption in the output and if I stop at
            that point<br>
            I've lost blocks, as many as 40 in one case. However it can
            run on way<br>
            longer than that with no lost blocks.<br>
            <br>
            I've checked every stage of the code with debug statements
            but<br>
            everything seems to pass through correctly.  I've also
            checked the<br>
            message queue length at each stage and it never builds up on
            any<br>
            process. I have no catch-all message handlers. The messages
            are all<br>
            large binary.<br>
            <br>
            The symptoms look like it just can't keep up but If a
            process was<br>
            getting behind I would expect the message q to build up. CPU
            is 5-7%.<br>
            <br>
            Any ideas would be very welcome.<br>
            <br>
            Bob<br>
            <br>
            <br>
            _______________________________________________<br>
            erlang-questions mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
            <a moz-do-not-send="true"
              href="http://erlang.org/mailman/listinfo/erlang-questions"
              target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>