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

Issue 805377 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Switching input sample rate breaks audio completely

Project Member Reported by grunell@chromium.org, Jan 24 2018

Issue description

Chrome Version: Both stable and canary as of yesterday
OS: Windows 7

What steps will reproduce the problem?
(1) Use a Focusrite Scarlett 6i6 as default devices, in and out. 44.1 kHz sample rate. No camera connected. Do a call using appr.tc in loopback mode and audio only (I think). Verify that it works fine.
(2) In system settings for the device, switch input device sample rate to 96 kHz, and back to 44.1 kHz.
(3) Do a new call in appr.tc.
(4) Listen to audio playout using Youtube or Google Music.

What is the expected result?
Audio works.

What happens instead?
No audio heard in either appr.tc, Youtube or Google Music. After Google Music spinned for a minute or so, audio playout started.

Will collect more information.
 
Description: Show this description
I tested this more now. All output audio seems to be broken; Firefox, Windows Media Player, and Windows notification sound. It's enough to switch to any other sample rate on the input device to get into the bad state.

Switching output device and back or switching output device sample rate and back remedies the bad state.

Thus, it looks like a driver issue.

What is interesting is if Chrome detects this and logs information about the problem. I'll revisit this shortly.

Comment 3 by tommi@chromium.org, Jan 25 2018

do we know if this is a common use case? I'm not a typical user, but fwiw if I'm playing around with the sample rate while audio is playing, I'd actually expect things to fail.
This happens when switching between playing audio. I did some more investigation and seems to happen mostly when sample rates for in and out differ, but can happen when they are changed to the same.

There are different types of failures logged, and in histograms I see several failures for subsequent stream opens, but not for first stream open. Maybe we're not handling stream re-usage properly? There's also fallback to high latency stream sometimes. Those are for output. For input, I saw "device in use" failure twice, and just no audio ("stream ended", which I think is due to no callbacks).

Next, I'll wrap up the investigation and summarize the findings along with any suggested actions.
Cc: ossu@chromium.org

Sign in to add a comment