Re: (#504) Re: Great ! (#501) Speex codec impl

On Sun, Oct 26, 2003 at 07:27:58PM +0100, Speak Freely Forum wrote:
> Message posted to the Speak Freely Forum
>   by Bill Burke on Sun, 26 Oct 2003 19:27:58 +0100 (MET).
>   http://www.fourmilab.ch/wb/speak-freely.pl?rev=504
> 
>   Reply To: (#503) Great ! [speak-freely] (#501) Speex codec implemen
>   Author:   Johannes Po....
>   Date:     2003-10-17 10:44
> 
> Hi Johannes,
> 
> I visited the patch page on your site, and in
> reading it (probably my blatant ignorance)
> I'm not sure if what you've done is/isn't SIP?
> 
> ============================
> : Forwarded from the [email protected]
> : mailing list: Hi John,
> 
> : That is great to see people continuing to
> : contribute to Speak Freely.
> 
> 

I am interested in continuing to maintain Speakfreely.  Thomas has
been helping me sort out the bugs in my recent patches, and I'm
reasonably positive about that and the other plans I have in mind for
mods.  I've only recently become involved with the mailing list
though, so I'm wondering who has been working on speakfreely recently?
I know at least Thomas and myself have web pages with patches up.  Is
anyone else actively doing things that could be brought together into
a common update tree? 

So Johannes, do you have any patches up somewhere?  Otherwise Bill
must be talking about mine.  What I've done doesn't implement SIP at
all.  It's still using the same protocol as before, but just adding a
codec and better received packet handling.

I would be interested in adding a SIP library, or perhaps going with
Thomas' idea of using the jabber network for session initiation.
Jabber could be a nice option to replace the lwl server.  We just need
to check if it can give the firewall information that would be useful
for NAT piercing. 

Over the weekend I modified the windows version of SF to be NAT
friendly.  It just means using common sockets for TX and RX.  It makes
an almost trivial patch.  The way I've done it still allows multiple
receipients at once, but there may be a slight increase in system load
because it can't use connect() to set the default address for the
sendto() calls.  I don't know about that yet though - there may be no
penalty at all. 

My future ideas are:
- echo cancellation (for speaker-phone)  using libspeex.  This should
be fairly easy on windows, but the split design of the unix version
may need a rework.
- adaptive jitter delays
- adaptive audio buffering (I know how to do this with ALSA, but need
to find out about underrun detection for other platforms) 

A this stage, it would be good to have some unix (non-linux) testers
of my packeting and speex patches, so I could get some more confidence
in that side of things.

My patches are at: http://www.2pi.info/software/sf_speex/index.html

I don't have the latest changes from the weekend up there yet
though. (Windows NAT, unix ogg/speex logging to come soon)


Soren
(previously posting as John H from forum page)

                      * * *

To unsubscribe from this mailing list, send E-mail containing
the word "unsubscribe" in the message body (*not* as the
Subject) to [email protected]