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

Issue 903213 link

Starred by 1 user
Status: Fixed
Owner:
maxmorin@chromium.org
Closed: Nov 13
Cc:
dgreid@chromium.org
peah@chromium.org
█ olka@chromium.org
solenberg@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

AudioInputStream timestamps incorrect on Chrome OS.

Project Member Reported by maxmorin@chromium.org, Nov 8 
There is a mixup of clocks in cras_input.cc. We get a timestamp from CLOCK_MONOTONIC_RAW, but we treat it as being from CLOCK_MONOTONIC when computing the delay. The results are very wrong. This impacts AEC3 negatively.
Project Member

Comment 1 by bugdroid1@chromium.org, Nov 8 

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

commit 7b7f61412e72e4c4287e577ad31194bda72cb2a3
Author: Max Morin <maxmorin@chromium.org>
Date: Thu Nov 08 15:26:04 2018

Fix Chrome OS audio capture time stamps.

The current code assumes that the time stamp given by CRAS is from the
clock that base::TimeTicks uses. It is not, leading to incorrect time
stamps.

I verified that, in a VM, the new code in apprtc reports ~the same latency
as running "cras_test_client --capture_file /dev/null --show_latency".

Bug:  903213 
Change-Id: Ib998414d4c4c8a3df7c7ef62f8386960f7439156
Reviewed-on: https://chromium-review.googlesource.com/c/1326142
Reviewed-by: Olga Sharonova <olka@chromium.org>
Commit-Queue: Max Morin <maxmorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606470}
[modify] https://crrev.com/7b7f61412e72e4c4287e577ad31194bda72cb2a3/media/audio/cras/cras_input.cc

Comment 2 by dalecur...@chromium.org, Nov 8

Cc: dgreid@chromium.org
Nice fix, I was always wondering when that assumption would bite us :)

Comment 3 by maxmorin@chromium.org, Nov 13

Status: Fixed (was: Started)
►

Sign in to add a comment