Date: Sun, 14 May 2006 22:57:54 +0200 From: =?ISO-8859-1?Q?Dirk_Thannh=E4user?= <dt@dtinnovations.com> To: freebsd-isdn@freebsd.org Subject: Re: Sound delay in i4b Message-ID: <E5B8828C-30ED-43EB-A264-2EA9983F00D9@dtinnovations.com> In-Reply-To: <200605141518.33634.hselasky@c2i.net> References: <0CDCE7F4-A7D2-4379-9560-516FFF3350C6@dtinnovations.com> <200605141518.33634.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 14, 2006, at 3:18 PM, Hans Petter Selasky wrote: > 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 =20= > ago. When > "chan_capi" registers its CAPI application, it sets the buffer to 7 =20= > frames of > 160/8ms =3D 20ms. The bug is that my I4B implementation did not check =20= > that > value and instead, by default, buffered up to 50 frames, which is =20 > equal to > near one second of data. Due to packet loss on IP connections, this =20= > 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 =20 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 =20 > 5*160/8ms =3D > 100ms. that sounds much better. :-) (I tried calling myself (My Phone -> HFC-=20= S-Card(NT-Mode) -> BSD Machine -> HFC-S-Card(TE-Mode) -> Telephone =20 Network and back to my Phone.) and then running the echo test =20 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 =20 Mode. Are there any "cheap" HFC-4S cards out there for testing? > > For IP-telephony the extra buffering is ideal to handle jitter and =20 > other > problems. =46rom my experience, if the buffer delay is less than =20 > 25ms, the > transmission will get prone to clicks due to buffer underruns, when =20= > the CPU > load is high or when you loose IP-packets. For ISDN to ISDN =20 > bridging it is > not so good, and I would recommend that you buy a HFC-4S/8S card, =20 > 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 =20 (HFC-1S) in slave mode, getting the clock from the other to keep them =20= in sync without soldering. For Voice over IP a huger delay might be ok. thats also my opinion. =20 but what about Faxing over ISDN. Here I think latency is an important =20= issue. (didn't test the CAPI Fax receiption, yet) > > --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E5B8828C-30ED-43EB-A264-2EA9983F00D9>