New issue
Advanced search Search tips

Issue 832894 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocked on:
issue 834883



Sign in to add a comment

Unusually low RMS for audio capture on eve

Project Member Reported by timkovich@chromium.org, Apr 13 2018

Issue description

Chrome Version: 67.0.3376.0
OS: CrOS 10506.0.0
Board: eve

On eve boards the recorded RMS values for captured audio is exceptionally low. This is causing tests that check whether the system is muted to fail.

Unmuted RMS: 0.010047
Muted RMS: 0.00957

For comparison, most boards have RMS values closer to the values below. (these numbers are from a veyron-minnie board)

Unmuted RMS: 0.909305
Muted RMS: 0.026725

The unmuted RMS on eve is lower than most boards muted RMS.

 
Components: -Internals>Media>Capture
Blockedon: 834883
Hi Tim, is there an autotest doing such measurement ?
The result should be better after we adjust the gain.
It is tracked in issue 834883.
The autotest doing the measurement is called "policy_AudioOutputAllowed". Thank you for linking that relevant ticket!
Cc: ka...@chromium.org
+kalin to take a look
Cc: yuhsuan@chromium.org
Labels: Needs-Feedback
Max, Can you post test results view URL with current status?

Cc: cychiang@chromium.org
Owner: yuhsuan@chromium.org
Lots of boards are failing the test output you posted.

The failure reason of 'RMS difference not large enough between mute and ummute' means the expected 'rms_diff < 0.4' at https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/policy_AudioOutputAllowed/policy_AudioOutputAllowed.py?l=119 is failing.

Have you researched if this RMS value varies per board?

Jimmy and Yu-hsuan, is there any other verification mechanism for this test. The RMS diff seems quite unreliable.

Is https://chromium-review.googlesource.com/1221107 supposed to help here, and to what extent?


Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.

Sign in to add a comment