Are there any prediction for the reason?

"client_id2":"34f3526e-a45b-47eb-aa2b-23ee880ca4f9"

olka@, henrika@: Any idea why AudioSyncReader would report these glitches? Is it likely that it is related to the crash?

Those sync reader glitches are almost always logged on renderer shutdown, when renderer stops delivering audio.

Referring to grunell@ regarding the AudioSyncReader question but to me adding 60 users sounds like a rather extreme load and that is most likely the reason for issues. 

What is the CPU load in this case?

Regarding the crash: please provide a crash ID from chrome://crashes/ if it happens again. I can't find any crashes for the client ID in comment #3.

Just guessing but perhaps the machine is too loaded to create and upload a crash log when the crash happens.

It's as Olga mentions in comment #9 - glitches can be reported at shutdown which is the case here.

Hi all,

Our system has client to server peer connection. When there is more than 50 users in the conference, although all of them except one is on mute, these audio problems occurred. 

We fixed our problem by making mute users' stream recvonly for audio. Then the crashes and robotic voices disappeared.

For the capacity concerns, what is chrome's encode/decode capacity for audio and video? Are there any documentations for the capacity results?

Adding some more resources for question in #13.

AFAIK, there is no distinct limitation valid for all platforms.
The exact limit depends on the hardware and other load (video resolution etc.) on the device.

In general, encoding is more complex than decoding.

selenkartoglu@: could you describe how the conference is setup a bit more? E.g., to confirm, you're using multiple PeerConnections, right? Is there any (simple) way we can reproduce this?

This is a Client to Server WebRTC application therefore, peer connection is just between Client and Media Server. Therefore there is only one peer connection.

An example of this kind of application is https://meet.jit.si/. Testing steps are;
1) 1 user joins with both video and  audio
2) more than 50 users join with audio muted and no video
3) When more people joins to session with audio muted and no video, Audio becomes robotic around 60 user at first and then crash occurs.

We think that maybe chrome tries to decode silence packages also, and this results in too many decoding and client crash occurs. Because when we make muted audio streams recvonly, crashes disappeared. Is this possible? 

Could you please answer the questions in #10. Thanks.

Thanks for the input in comment #18. As Henrik A noted, 60 streams are a lot and depending on processing power, that could surely cause problems such as poor audio.

For the crash, if it's possible for you to repro and get crash data uploaded that is very useful, otherwise it's hard to investigate. Does the crash happen on other platforms?

We reproduced this issue for several times, but unfortunately we cannot get any crash data, we only have debug logs. As I mentioned in the first description on this issue;
"After crash, no crash report is generated by Chrome although "send crash report automatically" is enabled. we check chrome://crashes/."

Are there any other configs that we are missing for the crash report?

We made capacity testing only on Windows, therefore we don't have any information for the other platforms.

To verify that the crash data uploading works as it should, could you open a new tab, go to chrome://crash (crashes the tab) and then to chrome://crashes and verify that it was uploaded?

When I go to chrome://crash, crash report is uploaded to chrome://crashes.

crash id: f05cc72e-83a7-4bc4-b382-87e5264a1cbd

That doesn't seem to be a valid crash ID. It should be found on the line

"Crash ID Chrome (Server ID: xyz)"

i.e. instead of xyz, there's the crash ID. Is this were you got it?

I looked it from chrome://crashes. See the attached screenshot

Deleted: crash.PNG 8.1 KB

	crash.PNG 8.1 KB View Download

Thanks for the screenshot. I wasn't aware there could be another ID (I don't have that). It's the "server ID" I was looking for, in your case 94f1762300000000. I can find it on the server so the crash uploading itself works as it should.

It's unfortunate that the uploading doesn't work in this bug's case. Is there any chance that you have a test that I can use to repro? I realize it's many participants so that large conference has to be setup.

grunell@: Is this bug still valid?

selenkartoglu@: does this still happen? If so, can you please reply to comment #27?

We are experiencing something similar when sending a screen capture stream through several RTCPeerConnection. 

It works fine up to a point, with normal gradual increase in CPU and memory usage, but when a certain number of target connections is reached, CPU suddenly jumps to 100% and Chrome freezes. No crash report.

The threshold number of target connection depends on the CPU but it's never over 8. It happens on Windows and Chrome OS, sometimes on MacOS as well.

Since we do not have any log data on this we need a reliable way of reproducing this ourselves (yes, this always applies but especially in this case).

Do you know how many streams, peerconnections etc are required, maybe a screenshot of chrome://webrtc-internals when it hangs would be useful (zoom out on the page so we get us much as info as possible and leave it open while reproducing and once Chrome hangs, take a screenshot). It might provide us with an idea of what state Chrome/WebRTC is in, its a long-shot but might be worth it.

Do you have a demo page that can reproduce this?

I tried a 100 streams using https://webrtc.github.io/test-pages/src/multiple-peerconnections/ on my beefy workstation and it does become quite slow and unresponsive (uses over 5 GB ram and 600-2500% out of 5800% CPU), updates now and then and crashes after 10 mins or so. Also not all video elements render the mediastream, 81 works and 19 (black video) do not. 

In my case it runs out of memory, crash/04c803afab358ec8. 

If this is the same issue I do not know but maybe it could be useful for debugging the steady memory increase, and yes I realize 100 is unrealistic perhaps but it might still be the same issue.

There's several issues in this bug now.

Original report is about poor (or no) audio when many participants join and then crash. Windows.

Comment #30 reports sudden CPU jump to 100 % and browser freeze. No crash. Seen on Windows, ChromeOS and Mac.

These are maybe related, maybe not.

I think we should have a separate bug for comment #30 as they could well be different issues.

I'm closing this since no feedback.

jansson@ if you want to follow up on comment #31, please file a new bug.