Re: Proposed Aim for Speak Freely

i disagree. 
when you talk over thing like inernet phone, 
your demands expand, perhaps you would like to send background noises, or you would like to have audio quality enough clean to be able to reproduce your voice when you move around the room , or even wanted to transmit some music .

there is ogg/vorbis compression, and mp3 compression, both which are lossy. they introduce bit larger lag than usual GSM compression, but still quite acceptable.
they're meant for high-compression ratios, and sound compresed using them sounds much better than using all other algorihms.
you should check out mp3rtp.

limiting bandwitch is good only in places where very small lag is needed.



On Thu, 14 Aug 2003 07:16:31 -0400
"WmBurke" <[email protected]> wrote:

> 
> Hello all,
> 
> If Speak Freely is remaining a voice-based application,
> sampling at anything past 22kHz will only cause more
> work and contribute nothing to voice quality.
> 
> Speech data, for *all languages & their dialects ranges
> from 220Hz to 7.8 - 7.9kHz. Sampling at 22kHz will insure
> all that data is captured, although the range a sampling at
> 16kHz covers would give almost identical results.
> 
> Sampling at 44.1kHz will exclude a lot of good compression
> codec's, as they don't support such rates as well as clog up
> application horsepower churning unnecessary data.
> 
> Just my 3 cents...
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Speak Freely Forum
> Sent: Sunday, August 10, 2003 8:52 PM
> To: [email protected]
> Subject: [speak-freely] (#371) Proposed Aim for the Speak Freely NG
> 
> 
> Message posted to the Speak Freely Forum
>   by Anshuman Ag.... on Mon, 11 Aug 2003 02:51:42 +0200 (MEST).
>   http://www.fourmilab.ch/wb/speak-freely.pl?rev=371
> 
> Hi all,
> Here is what I am personally looking towards achieving from this project. I
> believe that the internet users should be empowered to be able to operate in
> a
> peer to peer fashion for internet tele/video phony. Speak-Freely is an
> application which does the tele part very well at the moment and crosses the
> unix-window bridge fairly well. I reject the commercial solutions which
> either
> are not cross platform enough or use a server -client approach.
> On these lines based on my last post ...since a complete rewrite of the code
> base is needed, based on that here is the proposal:-
> - Speak Freely should be as it right now a complete tool for end to end
> point
> to point user communication developed with the GUI in mind ( not just an
> addon
> which never appears complete ) - wxWindows toolkit for instance
> - Modular and reusability of other code libraries..I have seen some good yet
> lacking RTP/Speech compression code bases..we should use those libraries (
> enhance them with speak freely code ) and incorporate them as needed.
> By making it modular enough we can plug in video, interoperability with SIP
> etc.
> - well designed and documented API so that the backend can be tapped into by
> other produts (IM client etc. etc. )
> - Aim at merging the myriad projects for internet telephony out
> there...picking up the good ( code and developers from all )
> - Base it on a solid design and architecture as scalable as we can think of
> today ( Pipeline , object oriented scalable code in C++ for instance )
> 
> This is my take on the project...I realize everybody has different
> expectations..personally I'd like this project to be a common goal so that
> we
> are all are working at different pieces of it instead of replicating work
> towards different ones.
> 
> Cheers
> Anshuman
> 
> Anshuman Aggarwal] I believe the most critical part of the application will
> be
> the initial design/structure/architecture...Once the RTP handling,
> connection
> managing, authentication/encryption framework is in place.
> An overlying Kernel class could co-ordinate the use of resources
> > > - Based on a cross platform GUI/utilities library: wxWindows (Open
> >source,
> > > available on all platforms, provides native GUI+TCP/IP). Adv.:
> > > Immediate
> >GUI
> > > for all unix platforms.
> >
> >I don't have any personal experience with wxWindows, but I've heard
> >good things about it. But I think the most important thing is to
> >create a kernel and API, completely independent of the user interface,
> >which does all of the real work (connection management, CODEC
> >interface, encryption [if that's left in--see below]) which GUI
> >packages call. The kernel could be supplied with a minimialist
> >command-prompt user interface that would allows anybody to get it
> >running on a new platform easily, then build whatever GUI they wished
> >(Macintosh, Tcl/TK, Gnome, etc.).
> 
> [Anshuman Aggarwal] Here is an initial concept
> Connection Authentication Encryption Compression I/O Class heirarchy:-
> - Kernel contains ref. To multiple Link objects..each Link object has
> multiple
> connection, authentication,encryption object ref. The compression ref. can
> be
> further
> > > - OO Design in C++. Adv: Easy scalability to new codecs (just derive
> >classes )
> >
> >Yes. Each CODEC should be an object one patches into the pipeline
> >which transforms audio in canonical form (which we might take the
> >opportunity to extend to 44.1 kHz linear PCM stereo for future growth
> >potential--the transform to and from mu-law mono is just a table lookup
> >and costs nothing) to the encoded form. All should have identical
> >methods, so it would be easy to add new ones.
> >
> > > + Video Conf. as and when SF grows.
> >
> >A new Speak Freely should, in my opinion, adopt RTP as its native
> >protocol. The existing Speak Freely protocol would be accepted and
> >sent to any connection which used it, but when talking new version to
> >new version, RTP should be the default. The advantage of RTP is that
> >it *already* has RFC-specified formats for most of the video CODECs, so
> >we'd simply be complying with a standard, not breaking new ground.
> >
> > > - Develop on existing code base for C code for compression etc.
> >(Suitably
> > > modified when needed) encapsulated inside the C++ classes (which can
> > > be upgraded with time)
> >
> >Yes. I'd keep the C CODECs and wrap them with the pipeline components
> >as mentioned above. As for encryption, basically Speak Freely doesn't
> >have any business doing encryption at all. We'd be much better off
> >either building with SSLEAY or relying on IPsec opportunistic
> >encryption such as FreeS/Wan. Unfortunately, to remain compatible with
> >the existing Speak Freely, some of the existing eccentric encryption
> >modes will need to remain. These, again, can be pipeline components
> >plugged in as required.
> >
> > > - Large following of SF (as seen on the mailing list) can offer help
> > > to migrate code for sections and non developers for quickly ironing
> > > out
> >bugs ( Go
> > > Auriemma! ).
> >
> >Don't be over-optimistic about this. Over 12 years of Speak Freely,
> >the total number of people who have submitted 100 lines or more of
> >usable code is less than five. I'm not being cynical, just providing a
> >data point. When Speak Freely downloads exploded in 1996-1997 and the
> >program got lots of coverage in the press (NASA even broadcast the air
> >to ground audio feed with Speak Freely for a couple of shuttle
> >missions), I thought it was a just a matter of time before dozens of
> >developers volunteered to pitch in with the many tasks that needed
> >doing. Didn't happen.
> >
> >------------- ------------
> >John Walker | What did the mystic say
> >[email protected] | to the hot-dog vendor?
> > | Make me one with everything.
> > | -- Laurence Kushner
> >
> >
> 
> 
>                       * * *
> 
> To unsubscribe from this mailing list, send E-mail containing
> the word "unsubscribe" in the message body (*not* as the
> Subject) to [email protected]
> 
> 
>                       * * *
> 
> To unsubscribe from this mailing list, send E-mail containing
> the word "unsubscribe" in the message body (*not* as the
> Subject) to [email protected]
> 

                      * * *

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