Voice Lag is around 2-4 Sec

[GoogleCodeExporter]

There is a Voice lag of around 3-4 Sec during Voice Chart over VOIP

Original issue reported on code.google.com by vishwana...@gmail.com on 15 Nov 2010 at 1:23

[GoogleCodeExporter]

Hi Vishwanathsubbanna,

Yes, there will always be lag in VoIP, but we'd like it to be less than 3-4 
seconds.

Can you give us details on your setup.  Specifically:

For the server:
  1) BigBlueButton Server version
  2) Bandwidth to/from the BigBlueButton server
  3) Geographic location of the BigBlueButton server

For the users
  4) Upstream bandwidth of clients
  5) Geographic location of the BigBlueButton server

If this is your own server, can you and your other users try the BigBlueButton 
demo server: http://demo.bigbluebutton.org/.  The demo server is located in 
Ottawa, Ontario, Canada.

Just to set expectations, there's not much we going to be able to do unless we 
can reproduce the problem. We've just come off of two months of development on 
improving the VoIP -- and we're very keen to make the VoIP as best as we can -- 
but there are things that are outside our control, such as bandwidth 
constraints of server or users.

Let us know the details of your setup.

Original comment by ffdixon@gmail.com on 15 Nov 2010 at 1:38

[GoogleCodeExporter]

i have similar problem, my server setup is :
0.71 've been using with either freeswitch and asterisks, vmware on hp dl380g6 
2core, 2ghz,2gbyte memory both server and clients are on the same segment local 
area connection segment both clients using core 2 duo 3ghz with logitech cam. 

Original comment by cosmic.f...@gmail.com on 28 Nov 2010 at 5:02

[GoogleCodeExporter]

Hi cosmic,

Thanks for providing some details.  When you said 2 gb of memory, is that the 
memory of the BigBlueButton VM or the host computer.

Whenever running BigBlueButton as a VM, the host CPU is only giving it a 
portion of its CPU cycles.  Since VoIP is very time sensitive, any lag in CPU 
is going to translate into a lag in audio packets.

The BigBlueButton VM isn't meant for production deployment; rather, an easy way 
to try out BigBlueButton.  Still, we want the VoIP to be good.

How much memory is allocated to the VM itself.  Also, is it possible to install 
BigBlueButton on a dedicated machine, even temporarily, to compare the 
performance relative to the VM on your network?

Original comment by ffdixon@gmail.com on 28 Nov 2010 at 5:21

[GoogleCodeExporter]

thank you very much for the quick reponse, i really appricate that, our rig has 
4gb mem using m$ 2008 x64 r2, since it wont boot using ubuntu (which is really 
disappointing come from hp products) with nothing else installed and running 
besides vmware it self. at the time we tested the bbb with 1 moderator and two 
other participants, the processor only hits 5% at max where memory steady at 
2.5gb, but the awesome things is the video works great even with 1 participant 
using cheap wifi router (tried it to simulate our branch connection - we use 
mikrotik ip vpn for several of them)i really wish you guys at bbb developers 
the best, it would be awesome to have other webconf solution.

Original comment by cosmic.f...@gmail.com on 29 Nov 2010 at 5:56

[GoogleCodeExporter]

We've continued our work to reduce the voice lag in 0.71a.  

Original comment by ffdixon@gmail.com on 11 Jan 2011 at 4:40

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 6 Feb 2011 at 11:44

• Added labels: Component-Voice, Usability

[GoogleCodeExporter]

I've just explored the problem with lags. I tried both demo.bigbluebutton.org 
and my own server, and both asterisk and freeswitch. The lags are approximately 
the same: 1-2 secs from one client to another and 3-4 secs for round-trip (echo 
from other clients).
The problem is sertainly not due to performance since the proc-load at my 
server is about 4% mainly by java.
The clients are also unlikly to be responsible since I tried FF,Opera and 
Konqueror. But Ok, the flush-plugin was the same in all cases (Sockwave 10.2 
r152). Operating system is also does not matter at least for Ubuntu 10.10 and 
WinXP. Network lags play no important role since the video streams go much 
fater than the audio. It is clearly seen when one counts his fingers, for 
example.

It would be not a problem for, say, presentation in contrast to dialogs, but 
unsyncronized audio and video streams make that nasty. It is worth thinking 
about some sync-events for them.

So, I suppose the problem of lags is due some artificial delays (by buffering 
or multiple buffering in the chain of format transformations) then due to 
preformance.

Original comment by sokatov@gmail.com on 12 Feb 2011 at 10:39

[GoogleCodeExporter]

> So, I suppose the problem of lags is due some artificial delays (by buffering 
or multiple buffering in the chain of format transformations) then due to 
preformance.

Part of the delay is the path for the audio packets.   See

  http://code.google.com/p/bigbluebutton/wiki/FAQ#Why_is_there_a_delay_in_the_audio_when_I_use_VoIP?

In comparison, if you install BigBlueButton on a local network (192.168.0.x), 
and connect to it with clients on the same subnet (giving you a direct route to 
the server), you get audio delays of close to 1 second to the client, 2 seconds 
for round trip.

Part of the delay is the inherent limitation of Flash to use TCP (not UDP) for 
sockets.  See

  http://p2p-sip.blogspot.com/2010/02/faq-on-using-flash-player-to-make-phone.html

UDP is much better for VoIP because it's fire and forget, whereas TCP adds the 
overhead of "guaranteed delivery".  The TCP stack determines when data packets 
need to be resent, and buffers the flow of data until the previous packets are 
successfully transferred.   Skype, for example, uses UDP.

The Skype analogy highlights another difference.  Skype is peer-to-peer, so 
there is no intermediate server, whereas in BigBlueButton all audio goes 
through the FreeSWITCH/Asterisk for mixing in the voice conference server.  
This gives us scalability and connections to the public service telephone 
network (PSTN).  You can have 25 people in a BigBlueButton session, all 
listening to the presenter, and half of them can be dialed in over the PSTN.

Another consideration is the context for the BigBlueButton session:

One-to-many: For a one-to-many session, where the presenter is speaking to 25 
students who are all muted, BigBlueButton works really well.  Yes, the video 
and audio are not synced, but we find after a while your focus goes to the 
presentation window.  The presenter's screen becomes added information around 
movements and gesters, not lip syncing.  Most time students will ask questions 
through chat, and the presenter can weave the answers into their presentation 
in real-time.

One-to-one:  The VoIP delay is an issue, and it slows down communications, but 
if both people are willing to let the other finish their sentences (such as a 
student listening to a teach explain a topic), you don't get both people 
constantly talking at once.  Conversations can occur similar to telephone 
conversations; the rhythm is slightly different.

Small groups: Here the VoIP delay has the biggest impact.  When there are three 
or more people all participating in a group discussion, you will find that a 
2-4 second delay means that whenever one person finishes talking, there will be 
times when two (or more) people begin replying at once.  You see this on news 
when a host has two or more guest speakers communicating from afar, where there 
are audio delays, and both want to reply at once.  You can have a group 
conversation with a voice delay, but you need a bit of protocol to make it work 
well.  Something like "... and those are my thoughts, Steve what do you think?"

What's interesting in small groups is the chat becomes more prevalent.  We've 
observed that when a discussion is ongoing between two members, others are 
typing into the chat adding their thoughts. A multi-channel communication 
begins to occur, and people save the chat notes afterwards as part of the 
discussion or meeting minutes.

The bottom line is that we (the core developers) want to make the voice delay 
as minimal as possible.  Flash is not going to be restricted from using UPD 
forever.  Networks will get faster.  And we will continue to optimize the 
handling of VoIP packets (which we can measure the improvements using a local 
network setup for BigBlueButton).

Aside from continuing the optimization, there are two other options to pursue 
in setting up a BigBlueButton server:

1) Provide dial-in numbers.  This bypasses the BigBlueButton server and the 
user's audio goes directly to the asterisk/FreeSWITCH server.  You get very 
good audio with very little delay.

2) Run an external SIP client.  The user's VoIP packets go directly to the 
asterisk/FreeSWITCH server over UDP, again bypassing the BigBlueButton server.  
There's extra setup for this for the users, and we're exploring ways to 
minimize this setup effort

   http://code.google.com/p/bigbluebutton/issues/detail?id=832

Not surprisingly, Skype uses UDP and is peer-to-peer: the packets directly from 
the client to the server

Original comment by ffdixon@gmail.com on 12 Feb 2011 at 2:48

[GoogleCodeExporter]

I can add a third option:

3) Run BigBlueButton within Adobe Air, which supports UDP.  With a flash-based 
SIP stack, you could have an internal SIP client for BigBlueButton that would 
use UDP.

Original comment by ffdixon@gmail.com on 12 Feb 2011 at 2:56

[GoogleCodeExporter]

Dear ffdixon,
thank you for your response, but my message was not a question but a little 
report.
I am sorry if it was not seen from the text.

I had intensivly studied the problem of lags in internet before I wrote that. I 
had seen the references you gave me. I even saw the previous "audio delay" bug 
report which was marked as fixed in version 0.7, where the developers announced 
the usage of speex codec. My version is 0.71a (the latest). But the problem of 
1 sec. lag still persists. I understand all the potential of the BBB-project 
and I very greatful to all developers for their efforts. But the problem of lag 
prevents many usages: a speaker may finish his topic and continue about other 
things when my comment reaches him. It is very problematic.

And in my message I just wanted to say that the delay (of course, if depends on 
many factors) is almost constant and weakly depend on distance, computer power, 
used software. To my opinion, the reason is something constant like amount and 
quantity of buffers in BBB, Red5 and Asterisk.

I hope my finding will help in trapping the bug of lags.

Original comment by sokatov@gmail.com on 12 Feb 2011 at 3:20

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 4 Mar 2011 at 2:17

• Changed title: Voice Lag is around 2-4 Sec

[GoogleCodeExporter]

I have explored the question of lags a bit more.
As I see, they exist not only in BBB, but also in all lossless programs.
If I do rec... | ssh host 'dd ibs=200' | play ... I get the same delays even if 
the host is localhost.
Moreover these delays strongly depend on the connection time. If connection 
establishes fast, the delay is smaller. It it takes 10 sec for establishing the 
connection, the delay is of about the same 10 secs.
As far as I anderstand, both input and output of a stream are syncronized to 
their host clocks. And these syncs differ by the time of connection. Even some 
data come earlier, they are not played until all previous queue is played.
May be, if the player jumps forward each time the buffer is filled larger than 
by X sec ahead (X is order of 0.1-0.5 sec), the problem with lags will 
disappear.

Original comment by sokatov@gmail.com on 6 Mar 2011 at 11:48

[GoogleCodeExporter]

Original comment by ffdixon@gmail.com on 8 Jun 2011 at 11:06

• Added labels: Milestone-Release0.8

[GoogleCodeExporter]

Issue 873 has been merged into this issue.

Original comment by ffdixon@gmail.com on 5 Jul 2011 at 7:38

[GoogleCodeExporter]

Original comment by ritza...@gmail.com on 6 Oct 2011 at 4:03

• Changed state: Fixed