Re: CU-SeeMe - Does Audio work on a Modem?

Scott Lacroix (
Wed, 07 Jan 1998 10:25:37 -0400

At 01:06 PM 1/6/98 -0600, Jason Williams wrote:
>I always assumed the more bandwidth an audio codec consumed, the better
>the quality (and the less compression and hence less CPU power required).
>If that's true, then the Delta-mod codec would be better quality than
>G.723..True? I can't confirm since I can't get any audio to work at all
>thru CU 3.1. G.723 work very well for music broadcasts?

So, I'm not an audio-wizard, but I know a few...
First, do you understand the way MIDI audio files work? Basically they
store a series of commands to explain HOW to reproduce the sounds for a
song. IE: "Play a Horn: Volume 8, Duration 5, Pitch 3, etc, etc" In that
way you reduce a complex sound wave to a small series of commands needed ro
REPRODUCE the sound & you store only that. The problem with MIDI is that
each system has it's own decoder(s) and they may differ in how they define
things like "Horn".
So, how does that relate to G.723?
Same effect. The audio is not stored, a VERY complex recipie of how to
reproduce it is. (The recipie is based on a system of modelling human
speach that I don't even PRETEND to understand) THAT is what gets sent to
the other side. Why does it always sound the same (unlike something like
MIDI)? Everyone uses the same decoder (G.723) which has a defined model
that everyone uses.
Thus, depending on the complexity of the model and the command set, the
bandwidth requiered my be more or less than a compressed codec and the
quality may be better or worse. Also, if the recipie is very complex,
encoding a sound wave become complex as well & requires more CPU power.
Make sense?
BTW, I believe Intel DVI and DeltaMod are the only two compressed codecs
we ship. The others use some form of the above modelling (which I am
probably not doing justice to in my description...)
Oh, and in final answer to your question, it may not work well at all for
music, since the model that it uses for encodeing & recreating the sound is
based on human speach.

>I've had some interesting experiences with audio that I don't quite
>understand. Using the 2.1.2 version (the only WP version I can get audio
>to work with), the quality of a single audio codec depended on what
>sending codec I had it set to. The sound coming from other participants
>when I had it set to Digitalk was drastically different than when I had it
>set to Delta-Mod..even when they were sending the same codec all the time.

There are 1000 reasons (give or take) why that might be, all relating to
your machine config... Care to describe it?

>I had a question about this...Not sure if you can answer it..But does the
>sending rate limit the codec? ie: If you have your max-send set to 10kbps
>and you try to send 16kbps delta-mod, does it get clipped? Or does it try
>to send the full 16kbps if there's no packet loss? I can understand
>trying to receive audio with bad rates, but does the max send also effect
>audio? I've always set my max send up to 20 or so then paused for

Hmmm... yes and no. :) It will try to send what it can, based on max send
AND current available bandwidth. If either drops below what's required for
the codec you are using, it will drop what it has to. If available
bandwidth reaches a point where all the data can be sent, it will be.
It seems that the older WP clients may try to send all the audio even if
it required going beyond your "max send" cap. The newer clients are much
more bandwidth aware.

>Nice advertising :)
>I don't quite see how conferencing on a private server is any different
>than conferencing on a fairly unused public server with respect to the
>quality of transmission and reception of audio. It's just as easy for
>someone to have screwed up rates on a private server as it is for a public
>server (After running both public and private reflectors..I can vouch for

I think what Gary meant here is that a private server is something you're
paying money for. Therefore you can expect a higher quality of service from
them. And constant monitoring & adjustment of server/client bandwidth
allowances. Certainly you can achieve the same effects on any WP server...
Keep in mind that the load will (potentially) be heavier for a public
server (since it's free) and may vary much more dramatically. Will someone
operating a public server (presumably not as thier main source of income)
be alloting the time needed to fine-tune the server for the constant load
I Dunno... :)

>Of course...with programs like Refmarshal out there, more and more
>reflectors (both White Pine and Cornell/Enhanced Reflectors) can be
>controlled with a nicely designed interface. The issue of monitoring and
>controlling will eventually be a thing of the past with more reflector
>operators taking advantage of the tools out there.

Didn't you write RefMarshal? Nice Advertising... :)
Seriously tho, we HAVE a nicely designed interface... Have you seen the
new Web UI? Very slick! <--- Nice advertising *G*

>improved? I'll let you know if and when I can get it to work :)
>Also keep in mind, not EVERYONE uses CU sending G.723 audio to a
>non-3.1 user has little effect. It's why a lot of people are still
>sending in B&W from what I've seen...backwards compatibility.

Mmmm... Again, if you need some help kick me an email or catch me on the
server. I'm not Support, but I'll do what I can :) Oh, and while it's true
that other, non-WP 3.1 clients (There are OTHER clients??? :) don't support
G.723... Almost ALL H.323 capable clients do. Sooooo.... It's not like WP
just thought it up & uses it 'cuz they thought it was nifty! (However, it
is... :) </sarcasm>

Just my humble, yet vocal, $0.02....

- Scott


,-==================================-.-==================================-. | I haven't lost my mind, it's backed | Scott LaCroix ( | | up on tape around here somewhere... | Sr. Software Engineer ___ | | - Author Unknown | White Pine Software ./_ -\. | | #include<disclaimer/std.h> | q| o O |p | `-==================================-^-=====================oOOo=~U~=oOOo-'