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

Issue 739760 link

Starred by 4 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

CRAS: busy looping when two input streams of huge difference

Project Member Reported by hychao@chromium.org, Jul 6 2017

Issue description

This is observed when investigating issue https://buganizer.corp.google.com/issues/63359224

What steps will reproduce the problem?
(1) Use modified cras_test_client to start two input streams, (A) 16K, buffer size 256, cb threshold 128. (bB 48K, buffer size 4800, cb threshold 4800
(2) start stream (B) and then start stream (A)
(3) Use top to check CPU usage of CRAS

What is the expected result?
CRAS stay in normal CPU usage range.

What happens instead?
CRAS busy looping.


cychiang@ and I found the cause is in the change adjusting logic to determine sleep time for input streams, which landed In M59 or earlier.
A fix to this is ready but needs some work to verify that doesn't break anything else. cychiang@ suspect this is causing some system hang issues so we might need the fix merge back to 59.

 

Comment 1 by ka...@chromium.org, Jul 6 2017

Cc: dchan@chromium.org gkihumba@chromium.org josa...@chromium.org ka...@chromium.org
Labels: M-59
Update Hsinyu's initial patch at
https://chromium-review.googlesource.com/#/c/563283/

The CL is ready for review, but unittest test is not added yet.

Project Member

Comment 3 by bugdroid1@chromium.org, Jul 14 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/adhd/+/e7680d389f098db3712432442c238babc60ce919

commit e7680d389f098db3712432442c238babc60ce919
Author: Cheng-Yi Chiang <cychiang@chromium.org>
Date: Fri Jul 14 02:46:12 2017

CRAS: audio_thread - Fix callback time for the second input stream

The second input stream should set its own next callback time.
This is different from output stream where we do not want to increase
the device buffer level so we align the second stream callback time with
the first stream.

BUG=chromium:739760
TEST=Use block size 4800 for stream 1 and block size 240 for stream 2.
Check that audio thread wake up for stream 2 in about 5 ms after it is
attached, instead of 100 ms.

Change-Id: Ia48f955316936f569e418839f139639ce34b019c
Reviewed-on: https://chromium-review.googlesource.com/564905
Commit-Ready: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-by: Chinyue Chen <chinyue@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/e7680d389f098db3712432442c238babc60ce919/cras/src/server/audio_thread.c

Project Member

Comment 4 by bugdroid1@chromium.org, Jul 14 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/adhd/+/3d024f63e64b4f50d723994985afd5bc42384824

commit 3d024f63e64b4f50d723994985afd5bc42384824
Author: Hsin-Yu Chao <hychao@chromium.org>
Date: Fri Jul 14 08:44:43 2017

CRAS: dev_stream - Fix busy loop when capturing to two streams

When there are two capture streams, setting wake up time for input
stream needs to take capture limit into consideration.

It may happen that although there are enough samples in the device for
stream 1 to meet callback level, the capture limit imposed by another
stream 2 disallow stream 1 to read samples from device to shared memory
of stream 1.
In this case, setting wake up time incorrectly to 0 for stream 1 causes
busy loop of CRAS audio thread.

Also, remove get_input_needed_frames and use dev_stream_capture_avail
instead.

Add an argument is_cap_limit_stream to dev_stream_wake_time to handle
the corner case where client happens to read samples in shm after audio
thread calculates capture limit.

BUG=chromium:739760
TEST=cras_test_client --capture_f /tmp/1 --block_size 4800
     cras_test_client --capture_f /tmp/2 --block_size 256
     top
     Check CRAS CPU usage is not above 90%.

Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: I51550c47b99e631a0a61136ca4fce7d10833f9ce
Reviewed-on: https://chromium-review.googlesource.com/563283

[modify] https://crrev.com/3d024f63e64b4f50d723994985afd5bc42384824/cras/src/server/dev_stream.c
[modify] https://crrev.com/3d024f63e64b4f50d723994985afd5bc42384824/cras/src/server/dev_stream.h
[modify] https://crrev.com/3d024f63e64b4f50d723994985afd5bc42384824/cras/src/server/audio_thread.c
[modify] https://crrev.com/3d024f63e64b4f50d723994985afd5bc42384824/cras/src/tests/audio_thread_unittest.cc
[modify] https://crrev.com/3d024f63e64b4f50d723994985afd5bc42384824/cras/src/tests/dev_stream_unittest.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Jul 14 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/adhd/+/500fa0c593e5ae336c495d4ee32071b78b29ca7d

commit 500fa0c593e5ae336c495d4ee32071b78b29ca7d
Author: Cheng-Yi Chiang <cychiang@chromium.org>
Date: Fri Jul 14 08:44:43 2017

CRAS: shm - Fix cras_shm_get_writeable_frames

cras_shm_get_writeable_frames should handle the case where write_limit
is less than the amount written in the buffer.
In this case, there is no need to write more frames into the buffer.

BUG=chromium:739760
TEST=unittest

Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: Ieffbf9fb0355f1e664ce5d0a4f91415c42a4ef3e
Reviewed-on: https://chromium-review.googlesource.com/569939

[modify] https://crrev.com/500fa0c593e5ae336c495d4ee32071b78b29ca7d/cras/src/tests/shm_unittest.cc
[modify] https://crrev.com/500fa0c593e5ae336c495d4ee32071b78b29ca7d/cras/src/common/cras_shm.h

Sign in to add a comment