From anthony at it.usyd.edu.au Mon Feb 20 11:05:49 2006 From: anthony at it.usyd.edu.au (Anthony Collins) Date: Mon, 20 Feb 2006 21:05:49 +1100 Subject: [Shtoom] Shtoom performance issues Message-ID: <20060220210549.B12487@it.usyd.edu.au> Hi All, I am currently using the Shtoom and Doug frameworks for an application I am developing that is used between a number of fairly slow (Via 700Mhz) machines. There is a perceived delay of about 2-3 seconds for voice communication. This can be eliminated by muting the call (on each machine) for about 4 seconds. Does anybody have any ideas about how this could be solved? I assume this is because Shtoom is queuing up lots of RTP packets, and falling behind, and then the packets are dropped when the call is muted. What would be the best way to programmatically solve this? I would like to implement something that flushes the RTP queue if it fills up to a certain amount (if this is infact the problem). Thanks, Anthony From zooko at zooko.com Mon Feb 20 17:01:33 2006 From: zooko at zooko.com (zooko at zooko.com) Date: Mon, 20 Feb 2006 12:01:33 -0400 Subject: [Shtoom] Shtoom performance issues In-Reply-To: <20060220210549.B12487@it.usyd.edu.au> References: <20060220210549.B12487@it.usyd.edu.au> Message-ID: <20060220160133.4D7D814A5@yumyum.zooko.com> This is a known issue. In the past there have been about five different "buffering" algorithms to address this (and to trade off the latency against its evil brother -- jitter). The best one was unfortunately only for Mac OS X. It was written by Donovan Preston in Objective C. The others were written in Python and were portable, but didn't work as well as Donovan's. I wrote two of the Python ones, and my favorite was the most recent one I wrote. I'm not sure which algorithm is in the current SVN head. Regards, Zooko From fs at beebits.com Mon Feb 20 17:09:44 2006 From: fs at beebits.com (Frank Scholz) Date: Mon, 20 Feb 2006 17:09:44 +0100 Subject: [Shtoom] Shtoom performance issues In-Reply-To: <20060220210549.B12487@it.usyd.edu.au> References: <20060220210549.B12487@it.usyd.edu.au> Message-ID: <43F9E9C8.5030704@beebits.com> Hi Anthony, > I am currently using the Shtoom and Doug frameworks for an application I > am developing that is used between a number of fairly slow (Via > 700Mhz) machines. which ones? I have an EPIA MS8000, and shtoom is working fine on that. With a small delay which is due to trip-time phone<->asterisk<->shtoom in my setup. I even tried it on slower systems. I once had a delay of 4 seconds, not with shtoom, but another RTP using application, but there the reason was a firewall on my system going crazy. So the questions are: OS? which codec (I use speex)? direct shtoom<->shtoom or with asterisk or any other registrar? Ciao, Frank From anthony at it.usyd.edu.au Tue Feb 21 00:14:05 2006 From: anthony at it.usyd.edu.au (Anthony Collins) Date: Tue, 21 Feb 2006 10:14:05 +1100 Subject: [Shtoom] Shtoom performance issues In-Reply-To: <43F9E9C8.5030704@beebits.com>; from fs@beebits.com on Mon, Feb 20, 2006 at 05:09:44PM +0100 References: <20060220210549.B12487@it.usyd.edu.au> <43F9E9C8.5030704@beebits.com> Message-ID: <20060221101405.B12608@it.usyd.edu.au> Hi Frank I am using a number of EPIA ML based systems, running Debian 3.1 (2.4 Kernel), and using ALSA (with PyAlsaAudio 0.2). I am using the standard Shtoom codec (Mulaw as far as I know). I am using OpenSER as a SIP registrar only, but this is running on the same network (as all of the EPIA machines). Would I see any performance improvements by switching to a codec such as Speex? What is the best codec to improve latency on low-powered hardware? Thanks On Mon, Feb 20, 2006 at 05:09:44PM +0100, Frank Scholz wrote: > Hi Anthony, > > I am currently using the Shtoom and Doug frameworks for an application I > > am developing that is used between a number of fairly slow (Via > > 700Mhz) machines. > which ones? I have an EPIA MS8000, and shtoom is working fine on that. > With a small delay which is due to trip-time phone<->asterisk<->shtoom > in my setup. > I even tried it on slower systems. > I once had a delay of 4 seconds, not with shtoom, but another RTP using > application, but there the reason was a firewall on my system going crazy. > > So the questions are: OS? which codec (I use speex)? direct shtoom<->shtoom > or with asterisk or any other registrar? > > Ciao, > Frank From fs at beebits.com Tue Feb 21 10:20:21 2006 From: fs at beebits.com (Frank Scholz) Date: Tue, 21 Feb 2006 10:20:21 +0100 Subject: [Shtoom] Shtoom performance issues In-Reply-To: <20060221101405.B12608@it.usyd.edu.au> References: <20060220210549.B12487@it.usyd.edu.au> <43F9E9C8.5030704@beebits.com> <20060221101405.B12608@it.usyd.edu.au> Message-ID: <43FADB55.1080000@beebits.com> Hi Anthony, > I am using a number of EPIA ML based systems, the ML and MS are very similar > running Debian 3.1 (2.4 Kernel), same here, but with Kernel 2.6.14.3 + epia patches > and using ALSA (with PyAlsaAudio 0.2). still on pyalsaaudio-0.1 here > I am using the standard Shtoom codec (Mulaw as far as I know). > I am using OpenSER as a SIP registrar only, but this is running > on the same network (as all of the EPIA machines). my * is working as a media gateway too, meaning all my communication between the phones are bridged and transcoded if necessary on the *. Which should introduce more overhead than your OpenSER, as there (afaik there is no bridging) the two shtooms talk directly to each other. > Would I see any performance improvements by switching to > a codec such as Speex?What is the best codec to improve latency on > low-powered hardware? http://www.speex.org/comparison.html and I think that there is something on http://voip-info.org/ that does some comparison too. But I'm uncertain if it is a question of 'low-powered hardware'. You have the same effect with some other phone sw? And I would try a kernel with the epia patches, as I recall some issues with the ethernet module with a stock 2.6 kernel. Maybe with 2.4 too? Ciao, Frank From ryanshaw at SIMS.Berkeley.EDU Thu Feb 23 00:54:15 2006 From: ryanshaw at SIMS.Berkeley.EDU (Ryan Shaw) Date: Wed, 22 Feb 2006 15:54:15 -0800 (PST) Subject: [Shtoom] Running latest CVS on OSX? Message-ID: <51774.128.32.209.195.1140652455.squirrel@mail.sims.berkeley.edu> Hello, I am trying to get the latest CVS code running on OSX, but am having trouble determining which documentation is obsolete and which isn't... What is the current state of Shtoom on OSX? I am able to build and install via setup.py, but running shtoomphone.py I get "no working audio interface found" and running shtoomclient.py fails due to a GTK2 dependency... do I need to have GTK2 or can I run a commandline client? Output of shtoominfo.py: Shtoom, version 0.3alpha0 Using python version 2.4.2 Using twisted version 2.1.0 Running on Darwin Power Macintosh 8.4.0 Available audio interfaces: fileaudio Available user interfaces: text Available codecs: mulaw Local IP address: 192.168.1.103 UPnP discovered a Linksys BEFW11S4 V.2 (Linksys Inc.) device UPnP controlURL: http://192.168.1.1:2468//WANIPConnection STUN says NAT type: RestrictedCone And the mapper we'd use is: Cheers, Ryan From kwan at media.mit.edu Thu Feb 23 21:35:25 2006 From: kwan at media.mit.edu (Kwan Hong Lee) Date: Thu, 23 Feb 2006 15:35:25 -0500 Subject: [Shtoom] error connecting shtoomphone between machines Message-ID: <43FE1C8D.2070701@media.mit.edu> Hi, I have installed shtoomphone and have tried echo test. But when one computer tries to connect to another using sip:username@: I get the following error 2006-02-23T15:20:18.998079 [audio] audio device close 2006-02-23T15:20:18.998377 [shtoom.sip.SipProtocol (UDP)] baseaudio CLOSE False 2006-02-23T15:20:18.998603 [shtoom.sip.SipProtocol (UDP)] ossaudiodev closing 2006-02-23T15:20:18.999457 [shtoom.sip.SipProtocol (UDP)] baseaudio REOPEN True 2006-02-23T15:20:18.999783 [shtoom.sip.SipProtocol (UDP)] ossaudiodev opening default device 2006-02-23T15:20:19.018158 [sip] failedIncoming because 2006-02-23T15:20:19.018423 [sip] exception: (2, 'No such file or directory') I have not registered the sip phone since I thought one doesn't need to do it between computers. Any help setting this up would be greatly appreciated. -kwan -- http://www.media.mit.edu/~kwan/info.html