Re: 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]