I'm guessing you've already tried increasing SASL debugging, and using dbg:tracer()?<div>How about putting a debugger (gdb or the like) on your driver?</div><div>Have you tried synthetic testing (eg, loop the same packet into your system, injected just after </div>
<div>the UDP layer and then check the output on the other side?"</div><div>You say that you're breaking the packets up for processing, and putting them back together, with </div><div>sequencing staying the same... but you're losing packets? That seems only possible if your</div>
<div>hardware isn't actually sending it (or there's a bug in your sequencing numbers/checks.)</div><div><br></div><div>Have you put Ethereal/Wireshark/tcpdump etc on the wire during the tests? Have you seen a pause</div>
<div>in output?</div><div><br></div><div>Hard to tell from this far away. =/</div><div><br><div class="gmail_quote">On Thu, Jun 2, 2011 at 2:02 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;">
<div text="#000000" bgcolor="#ffffff"><div class="im">
On 02/06/2011 20:26, Mike Oxford wrote:
<blockquote type="cite">
<div>
<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></div>
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.<div class="im"><br>
<blockquote 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></div>
This is akin to audio processing but the signal processing is under
my control so there are no unknowns in the chain.<div class="im"><br>
<blockquote 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></div>
I'm using 48k input and output rate for the test. <br><div><div></div><div class="h5">
<blockquote 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 href="mailto:bob@bobcowdery.plus.com" target="_blank">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 href="mailto:erlang-questions@erlang.org" target="_blank">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>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>