Re: [GnomeMeeting-list] Enforcing half-duplex?

["Mihai T. Lazarescu" <mihai email it>]

On Fri, 6 Feb 2004, Damien Sandras wrote:

> Le ven 06/02/2004 à 17:15, Mihai T. Lazarescu a écrit :
> 
> > The idea behind my question is to make GM behave as a
> > speakerphone for meetings over IP between two groups of people.
> 
> That mode was invented more than 10 years ago when
> full-duplex was not possible due to hardware limitation and is thus
> clearly not the solution to your problem.

Never tried to talk using GM to someone that put you on the
speaker instead of using the headset?  You hear loud and clear
all what you say, through his mic, delayed by the communication.
Quite disturbing.  Even more, if both ends are on speakers,
the system may end up oscillating.

I'd argue that modern speaker-phones over land lines use
half-duplex mode due to technical limitations.  They are
full-duplex while using the handset, but go half-duplex
when put on speaker to avoid local echo and oscillations.
And this is true for the cheapest consumer speaker-phone as
well as for the most expensive conferencing equipment.

> How would you decide who can speak and who can not with that
> speakerphone mode? 

It's based on levels.  If the level on the mic is higher than
the Rx level on the line (usually because the line is silent),
then the Tx is open and viceversa.  It's similar to the silence
detection mechanism, but:

- the reference for deciding "who's silent" is a dynamic
  comparison of the Tx/Rx levels;

- you turn off the Rx when turn on the Tx and viceversa (not
  just switch off Tx when the mic level is dropping below a
  threshold as in silence detection).

Useless to say that human communication is naturally
half-duplex.  You cannot hope to understand the other if you
speak to him at the same time.  So, everybody mutes himself
while listening and speaks only when detects silence around.
Conferencing equipment does just that, but this may be perhaps
beyond the designated purpose of GM.

Problem is that, while human brain is doing quite a good job
cancelling local echo (*undelayed*, mouth-to-ear), they are
very disturbed by the *delayed*, remote echo (remote speaker to
remote mic).  That's why the mic gets muted by the conferencing
equipment while a loud enough sound comes from the other end.

> Advanced MCU's can do what you
> request however.
> 
> > As far as I remember, there was an openmcu option to switch
> > only the loudest source on, only one at a time.  I was looking
> > for something like this without setting up openmcu... ;)

As you can see we do agree here.  I was wondering if this
exists or is planned for GM and got the answer: no.

Thanks,

Mihai