[erlang-questions] Losing data

[Mike Oxford]

Can you pin down where you think you're losing the data?  You state a hard
number....where in the chain are you measuring?

Usually in audio-processing you're going to run into issues in two main
places; buffer starvation and codec corruption.
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.
Codec corruption happens when the codec tries to use the new incoming
packets against it's stored run-state.  If
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.

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.

-mox

On Thu, Jun 2, 2011 at 12:09 PM, Bob Cowdery <bob@REDACTED>wrote:

> Can anyone give me some hints on how to debug this problem. I know its a
> long-shot but maybe someone has experience of a similar problem.
>
> I have a real-time system that reads from a device using UDP and writes
> back to the same device using UDP. The data processing chain comprises 6
> processes:
>
> Reader - Decoder - Input to linked-in-driver - output from
> linked-in-driver - Encoder - Writer
>
> With the parameters I'm using I should be writing the same number of
> blocks that I am reading. There are sequence numbers on both input and
> output blocks. For a while this is what happens, then I start to lose
> blocks. I believe in snatches rather than a regular pattern. I can
> sometimes hear the disruption in the output and if I stop at that point
> I've lost blocks, as many as 40 in one case. However it can run on way
> longer than that with no lost blocks.
>
> I've checked every stage of the code with debug statements but
> everything seems to pass through correctly.  I've also checked the
> message queue length at each stage and it never builds up on any
> process. I have no catch-all message handlers. The messages are all
> large binary.
>
> The symptoms look like it just can't keep up but If a process was
> getting behind I would expect the message q to build up. CPU is 5-7%.
>
> Any ideas would be very welcome.
>
> Bob
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110602/5b9a7f58/attachment.htm>