Re: Proposed Aim for Speak Freely

> > If there are going to be more codecs than there are now (a bad idea,
IMHO),
>
> Not necessarily bad. It's good to have choices, and you can't predict all
> the possible special minority cases. You also can't predict if/when a new
> revolutionary groundbreaking high-quality low-bandwidth codec will appear,
> then a defined low-hassle interface for adding it will be handy.

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.

I do think that adding codec negotiation logic should be a high priority
item.

> > then there should be a 2-way negotiation process to select codecs for
> > both sides of a conversation.  Each side should be able to limit the
> > negotiation to a subset of codecs in the event of local low network or
CPU
> > bandwidth, or in the event of missing/broken codecs.  When you start
adding
> > codecs willy-nilly, it is likely that people with older SF versions
won't
> > have the latest whizbang codec that handles 6 channel surround sound,
> > 10Hz-100KHz  +- 0.5 dB with 0.01% THD.
>
> SF in current version already has several codecs, from "uncompressed"
> through GSM and CELP to LPC and LPC10. We may either keep the approach
> used now (a sensible default (GSM) and user-selectable other options and
> keep the negotiation on the users themselves and believe they know what
> they are doing, or use a simple negotiation ("I know B, C, and A in order
> of preference" - "I know C and D in order of preference" -> codec C is
> selected) in the beginning of the transaction. As there should be a
> session encryption key negotiation anyway, this shouldn't add much
> overhead.

> 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?
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.

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.

> > Things will get really complicated in conferences.  There may not be
enough
> > bandwidth in the conference "reflector" to handle wideband data streams,
> > sent out to many listeners.  The negotiation process would be very
complex -
> > I suppose you'd have to use the lowest common denominator for all
conference
> > members.  The conference reflector may have to keep track of the
individual
> > abilities and preferences of each of its conference members and possibly
act
> > as a codec negotiation proxy.
>
> Either this, or build the negotiation into the reflector and disallow the
> high-bandwidth codecs there. Or specify that high-bandwidth codecs aren't
> allowed in conferences by default. Not everything has to be complicated.
:)
>
> There is also a more advanced solution, the possibility of a protocol
> convertor, which could be used with advantage if we'd develop a next
> generation of the reflector that would be able to receive sound
> simultaneously from multiple sources and mix it together instead of
> sending chopped pieces. (Could be good for multiplayer games, eg. IVAO
> network of flight simulators and control towers, <www.ivao.org> - they are
> typically using Roger-Wilco now.) (Disclaimer: I never used the SF
> conference feature, so I am not really familiar with it.)

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.

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.




                      * * *

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