From daf at muse.19inch.net  Mon Feb  7 13:00:14 2005
From: daf at muse.19inch.net (Dafydd Harries)
Date: Mon, 7 Feb 2005 12:00:14 +0000
Subject: [Shtoom] visible passwords
Message-ID: <20050207120014.GF6791@muse.19inch.net>


I've noticed that the register_authpasswd option is a StringOption
rather than a PasswordOption. Attached is a patch to fix this. While
fixing this, I also found a password widget in the Glade file for the
auth dialog (which I've never actually seen instantiated) which has
visibility set to True. The patch fixes this also.

-- 
Dafydd
-------------- next part --------------
Index: shtoom/opts.py
===================================================================
--- shtoom/opts.py	(revision 1234)
+++ shtoom/opts.py	(working copy)
@@ -12,7 +12,7 @@
     return username
 
 def buildOptions(app):
-    from shtoom.Options import AllOptions, OptionGroup, StringOption, NumberOption, ChoiceOption, BooleanOption
+    from shtoom.Options import AllOptions, OptionGroup, StringOption, PasswordOption, NumberOption, ChoiceOption, BooleanOption
     opts = AllOptions()
 
     app.appSpecificOptions(opts)
@@ -43,7 +43,7 @@
                         'URI of registration server (e.g. sip:divmod.com:5060)'))
     register.addOption(StringOption('register_user','Username to register'))
     register.addOption(StringOption('register_authuser','Username to use for auth'))
-    register.addOption(StringOption('register_authpasswd','Passwd to use for auth'))
+    register.addOption(PasswordOption('register_authpasswd','Passwd to use for auth'))
     opts.addGroup(register)
 
     debug = OptionGroup('debug', 'Debugging', gui=False)
Index: shtoom/ui/gnomeui/shtoom.glade
===================================================================
--- shtoom/ui/gnomeui/shtoom.glade	(revision 1234)
+++ shtoom/ui/gnomeui/shtoom.glade	(working copy)
@@ -519,7 +519,7 @@
 		  <property name="visible">True</property>
 		  <property name="can_focus">True</property>
 		  <property name="editable">True</property>
-		  <property name="visibility">True</property>
+		  <property name="visibility">False</property>
 		  <property name="max_length">0</property>
 		  <property name="text" translatable="yes"></property>
 		  <property name="has_frame">True</property>

From anthony at interlink.com.au  Mon Feb  7 15:42:14 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue, 8 Feb 2005 01:42:14 +1100
Subject: [Shtoom] visible passwords
In-Reply-To: <20050207120014.GF6791@muse.19inch.net>
References: <20050207120014.GF6791@muse.19inch.net>
Message-ID: <200502080142.16565.anthony@interlink.com.au>

On Monday 07 February 2005 23:00, Dafydd Harries wrote:
> I've noticed that the register_authpasswd option is a StringOption
> rather than a PasswordOption. Attached is a patch to fix this. While
> fixing this, I also found a password widget in the Glade file for the
> auth dialog (which I've never actually seen instantiated) which has
> visibility set to True. The patch fixes this also.

Woops. I dunno how that slipped through. Thanks! Patch has been
applied.


From daf at muse.19inch.net  Mon Feb  7 16:02:44 2005
From: daf at muse.19inch.net (Dafydd Harries)
Date: Mon, 7 Feb 2005 15:02:44 +0000
Subject: [Shtoom] hash-bang lines
Message-ID: <20050207150244.GG6791@muse.19inch.net>


Attached is a script which makes the #! lines in script/*.py consistent
-- i.e. it adds #! lines to scripts which don't have them and changes
shreadder.py so that s/python2.3/python/.

-- 
Dafydd
-------------- next part --------------
--- shtoom-0.2+svn20050124.orig/scripts/testdoug.py
+++ shtoom-0.2+svn20050124/scripts/testdoug.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 #
 # Hack hack hack.
 import sys, os
--- shtoom-0.2+svn20050124.orig/scripts/shreadder.py
+++ shtoom-0.2+svn20050124/scripts/shreadder.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python2.3
+#!/usr/bin/env python
 
 
 import struct, math, sys
--- shtoom-0.2+svn20050124.orig/scripts/testcisco.py
+++ shtoom-0.2+svn20050124/scripts/testcisco.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 #
 # This is a test-bed for working out _how_ a VoiceApp would look.
 #
--- shtoom-0.2+svn20050124.orig/scripts/shmessage.py
+++ shtoom-0.2+svn20050124/scripts/shmessage.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 #
 # Hack hack hack.
 # This thing allows the script to be run from a subdirectory of the
--- shtoom-0.2+svn20050124.orig/scripts/shecho.py
+++ shtoom-0.2+svn20050124/scripts/shecho.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 #
 # Hack hack hack.
 import sys, os
--- shtoom-0.2+svn20050124.orig/scripts/shtam.py
+++ shtoom-0.2+svn20050124/scripts/shtam.py
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 #
 # Hack hack hack.
 import sys, os

From zooko at zooko.com  Wed Feb  9 05:59:43 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: 8 Feb 2005 20:59:43 -0800
Subject: [Shtoom] playout patch
Message-ID: <570be7e05994111eaa0b81e2cad738cb@zooko.com>

This patch is against svn head.  I thought it passed its self-test 
today, which you have to run directly -- not from trial.  However, now 
it does not pass its own tests.  So please do not apply this patch, and 
I will work on it tomorrow, but tonight I'm too tired, and I'm just 
sending it so you'll have it in case I get hit by a bus tonight.

This patch changes several things that it does not necessarily have to, 
but as Blaise Pascal once said "I apologize for making this letter too 
long, but I had not the time to make it shorter.".

Regards,

Zooko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnworld-also-playout-new.patch
Type: application/octet-stream
Size: 48030 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050208/c569564a/attachment.obj>

From zooko at zooko.com  Thu Feb 17 22:00:19 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: 17 Feb 2005 17:00:19 -0400
Subject: [Shtoom] new versions of playout and test_playout
Message-ID: <21390e2cd5b499aa05353756605d4f6e@zooko.com>

(Still doesn't work, but I thought maybe someone would like to see 
what's going on.)

--Z


-------------- next part --------------
A non-text attachment was scrubbed...
Name: playout.py
Type: application/octet-stream
Size: 6383 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050217/b234fffc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_playout.py
Type: application/octet-stream
Size: 5399 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050217/b234fffc/attachment-0001.obj>

From daf at muse.19inch.net  Fri Feb 18 14:05:12 2005
From: daf at muse.19inch.net (Dafydd Harries)
Date: Fri, 18 Feb 2005 13:05:12 +0000
Subject: [Shtoom] run-time UI selection
Message-ID: <20050218130512.GZ6791@muse.19inch.net>

Shtoom currently checks for the availability of various libraries such
as GTK at runtime before choosing which UI to use. However, it's
desirable for packaging Shtoom that the various Shtoom UI modules be
separated into separae packages for better dependency handling. Attached
is a patch which makes Shtoom check for the availability of its own UI
modules.

-- 
Dafydd
-------------- next part --------------
--- shtoom-0.2+svn20050218.orig/shtoom/avail/ui.py
+++ shtoom-0.2+svn20050218/shtoom/avail/ui.py
@@ -16,8 +16,9 @@
 def getQtInterface(fail=False):
     try:
         import qt
+        import shtoom.ui.qtshtoom
     except (ImportError, SystemError):
-        cleanup('qt')
+        cleanup('qt', 'shtoom.ui.qtshtoom')
         qt = None
         if fail:
             raise
@@ -29,8 +30,9 @@
     try:
         import wx
         import wxPython.wx
+        import shtoom.ui.wxshtoom
     except:
-        cleanup('wx', 'wxPython', 'wxPython.wx')
+        cleanup('wx', 'wxPython', 'wxPython.wx', 'shtoom.ui.wxshtoom')
         wx = None
         if fail:
             raise
@@ -43,8 +45,9 @@
     import sys
     try:
         import Tkinter
+        import shtoom.ui.tkshtoom
     except ImportError:
-        cleanup('Tkinter', '_tkinter')
+        cleanup('Tkinter', '_tkinter', 'shtoom.ui.tkshtoom')
         Tkinter = None
         if fail:
             raise
@@ -59,8 +62,10 @@
         import gnome.ui
         import gtk
         import gtk.glade
+        import shtoom.ui.gnomeshtoom
     except ImportError:
-        cleanup('pygtk', 'gnome', 'gtk', 'gtk.glade', 'gnome.ui')
+        cleanup('pygtk', 'gnome', 'gtk', 'gtk.glade', 'gnome.ui',
+            'shtoom.ui.gnomeshtoom')
         if fail:
             raise
         gtk = None

From zooko at zooko.com  Mon Feb 21 14:05:02 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: 21 Feb 2005 09:05:02 -0400
Subject: [Shtoom] Fwd: [p2p-hackers] Final version of "P2P over NAT" paper
	available
Message-ID: <5019e548486df94099c6c66d653acfc1@zooko.com>

 From the p2p-hackers mailing list, discussion of the effectiveness of 
"hole-punching", e.g. sending a useless UDP packet to your peer, even 
though you know that your peer's NAT will discard it, in order to prime 
*your* NAT to accept incoming UDP packets from your peer.  See this new 
paper by Bryan Ford et al.:


Peer-to-Peer Communication Across Network Address Translators, Bryan 
Ford,
Pyda Srisuresh, and Dan Kegel. USENIX Annual Technical Conference, 
April 2005.
(PDF) http://www.brynosaurus.com/pub/net/p2pnat.pdf
(HTML) http://www.brynosaurus.com/pub/net/p2pnat/

--Z

Begin forwarded message:

> From: Alex Pankratov <ap at hamachi.cc>
> Date: 2005, February 19,  16:13:24 AST
> To: "Peer-to-peer development." <p2p-hackers at zgp.org>
> Subject: Re: [p2p-hackers] Final version of "P2P over NAT" paper 
> available
>
> Well, based on same stats it looks like 'hole punching' as it's
> described in p2pnat paper succeeds in ~84% of the cases. Our
> proggy is a bit more complex than that so our success rate is
> about 97%.
>
> Alex
>
> David Barrett wrote:
>
>> Heh, great validation of the results.
>> So if what's the latest values for the following chart:
>>                         NAT'd     Firewalled
>>                      +---------+-------------
>> % Able to hole punch |  82.2%  |   50-60% *
>> % of total internet  |   ??    |     ??
>>                      +---------+-------------
>> % Benefiting         |   ??    |     ??
>> * http://zgp.org/pipermail/p2p-hackers/2004-December/002215.html
>> Basically, I'd like to get a better understanding of what fraction of 
>> all
>> internet users might benefit from these techniques, estimated as the 
>> product
>> of the above rows.
>> -david
>>> -----Original Message-----
>>> From: p2p-hackers-bounces at zgp.org 
>>> [mailto:p2p-hackers-bounces at zgp.org] On
>>> Behalf Of Alex Pankratov
>>> Sent: Friday, February 18, 2005 11:04 PM
>>> To: Peer-to-peer development.
>>> Subject: Re: [p2p-hackers] Final version of "P2P over NAT" paper 
>>> available
>>>
>>> Bryan,
>>>
>>> Quoting your paper -
>>>
>>> > .. we find that about 82% of the NATs tested support hole punching
>>> > for UDP.
>>> > ..
>>>
>>>> The NAT Check data we gathered consists of 380 reported data points
>>>
>>> > ..
>>>
>>> I happened to have statistics for more than 16000 'data poits', and
>>> check this out - the rate of 'identity preserving' NAT devices 
>>> suitable
>>> for hole punching works out to be 82.2%. *UDP* hole punching that is.
>>>
>>> Alex
>>>
>>> Bryan Ford wrote:
>>>
>>>
>>>> Hi folks,
>>>>
>>>> For those interested in P2P-over-NAT issues, I just wanted to 
>>>> announce
>>>
>>> that
>>>
>>>> the final version of the following paper, to appear in USENIX '05, 
>>>> is
>>>
>>> now
>>>
>>>> available:
>>>>
>>>> Peer-to-Peer Communication Across Network Address Translators, Bryan
>>>
>>> Ford,
>>>
>>>> Pyda Srisuresh, and Dan Kegel. USENIX Annual Technical Conference, 
>>>> April
>>>> 2005.
>>>> (PDF) http://www.brynosaurus.com/pub/net/p2pnat.pdf
>>>> (HTML) http://www.brynosaurus.com/pub/net/p2pnat/
>>>>
>>>> An earlier draft of this paper was announced on this list a few 
>>>> months
>>>
>>> ago.
>>>
>>>> The final version includes, among other minor revisions, new "NAT 
>>>> Check"
>>>> testing results based on almost twice the number of data points as 
>>>> the
>>>> original draft.
>>>>
>>>> Cheers,
>>>> Bryan
>>>>
>>>> ---
>>>>
>>>> Abstract:
>>>>
>>>> Network Address Translation (NAT) causes well-known difficulties for
>>>> peer-to-peer (P2P) communication, since the peers involved may not 
>>>> be
>>>> reachable at any globally valid IP address. Several NAT traversal
>>>
>>> techniques
>>>
>>>> are known, but their documentation is slim, and data about their
>>>
>>> robustness
>>>
>>>> or relative merits is slimmer. This paper documents and analyzes 
>>>> one of
>>>
>>> the
>>>
>>>> simplest but most robust and practical NAT traversal techniques,
>>>
>>> commonly
>>>
>>>> known as ``hole punching.'' Hole punching is moderately 
>>>> well-understood
>>>
>>> for
>>>
>>>> UDP communication, but we show how it can be reliably used to set up
>>>> peer-to-peer TCP streams as well. After gathering data on the
>>>
>>> reliability of
>>>
>>>> this technique on a wide variety of deployed NATs, we find that 
>>>> about
>>>
>>> 82% of
>>>
>>>> the NATs tested support hole punching for UDP, and about 64% support
>>>
>>> hole
>>>
>>>> punching for TCP streams. As NAT vendors become increasingly 
>>>> conscious
>>>
>>> of the
>>>
>>>> needs of important P2P applications such as Voice over IP and online
>>>
>>> gaming
>>>
>>>> protocols, support for hole punching is likely to increase in the
>>>
>>> future.
>>>
>>>> _______________________________________________
>>>> p2p-hackers mailing list
>>>> p2p-hackers at zgp.org
>>>> http://zgp.org/mailman/listinfo/p2p-hackers
>>>> _______________________________________________
>>>> Here is a web page listing P2P Conferences:
>>>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>>>>
>>>>
>>>
>>> _______________________________________________
>>> p2p-hackers mailing list
>>> p2p-hackers at zgp.org
>>> http://zgp.org/mailman/listinfo/p2p-hackers
>>> _______________________________________________
>>> Here is a web page listing P2P Conferences:
>>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>> _______________________________________________
>> p2p-hackers mailing list
>> p2p-hackers at zgp.org
>> http://zgp.org/mailman/listinfo/p2p-hackers
>> _______________________________________________
>> Here is a web page listing P2P Conferences:
>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>



From zooko at zooko.com  Mon Feb 21 22:05:58 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: 21 Feb 2005 17:05:58 -0400
Subject: [Shtoom] playout alg works!
Message-ID: <41b272fb14b5d807b4c367adadd5f54b@zooko.com>

This passes its self-tests.  See "test_playout.py" for details.  It 
means that it handles the following four cases nicely:

1.  A nearly perfect even flow of input packets.  It correctly plays 
them all out to the speaker.
2.  A flow of packets way too fast to play out.  It correctly "catches 
up" by dropping the oldest ones and playing out the newest ones.
3.  Out of order packets, where packets arrive in the following order: 
2, 1, 4, 3, 6, 5, 8, 7, etc.  It correctly re-orders them all.
4.  Jittery packets, where 40 ms pass with no packets arriving, 
followed by two packets arriving at once, followed by 40 ms of nothing, 
etc. (where each packet contains 20 ms worth of audio).  It correctly 
evens out the jitter and plays smooth audio.

This algorithm isn't perfect, but it is better than the two that are 
currently in Shtoom SVN head -- BraindeadPlayout and BacklogPlayout.

This algorithm evolved from BacklogPlayout.

Unfortunately there are a few shallow merge conflicts which break 
Shtoom's unit tests.  These arose within the last two weeks.  I'll fix 
them tomorrow.

Also I haven't actually run Shtoom with this patch and listened to the 
result.

Also there are some changes that this patch makes to Shtoom which are 
not really necessary -- namely that it introduces a MediaSample class 
which has a sample and a Content-Type instead of using RTPPacket for 
the same purpose.  However, the MediaSample class is somewhat useful as 
it helped me understand what parts of the code did what.  If you 
(Anthony) don't want that part, I'll help make a patch which doesn't do 
that part.

class Playout:
     """
     Theory of operation: you have two modes: "playout" mode and 
"refill" mode.
     When you are in playout mode then you play out sequential audio 
packets from
     your jitter buffer to the audio output device's FIFO as needed.  Do 
the
     obvious right thing with out-of-order packets.

     You switch to refill mode when you have a buffer underrun -- that 
is not
     enough in-order data came in from the network so the audio output 
device
     (i.e., the speaker) ran dry.  When you are in refill mode, you 
don't send
     any packets to the audio output device, but instead hoard them 
until you
     have JITTER_BUFFER_SECONDS worth of sequential, in-order data 
ready, and
     then switch to playout mode.

     There's an added complication because this code doesn't currently 
have a
     nice clean way to say "write this 20 milliseconds worth of audio to 
the
     output device\'s FIFO, and then run the following method *just* 
before those
     20 milliseconds are all used up".  This complication is called the 
"playout
     buffer", and it is a way to stuff way more than 20 milliseconds 
worth of
     audio into the audio output device's FIFO, so that we'll get a 
chance to add
     more packets before it underruns, even when reactor.callLater() 
sometimes
     gets called 110 milliseconds later than we wanted.  This happens on 
Mac.
     See TODO item about playout buffer in comments above.
     """

Zooko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: playout.patch
Type: application/octet-stream
Size: 50391 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050221/d0efb423/attachment.obj>

From zooko at zooko.com  Tue Feb 22 17:56:39 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 12:56:39 -0400
Subject: [Shtoom] patch: move some tests from test/ to livetest/
Message-ID: <ddf3f7cbdbbdb96973435d065ab2b186@zooko.com>

Problem 1:  Some tests require things like a good network, good DNS 
servers, etc., and these tests can show "FAILED" if the network is bad 
or disconnected even though the Shtoom source code itself has no bugs.

Problem 2: On my network in my workshop here, these tests take 1m30s to 
complete.  When I have to wait that long I get distracted and start 
reading e-mail, building little ships in bottles, or something, and my 
productivity plummets.

I've been encountering problem #2 just now as I'm running the Shtoom 
unit tests to test my new playout patch.

Proposed solution in this patch: move tests which require something in 
addition to working-Shtoom-source-code into a separate dir named 
"livetest".  After this patch it takes 1m30s to do "trial 
shtoom.livetest" and it takes 2s to do "trial shtoom.test".  This helps 
me work more efficiently.

Regards,

Zooko

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: livetest.patch.txt
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050222/8d0370c5/attachment.txt>

From zooko at zooko.com  Tue Feb 22 18:15:12 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 13:15:12 -0400
Subject: [Shtoom] whoops -- I omitted the runme_test_playout.py file from
	that last patch
Message-ID: <68bb18c2e7810fc9632930759e2866d3@zooko.com>

Here is the self-test for the playout module.  It would be excellent if 
someone would think of other tests, because the playout algorithm 
probably needs some improvement.  Look at this file for an example of 
how to implement such.

Each test (there are four in here) has a "feed_next_packet()" method 
that gets called every so often to simulate an RTP packet arriving from 
the network.  For example, the EvenFlowTester calls feed_next_packet 
every 20 ms and gives another packet containing 20 ms worth of audio.  
The SmoothJitterTester calls feed_next_packet every 40 ms and gives two 
20 ms packets at once.

Each test also has a "check_test()" method which asserts that there is 
some desirable quality about the output from the playout module.  For 
example the EvenFlowTester asserts that every one of those nicely timed 
input packets got written out to the audio device.  The 
SmoothJitterTester asserts that there were no gaps between audio 
samples written to the audio device.

Regards,

Zooko

#!/usr/bin/env python
# Copyright (C) 2004 Anthony Baxter
"""Tests for shtoom.audio.playout
Hello I am not a unit test.  Run me explicitly from the cmdline.  Thank 
you.
"""

# from shtoom
import shtoom.audio.playout
# shtoom.audio.playout.DEBUG = True
from shtoom.audio.playout import Playout
from shtoom.audio.converters import MediaSample

# from the Twisted library
from twisted.internet import reactor, defer
from twisted.python import log

# from the Python Standard Library
import sys
log.startLogging(sys.stdout)


EPSILON=0.0001

SAMPLEHZ = 8000
SAMPLESIZE = 2
BPS = SAMPLEHZ * SAMPLESIZE

PACKETLEN=0.020

PACKETSIZE=int(PACKETLEN * BPS)

# We must give enough test packets to satisfy the playout object's 
desire to store up media in order to compensate for jitter.
TESTPACKETS=int(shtoom.audio.playout.JITTER_BUFFER_SECONDS * BPS / 
PACKETSIZE)

import datetime, time
def timestamp():
     return datetime.datetime.fromtimestamp(time.time()).isoformat(' ')

class DummyWriter:
     def __init__(self):
         self.b = []
         self.ts = []
     def write(self, data):
         self.b.append(data)
         self.ts.append(time.time())

class DummyMediaLayer:
     def __init__(self):
         self._d = DummyWriter()

class Tester:
     def __init__(self):
         self.dml = DummyMediaLayer()
         self.p = Playout(self.dml, )
         self.inb = []
         for i in range(TESTPACKETS):
             self.inb.append(str(i) + ('\x00' * (PACKETSIZE - 
len(str(i)))))
         self.i = 0
         log.msg("%s %s.__init__()" % (timestamp(), 
self.__class__.__name__,))
         self.d = defer.Deferred()
         reactor.callLater(0, self.feed_next_packet)


def repr_buf_for_log(buf):
     return map(lambda x: x[:3], buf)

class EvenFlowTester(Tester):
     """
     If a steady flow of TESTPACKETS packets arrives, followed by a long 
silence, then the playout ought to play all TESTPACKETS of the packets.
     """
     def check_test(self):
         self.d.callback(None)
         assert self.dml._d.b == self.inb, "%s %s, %s" % (timestamp(), 
repr_buf_for_log(self.dml._d.b), repr_buf_for_log(self.inb),)
         log.msg("%s %s success" % (timestamp(), self,))

     def feed_next_packet(self):
         # log.msg("%s %s about to write %s, %s" % (timestamp(), 
self.__class__.__name__, `self.inb[self.i]`, self.i,))
         data = self.inb[self.i]
         self.p.write(data, self.i)
         self.i += 1
         if self.i < TESTPACKETS:
             reactor.callLater(max(0, (len(data) / float(BPS)) - 
EPSILON), self.feed_next_packet)
         else:
             reactor.callLater(max(0, ((len(data) * len(self.inb)) / 
float(BPS)) - EPSILON), self.check_test)


class OutOfOrderArrivalTester(Tester):
     """
     If a steady flow of TESTPACKETS packets arrives, but with each pair 
swapped, followed by a long silence, then the playout ought to play all 
TESTPACKETS of the packets (in the right order).
     """
     def check_test(self):
         self.d.callback(None)
         assert self.dml._d.b == self.inb, "%s, %s" % (self.dml._d.b, 
self.inb,)
         log.msg("%s %s success" % (timestamp(), self,))

     def feed_next_packet(self):
         thisi = self.i ^ 1
         data = self.inb[thisi]
         self.p.write(data, thisi)
         self.i += 1
         if self.i < TESTPACKETS:
             reactor.callLater(max(0, (len(data) / float(BPS)) - 
EPSILON), self.feed_next_packet)
         else:
             reactor.callLater(max(0, ((len(data) * len(self.inb)) / 
float(BPS)) - EPSILON), self.check_test)


class CatchupTester(Tester):
     """
     If a steady flow of TESTPACKETS packets arrives at faster than 
realtime, followed by a long silence, then the playout ought to play 
the last packet.
     """
     def check_test(self):
         self.d.callback(None)
         assert self.dml._d.b[-1] == self.inb[-1], "%s, %s" % 
(`self.dml._d.b[-1][:4]`, `self.inb[-1][:4]`,)
         log.msg("%s %s success" % (timestamp(), self,))

     def feed_next_packet(self):
         data = self.inb[self.i]
         self.p.write(data, self.i)
         self.i += 1
         if self.i < TESTPACKETS:
             reactor.callLater(0, self.feed_next_packet)
         else:
             reactor.callLater(max(0, ((len(data) * len(self.inb)) / 
float(BPS)) - EPSILON), self.check_test)

class SmoothJitterTester(Tester):
     """
     If an unstead flow arrives: two packets back-to-back followed by an 
"empty slot" followed by two packets back-to-back, etc., then the 
playout should output a perfectly even flow.
     """
     def check_test(self):
         self.d.callback(None)
         prevend = self.dml._d.ts[0] + (len(self.dml._d.b[0]) / 
float(BPS))
         for i in range(1, len(self.dml._d.ts)):
             ts = self.dml._d.ts[i]
             bl = len(self.dml._d.b[i])
             assert ts <= prevend, "ts: %s, prevend: %s, i: %s" % (ts, 
prevend, i,)
             prevend += bl / float(BPS)
         log.msg("%s %s success" % (timestamp(), self,))

     def feed_next_packet(self):
         data = str(self.i) + ('\x00' * (PACKETSIZE - len(str(self.i))))
         self.inb.append(time.time())
         self.p.write(data, self.i)
         self.i += 1
         data = str(self.i) + ('\x00' * (PACKETSIZE - len(str(self.i))))
         self.inb.append(time.time())
         self.p.write(data, self.i)
         self.i += 1
         if self.i < TESTPACKETS:
             reactor.callLater(max(0, (2 * len(data) / float(BPS)) - 
EPSILON), self.feed_next_packet)
         else:
             reactor.callLater(max(0, ((len(data) * len(self.inb) * 2) / 
float(BPS)) - EPSILON), self.check_test)


if __name__ == "__main__":
     l = []
     l.append(EvenFlowTester().d)
     l.append(CatchupTester().d)
     l.append(SmoothJitterTester().d)
     l.append(OutOfOrderArrivalTester().d)
     dl = defer.DeferredList(l)
     dl.addCallbacks(lambda x: reactor.stop(), lambda x: reactor.stop())
     reactor.run()



-------------- next part --------------
A non-text attachment was scrubbed...
Name: runme_test_playout.py
Type: application/octet-stream
Size: 5851 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050222/24fd4675/attachment.obj>

From zooko at zooko.com  Tue Feb 22 18:35:20 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 13:35:20 -0400
Subject: [Shtoom] patch: move some tests from test/ to livetest/
In-Reply-To: <ddf3f7cbdbbdb96973435d065ab2b186@zooko.com>
References: <ddf3f7cbdbbdb96973435d065ab2b186@zooko.com>
Message-ID: <0b3cc030a114cbc8ff71cabc456ce95f@zooko.com>

Oh, I forgot to mention that on my network, the livetests take 1m30s to 
complete, and then they FAIL due to timeout!  On my proprietary branch 
of Shtoom, I've bumped up the timeouts to insane levels so that after 
waiting for ridiculous amounts of time I can see the livetests complete 
successfully.

--Z



From smadim2 at grads.ece.mcmaster.ca  Wed Feb 23 02:05:08 2005
From: smadim2 at grads.ece.mcmaster.ca (M.N.A.Smadi)
Date: Tue, 22 Feb 2005 20:05:08 -0500
Subject: [Shtoom] i cannot register
Message-ID: <421BD6C4.7060500@grads.ece.mcmaster.ca>

am trying to register with an asterisk box but no luck so far.  Here is 
my config file:

[shtoom]
audio=oss

[network]
localip=192.168.2.8
listenport=5060

[register]
register_uri=<sip:192.168.1.13>
register_authuser=112
register_user=112 at 192.168.2.13
register_authpasswd=112



any clue
m.smadi



From zooko at zooko.com  Tue Feb 22 18:05:08 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 13:05:08 -0400
Subject: [Shtoom] patch: playout.patch.txt now passes all shtoom unit tests
Message-ID: <9b6a8b74dd952d024530e5633c81bd69@zooko.com>

This patch applies to SVN HEAD and unit tests pass just as well after 
this patch as before.

To run the playout module's self test, execute 
./shtoom/test/runme_test_playout.py.

I will now build this and actually run it and listen to how it sounds 
on Mac and Linux.

Regards,

Zooko
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: playout.patch.txt
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050222/28b3d2bd/attachment.txt>

From zooko at zooko.com  Tue Feb 22 20:15:14 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 15:15:14 -0400
Subject: [Shtoom] new version of playout patch -- sounds okay on Mac,
	not on Linux
Message-ID: <97fa3f8d776dc2d30a3c04fc33e70721@zooko.com>

This version of the patch fixes a bug which prevented Mac Shtoom from 
sending any RTP.

With this patch, playout sounds okay on Mac, as far as I can tell.  It 
sounds awful on Linux, because the huge playout buffer is bigger than 
the alsa fifo (see comments and docstrings in the patch for details).

I'll think about how to improve the situation on Linux.  I guess the 
trivial solution is to do this:

-PLAYOUT_BUFFER_SECONDS=0.8 # stuff up to this many seconds worth of 
packets into the audio output buffer
+if 'linux' in sys.platform.lower():
+    PLAYOUT_BUFFER_SECONDS=0.03 # stuff up to this many seconds worth 
of packets into the audio output buffer
+else:
+    PLAYOUT_BUFFER_SECONDS=0.8 # stuff up to this many seconds worth 
of packets into the audio output buffer

This is easy enough that it is worth me testing right now, but after I 
resubmit this patch, I'll be motivated to actually improve the playout 
buffer stuff, as documented in comments and docstrings herein.

Regards,

Zooko
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: playout.patch.txt
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050222/f19e5bd4/attachment.txt>

From zooko at zooko.com  Tue Feb 22 21:54:00 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 22 Feb 2005 16:54:00 -0400
Subject: [Shtoom] new playout patch: it, um, doesn't suck
Message-ID: <948de55e5b257e7b30d45d4602c30262@zooko.com>

So I did the "if on darwin use ridiculous playout buffer depth" hack, 
as described in my previous mail.

The result, appended here, is okay at playout on both Mac and Linux.  
However, the result here *sends* RTP packets at a bad rate on Mac.

That is, it sends 20-ms PCMU packets at a rate of 40 of them per 
second.  Bad.

I did some experimentation, and SVN HEAD of Shtoom currently sends a 
proper rate -- 50 packets per second -- but sometimes with short 
contents -- less than 160 bytes of mulaw-encoded audio in each packet.

With SVN HEAD of Shtoom on Mac, sending to SVN HEAD+playout.patch on 
Linux, I get high latency in long call.

With SVN HEAD+playout.patch on Mac and on Linux, I get choppy, ugly 
audio as the playout on Linux underruns frequently since it isn't 
receiving enough packets.  Note that the playout patch includes putting 
a small buffer in the media encoder to buffer enough bytes for a 
standard media frame, so it guarantees no funny-sized PCMU packets.

My proprietary branch of Shtoom has some refactored Mac audio work, and 
it sends PCMU packets at a good rate and with 160 bytes per packet.  
With that sending from Mac, the Linux playout sounds good!

So: you can apply this patch if it works for you.  I will, tomorrow, 
work up a patch that contributes our Mac audio refactoring (largely due 
to Donovan Preston).

Regards,

Zooko

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: playout.patch.txt
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050222/4866a10b/attachment.txt>

From zooko at zooko.com  Wed Feb 23 14:06:13 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Wed, 23 Feb 2005 09:06:13 -0400
Subject: [Shtoom] latest version of runme_test_playout.py
Message-ID: <0a2ad0243c7fecb00532e1f0139c00db@zooko.com>

Once again, I accidentally omitted this from the patch I submitted.

--Z

-------------- next part --------------
A non-text attachment was scrubbed...
Name: runme_test_playout.py
Type: application/octet-stream
Size: 5855 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050223/10819280/attachment.obj>

From zooko at zooko.com  Wed Feb 23 21:56:19 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Wed, 23 Feb 2005 16:56:19 -0400
Subject: [Shtoom] want a sumo patch?
Message-ID: <60464aead8e902a159dbcbd4977b312c@zooko.com>

Anthony:

I had wanted to make a series of patches, where each one contains a 
single logical feature, so that you could examine, test, and apply each 
feature in turn.

With the first two -- RTP Packet and Playout -- I've successfully done 
that, but the next one -- Mac Audio -- is so intertwined with other 
changes that it has taken hours and I'm still not finished.  Also, 
there are so many more patches to come, and they are so intertwined, 
that I have a new proposal:

Sumo Patch

I'll submit a patch which is "everything that differs between 
SVNHEAD+playout.patch and our-proprietary-branch, excluding secret 
sauce".

Then I'll help you pick over it, change pieces, etc.

It is still going to take me hours of work to submit it because I want 
to at least *document* what the logically separate changes are, even if 
I can't actually extract them into separate patches...

What do you say?

Regards,

Zooko



From anthony at interlink.com.au  Thu Feb 24 04:22:31 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu, 24 Feb 2005 14:22:31 +1100
Subject: [Shtoom] want a sumo patch?
In-Reply-To: <60464aead8e902a159dbcbd4977b312c@zooko.com>
References: <60464aead8e902a159dbcbd4977b312c@zooko.com>
Message-ID: <200502241422.32951.anthony@interlink.com.au>

On Thursday 24 February 2005 07:56, Zooko O'Whielacronx wrote:
> I'll submit a patch which is "everything that differs between
> SVNHEAD+playout.patch and our-proprietary-branch, excluding secret
> sauce".
>
> Then I'll help you pick over it, change pieces, etc.
>
> It is still going to take me hours of work to submit it because I want
> to at least *document* what the logically separate changes are, even if
> I can't actually extract them into separate patches...

That sounds fine to me. 

-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From anthony at interlink.com.au  Thu Feb 24 07:48:14 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Thu, 24 Feb 2005 17:48:14 +1100
Subject: [Shtoom] i cannot register
In-Reply-To: <421BD6C4.7060500@grads.ece.mcmaster.ca>
References: <421BD6C4.7060500@grads.ece.mcmaster.ca>
Message-ID: <200502241748.17959.anthony@interlink.com.au>

On Wednesday 23 February 2005 12:05, M.N.A.Smadi wrote:
> am trying to register with an asterisk box but no luck so far.  Here is
> my config file:

Have a look at the example on 
http://divmod.org/Home/Projects/Shtoom/FAQ.html

If it still fails, please reply, including a debug log showing what 
happened.

-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From zooko at zooko.com  Thu Feb 24 18:04:19 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Thu, 24 Feb 2005 13:04:19 -0400
Subject: [Shtoom] Re: patch: move some tests from test/ to livetest/
In-Reply-To: <ddf3f7cbdbbdb96973435d065ab2b186@zooko.com>
References: <ddf3f7cbdbbdb96973435d065ab2b186@zooko.com>
Message-ID: <cd9652127cabe02772547ff54d30b1e7@zooko.com>

Anthony:

This patch was incorrect.  I don't really know how to make a patch that 
moves a file from one place to another in SVN.  Would you like me to 
actually make these changes in SVN?  The changes are:

mkdir shtoom/livetest
mv shtoom/test/test_{stun,upnp,natmappers,defcache}.py shtoom/livetest
cat > shtoom/livetest/__init__.py
"""Live-tests for shtoom.  These are tests that require something 
outside of Shtoom's source code to pass, such as a network connection, 
a remote server or peer, etc.

You can run all tests by command-line:

   $ trial shtoom.livetest
"""

I'm not sure that test_defcache really belongs in there.  I moved it 
because it takes time to pass (testing a timeout)...

Regards,

Zooko



From zooko at zooko.com  Thu Feb 24 21:59:19 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Thu, 24 Feb 2005 16:59:19 -0400
Subject: [Shtoom] patch progress report
Message-ID: <012db7028f7341cc91326c99cbd4c65e@zooko.com>

Well, I generated the mega-patch, then started laboriously going  
through it and separating out bits that are supposed to be kept  
proprietary, then I had the bright idea of stuffing the megapatch into  
a new darcs repository.  That worked a charm!  Darcs is the perfect  
tool for taking a megapatch and splitting it up into separate, coherent  
patches.  It will only take about two hours more work, and I'll have a  
set of nice separate patches that you can pick and choose from.  That  
two hours of work will happen tomorrow morning, as it is Family Time in  
the Atlantic Time Zone.

You can see the first three patches here (they are the two that I  
already submitted to the list, but slightly cleaned up, plus a trivial  
third one):

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
patches/?c=patches

Regards,

Zooko



From smadim2 at grads.ece.mcmaster.ca  Thu Feb 24 23:56:53 2005
From: smadim2 at grads.ece.mcmaster.ca (Mohammed Smadi)
Date: Thu, 24 Feb 2005 17:56:53 -0500 (EST)
Subject: [Shtoom] i cannot register
Message-ID: <Pine.LNX.4.44.0502241755130.9499-100000@grads.ece.mcmaster.ca>

I can register from kphone no problem.  But i cannot register from 
shtoom, there isn't even a SIP REGISTER Request that is being sent out 
as i can see:
==============

2005-02-24T13:30:29.620608 [-] Log opened.

2005-02-24T13:30:29.646919 [-] <class 'shtoom.sip.SipProtocol'> starting 
on 5060

2005-02-24T13:30:29.647313 [-] Starting protocol <shtoom.sip.SipProtocol 
object at 0x40a2f5ac>

2005-02-24T13:30:29.647522 [app] sip listener installed on 5060

2005-02-24T13:30:29.669062 [-] <class 'shtoom.upnp.UPnPProtocol'> 
starting on 1900

2005-02-24T13:30:29.669435 [-] Starting protocol 
<shtoom.upnp.UPnPProtocol object at 0x40a2268c>

2005-02-24T13:30:29.671151 [-] <class 'shtoom.stun._DetectSTUNProt'> 
starting on 0

2005-02-24T13:30:29.671837 [-] Starting protocol 
<shtoom.stun._DetectSTUNProt object at 0x40b05d4c>

2005-02-24T13:30:29.672534 [sip] no outstanding registrations, registering

2005-02-24T13:30:29.673100 [-] 
/usr/lib/python2.3/site-packages/shtoom/sip.py:296: 
exceptions.DeprecationWarning: use listenUDP and then transport.connect().

2005-02-24T13:30:29.673311 [-] 
twisted.internet.protocol.ConnectedDatagramProtocol starting on 0

2005-02-24T13:30:29.673582 [-] Starting protocol 
<twisted.internet.protocol.ConnectedDatagramProtocol instance at 
0x40b4d0ac>

2005-02-24T13:30:29.673887 [sip] discovered local address 
('192.168.0.8', 5060), remote ('64.52.204.38', 5060)

2005-02-24T13:30:29.674320 [sip] NAT policy says yes, we're transitting 
a NAT

2005-02-24T13:30:29.840817 [-] 
twisted.internet.protocol.ConnectedDatagramProtocol starting on 0

2005-02-24T13:30:29.841155 [-] Starting protocol 
<twisted.internet.protocol.ConnectedDatagramProtocol instance at 
0x40b4d3ec>

2005-02-24T13:30:30.048681 [-] (Port 0 Closed)

2005-02-24T13:30:30.048932 [-] Stopping protocol 
<twisted.internet.protocol.ConnectedDatagramProtocol instance at 
0x40b4d0ac>

2005-02-24T13:30:30.050253 [-] (Port 0 Closed)

2005-02-24T13:30:30.050418 [-] Stopping protocol 
<twisted.internet.protocol.ConnectedDatagramProtocol instance at 
0x40b4d3ec>

2005-02-24T13:30:30.062625 [stun] got STUN response from ('64.69.76.23', 
3478)

2005-02-24T13:30:30.202243 [stun] got unexpected STUN response 
'\xd6\x0f\xc5\xbb\xc6\xdf\x93\xd5\x10`\xd5\x115\x94\x9fI' != 
'\x8c\xe1\xfa\x8b\nrn\x9c"\xdf\xab\x1cF\xe0\x97\x1c' from 
('64.69.76.23', 3478)

2005-02-24T13:30:30.215056 [stun] got STUN response from ('64.69.76.24', 
3479)

2005-02-24T13:30:30.215529 [-] (Port 0 Closed)

2005-02-24T13:30:30.215708 [-] Stopping protocol 
<shtoom.stun._DetectSTUNProt object at 0x40b05d4c>

2005-02-24T13:30:30.673730 [UPnP] got a response from ('192.168.0.1', 
1900), status 200

2005-02-24T13:30:30.675204 [UPnP] found a UPnP device at 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:30.681011 [UPnP] got a response from ('192.168.0.1', 
1900), status 200

2005-02-24T13:30:30.681520 [UPnP] found a UPnP device at 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:30.682906 [UPnP] got a response from ('192.168.0.1', 
1900), status 200

2005-02-24T13:30:30.683368 [UPnP] found a UPnP device at 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:30.694981 [UPnP] before 
stupidrandomdelaytoworkaroundbug got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:30.710824 [UPnP] before 
stupidrandomdelaytoworkaroundbug got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:30.714710 [UPnP] before 
stupidrandomdelaytoworkaroundbug got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.695597 [UPnP] after 
stupidrandomrelaytoworkaroundbug, got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.705563 [UPnP] you're behind a Microsoft

2005-02-24T13:30:34.706581 [UPnP] upnp response has no urlbase, falling 
back to 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.707158 [UPnP] upnp response showed no WANIPConnections

2005-02-24T13:30:34.711567 [UPnP] after 
stupidrandomrelaytoworkaroundbug, got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.718826 [UPnP] you're behind a Microsoft

2005-02-24T13:30:34.719757 [UPnP] upnp response has no urlbase, falling 
back to 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.720352 [UPnP] upnp response showed no WANIPConnections

2005-02-24T13:30:34.720581 [UPnP] after 
stupidrandomrelaytoworkaroundbug, got an IGDevice from 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.728114 [UPnP] you're behind a Microsoft

2005-02-24T13:30:34.729140 [UPnP] upnp response has no urlbase, falling 
back to 
http://192.168.0.1:2869/upnphost/udhisapi.dll?content=uuid:62001f1d-3b31-4ea5-bd1d-553f09c4c136

2005-02-24T13:30:34.729705 [UPnP] upnp response showed no WANIPConnections
====================

My shtoomrc file looks like:
[shtoom]
audio=oss

[register]
register_uri=sip:XXX.XXX.XXX.XXX:5060
register_user=666

I am surpired that happened because i used shtoom long time ago and as i 
recall thing went fine then!

thanks
m.smadi



From zooko at zooko.com  Fri Feb 25 16:16:36 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 25 Feb 2005 11:16:36 -0400
Subject: [Shtoom] patch: play ringring files.  (untested)
Message-ID: <030ebd5ba9e4de6c55f56b159b3e0d25@zooko.com>

You can follow along with my ongoing work to make patches for Shtoom by  
looking at this list of patches:

https://192.168.1.112:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
patches/?c=patches

The current interesting one is the latest: "play ring.wav on incoming  
call and ringback.wav on outgoing ringback".  I am now testing that  
patch.

Regards,

Zooko



From zooko at zooko.com  Fri Feb 25 21:17:14 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 25 Feb 2005 16:17:14 -0400
Subject: [Shtoom] ringring feature works!
Message-ID: <6c551e5d5e7b3b3e3da119dffaf74f76@zooko.com>

Anthony, et al:

The list of patches we're contributing:

https://192.168.1.112:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
patches/?c=patches

Now has several patches that I recommend that you adopt:

  * fix alsa audio to do the "isClosed()" method properly
It's a bugfix!  You want it.

  * CocoaShtoom/setup.py creates symlinks for frameworks
It doesn't hurt, but it doesn't help you either unless you use a  
revision control system like darcs that won't deal with symlinks.   
Click on the "more detail" button for verbose changelog entry  
explaining what this patch does.

  * fix bug in which the value of Mac audio isClosed() was reversed
It's a bugfix!  Yum!

  * play ring.wav on incoming call and play ringback.wav on outgoing ring
It's a feature!  It comes with wav files.  Whee!

  * move some tests from test/ to livetest/
As earlier discussed -- you may or may not want this.

  * fix bug in aufile's handling of stereo files
It's a bugfix!

  * Post the preference pages to the right place; Make checkboxes work  
properly.
Some web ui stuff from Donovan.  I think it's a bugfix so you should  
take it

  * bump up upnpTimeout from 6s to 12s
This made UPnP work on my network, I think.

  * add shreadder to scripts
Everyone should have a shreadder.

Okay, there are more to come.

You can clicketyclicketyclick on the web site to get unified diffs for  
any of these patches, or ask me and I'll mail them to the list.

Regards,

Zooko



From zooko at zooko.com  Fri Feb 25 21:23:10 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 25 Feb 2005 16:23:10 -0400
Subject: [Shtoom] ringring feature works!
In-Reply-To: <6c551e5d5e7b3b3e3da119dffaf74f76@zooko.com>
References: <6c551e5d5e7b3b3e3da119dffaf74f76@zooko.com>
Message-ID: <e8b06ab0edfc5572a00f3f958c3efa45@zooko.com>

> The list of patches we're contributing:
>
> https://192.168.1.112:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
> patches/?c=patches

Whoops.  Try

https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
patches/?c=patches

or, here, I'll shorten the directory name to make the URL shorter:

https://24.222.185.250:19144/cgi-bin/darcs.cgi/sh



From zooko at zooko.com  Fri Feb 25 21:52:39 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 25 Feb 2005 16:52:39 -0400
Subject: [Shtoom] ringring feature works!
In-Reply-To: <6c551e5d5e7b3b3e3da119dffaf74f76@zooko.com>
References: <6c551e5d5e7b3b3e3da119dffaf74f76@zooko.com>
Message-ID: <ef3cd3f725933fdb4ce8fd7e626f8208@zooko.com>

>  * play ring.wav on incoming call and play ringback.wav on outgoing 
> ring
> It's a feature!  It comes with wav files.  Whee!

Note: this only works when there is a nice fat audio output FIFO that 
can store up the whole ring file (approx 1 second).

So on Linux/ALSA, you hear just a blip of a ring instead.

See comments in code (such as by clicking on the patch on my web site) 
to see why.

--Z



From zooko at zooko.com  Fri Feb 25 22:08:15 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Fri, 25 Feb 2005 17:08:15 -0400
Subject: [Shtoom] new version of the playout patch
Message-ID: <5d7b3eb8f47c197126f896f2ae5d8aa0@zooko.com>

The patch entitled "new playout algorithm":

https://24.222.185.250:19144/cgi-bin/darcs.cgi/sh/?c=patches

Has the same qualities as the one I submitted via e-mail to this list 
yesterday.  But this one is applied on top of all the other patches 
listed on this web page.

Regards,

Zooko



From smadim2 at grads.ece.mcmaster.ca  Sat Feb 26 06:53:47 2005
From: smadim2 at grads.ece.mcmaster.ca (Mohammed Smadi)
Date: Sat, 26 Feb 2005 00:53:47 -0500 (EST)
Subject: [Shtoom] sip.py file
Message-ID: <Pine.LNX.4.44.0502260048350.32246-100000@grads.ece.mcmaster.ca>

hi;

i want to  modify the sip.py file. I want to do the modifications and testing with minimal 
interaction with the other files.  If i perform twisd sip.py i get the 
following errors:
===============
Failed to load application: No module named digestauth
and

Failed to load application: name 'ISip' is not defined

and many others
================

i guess my question is how force these modules to include when running 
twisd -ny sip.py ?

thanks
m.smadi



From zooko at zooko.com  Sun Feb 27 22:07:20 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Sun, 27 Feb 2005 17:07:20 -0400
Subject: [Shtoom] more patches for you
Message-ID: <533cf6f121bb8a235a69d937c706d0d2@zooko.com>

I committed about two dozen patches today:

https://24.222.185.250:19144/cgi-bin/darcs.cgi/sh/?c=patches

After all these, my sandbox has what I think is just the 
new-microphone-reading patch.  My sandbox passes all unit tests, but I 
haven't run it and listened to it recently.

Familytime now.  I'll definitely commit the new-microphone-reading 
patch tomorrow, and then I think I'll be all synced up in terms of 
patches to contribute to Shtoom.

Regards,

Zooko



From zooko at zooko.com  Mon Feb 28 17:33:55 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Mon, 28 Feb 2005 12:33:55 -0400
Subject: [Shtoom] patchety patch
Message-ID: <a345d8af3ac7f8f01c62defaa0d574a6@zooko.com>

Anthony, et al.:

Please see patches as I add them to this list:

https://24.222.185.250:19144/cgi-bin/darcs.cgi/shtoom-adhoc-plus- 
patches/?c=patches

If you click on the name of the patch (the leftmost column) or  
equivalently on the "detail" button (the rightmost column) then you get  
the page for that patch, which shows which files were changed, how many  
lines were changed, the verbose log entry.  If you click on the "diff"  
button on that page, you get the unified diff of the patch.

Regards,

Zooko



From zooko at zooko.com  Mon Feb 28 19:41:21 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Mon, 28 Feb 2005 14:41:21 -0400
Subject: [Shtoom] new microphone code works
Message-ID: <b6286989646d10ffee7ea2b3464dee96@zooko.com>

The last big patch is named "rewrite of the microphone -> encoder -> 
RTPstream channel":

https://24.222.185.250:19144/cgi-bin/darcs.cgi/sh/?c=patches

If you click on its name on that page, you'll see this verbose log 
entry:

   * Microphone samples are asynchronously pushed up by the lower layers 
rather than being polled by the upper layers.  On Mac, the 
high-precision realtime thread is used to push microphone samples.  
This fixes a bug with short reads and a bug with inaccurate polling.  
On ALSA, there is a LoopingCall in the ALSA driver that polls at an 
appropriate interval.
  * The encoder base class has a buffer to store up the appropriate 
bytes of microphone data to make up a media frame.  This buffer gets 
flushed when the audio device closes or reopens.
  * The audio device gets closed and reopened during important state 
transitions, namely call start and call end.  This fixes the "That 
jerk!" bug, in which you could say "I have to call that jerk!" 
immediately before a call connected and then the jerk in question would 
hear you say it when he answered.
  * Remove some extremely detailed diags that measured the number of 
packets sent per second and the number of packets received per second.  
Those diags have served well and are now retired.
  * The Mac audio loopback test is rewritten, and a bug involving 
closing the loopback test versus closing a phone call is fixed.
  * The discovery/selection of the appropriate audio device is done 
before the construction of the Phone object.  This makes the other 
platforms' initialization process parallel to the Mac initialization 
process, and also I prefer this approach.  (The other approach is that 
you construct the Phone object and then it discovers/selects the audio 
device itself.)


With this patch, Shtoom passes all unit tests, and the audio it sends 
from a Mac sounds much better.  Also, as described in the verbose log 
entry, this patch fixes a bug in which buffered audio got sent at the 
wrong time...

Unfortunately, this patch breaks all audio devices that aren't the Mac 
audio device or the ALSA audio device.

I will willingly help convert other audio device objects to this new 
scheme.

Regards,

Zooko



From zooko at zooko.com  Mon Feb 28 21:30:41 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Mon, 28 Feb 2005 16:30:41 -0400
Subject: [Shtoom] Shtoom on w32
Message-ID: <0813d373d9898b8f87c43928c7e61696@zooko.com>

When's the last time anyone ran Shtoom on Windows?

As for me: never yet, but I will soon.

Regards,

Zooko