Re: Proposed Aim for Speak Freely

Hi,
Question.
I miss the modem-feature for direct modem-to modem-connections that was
available in all the 16-bit versions of windows, didn't know why Mr. john
Walker dropped this feature in the later Versions.
What about backward-compatibility to all types of obscure wind0wz Systems,
and the related work-arrounds?
Wasn't this also a challenge that would lead to different codebases in the
past for sf?
Never know what m$ holds for the future.
Regards, Attila.
----- Original Message -----
From: "Thomas Shaddack" <[email protected]>
To: <[email protected]>
Sent: Tuesday, August 19, 2003 4:02 AM
Subject: Re: [speak-freely] Proposed Aim for Speak Freely


> On Mon, 18 Aug 2003, Kevin McCoy wrote:
>
> > I think there are bigger fish to fry right now than adding additional
> > codecs. There are plenty of codecs that are already implemented for SF's
> > intended use.
>
> Definitely. But there are people that will insist on them. So let's give
> them a way to add them on their own. This shall prevent forking of the
> code and lower the amount of disputes.
>
> > I do think that adding codec negotiation logic should be a high priority
> > item.
>
> I agree. Though I'd suggest to just keep it manual (with GSM or something
> similar as a default) for the first versions - so far it works well.
>
> > > We shall be also able to manually override the negotiation for
> > > individual sessions, maybe possibly keeping the required individual
> > > default overrides in your local phone book. (Eg, high-bandwidth
> > > high-quality prefered for IPs within your netmask, low-bandwidth
prefered
> > > otherwise.)
> >
> > Errrr. Why?  If one person has a 28.8 Kbps modem hitched to a 486 and
the
> > other has a 384 Kbps DSL connection on a P-IV box, why would you want to
> > override a sensible low UDP bandwidth/low CPU impact codec on the 486
side?
>
> If both persons have 128k lines, and at least one of them doesn't want to
> use more than 9k6 with certain subgroup of the users (but not with all),
> then manual override is handy. Let's leave it as an option for advanced
> users and uncommon scenarios. Or for debugging. Or for testing.
>
> > Just let the two sides negotiate every time - it only takes a few
> > miliseconds. An address book entry does not take into account any
> > hardware changes or machine swaps.  Laptop computers downshift in CPU
> > frequency when running on batteries.  This might be a problem with
> > CELP and other CPU-intense codecs.
>
> Good for common scenarios. Again, we don't have crystal balls so we can't
> accurately predict all the things that may happen. We also can't rule out
> a bug in the negotiation routines or protocol and a necessity of an ad-hoc
> workaround. Or a minimalistic implementation on the other side that would
> be listening-only with no negotiation routines and hardcoded codec (eg,
> something embedded).
>
> > In my case I have *9600 Baud* satellite phones to deal with, and I have
to
> > share that vast bandwidth with other applications.  I don't want a DSL
user
> > to override my low bandwidth CELP settings on the 9600 Baud side. On
other
> > systems I need to use ADPCM to preserve the DTMF control tones we
sometimes
> > send over SF.  Other codecs munch the tones.  I need absolute control
over
> > any codec negotiation.
>
> I need manual override. You never know when it will be handy. You don't
> HAVE to use it, it may be hidden deep in some menu or as an obscure
> commandline option, but it's better if it's there.
>
> > Mixing is not the problem; Receiving a stream of packets and then
sending it
> > back out over the same wire to potentially dozens of attached clients
is.
> > In a high bandwidth codec scenario, you'd saturate a 10BaseT
DSL/cablemodem
> > connection in short order - not to mention the poor CPU trying to
convert
> > one protocol into 5 or 6 different ones in realtime.
>
> All depends on the scenario. If you have a conference of just a half-dozen
> people, discussing eg. a piece of music, it may warrant and require a
> high-quality codec, while still not overloading the machine. You of
> course can't afford it with many users. All depends on the scenario. If
> the machine can't handle protocol conversions, let specify for that given
> server that it won't accept any other protocol than a specified one.
>
> > BTW, all codecs send "chopped up" audio. The trick is sending the chunks
> > fast enough so that the receiving buffer never runs out or overruns. If
you
> > are talking about multicasting, then don't hold your breath for its
> > implementation on the Internet at large. Most ISPs block multicast
packets.
>
> I expressed myself wrong. By "chopped" I meant the telltale situation when
> two data streams come to the receiver and instead of playing them both
> simultaneously the packets are playing in alternate order, as they arrive,
> which sounds AWFUL.
>
>
>                       * * *
>
> 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]