Our installation is managed by Stephen Dame, who has set up a dedicated server for it. I have copied him on this email. He can provide you with details of the server configuration.
You are correct, we were running 0.8-beta. We were set at maxParticipants = -1 (unlimited) and the server crashed at 63 attendees. Specifically, we crashed as I attempted to mute participants.
Specific issues encountered in crowd management were:
- as attendees arrived, they had to be told to click on the headphones in order to hear anything - when they clicked on the headphone, however, they defaulted to 'unmute', even when the audience default was set to mute - there should be an option to set new arrivals to 'mute' or 'unmute' by default - and all new arrivals should default to 'earphones on'
- as more unmuted participants arrived, the sound degraded, even if they weren't saying anything - the presence of a silent unmuted participant definitely degraded the audio of speaking participants
- the arrival and departure tones when people clicked their headphones on and off became a cacophony - I understand there's a server setting that turns this off - this should be available as a control in the environment, or off by default
Except for the audio issues, and the crashing, the installation worked fine. If I were a developer I would really be focusing on audio, pretty much to the exclusion of all else. The audio really needs to be improved, even with small numbers of participants. I think Flash compresses the input too much - you get a lot of squeaking and squonking, much like audio compressed to 32bps. And mixing of separate audio streams is very poor. This sort of problem is not unique to BBB - I find the same issues with Adope Connect, which is why I blame Flash.
I've authored a full Perl interface to the API - it's pretty integrated into gRSShopper, but I'll write a stand-alone version people can use (there's a Perl BBB module, but the module is not stand-alone (it also has to be integrated into some application) and the documentation is awful). I'll post it on git and sent you the links when it's done.
Update - Blogger refuses to accept this as a comment, even from me, so I'm posting this comment here:
Hi Stephen,
Thanks again for sharing your experiences with BigBlueButton. I posted the following reply to your blog (it's probably awaiting moderation)
Regards,... Fred
BigBlueButton Developer
(Note - there's no comment moderation on new posts - but Google has some weird anti-spam feature totally outside my control -- SD)
-----------------
As one of the developers of BigBlueButton, thank you for posting your
experiences! My responses are inline.
> We were set at maxParticipants = -1 (unlimited) and the server crashed at 63 attendees.
> Specifically, we crashed as I attempted to mute participants.
Let me say outright that we (the BigBlueButton developers) strongly recommend you use BigBlueButton for sessions of 25 users or less. You can provision a server for higher capacity, but as we have no control over what users install BigBlueButton, we tend to give a conservative number.
For more reasons why, see
http://code.google.com/p/bigbluebutton/wiki/FAQ#How_many_simultaneous_users_can_a_BigBlueButton_server_support?
The number of 25 is arbitrary. With proper provisioning a server can support more; however, every server is different. I would recommend you work with Stephen to do some stress testing on your server, find out the number of users at which the audio starts to degrade (it will be when the CPU hits about 80%) and then cap the server at that number.
Specifically, in your landing page, poll the number of users on the server and then, when a user tries to join, the # of concurrent users
exceeds the maximum, don’t let them join. Instead, print out a message saying that no more users can join. Living within the limits of the server will ensure those that are in the session have a good experience.
If the maximum number of users for a server is too low, then we recommend talking with Stephen and getting a more powerful server. The key bottleneck in the server will be the CPU (again, see the above link for more information as to why this is the bottleneck).
> Specific issues encountered in crowd management were:
- as attendees arrived, they had to be told to click on the headphones in
> order to hear anything - when they clicked on the headphone, however,
> they defaulted to 'unmute', even when the audience default was set to mute
If you as a moderator have ‘mute all’ set, then newcomers should come in as unmated. If that didn’t happen, it’s a bug and we want to
reproduce and fix. You can first try using
http://demo.bigbluebutton.org/
to see if the bug is there. That’s a dedicated server we make available to the community to test the latest version of BigBlueButton. If you've found a bug, and you can take a moment to
report it
http://code.google.com/p/bigbluebutton/wiki/IssuesInstructions?tm=3
we are *very* appreicative as we can work on fixing it.
> - there should be an option to set new arrivals to 'mute' or 'unmute' by
> default - and all new arrivals should default to 'earphones on'
When you click ‘mute all’, it will (a) mute all current participants and (b) automatically mute new participants as well. Again, if it's
not, that's a bug .
> - as more unmuted participants arrived, the sound degraded, even if
> they weren't saying anything - the presence of a silent unmuted
> participant definitely degraded the audio of speaking participants
This is a function of BigBlueButton’s design. We optimized the experience for small to medium (25 or less) groups where *everyone* can be talking at one time.
In contrast, compare this to a conference server designed for webinar mode, there is no concept of everyone talking, rather, there is only one person talking and everyone else listens.
You can see there is a very conscious design choice behind BigBlueButton. The two options: (a) high quality collaboration for small groups, or (b) scalability to large groups. We choose (a) because the market is much larger. In other words, our focus is to keep working on BigBlueButton until it does (a) really, really well (i.e. please a good chunk of the distance education market) before moving to (b).
> - the arrival and departure tones when people clicked their headphones on and off became a cacophony
These can be turned off on the server. Stephen can do this for you.
> - I understand there's a server setting that turns this off - this should be available as a control in the environment, or off by default
Agreed.
> If I were a developer I would really be focusing on audio, pretty much to the exclusion of all else.
It’s been over a year and a half development on the audio portion of BigBlueButton, and during that time we learned a lot about how to do
VoIP properly.
So much is dependent on the server. If you try the audio a http://demo.bigbluebutton.org/, you should be able to experience good quality VoIP. Again, its dedicated server (dedicated hardware) and you should have a good experience with small goups.
> I'll post it on git and sent you the links when it's done.
Much appreciated!
Update - Blogger refuses to accept this as a comment, even from me, so I'm posting this comment here:
Hi Stephen,
Thanks again for sharing your experiences with BigBlueButton. I posted the following reply to your blog (it's probably awaiting moderation)
Regards,... Fred
BigBlueButton Developer
(Note - there's no comment moderation on new posts - but Google has some weird anti-spam feature totally outside my control -- SD)
-----------------
As one of the developers of BigBlueButton, thank you for posting your
experiences! My responses are inline.
> We were set at maxParticipants = -1 (unlimited) and the server crashed at 63 attendees.
> Specifically, we crashed as I attempted to mute participants.
Let me say outright that we (the BigBlueButton developers) strongly recommend you use BigBlueButton for sessions of 25 users or less. You can provision a server for higher capacity, but as we have no control over what users install BigBlueButton, we tend to give a conservative number.
For more reasons why, see
http://code.google.com/p/bigbluebutton/wiki/FAQ#How_many_simultaneous_users_can_a_BigBlueButton_server_support?
The number of 25 is arbitrary. With proper provisioning a server can support more; however, every server is different. I would recommend you work with Stephen to do some stress testing on your server, find out the number of users at which the audio starts to degrade (it will be when the CPU hits about 80%) and then cap the server at that number.
Specifically, in your landing page, poll the number of users on the server and then, when a user tries to join, the # of concurrent users
exceeds the maximum, don’t let them join. Instead, print out a message saying that no more users can join. Living within the limits of the server will ensure those that are in the session have a good experience.
If the maximum number of users for a server is too low, then we recommend talking with Stephen and getting a more powerful server. The key bottleneck in the server will be the CPU (again, see the above link for more information as to why this is the bottleneck).
> Specific issues encountered in crowd management were:
- as attendees arrived, they had to be told to click on the headphones in
> order to hear anything - when they clicked on the headphone, however,
> they defaulted to 'unmute', even when the audience default was set to mute
If you as a moderator have ‘mute all’ set, then newcomers should come in as unmated. If that didn’t happen, it’s a bug and we want to
reproduce and fix. You can first try using
http://demo.bigbluebutton.org/
to see if the bug is there. That’s a dedicated server we make available to the community to test the latest version of BigBlueButton. If you've found a bug, and you can take a moment to
report it
http://code.google.com/p/bigbluebutton/wiki/IssuesInstructions?tm=3
we are *very* appreicative as we can work on fixing it.
> - there should be an option to set new arrivals to 'mute' or 'unmute' by
> default - and all new arrivals should default to 'earphones on'
When you click ‘mute all’, it will (a) mute all current participants and (b) automatically mute new participants as well. Again, if it's
not, that's a bug .
> - as more unmuted participants arrived, the sound degraded, even if
> they weren't saying anything - the presence of a silent unmuted
> participant definitely degraded the audio of speaking participants
This is a function of BigBlueButton’s design. We optimized the experience for small to medium (25 or less) groups where *everyone* can be talking at one time.
In contrast, compare this to a conference server designed for webinar mode, there is no concept of everyone talking, rather, there is only one person talking and everyone else listens.
You can see there is a very conscious design choice behind BigBlueButton. The two options: (a) high quality collaboration for small groups, or (b) scalability to large groups. We choose (a) because the market is much larger. In other words, our focus is to keep working on BigBlueButton until it does (a) really, really well (i.e. please a good chunk of the distance education market) before moving to (b).
> - the arrival and departure tones when people clicked their headphones on and off became a cacophony
These can be turned off on the server. Stephen can do this for you.
> - I understand there's a server setting that turns this off - this should be available as a control in the environment, or off by default
Agreed.
> If I were a developer I would really be focusing on audio, pretty much to the exclusion of all else.
It’s been over a year and a half development on the audio portion of BigBlueButton, and during that time we learned a lot about how to do
VoIP properly.
So much is dependent on the server. If you try the audio a http://demo.bigbluebutton.org/, you should be able to experience good quality VoIP. Again, its dedicated server (dedicated hardware) and you should have a good experience with small goups.
> I'll post it on git and sent you the links when it's done.
Much appreciated!
0 comments:
Post a Comment