Subject: RE: Silence suppression with NetMeeting

From: [email-masked] (Fred M Burg)
Date: Tue, 3 Nov 1998 21:25:40 -0500

The issue of using Comfort Noise Generation (CNG) and Voice Activity
Detection (VAD) - hand in hand - is a delicate one. When a person is
speaking, there is usually some background noise that the listener
hears anyway, especially if one is using a mike and speakers (not to
mention echo). The amount of background noise depends on how well the
speaker is decoupled from the background so little, if any, of it is
overheard by the listener (contrast a traditional handset with a
mouthpiece to an open mike).

The reason this becomes an issue is that when the main speaker stops
talking, the listener still expects to hear the background noise continue.
If it too stops, this can be disconcerting. Dead silence is very
disconcerting (the listener may think the line went dead).

Now the receiving station can always generate some noise so the listener
thinks they are still hearing what is going on in the background on the
speaking side. But the best that can be done is to extrapolate previous
speech/background to create subsequent background noise. Short of doing
nothing (same dead-line syndrome), the receiver can generate random
noise. But the discontinuity between the background while someone was speaking
and the subsequent random noise is also disconcerting.

The above methods (sender sends nothing AND ((receiver does nothing) OR
(receiver generates something [random or extrapolated background]))
have the desirable effect of requiring no bits to be sent while the
speaker is silent. At the other extreme, is that the voice coder continues
its job but, since the speaker is silent, it is only encoding background
noise AT THE  FULL BANDWIDTH of the coder (eg, 6.3 kbps for high rate of
G.723.1).

In the middle is where you use CNG/VAD. Given that all of the above
"solutions" are less than desirable, another choice uses a VAD to
detect when the power levels at the transmitting side drop below a
certain level and go above a certain level. Presumably, the background
noise is below the threshold of detecting a "main speaker". In between is
when you can use the CNG to code the background. Of course, the whole idea
is that the CNG should take less bps than the codec since it only needs to
reproduce a "close approximation" of what the background is so the
listener thinks it is what he/she heard before (while the speaker was
talking) and it is not dead silence.

So the need for using CNG/VAD depends on what you're trying to
accomplish. Hope this helps.

Fred Burg
AT&T
=====

NetMeeting doesn't use these optional modes.  If there's silence, we don't
send anything at all.  This is consistent with most other H.323
implementations that we interoperate with.  In contrast, H.320 systems
typically send silence because they have to send something.

-Max Morris
 NetMeeting Program Manager

> -----Original Message-----
> From:	Reinaldo Penno Filho [SMTP:[email-masked]]
> Sent:	Tuesday, November 03, 1998 9:44 AM
> To:	list iptel; Linden, Dominique
> Subject:	RE: Silence suppression with NetMeeting
> 
> 
> you> -----Original Message-----
> you> From: [email-masked]
> you> [mailto:[email-masked]]On Behalf Of Linden,
> you> Dominique
> you> Sent: Tuesday, November 03, 1998 11:49 AM
> you> To: list iptel
> you> Subject: Silence suppression with NetMeeting
> you>
> you>
> you> Does anybody know how you can make NetMeeting support silence
> you> suppression /
> you> comfort noise generation?
> you>
> 
> As far as I know, *if* netmeeting supports G.723.1 (and Anexes), silence
> supression, comfort noise generation and VAD should be implemented by
> default. It´s in the ITU standard.
> 
> Best Regards,
> 
> _________________________________
> Reinaldo Penno Filho
> Consultor Tecnico
> SAGA Sistemas e Computadores S.A.
> tel: 55-21-5508506
> e-mail : [email-masked]
> 
> Universidade Federal do Rio de Janeiro
> Nucleo de Computacao Eletronica / Instituto de Matematica
> Grupo de Redes de Alta Velocidade
> e-mail : [email-masked]
> 
> IEEE member
> e-mail : [email-masked]
> _________________________________
> 
> 
> 
> 
> you> Thanks,
> you> Dominique
> you> ---------
> you> This message came from the IETF IPTEL Working Group Mailing List.
> you>
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
---------
This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Nov 1998 09:39:46 -0500 (EST)

This is a very old topic that has been addressed since the beginning of
packet voice.  It is made more complex by the need to detect packet losses
and fill the gap with some comnfortable interpolation.

The classic solution is:

* to have senders terminate the talk spurt by at least one full
  bandwidth noise packet (i.e., transmit at least one packet even if VAD
  detects silence.)

* to have receivers fill up gaps with a slightly lower energy
interpolation
  of the previous packet -- typically using some form of exponential
decay.

Indeed, how to "interpolate" is somewhat of a black art.  It goes all the
way to simply repeat a halved value of the previous packet, to generating
a white noise at the same energy level, to generating a hite noise using
the energy level and linear prediction coefficients of the previous
packet, to even use pink noise.  The LPC+energy is a natural fallout of
the LPC based codecs -- including GSM, G.729 and G.723.

-- 
Christian Huitema
---------