[asterisk-dev] asterisk-dev Digest, Vol 104, Issue 34

[Rifat Rahman]

Hello Dan,

> I suspect the jitter may follow a pattern, as I saw something similar
> when packetization support was added to Asterisk. Due to how outgoing
> packets were the average jitter would approximate the smaller ptime of the
> two legs.  This was easiest to see with p1=20ms and p2=30ms:

Thanks for the info that when packetizatization was added to Asterisk,
same things were
observed. May be I am hitting the right thing. And again a large
thanks for the simulation
with packets p1=20ms and p2=30ms.

> 0.00 - start conversation
> 0.02 - p1(1) arrives, not enough data to assemble p2(1)
> 0.04 - p1(2) arrives, p2(1) assembled, leaving 10ms in the buffer
> 0.06 - p1(3) arrives, p2(2) assembled and sent 10ms early, buffer empty
> 0.08 - repeat

This is exactly the same thing I am doing. Tracking connection via
some lists, hash tables,
and then freeing buffer. I am optimizing the list search. But is there
any other problem?
I thought the inefficiency of the searching and merging led me to the
problem of robotic
voice. But maybe other things are to be considered which I have little
or no idea at all.

I once wrote it in userspace. And the module fell catastrophically: NO
VOICE was found.
Although captured packets were perfect. We found huge delta and zitter
that time.
Now in kernel space, voice is found, but robotic. I used the speed of
execution of
kernel level code than userspace: and hence the gain (partially) in
delta and zitter.

> The device receiving p2 would see two 30ms packets in 40ms and then
> the next packet after another 40ms.  Some devices handled the jitter,
> others would reproduce the audio with a 'robotic' quality.

Does it depends on the end device? How should then I proceed? Is it a problem in
the module, or i should look at the zitter buffer in the client. I am
writing the code
for ptime increase in a more efficient way.

> If your module is sending packets as soon as they are complete you
> would see this.

Then should I hold the packets for some time and then send them?

> If you are actually using the larger ptime to
> schedule the packet transmission, then this observation is not
> likely to help you.

I don't get the point.

Thanks for your wise reply once again.

Rifat