Chrome updates (even minor ones) often break WebRTC in strange ways

[Jeremy Noring]

I'm curious if other people have experienced this, but we're finding that when Chrome is in an intermediate state (i.e. "You're nearly up to date, relaunch Chrome!") WebRTC can be broken in very strange ways.  For example, this morning we did a 4-way call where one person simply could hear no audio.  He could see everyone, and we could see/hear him.  His speakers were working correctly.  He was running Version 43.0.2357.124 (64-bit); after updating to Version 43.0.2357.130 (64-bit) everything worked just fine.

This happens with relatively high frequency, and even with minor updates.  Does anyone else experience this?  Are there any defects around this?

[Christoffer Jansson]

Hi Jeremy,

I've heard of similar things before, but I do not think the intermediate update state has been to blame, it's usually a red herring. This can be caused by several other factors but not knowing any details about the OS or what state the audio backend is etc makes it hard to guess.

But to be sure could you file an issue here for that and post the bug number here? Please include as many details as possible and also if you encounter this again, please try out https://test.webrtc.org, after all the tests have run, please click on the bug report icon, select upload and post the link in the bug.

Thanks a lot!

/Chris

On Thu, Jun 25, 2015 at 5:18 PM Jeremy Noring <jno...@hirevue.com> wrote:

I'm curious if other people have experienced this, but we're finding that when Chrome is in an intermediate state (i.e. "You're nearly up to date, relaunch Chrome!") WebRTC can be broken in very strange ways.  For example, this morning we did a 4-way call where one person simply could hear no audio.  He could see everyone, and we could see/hear him.  His speakers were working correctly.  He was running Version 43.0.2357.124 (64-bit); after updating to Version 43.0.2357.130 (64-bit) everything worked just fine.

This happens with relatively high frequency, and even with minor updates.  Does anyone else experience this?  Are there any defects around this?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/50bbd814-b52b-4a7d-8853-4efddea0a933%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Silvia Pfeiffer]

I believe I've seen that effect, too. Wouldn't be able to confirm now, because I've not systematically tested it. However, I run my chrome for long times without restarting and when I get into a call and hear no audio, I restart my browser and am usually OK. Mud you, it could also be an operating system related issue that happens after suspending and restarting the computer, which is why I'm only agreeing tentatively.

OTOH were are currently mortally afraid of chrome updates because for the last few weeks we've been setting enormous echo cancellation issues. We've managed to set flags so it only hits us after about 1hr, but whatever new echo cancellation experiments are being done, have currently only made it worse. We're hoping the new experiments will conclude soon and a better chrome will emerge. Again: I have no systematic analysis yet, so it's hard to register a bug... This if therefore just indicative venting. I'm still trying to make time...

Best Regards,
Silvia.

On 26 Jun 2015 1:18 am, "Jeremy Noring" <jno...@hirevue.com> wrote:

I'm curious if other people have experienced this, but we're finding that when Chrome is in an intermediate state (i.e. "You're nearly up to date, relaunch Chrome!") WebRTC can be broken in very strange ways.  For example, this morning we did a 4-way call where one person simply could hear no audio.  He could see everyone, and we could see/hear him.  His speakers were working correctly.  He was running Version 43.0.2357.124 (64-bit); after updating to Version 43.0.2357.130 (64-bit) everything worked just fine.

This happens with relatively high frequency, and even with minor updates.  Does anyone else experience this?  Are there any defects around this?

--

[Jeremy Noring]

On Thursday, June 25, 2015 at 10:01:34 AM UTC-6, Christoffer Jansson wrote:

Hi Jeremy,

I've heard of similar things before, but I do not think the intermediate update state has been to blame, it's usually a red herring. This can be caused by several other factors but not knowing any details about the OS or what state the audio backend is etc makes it hard to guess.

But to be sure could you file an issue here for that and post the bug number here? Please include as many details as possible and also if you encounter this again, please try out https://test.webrtc.org, after all the tests have run, please click on the bug report icon, select upload and post the link in the bug.

That does make sense--I had assumed that updates were the root cause, but that may be unrelated and it may just be the act of restarting the browser.  Either scenario seems possible to me.  When we hit it again, I'll go the test.webrtc.org route and file a bug.

The one other issue that we encounter frequently (but have no clear reproduction steps for) is audio failure in OSX.  In the sound preferences pane the mic meter works fine, but chrome won't pick up any mic volume.  Also, all of the speaker audio will be completely broken.  I think this is a separate problem, but I think it may be related.  We definitely hit this with some frequency that there is some bug in Chrome related to audio input/output on OSX, but I still have no reproduction steps.

[Robert Hunt]

The one other issue that we encounter frequently (but have no clear reproduction steps for) is audio failure in OSX.  In the sound preferences pane the mic meter works fine, but chrome won't pick up any mic volume.  Also, all of the speaker audio will be completely broken.  I think this is a separate problem, but I think it may be related.  We definitely hit this with some frequency that there is some bug in Chrome related to audio input/output on OSX, but I still have no reproduction steps.

We also experience this and haven't been able to repro. Anecdotally, a Mac that has gone to sleep with Chrome open and then is resumed seems more prone to this. In a couple of the instances that this has occurred we have tried Hangouts as well and the problem also existed there. That points to it being something in Chrome vs our code.  

I filed a bug here: https://code.google.com/p/webrtc/issues/detail?id=4799

Robert

[Andreas]

Any updates or workarounds? We also experience this and haven't been able to repro.