LCCS Audio/Video Limitations

[__DEBUG__]

The goal of our project is to have an Audio/Video chat of 10-20 users (most of the users in the chat stream low-quality video and have audio muted, while two groups with up to 5 users all streaming full audio and video). We decided to use the latest LCCS with Flash 10.1 as a platform for our solution, because this combination seemed that it will provide us with a transparent way to achieve p2p communication with a fail-over mechanism.

But in our attempts to reach 10 users with full Audio/Video chat we run into some issues that look like we've hit the current technology limitations. We tried all kinds of options, but whatever we've tried our current achievement is just 5 users in an AV chat. Trying to join another user to the conversation results either in browser hangup or crash, we even managed to get our local network wi-fi router to get sunk when we reached 6 users.

I'll give you a brief explanation of the 3 main options we've tried and I'll also supply you with a link from where you can download an isolated example we've used in our tests, so everyone can check it. I'll be happy to get any feedback on whether I'm using the LCCS framework components in the correct and intended way.

1. Using the default settings of LCCS, no changes to the StreamManager properties.

On a single Mac computer the limit is 3-5. On Macs it tends to crash with fewer users in comparison with Windows. We tested it also on the local network with different machines - again Safari on Mac is crashing when we try to join a 6th user to a chat with 5.

Almost identical results we're getting with the other options.

2. Increasing the number of streamManager.maxP2PStreamPublish to 20.

3. Using streamManager.maxP2PStreamPublish=20 and session.streamManager.streamMulticast=true

From the link below you can download the Flash Builder project. You can import it and start testing.

DOWNLOAD THE TEST APPLICATION

Some notes on the Test Application:

The test application consists of two mxml application - LccsLimitationsOwner and LccsLimitationsPublisher. You should modify LccsLimitationsOwner with your correct username and email. And you should run it before the publishers applications, because the owner sets the StreamManager properties. Make sure you edut the correct room URLs in both applications.Also make sure that you check Auto Promote Users from the Room Console of your room. The users should be at least publishers.

When you start the publisher app, you will be prompted for a username - here you can put whatever you want, later you'll refer to these usernames when you want to connect to someone with the test app.

The testing is basicaly connecting several users and then each of them adds the rest by typing a username and clicking the GO-button.

Before running the owner's application you can set in the mxml what kind og configuration you want to test, by changing the value of the lccsConfiguration-property to one of the following values:

[Bindable] public static var DEFAULT_CONFIGURATION:String = "default";
[Bindable] public static var HUB_SPOKE_CONFIGURATION:String = "hub-spoke";
[Bindable] public static var MULTICAST_CONFIGURATION:String = "multicast";

Let me know if you have any questions on the test application!

[aj-runtimelogic]

Hi Hironmay,

Happy New Year.

I just wanted to follow-up with you and see if you have heard back from the Flash Player team in regard to the multicasting latency issue?  I'd like to continue to work with you to solve this issue which may be preventing anyone from using multicast audio streams.

In the meantime, I've turned off the use of multicasting with my application, and initial tests show superior performance with no noticeable latency.  We will go into production this way for now, but would ultimately like to transition back to using multicasting when it is ready.

I look forward to working with you on this further.  Thanks.

[Former Community Member]

Hi Antonia,

No, I haven't heard. It was kind of a holiday period and I was out too.

But I will try to follow it up on coming days. If possible, you can

invite me to one of your tests where I can see how it behaves and then

look at my side for corrective measures.

Hope this helps

Thanks

Hironmay Basu

[Raff_]

I went to talk to the Flash engineer that developed p2p multicast and he said that the initial latency is actually a "feature" (I guess you'd call it a limitation).

When multicast starts the peers work in "pull" mode until there is enough data and information about the mesh to switch to "push" mode and this causes the initial latency.

This post explains some of the details and the 2009 MAX presentation mentioned at the end (Watch the session about P2P from MAX 2009 explaining multicast by Matthew Kaufman - Seek to 36:28)

Anyway, according to them there isn't much that can be done to reduce the initial latency but if you are experience continous latency, let's figure out how we can reproduce the problem and we'll do more investigation.

[Former Community Member]

If I am not wrong, it was only the initial latency mentioned by user and there was no continuous latency. But as I said Antonio, if you are running any test and want me to join, please let me know the time and I will chip in.

Thanks

Hironmay Basu

[aj-runtimelogic]

Actually, in the most recent testing I have done, we always have continuous latency if muticasting is enabled.  We never get to a point where there is less than a 3 second round-trip delay (measured from when user speaks to when they hear their echo, when using a speaker / mic setup on the receiving end).

Hironmay: I'd love to have you join us for a test.  I have some other work I'm busy with for the rest of this week, but next week would be a good time to set up a test.  Please PM me with your email address in order to set up a time and to send you a test link for our application.  Thanks!

Raff: I'll check out the links you mention and make sure I'm fully up to speed on these details.  Thanks.  It does seem odd that it would stay in "push" mode for 10-20 seconds though, even with only 2 nodes in the mesh.  It also seems like something has changed over the last couple months with how this works because as mentioned above we never get to a usable latency even after the streams have been connected for many minutes, where it used to improve after 10-20 seconds.