Re:CUSeeMe Audio -- where are we going?

Bill Woodland (wcw@bga.com)
Sun, 25 Feb 1996 23:41:46 -0600


>Date: Sun, 25 Feb 1996 18:43:46 -0700
>Reply-To: strev@mobius.net
>Sender: owner-CU-SEEME-L@cornell.edu
>From: strev@mobius.net (Dennis J. Streveler)
>To: <CU-SEEME-L@cornell.edu>
>Subject: CUSeeMe Audio -- where are we going?
>X-Sender: strev@mail.mobius.net
>X-PH: V4.1@cornell.edu (Cornell Modified)
>X-Listprocessor-Version: 7.2(a) -- ListProcessor by CREN
>
>SFO DJS 96/02/25 11.17
>
>
>Hello!
>
>I have now been an avid user and experimenter with CUSeeMe for several
>weeks. It appears one deep dark secret which no one seems to want to
>discuss: CUSeeMe's weakest point is its audio capabilities on relatively
>constrained-bandwidth Internet connections (28.8k modem connections up to
>128k ISDN connections).
>
>Upon some reflection, it is interesting to note that AUDIO becomes more a
>problem than VIDEO on TCP/IP networks such as the Internet. If you get
>lagged, if the network becomes overloaded, with VIDEO you can merely throw
>away a frame or two, or not accept new frames from the transmitter. With
>AUDIO, connected speech requires a smooth delivery of packets and a
>relatively constant available bandwidth in order to delivery PLEASANT
>speech. I make the distinction between INTELLIGIBLE speech (ham radio
>operators surely must be aware of this notion) and PLEASANT, COMFORTABLE
>speech, which by its nature is continuous, full-duplex and relatively
>consistent in audio spectrum quality. CUSeeMe fails to deliver the latter.
>
>
>
>Here are some specific questions:
>
>
>1) Is the quality of audio transmission a function of PLATFORM or CLIENT
>these days? Does Mac-PPC do a great deal better job in digitizing speech
>than Mac-68k? Does Wintel (with reasonable soundcard) do better than
>Mac-PPC? (My unscientific observation is that Mac-68k appears to be the
>WORST of the three, and Wintel the best.)

It's a combination of:
microphone quality
sound card quality
sound driver quality
processor speed
connection speed

>2) Are there new (better) speech compression algorithms out there which is
>going to alleviate this problem to some extent SOON?

Try the White Pines version. They have an 8.5k and a 2.5k audio compression
algorithm. The latest version of the reflector software from White Pines
has also cut down on some of the overhead, which results in more b/w for
video/audio.

>3) Rather than play black magic with the CUSeeMe transmission settings,
>surely there must be a document which says: "if it appears that you are
>getting xxkbps thruput, then your transmission setting should be xx,xx,xx."
>It would seem however, that perhaps there should be NO settings at all, and
>CUSeeMe itself should make those determinations on the fly!

Basically your max settings should match your connection speed, at least for
modem and ISDN users. On ethernet, 80k transmit max should give your
viewers (if they can receive that much data) produce pretty fluid video
motion (15frames/second) and high quality audio.

>Viable "videoconferencing" using CUSeeMe requires a fluid, usable audio
>capability. I can put up with jerky pictures. But I am surprised that the
>developers added color and all those neat things to CUSeeMe when the audio
>capability of CUSeeMe appears largely unusable!

CU-SeeMe was developed originally for ethernet speeds, and we are all very
lucky to be able to use it on 28.8 and even 14.4 modems. To quote another
person on this list, "don't expect to push a basketball thru a straw". If
you are talking about the Cornell version, remember that it's currently FREE
and BETA. If you are talking about the White Pines version, PAY your fee
for the software, and send these comments to them.

>One final remark, it amazes me that White Pine allows its "test reflector"
>to take on the loads which it does. Many times the reflector comes to
>complete gridlock, refusing to send any new (useable) video, and nobody
>DARES to try sending audio! Is this a way to promote the viability of
>CUSeeMe?? I think not.

Most of this is caused by slow modem users filling up the reflector and
using the incorrect settings. I DO agree, however, that the reflector
should be able to handle this by adjusting the amount of data sent and
received from these slower connections, but I'm not sure if it is
intelligent enough to be able to do this. The config settings for a
reflector can be set to disallow min settings lower than a set vlaue, or max
settings higher than a value, but I don't believe it can tell what speed
connection you are using so that it could adjust the amount of data it is
attempting to send back to the users.

>
>Regards,
>Dennis
>
>
>
>------------------------------------
>Dennis J. Streveler, Ph.D.
>Systems Consultant
>San Francisco, California, USA
>------------------------------------
>CIS: 71036,1645
>Internet: strev@mobius.net
>CUSeeMe: strev.mobius.net
>------------------------------------
>My job? To send the appropriate electrons hurtling around the globe.
>

Bill Woodland (wcw@bga.com)
Squeek on Undernet IRC
Channel Manager #CU-SeeMe
http://www.realtime.com/~wcw/