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

[Dan Austin]

>> 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.
Some devices are very good at reassembling audio with excess jitter and
delay, and these devices hide the problem.  If you have devices that
are not good at this, they are ideal for testing your code.

>> 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?
The short answer is yes.  The longer answer is that a packet should
be sent using the ptime interval.  If ptime is 30ms, then a packet
should be sent every 30ms, and only one packet.  This will be true
for every conversion, but critically important for conversions that
have residual data in the buffer.

>> 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.
You did not mention how you were deciding to transmit the packet.
The two likely methods are when a packet has enough data or when
enough time has passed since the last transmission.  The first
method is easy, but jitter prone, but I did not want to assume
it is the method you used.

Dan