Re: Sound delay in i4b
Dirk Thannhäuser <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.isdn |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isdn To unsubscribe, send any mail to "[email protected]"