<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><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><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><div>-mox </div><div><br><div class="gmail_quote">
On Thu, Jun 2, 2011 at 12:09 PM, Bob Cowdery <span dir="ltr"><<a href="mailto:bob@bobcowdery.plus.com">bob@bobcowdery.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>