From owner-freebsd-isdn@FreeBSD.ORG Sun May 14 20:58:04 2006 Return-Path: X-Original-To: freebsd-isdn@freebsd.org Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB97F16A402 for ; Sun, 14 May 2006 20:58:03 +0000 (UTC) (envelope-from dt@dtinnovations.com) Received: from dtserv.dtinnovations.com (dtserv.dtinnovations.com [212.20.164.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id E67F243D53 for ; Sun, 14 May 2006 20:58:02 +0000 (GMT) (envelope-from dt@dtinnovations.com) Received: from [212.20.180.34] (office.dinslaken.dtinnovations.com [212.20.180.34]) (authenticated bits=0) by dtserv.dtinnovations.com (8.13.4/8.13.4) with ESMTP id k4EKuCHH033110; Sun, 14 May 2006 22:56:13 +0200 (CEST) (envelope-from dt@dtinnovations.com) In-Reply-To: <200605141518.33634.hselasky@c2i.net> References: <0CDCE7F4-A7D2-4379-9560-516FFF3350C6@dtinnovations.com> <200605141518.33634.hselasky@c2i.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Dirk_Thannh=E4user?= Date: Sun, 14 May 2006 22:57:54 +0200 To: freebsd-isdn@freebsd.org X-Mailer: Apple Mail (2.750) Cc: Subject: Re: Sound delay in i4b X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2006 20:58:04 -0000 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