Re: Hardware Help For CU...

Dennis J. Streveler (
Fri, 28 Jun 1996 08:52:47 -0700

Hello Dave,

See my comments below. Cheers, Dennis

At 11:20 PM 6/27/96 -7, Dave Easton wrote:
>One of the prime basics of CU, as I see it, is no hardware processing
>is required, it's all done in software. Other systems REQUIRE some
>kind of hardware add-on card(s) at each end. I am, of course, not
>including video digitising cards, if the camera isn't digital output,
>in this.

It is not only CU, but the field is filling with contenders rather rapidly.
There is also Videophone, VDOphone, FreeVue and CoolView. All can use tje
quickcam as a video source without a video capture card. (I should note,
that for some reason, FreeVue cannot use a COLOR quickcam.)

>What I am wondering though, is this; could there be some kind of
>OPTIONAL "helper" card for CU? Especially with the problems folks are
>having with color CU, ie: there is no cpu prossing power left to do
>the receiving if you are trying to send color at fast fps, etc. Some
>inexpensive, say, under $100, card to just help take the load off the
>CPU, but still remain completely compatable with current CU
>I get the impression,with color, the limiting factor is not a 28.8KBPS modem
>or even a 56K line, but one runs out of cpu power as so much transmit
>and receive processing must take place. . A cheap add-on card could
>let you off-load your transmit processing and reserve your CPU for the receive
>processing. (Or which ever way was best.) The standards would remain
>the same so those without the "helper card" would see no difference,
>and certainly would not be excluded from anything as would be the case if
>"hardware CU" ran on a different standard.

Surprise, surprise. Inside the Color QuickCam, in fact, is a daughterboard
which contains a compression chip which can produce "Videc" compression of
the image. Unfortunately, that method of compression is not supported by CU
or ECU at the moment. This is a real pity, and sure hope the situation will
change. This will certainly relieve a good deal of pressure on the CPU,
which, as you point out, is a major drawback to the use of the CQCW with ECU
at the moment.

>I have never tried CU audio, but also see lots of negative comments
>here, too. Possibly such a helper card might also assist in
>processing audio, as well? Again, using current CU standards for
>compatibility with non-card users.
>I am no computer scientist, but I know some on the mail-list are. Is
>there any possibility of such a thing?

I really don't know what the solution for improved AUDIO is. I have spoken
to White Pine people about it, but there seems to be general denial that
there is a problem. Audio is a real problem, since it must be delivered in
"real-time" (more or less) therefore it must use the UDP protocol.

But it is so fragile. If the packet loss rate climbs too high (say, above
20%) it is nearly impossible to make speech intelligible. All I can say is
that some other products do it better, probably using more advanced "codecs"
to minimize the number of packets required, which in turn minimizes the
chance that they get lost.

I have wondered whether the codec of some products might include some
proprietary notion to send REDUNDANT audio data, on the premise that if one
packet gets lost, its redundant twin gets through. But I have no direct
knowledge of this scheme being used. Something like that, however, in my
opinion, will have to be devised in order to improve the audio quality of
such products.

>Regards, Dave in Phoenix

Dennis J. Streveler, Ph.D., | Internet:
Systems Consultant | CIS: 71036,1645
| CUSeeMe:
-Future Technologies in Medicine / | web:
Telemedicine +------------------------------
-International Software Development | 415 239-1441
Methodologies | 415 469-9476 fax
-Human-Computer Interface Design | 127 Lake Merced Hill
for Casual Users | San Francisco CA 94132 USA
My job? To send the appropriate electrons hurtling around the globe.