Date: Sun, 14 May 2006 15:18:33 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-isdn@freebsd.org Cc: Dirk =?iso-8859-1?q?Thannh=E4user?= <dt@dtinnovations.com> Subject: Re: Sound delay in i4b Message-ID: <200605141518.33634.hselasky@c2i.net> In-Reply-To: <0CDCE7F4-A7D2-4379-9560-516FFF3350C6@dtinnovations.com> References: <0CDCE7F4-A7D2-4379-9560-516FFF3350C6@dtinnovations.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Sunday 14 May 2006 14:28, Dirk Thannh=E4user 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. Wh= en=20 "chan_capi" registers its CAPI application, it sets the buffer to 7 frames = of=20 160/8ms =3D 20ms. The bug is that my I4B implementation did not check that= =20 value and instead, by default, buffered up to 50 frames, which is equal to= =20 near one second of data. Due to packet loss on IP connections, this value i= s=20 always kept low. But if you run the echo test, the buffer can grow. I have fixed this in the SVN version of "i4b + "chan_capi". Upgrading=20 "chan_capi" should do the trick. Maybe you want to try out that first. Do you have SVN installed?=20 The round trip delay for I4B + HFC-S PCI A, should be close to 5*160/8ms = =3D=20 100ms. It is possible to get the delay down, and the HFC-E1/HFC-4S/8S drive= r=20 has a round trip delay of 50ms. =46or IP-telephony the extra buffering is ideal to handle jitter and other= =20 problems. From my experience, if the buffer delay is less than 25ms, the=20 transmission will get prone to clicks due to buffer underruns, when the CPU= =20 load is high or when you loose IP-packets. For ISDN to ISDN bridging it is= =20 not so good, and I would recommend that you buy a HFC-4S/8S card, that will= =20 have a buffer delay of around 1ms, when line interconnect is used. =2D-HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605141518.33634.hselasky>