Problems with audio delay using VoIP #1279

bigbluebutton-issue-import opened this Issue Aug 12, 2015 · 26 comments


None yet

3 participants


Originally reported on Google Code with ID 524

What steps will reproduce the problem?
1.Install BBB on Ubuntu 9.04 and 10.04, on XEN virtual machine and hardware 
2.Go to conference, enable audio first time others hears my voice a little delay 1-2sec. But a delay of 
up to 5 minutes for 10 seconds, 10 minutes - 20 .. this is very bad.

What version of the product are you using? On what operating system?
BigBlueButton Version 0.64, Ubuntu 9.04, Ubuntu 10.04

Reported by polumish on 2010-05-11 12:09:02

Hi polumish,

The mixing of audio is sensitive to CPU usage.  Even though we run on a virtualized machine (KVM), you'll get better performance

when installing BigBlueButton natively on a host.

How much memory are you giving the XEN instance?

Reported by ffdixon on 2010-05-11 13:35:11

On XEN virtual host I have 1.5 Gb memory, and 2 core 2.2 CPU.
On native host I have 1 Gb memory and 2 core 2.6 CPU.
On both servers BBB the same problem.

Reported by polumish on 2010-05-11 15:43:52

Several people have complained of this in 0.64, and it doesn't seem it was a problem
0.63. It would be best to try to reproduce and investigate so we don't release 0.7
the same bug

Reported by Me.Snap on 2010-05-20 18:59:21

  • Labels added: Priority-High, Milestone-Release0.7
  • Labels removed: Priority-Medium
I can confirm this. 
Native install (non virtual)

2gb ram
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09

ubuntu 9.04 fresh install,
add repo and install via apt-get

Reported by 808blogger on 2010-06-07 21:13:52


Does any one working on this issue. Because I think the problem become from the Red5
0.91. I try to upgrade with the RED5 trunck 1.0.0, but a can connnect to asterisk because
I have an RTMP handshake problem. I will work on this problem.

Reported by qdqdsqdqs on 2010-07-03 07:37:37

It's the same on the demo server.
It's impossible to use conference with this issue.

It the same with RED5 trunck 1.0.0. May be it came from red5 phone or JAVA !

Reported by qdqdsqdqs on 2010-07-07 16:23:18

Hi jproussandies,

High-quality VoIP conferencing is a tough nut to crack.  TCP/IP does not guarantee
delivery of packets within a certain time.  As well, the network latency (i.e. a remote
user's upload bandwidth and distance from the server) plays a big factor.

We know this problem well.  Here's some more background information along with some
of our suggestions/plans to improve it

Regards,... Fred

We have a pretty good idea where the 

Reported by ffdixon on 2010-07-07 19:12:59

Thank, I read the FAQ, and the problem came from the transcode latency in red5 phone.
Flash Player 10 support SPEECH and ADPCM codec, who are natively supported in Asterisk.

All the sip rtp to and from asterisk can be in SPEECH (I check and the bbb-voice manage
the SPEECH), also the FP 10 will talk in SPEECH.

The ubuntu 10.4, comme with asterisk 1.6.2 and a new function confbridge who can mix
no-linear codec like SPEECH.

If we need to do some voice transcode, it can be perform by Asterisk.

What do you think of my idea ?

Reported by qdqdsqdqs on 2010-07-08 10:43:44

Hi jproussanides,

Thanks for your suggestions.  We are currently using a modified version of app_konference
for mixing voice.  We're working on packages for Ubuntu 10.04, which give us Asterisk

We're aware of the support for speex in FP 10, but at the moment asterisk only supports
8 khz speex.  See

We'll definitely be exploring using speex in a future iteration of BigBlueButton.

Reported by ffdixon on 2010-07-08 11:13:27

We've been looking into this and we think the problem is related to timestamping of
incoming RTMP packets.  

For the audio packages, if the BigBlueButton server gets loaded down (such as with
a slide conversion), the transcoding of some of the audio packages may lag, causing
the queue of incoming audio packets to build-up for a user.

When the red5 server does transcode the packets, they are now lagging behind and the
user's voice comes in as delayed.

One solution is to drop packets that are too old to catch up, rather than now leave
the user 2, 3, 4, or 5 seconds behind in the audio.

More investigation needed.

Reported by ffdixon on 2010-07-14 23:23:34

  • Status changed: Accepted

Reported by ffdixon on 2010-07-14 23:24:40

We are still investigating trying to narrow down where the problem is. We notice that
not all experience the delay at the same time.

A workaround is to the user who is experiencing the delay to leave and join the voice
conference (i.e. clicking on the headset icon).

Reported by ritzalam on 2010-07-15 15:42:44

  • Labels removed: Milestone-Release0.7
Issue 587 has been merged into this issue.

Reported by Me.Snap on 2010-07-26 15:11:44


Reported by ffdixon on 2010-08-09 11:31:26

  • Labels added: Milestone-Release0.71
Experiencing similar issues myself. Audio is delayed by about 1 second (1 way only,
inbound Audio). 

How can you get the incorrectly stamped packets to be dropped? I would either like
them to be dropped or un-queued. 

Reported by colinjamesmcdermott on 2010-08-31 01:44:33

We're looking at the time stamping of the audio packets as one of the ways to improve
the audio.  See

Reported by ffdixon on 2010-08-31 09:41:51

Some here on Ubuntu 10.04 LTS/BBB 0.7 on Xen and on physical

Given the current implementation of the VoIP in BBB, do you think is possible to just
drop the late-come-packets and resync? What if I want to help implement such a workaround?

Reported by davide.vaghetti on 2010-09-08 09:23:30

I checked out BBB on github and saw a 14 hours old "throw away delayed rtp packets"
commit on bbb-voice! Great! You guys rock! I'll test right now. 

Reported by davide.vaghetti on 2010-09-08 09:32:51

Thanks!  Let us know what you find.  We've been working hard on this and we really want
to solve it (as much as possible).  The goal of BigBlueButton is to offer remote students
a high-quality learning experience, and that includes high-quality audio.

Davide, if you are experienced with this type of programming, please contact us directly.

Reported by ffdixon on 2010-09-08 11:15:55

Is it possible to have trunck repository to test it ?

Reported by qdqdsqdqs on 2010-09-08 11:20:26

At the moment, you would need to have setup a BigBlueButton development environment

And be working on the "bleeding edge"

Once we into our testing phase, we'll make an announcement to bigbluebutton-dev and
provide a test server everyone can try out.  If your not a developer, best wait until
you see that announcement.

Reported by ffdixon on 2010-09-08 11:31:09

Asterisk now supports 16kHz Speex:

(The contradictory comment above was posted to the Asterisk-dev mailing list in May;
the patch was posted June 12.)

Reported by rod.montgomery on 2010-09-10 20:55:35


Yes, that issue was reported by a developer that we ( paid to add Speex
support, specifically for BigBlueButton.  Richard is aware of it and using it to support
WB Speex already for the 0.71 release.  We were able to get our WB Speex support into
trunk for the upcoming Asterisk 1.8 release, but it was not possible to add it to the
core in 1.6 (because all of the available codec slots were already full, meaning you
had to remove support for other codecs to add this one).  Instead, we created a patch
so that we could build a custom version of Asterisk 1.6 with WB Speex.  See
for more information

Reported by jeremythomerson on 2010-09-11 04:00:13

Fixed....on going testing in

Reported by ritzalam on 2010-10-17 16:52:21

  • Status changed: Fixed
Issue 676 has been merged into this issue.

Reported by ffdixon on 2010-10-24 00:21:45

Please can you just explain what the actual delay is. Because of the 2-3 seconds delay
in the past. Is this also better / faster now

Reported by rb.proj on 2010-11-02 18:36:31

@kepstin kepstin modified the milestone: Release 0.71 Aug 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment