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.

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

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




                      * * *

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