feedback report : https://listnr.corp.google.com/report/85832022429 

 Issue 753596  is possibly related.

I haven't heard of this happening before and don't have a strong opinion about whether muted audio should be ignored or not for the purposes of deferring suspend.

So it looks like the problem was fixed or at least heavily mitigated.

Then the question is whether mine was an unusual situation (and how often it happens) or whether I am plain wrong and something was actually playing audibly.

I think that the frequency may be a bit too hard to figure out (system shut down because battery was low AND sound was playing AND user was idle).  Not a low hanging fruit :/

Yes IIRC, since the fix in the above mentioned bug, muted / zero volume audio counts as 'empty', and will not keep the system awake (note that very low volume might not be audible, but would still keep the system awake)

OK, let's assume user error.  I'll try to repro it an reopen if applicable.  Thanks.

FWIW, this is what's keeping device awake I believe,
 
[1207/103144:INFO:activity_logger.cc(20)] Active wake locks: system (Prefs, WebRTC has active PeerConnections)


I was expecting to see something related to audio here though ... specifically, 'Playing audio'.

So IIUC while audio did start it subsequently stopped but the persistence of the WebRTC connection held the wake lock and therefore inhibited suspend,

[1207/001516:INFO:activity_logger.cc(20)] Audio activity started
[1207/001516:INFO:daemon.cc(1095)] Received updated external policy: ac_dim=7m ac_screen_off=7m30s ac_lock=7m40s ac_idle_warn=0s ac_idle=8m30s battery_dim=5m battery_screen_off=5m30s battery_lock=5m40s battery_idle_warn=0s battery_idle=6m30s ac_idle=suspend battery_idle=suspend lid_closed=suspend system_wake_lock=1 use_audio=1 use_video=1 presentation_factor=1.0 user_activity_factor=1.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs, WebRTC has active PeerConnections, Playing audio)
[1207/001518:INFO:daemon.cc(1095)] Received updated external policy: ac_dim=7m ac_screen_off=7m30s ac_lock=7m40s ac_idle_warn=0s ac_idle=8m30s battery_dim=5m battery_screen_off=5m30s battery_lock=5m40s battery_idle_warn=0s battery_idle=6m30s ac_idle=suspend battery_idle=suspend lid_closed=suspend system_wake_lock=1 use_audio=1 use_video=1 presentation_factor=1.0 user_activity_factor=1.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs, WebRTC has active PeerConnections)
[1207/001526:INFO:activity_logger.cc(20)] Audio activity stopped

Is it expected that a WebRTC connection alone should/could keep device awake for an extended (10hr) time?

Yes, WebRTC peer connections are expected to acquire a wake lock. If there wasn't an open Hangouts session or something similar, I'd suspect that this is a bug in the WebRTC code.

You can see some older bugs around connections not releasing their locks as expected at https://bugs.chromium.org/p/chromium/issues/list?can=1&q=%22WebRTC+has+active+PeerConnections%22+os%3Dchrome&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids.

Some more reports that look similar

https://listnr.corp.google.com/report/85831161044
https://listnr.corp.google.com/report/85821742363

Going to re-open.

I think it's unlikely that anyone is going to look at this unless there's an owner on the WebRTC side. (I don't know who that would be.)

Jimmy, did the feature to measure the audio level of the output land?

#11: Yes -- see  issue 753596 .

got it. thanks. This is just a matter of webRTC behavior then.

Guido or Henrik would you be the right folks to own this?  If not, could you suggest someone?

Additionally is there visibility into current ChromeOS feedback reports (#c2) which details what tab/url is keeping the WebRTC peer connection alive?  I think the assumption is a google hangouts session but wonder if there's a definitive way to confirm.

If you have pages with active peer connections then this is probably not a bug. If the peer connections shouldn't be active on the other hand then they shouldn't prevent suspension.

guidou@ fixed a bug recently, assigning to him, but I suspect this is a "WontFix" or a "NeedsFeedback". Please take a look.

There is a change in M72 that reduces the cases where peer connections inhibit power savings to the case where the peer connection is actually connected.
Prior to 72, any peerConnection will inhibit power savings even if is not yet connected to a remote peer.

semenzato@: Can you try with a 72 build (currently in beta) and see if it works better?
In 71 and older it's pretty easy to have powersaving inhibited due to a peer connection that is doing nothing.

#16 I don't know how to repro this, sorry.  I have left the lid open overnight a few times but it hasn't happened again.

OK. Since you were most likely using a version older than 72, I'll close this bug. Please reopen or file a new one if you see the issue again on 72 or newer.

Thanks for details.  Yes, all feedback reports I've seen are on 71 so far.

Do you have a pointer to the bug/CL that fixed the issue in 72 for reference here as well?

This is the CL:
https://chromiumdash.appspot.com/commit/0bc103ac42ee5fd6e92577dfcf391965dedd5420

 bug 866200