Re: Audio with CU-Seeme

John Ingham (johningh@tafe.sa.edu.au)
Mon, 25 Nov 1996 10:59:29 +0930


Neal Kite said...
>Has anyone had any good luck with sending audio through CU-Seeme using a
>28.8 modem?
>
>I can receive video just fine, but only get a couple of cracks when sending
>audio. <snip>

Firstly Neal, it's a good idea to give full details of your setup when
asking questions. But apart from that I must say that I have noticed over
the last 4-5 months a gradual drop-off in performance of my received audio
on CU-Seeme.

I'm using a 7200 Mac via a 28,800 BPS PPP dial-up line. My results with
both the Cornell and White Pine flavours of CU-SeeMe are similar using
Delta Mod (16kbs) and 50 or 100 ms quatization; generally I get good
reports on my SEND sound but my RECEIVED sound is now so choppy with so
many lost packets that it is all but unintelligable. My ISP is a major
provider with wide bandwith to the Internet.

When down-loading stuff via Netscape I regularly run at 3.6 Kbytes/sec. I
run Real-Audio3 with good success. But with CU-Seeme the error log is
almost always running with twice as many incoming lost packets as outgoing,
sometimes over 50% lost packets, even when both ends are capped at 20 kbs.
I never see errors in Chat but I believe that's because it uses TCP for
transport rather than UDP.

Back on 30 May 1996, Dennis J. Streveler said in part...

>Yes, it most certainly is the state of the Net these days. Packet loss of
>60% is not all that uncommon. When this happens forget about audio
>altogether because you are going to lose so much as to make the conversation
>nearly unintelligible.
>
>Where do these packets go? Well, to cyberspace heaven of course! Seriously,
>the Net is fundamentally a maybe-my-packet-will-get-there arrangement.
>Protocols on the Net include UDP which is a protocol which requires no
>acknowledgement that a packet ever arrives. TCP/IP is a protocol which
>requires an acknowledgement and resends a packet if one gets lost, but
>requires considerably more net overhead.
>
>So, most video and audio applications on the Net use primarily UDP to
>communicate. This is because UDP is more suitable to "real-time"
>applications, where you can't wait all day for all packets to arrive.
>
>Thus, with CUSeeMe, as with its competitors, video information can get lost.
>This is not such a big deal, really, since you lose part of a frame. But
>with audio information, and even for information in the Chat/Talk window, if
>substantial information gets lost, it can render a conversation worthless.
>
>Regarding color, believe it or not, given the state of the developoment of
>color compression algorithms these days, COLOR uses less bandwidth to
>transmit than b&w. This is counter-intuitive, and I suspect it springs from
>the fact that more research has been done in color image compression these
>days. But go figure, reportedly the Color QuickCam can outperform the B&W
>version on CUSeeMe because of this.

It would be useful if someone who is having good success with CU-SeeMe
would publish on this list their settings for several connection types - eg
14,400, 28,800, ISDN Ethernet etc.

John Ingham
Supervisor, Technical Operations, CALS (Centre for Applied Learning Systems)
Adelaide Institute of TAFE (Training and Further Education)
GPO Box 1872 Adelaide South Australia 5001
Ph: +61 8 8207 8550 Fax: +61 8 8207 8552
Email: johningh@tafe.sa.edu.au
Web Site: http://www.tafe.sa.edu.au/video-conf/
=======================================================