Sound is coming late

[Cumali Yaşar]

Hi Mr. Fred;
Your installed system is fine. Everything is so beautiful but the sound is coming late. Overcome the problem of sound. After describing the teacher's voice lesson comes too. Participants' sound comes later. What do you suggest? Thank you very much for your help again.
Sincerely Cumali YAŞAR

Cumali YAŞAR
Çanakkale Onsekiz Mart Üniversitesi
Eğitim Fakültesi

İŞ: 0286 217 13 03

2012/6/27 Darren Rickets <rick...@googlemail.com>

Hi Fred,

When using the iMac internally on the network it uses RTMP (works fine) when using at home it uses RTMPT (fails) even though firewall is set up to use RTMP incoming and outgoing.  I have set up the API to allow testing directly through to the server as normally it would through Moodle. If you want to test to see if i have missed anything or try to get the same error I can email you the server address 

Darren

--
You received this message because you are subscribed to the Google Groups "bigbluebutton-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-users/-/j6rzF6hHRoQJ.

To post to this group, send email to bigbluebu...@googlegroups.com.
To unsubscribe from this group, send email to bigbluebutton-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bigbluebutton-users?hl=en.

[Fred Dixon]

Hi Cumali,

Good to hear from you.  One factor in sound is the network latency.  For a user whose sound is coming in late, can you have them do a speed test

   http://speedtest.net/

and let us know their upstream/downstream bandwidth.  We recommend 0.5 Mbits/sec upstream and 1 Mbits/sec downstream.  Of course, BigBlueButton will work with less bandwidth, and these are only rough numbers, but as bandwidth decreases -- or if there are packet losses in the transmission -- the BigBlueButton client will take longer to send -- or resend -- the VoIP packets from the client to the server.

Can you also have one of your users try out our demo server at

  http://demo.bigbluebutton.org/

with you and see if there is any difference in the delay of their audio.

Regards,... Fred

-- 
BigBlueButton Developer

http://bigbluebutton.org/
http://code.google.com/p/bigbluebutton

BigBlueButton on twitter: @bigbluebutton

[neeraj]

Hello,

We have BBB 0.8beta 4 installed on a dedicated ubuntu 10.0.4 LTS server. When we join to the BBB meetings using a decent network (download speed - 24 Mbps, upload speed = 2 Mbps and latency 17 ms ), we get a remarkably great audio and video quality. However, few of our non-US based collaborators who are using network with download speed = 2 Mbps, upload speed = 2 Mbps, latency = 200 ms get very poor audio and video quality. The audio that they get is delayed and has substantial breaks. 

Is there any recommended network configuration, especially for maximum allowable latency, which will guarantee a good audio / video (only slides without webcam and desktop sharing)?

Best Wishes,

Neeraj

2012/6/27 Darren Rickets <rick...@googlemail.com>

To unsubscribe from this group, send email to bigbluebutton-users+unsub...@googlegroups.com.

[Fred Dixon]

Hi Neeraj,

Your results pretty much tell it all: on a poor network connection, the audio is not going to be good.  

Did you get these numbers from the service provider, or from speedtest.net?

The latency is a big problem.  A latency of 200 ms is very poor, and when sending real-time audio and video packets, it's going to have a substantial impact.  

The audio/video packets are also sent via TCP (not UDP), which means any corrupt packets get resent -- increasing the delay for packets.  We would send audio by UDP if we could, but it's a limitation of the Flash runtime environment for browsers that restrict applications to using TCP.   An Adobe Air application could use UDP, but we've not investigated turning BigBlueButton into an Air application.

Poor latency and resending packets are going to cause poor audio.  

Can you confirm if those numbers are from a speedtest.net.  We don't have a recommended network latency yet, but again your results pretty much tell the story.  Any user with decent bandwidth (at least .5 Mbits up and 1 Mbits down) and low network latency and low packet loss should experience good audio.

You could explore setting up dial-in numbers (via SIP trunking) for international users.  This would give them an alternative audio path that bypasses their internet connection.

Regards,... Fred

-- 
BigBlueButton Developer

http://bigbluebutton.org/
http://code.google.com/p/bigbluebutton

BigBlueButton on twitter: @bigbluebutton

To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-users/-/rOMV30iNayIJ.

To post to this group, send email to bigbluebu...@googlegroups.com.

To unsubscribe from this group, send email to bigbluebutton-u...@googlegroups.com.

[neeraj]

Thank you Fred,

We got the network numbers from speedtest.net

Regards,

Neeraj

2012/6/27 Darren Rickets <rick...@googlemail.com>

To unsubscribe from this group, send email to bigbluebutton-users+unsubscribe...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/bigbluebutton-users?hl=en.

[neeraj]

Hello, 

I am posting my experience with poor audio quality of bbb with some networks. Initially, I had hypothesized that poor audio quality is caused by high network latency (~150 ms or more). Recently, I simulated poor network (latency ~ 2000 ms, upload/download speed < 0.6 Mbps) using a bandwidth throttler software (http://www.charlesproxy.com/documentation/proxying/throttling/). To my surprise, the audio quality was quite reasonable even at a latency of 2000 ms - of course, there was a considerable delay in the audio but there were no breaks.

So I believe that breaks in audio might not be caused by high network latency (up to some threshold). We have experienced breaks in sound when interacting with folks based in Asia / Africa using their university internet. In most of the cases, university internet is directed through a proxy - so my guess is that these proxy server are configured to limit the traffic for flash-based contents. 

Any comments ? At this stage, I am not sure how to validate my working hypothesis - suggestions are welcome.

Best Wishes,

Neeraj 

[Fred Dixon]

Hi Neeraj,

Thanks for sharing this!  

Ruling out network latency, the other factors are packet corruption (which causes resend) and network congestion which causes packets to arrive late and be dropped.

Flash limits applications to use TCP/IP,  For real-time applications, such as audio, we really, really want to use UDP.  With UDP, any packet loss is ignored.  However, with TCP/IP, the OS will resent packets until they get through. 

Once the packets hit BigBlueButton, there are sent to FreeSWITCH by BigBlueButton (bbb-apps-voide), and the receiving data back from FreeSWITCH is sent back to the client.  Richard can go into details further, but there are timestamps applied during this process and if the packets can not be sent back in time, they are dropped.

There may be more optimizations on audio that we can do -- we're always looking into ways to improve it.  At the moment, for this release, our focus has been on record and playback.  We're pushing hard to get to a beta of 0.81.

Please continue to share the results of your testing.  

Regards,... Fred

-- 
BigBlueButton Developer

http://bigbluebutton.org/
http://code.google.com/p/bigbluebutton

BigBlueButton on twitter: @bigbluebutton

To view this discussion on the web visit https://groups.google.com/d/msg/bigbluebutton-users/-/nRWv92ED3vUJ.

To post to this group, send email to bigbluebu...@googlegroups.com.

To unsubscribe from this group, send email to bigbluebutton-u...@googlegroups.com.