It's a combination of:
sound card quality
sound driver quality
>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
>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.
>Dennis J. Streveler, Ph.D.
>San Francisco, California, USA
>My job? To send the appropriate electrons hurtling around the globe.
Bill Woodland (email@example.com)
Squeek on Undernet IRC
Channel Manager #CU-SeeMe