Sound delay in i4b

[Dirk Thannhäuser]

On May 14, 2006, at 3:18 PM, Hans Petter Selasky wrote:

> Hi,
>
> On Sunday 14 May 2006 14:28, Dirk Thannhäuser wrote:
>> Hello Folks,
>>
>> i compiled successfully the new isdn4bsd and chan_capi on FreeBSD 6.
>> chan_capi also works fine with asterisk. As already mentiones
>> somebody before there is a huge delay on the channel when
>> transferring sound. (256ms?)
>> I experienced this using the echo test application in Asterisk.
>> As a result I began diving into the i4b source to check out the
>> problem. Soon I got stuck as I couldn't find any source for the delay
>> in the driver itself. (it was the first look into the source, and i
>> am currently learing how things work an fit together) Maybe that the
>> delay is _only_ an issue while processing sound an that i am seeking
>> for the problem at the wrong place.
>> Is there anybody who has some advice?
>
> It is due to a buffering bug in I4B, which I discovered not so long  
> ago. When
> "chan_capi" registers its CAPI application, it sets the buffer to 7  
> frames of
> 160/8ms = 20ms. The bug is that my I4B implementation did not check  
> that
> value and instead, by default, buffered up to 50 frames, which is  
> equal to
> near one second of data. Due to packet loss on IP connections, this  
> value is
> always kept low. But if you run the echo test, the buffer can grow.
>
ah that is why i got stuck with the sources :-)

> I have fixed this in the SVN version of "i4b + "chan_capi". Upgrading
> "chan_capi" should do the trick. Maybe you want to try out that first.
>
>
> Do you have SVN installed?

yes i have. I checked out the version which included both, the i4b  
and the chan_capi. Is ist possible that my version was to old?
I just did a new checkout.
Subversion says "Checked out revision 264."
Is this the current version or did I check out something wrong?
I will give it a try.

>
> The round trip delay for I4B + HFC-S PCI A, should be close to  
> 5*160/8ms =
> 100ms.

that sounds much better. :-) (I tried calling myself (My Phone -> HFC- 
S-Card(NT-Mode) -> BSD Machine -> HFC-S-Card(TE-Mode) -> Telephone  
Network and back to my Phone.) and then running the echo test  
application. As a result the latency was very high)


> It is possible to get the delay down, and the HFC-E1/HFC-4S/8S driver
> has a round trip delay of 50ms.

I currently use two HFC-S Cards. One in NT-Mode and the other in TE  
Mode.
Are there any "cheap" HFC-4S cards out there for testing?

>
> For IP-telephony the extra buffering is ideal to handle jitter and  
> other
> problems. From my experience, if the buffer delay is less than  
> 25ms, the
> transmission will get prone to clicks due to buffer underruns, when  
> the CPU
> load is high or when you loose IP-packets. For ISDN to ISDN  
> bridging it is
> not so good, and I would recommend that you buy a HFC-4S/8S card,  
> that will
> have a buffer delay of around 1ms, when line interconnect is used.

I think that this also means that i am not able to run one card  
(HFC-1S) in slave mode, getting the clock from the other to keep them  
in sync without soldering.
For Voice over IP a huger delay might be ok. thats also my opinion.  
but what about Faxing over ISDN. Here I think latency is an important  
issue. (didn't test the CAPI Fax receiption, yet)

>
> --HPS