I can reproduce this issue in our local environment with Blaze on ver. 57.0.2987.146 / 9202.64.0 and Cave ver. 58

From what I can see in the power manager logs, it did not initialize sleep mode while Chromevox is enabled.
It seems that Chromevox generates audio activity even if nothing is triggering screen reader.

- Chromvox disabled:

[0504/184245:INFO:state_controller.cc(757)] Updated settings: dim=0s screen_off=0s lock=0s idle_warn=0s idle=1m (suspend) lid_closed=suspend use_audio=1 use_video=1
[0504/184312:INFO:activity_logger.cc(20)] User activity stopped; last reported 20 sec ago
[0504/184352:INFO:state_controller.cc(882)] Ready to perform idle action (suspend) after 1m
[0504/184352:INFO:suspender.cc(397)] Starting request 50266113
.............
[0504/184352:INFO:suspend_delay_controller.cc(224)] Notifying observers that suspend is ready
[0504/184352:INFO:suspender.cc(466)] Starting suspend
.............
[0504/184356:INFO:suspender.cc(424)] Finishing request 50266113 successfully

- Chromevox enabled:

[0504/184411:INFO:state_controller.cc(757)] Updated settings: dim=0s screen_off=0s lock=0s idle_warn=0s idle=1m (suspend) lid_closed=suspend use_audio=1 use_video=1
[0504/184430:INFO:activity_logger.cc(20)] User activity stopped; last reported 20 sec ago
[0504/184431:INFO:daemon.cc(772)] On AC (Mains) with battery at 10% (displayed as 7%), 0.325/3.195Ah at 1.559A, 12m5s until empty (7m56s until shutdown)
.............
[0504/184702:INFO:daemon.cc(772)] On AC (Mains) with battery at 12% (displayed as 9%), 0.390/3.195Ah at 1.559A, 14m27s until empty (10m18s until shutdown)
[0504/184702:INFO:activity_logger.cc(20)] Audio activity ongoing
.............
[0504/185002:INFO:activity_logger.cc(20)] Audio activity ongoing
.............

full log: https://drive.google.com/a/google.com/file/d/0By9xEkAUmm_cZjNFVDJaZDlPOFk/view?usp=sharing


@bhthompson - Could you please help to triage this bug?   
 

+folks whom are assigned to ChromeVox bugs and our powerd wizard.

I think this might be expected behavior?

The log there seems reasonable, powerd will not suspend if it determines audio is active. 

If ChromeVox being active implies audio is always active this is WAI.

If ChromeVox is expected to not have audio always active, than this may be a bug in ChromeVox?

My guess from #1 would be that ChromeVox is holding one or more audio streams open even when it's not playing audio. I don't know if this is intentional or not (maybe there's latency associated with opening streams on-demand), but blocking suspend is undesirable.

Note also that this likely happens independently of whether a shorter idle delay is set via policy or not.

chinyue, maybe we should have chromevox open a special stream type (as soon as we have stream types enabled).  Then we could modify the power manager/cras interface to only prevent suspend for non-system like streams.

ChromeVox should probably close the stream though, it's not free w.r.t. power or cpu cycles

We do have stream types enabled now so we can define an ACCESSIBILITY type for this use case.

Hi all,

Are there any updates on this issue. Is there something else we can help with through the Tech case?

Thanks!

It sounds like the next steps are:

a) Someone on the CRAS team adding a new a11y stream type, and me updating powerd to disregard it.
b) Someone on the ChromeVox team independently fixing it to not hold streams open unnecessarily.

When ChromeVox is enabled, there are two sources of audio:

* From the ChromeVox extension, via the web audio api:
https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/chromevox/cvox2/background/earcon_engine.js

* From the TTS extension, via NaCl / PPAPI

Do we know which one is causing it? Maybe try killing just one or the other?

If it's TTS, then this is affecting more than just ChromeVox. There's already code to shut down the audio stream after a timeout, it's not clear why that wouldn't be working.

If it's ChromeVox's use of the web audio API, any pointers on how we're supposed to be shutting that stream down? No audio should be playing when we're not directly triggering a sound. The filters are expensive to load so it wouldn't make sense to disconnect all of the sources.

Uploaded https://chromium-review.googlesource.com/#/c/540982/ for review to add ACCESSIBILITY stream type.

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

commit a2dbfc3e3a058fa20712ccae6e7dc7738e2669b1
Author: Chinyue Chen <chinyue@google.com>
Date: Tue Jun 20 20:38:10 2017

CRAS: Add ACCESSIBILITY stream type.

Also add a compile-time check to prevent mismatch of stream type enum
and use case verbs.

BUG= chromium:718051 
TEST=make check

Change-Id: I808e926b73512e230632158565c298cbafa4d9a5
Reviewed-on: https://chromium-review.googlesource.com/540982
Commit-Ready: Chinyue Chen <chinyue@chromium.org>
Tested-by: Chinyue Chen <chinyue@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/a2dbfc3e3a058fa20712ccae6e7dc7738e2669b1/cras/src/server/cras_alsa_ucm.c
[modify] https://crrev.com/a2dbfc3e3a058fa20712ccae6e7dc7738e2669b1/cras/src/common/cras_types.h

To be clear, we *do* want sleep to be prevented if ChromeVox is speaking. We should make the fix in ChromeVox or text to speech as indicated by Dominic once we figure out where we're hanging onto an audio stream.

Per #9, re-assign to derat@ for next step. Thanks!

Sorry, but #13 indicates that we actually don't want to ignore ChromeVox streams for power management.

Can you help answer Dominic's questions from #10?

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.