New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 745537 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment

WebRTC unresponsive when tab put in background

Project Member Reported by ossu@chromium.org, Jul 18 2017

Issue description

Bisected it down to this CL: https://codereview.chromium.org/294861300

I do the following:
- Start an appr.tc call between my MacBook Air and my workstation in one tab.
- Open YouTube in another tab (and let the first one keep running) on the MacBook.
- Mute the microphone in apprtc on my workstation.

At this point, the video feed from the MacBook (as shown on my workstation) stops updating and all the Chrome audio on the MacBook becomes terribly choppy. Looking at the logs, they're spewing out errors from different subsystems, like "UDP send of 1130 bytes failed with error 35", "AudioSyncReader::Read timed out, [...]" etc.

Sometimes I need to change back to apprtc and then back away from it for the problems to appear. They all disappear once I again focus the apprtc frame or unmute the mic on my workstation, but reappear once the mic is muted and apprtc is not the currently visible frame.

What is the expected result?
WebRTC continues to function even if not the currently active tab, regardless if the other side is sending audio or not.

What happens instead?
No video is sent from the affected computer. Other tabs' audio playout gets choppy.

I've only seen this happen on a MacBook Air, though I cannot confirm that it's limited to OSX.
 

Comment 1 by l...@chromium.org, Jul 18 2017

Cc: dalecur...@chromium.org
Status: Assigned (was: Untriaged)
Changing to "Assigned" since the bug has an owner.
Cc: maxmorin@chromium.org olka@chromium.org solenberg@chromium.org
lpy@: any work done on this?
Looks like issue 753943.
Also, the link in the report appears dead?
This is the correct link: https://codereview.chromium.org/2948613002.

Comment 8 by olka@chromium.org, Aug 14 2017

We are backgrounding WebTRC because there are no active audio output streams. But there is still an active input stream from the mic. It should be take into account.
Cc: l...@chromium.org
Labels: -OS-Mac OS-All
Owner: maxmorin@chromium.org
Status: Started (was: Assigned)
I'll take care of this before the M62 cut.
Project Member

Comment 10 by bugdroid1@chromium.org, Aug 31 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b65f4bf201bd2220bab6cf83887e071a714afcee

commit b65f4bf201bd2220bab6cf83887e071a714afcee
Author: Max Morin <maxmorin@chromium.org>
Date: Thu Aug 31 11:16:54 2017

Prevent backgrounding when audio input is active.

If one participant is quiet/muted in a call, the other participants renderer process might get backgrounded, since we only count audible output streams for preventing backgrounding. This results in audio input not being properly processed.

Bug:  745537 
Change-Id: I0b58f74b8fba8163056db17c4c66e8947104d5cc
Reviewed-on: https://chromium-review.googlesource.com/633603
Commit-Queue: Max Morin <maxmorin@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498815}
[modify] https://crrev.com/b65f4bf201bd2220bab6cf83887e071a714afcee/content/browser/renderer_host/media/audio_input_renderer_host.cc
[modify] https://crrev.com/b65f4bf201bd2220bab6cf83887e071a714afcee/content/browser/renderer_host/render_process_host_browsertest.cc

Comment 11 by olka@chromium.org, Aug 31 2017

Great job Max!!

Comment 12 by ossu@chromium.org, Aug 31 2017

Yeah, real nice getting it in before the cut!
Can this be closed?
Status: Fixed (was: Started)
Yes.

Sign in to add a comment