I'd guess this is a stale WebAudio context which requires a page to manually shut it down:

https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/suspend

On Android we'll stop these after some time if only silence is playing. We've talked about doing this on desktop platforms as well.

https://cs.chromium.org/chromium/src/content/renderer/media/renderer_webaudiodevice_impl.cc?l=173

+rtoy

That sounds like a plausible suggestion and a very worthwhile fix. If we have code to detect when only silence is playing would it be worth using that to add some UMA metrics to measure the frequency of the issue?

My anecdata on my personal machine suggests that this issue is quite common, although I have not actually done any estimates of the power draw yet.

Finding a repro case would be really helpful.  WebAudio AudioContexts should get GC'ed, but I think we often take too long (or maybe never) because it's pretty hard to know if the graph doesn't have something scheduled to play in the future.

I think there may just be a lot of sites or js packages which create an audioContext for probing and never release the JS variable. I think we have enough evidence that this happens in the wild that it may be worth turning on for all platforms. I think it's fairly rare that any site has a use case where 30+ seconds of silence is part of the steady state.

I've just started experimenting with chrome://media-internals so I'm not sure if it can tell me what page has left an AudioContext open. Can it?

Also, if a page has left an AudioContext open is it expected that there would be no audio-playing icon on the tab? The lack of that was confusing to me.

I don't think media-internals knows anything about WebAudio, sadly.

I think the tab icon doesn't show if the output is silent.  So an oscillator connected to a gain node with 0 gain will suck up power, but the icon won't show there's audio is playing because the output is silent.

A context is in use if you see a controller + stream w/o any playing media players. The controllers page will say which tab has the stream controller attached. Sorry there's not a cleaner way currently.

rtoy@ is correct, we don't show the indicator for silent audio.

I hit this again over the weekend. I think we either need to fix this or add some UMA instrumentation to prove that it's not important.

I looked at chrome://media-internals when it happened and saw this:

Controller 1:2 Properties
channel_layout: STEREO
channels: 2
component_id: 2
component_type: 1
device_id: default
device_type: pcm_low_latency
effects: NO_EFFECTS
frames_per_buffer: 480
owner_id: 1
sample_rate: 48000
status: started
 
Stream 1:0 Properties
channel_layout: STEREO
channels: 2
component_id: 0
component_type: 2
device_id: {0.0.0.00000000}.{cd52971a-f12f-43ea-b994-9f926eef6eae}
device_type: pcm_low_latency
effects: NO_EFFECTS
frames_per_buffer: 480
owner_id: 1
sample_rate: 48000
status: started
volume: 1


However I'm not sure what to do with this information.

I also tried measuring the power draw. Intel Power Gadget was useless. My Kill-A-Watt said that my laptop's total power usage dropped from 16 W to 15 W when I turned off the audio service (power savings from fixing this would be at least that much) but given that the display only has 1 W of precision it's hard to know how to interpret that - somewhere between 0.1 W and 1.9 W I guess?

BTW, if anybody else hits this (audiodg.exe running continuously but no audio playing) you can get audiodg.exe to halt by running the Services program and halting the Windows Audio service.

There should be a web_contents_title in the controller section. Did that help identify the site triggering this so we can classify?

I think we have enough information indicating that this is a problem on Android, so I'm supportive of turning our silence suppressor on everywhere.

rtoy@ we don't invoke this until after 30s of silence; do you know of any use cases that might affect? The cutoff / resume should be transparent to the user too, so is there a worry with enabling this everywhere?

> There should be a web_contents_title in the controller section

I copied all of the text. Looking now I can't see a web_contents_title anywhere.

Hmm, that's weird; it's required to create an AudioLog object without which you wouldn't have a controller entry in media-internals. Are there cases where a WebContents doesn't exist for a rf_id+rp_id?

https://cs.chromium.org/chromium/src/content/browser/media/media_internals.cc?l=258
https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_renderer_host.cc?l=293

+maxmorin in case he's seen this or if it has anything to do with the new audio path...

Bruce: what channel are you on? The mojo IPC has only been enabled for ~a week, and only on canary/dev. Would be great if you checked for a web contents title next time as well, if this is some weird edge case.

The setting of web contents title is very similar as well (https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/renderer_audio_output_stream_factory_context_impl.cc?l=82). The only reason I can think of for it failing is if the frame/webcontents is gone by the time we attempt to set the web contents title. In the mojo case, the stream is closed when the frame is destroyed. In the AudioRendererHost case, the stream could stick around forever ( crbug.com/717825 ), but AudioRendererHost checks that the frame exists when creating the stream, so the frame should (very likely) exist when setting the web contents title as well. In short: I don't get it.

I managed to repro this on an internal site (see b/38442046 about the repro case, visiting the main page i enough). It repros both with and without the mojo experiment, but not very consistently. Adding a log message here: https://cs.chromium.org/chromium/src/content/browser/media/media_internals.cc?l=276 indicates that the title is correctly found.

Looks like the issue is that sometimes the title is set first, but that update is dropped due to the use of UPDATE_IF_EXISTS. The code assumes that the call to OnCreated arrives first. I guess simply moving the OnCreated before SetWebContentsTitle... is enough to fix this? 

I'm on stable channel and I've been seeing this behavior for many months (the constantly playing silence, I don't know about whether web_contents_title not being set is a new problem or an old one.

So, there are two bugs? Audio device being left open, and web_contents_title not consistently set?

Sounds like it, max filed  issue 735037  for the title issue and has a fix out.

Burndown testing on a SurfaceBook (thanks johnpallett@) suggests that having the Windows Audio service enabled increases battery life by about 3.8%. I don't know how accurate this is (and doing multiple overnight runs is painfully slow) but that gives us one estimate of the possible cost of leaving the audio service running. I don't know if there is any additional CPU cost on the Chrome side.

Ping rtoy@ for c#12, +hongchan from WebAudio as well.

Sorry Dale, I was OOO these last few days.

I remember when enabling the cutoff/resume on Android had a few isues (that have been fixed).  IIRC, restarting the audio isn't instantaneous.  And does the audio context currentTime progress correctly with the audio cutoff?  That is, the clock is still running?

Restarting isn't instant, but we don't lose any data and the delay information should be accurate.

BTW, the 3.8% estimate of the cost of the audio process was from a machine that was playing video. On an idle machine the total power usage would be lower, so the audio process would account for a higher percentage of power draw. It's tough to get exact numbers, and it will vary from machine to machine, but on my new laptop at home with the screen at 50% brightness it looks like the audio process playing silence accounts for about 6-8% of total power draw (a bit less than a Watt). YMMV.

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

commit 9eef9cf2ba172c7fc8416aa6b78c5c6a4c610a21
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Jul 13 03:18:49 2017

Enable silent sink suspension for WebAudio everywhere.

Previously this was only enabled on Android, but we've continued
to see issues with sites in the wild wasting power with a silent
audio context that they never suspend.

BUG= 707462 , 732450 
TEST=none

Change-Id: I3ceba194be8f98b7b0a7078476fb5f000d262198
Reviewed-on: https://chromium-review.googlesource.com/568817
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486251}
[modify] https://crrev.com/9eef9cf2ba172c7fc8416aa6b78c5c6a4c610a21/content/renderer/media/renderer_webaudiodevice_impl.cc

I finally got a working version of Intel Power Gadget on my home laptop (a beta version of 3.5 shared by Intel) and used that to try to measure the power savings of this fix. Chrome was in the state where it was constantly playing silence (evident by audiodg.exe using ~0.6% of CPU, which is ~5% of a core). I used Intel Power Gadget to measure the package power (CPU) and it was 2.x W, varying from 2.19 to ~2.95 W.

I then restarted Chrome and, as hoped, audiodg.exe did not start up again. Once my system settled down I saw package power that was around 1.x W, typically varying from 1.1 to 1.95 W. It occasionally went as low as 0.70 W and the highest I saw it go was 2.05 W. There's enough noise in the measurement to make precise claims impossible but it looks like this is a solid 1.0 W saving, possibly more.

I did these measurements on battery power. The typical power when plugged in on this laptop is ~16 W, so this suggests a 6% total power savings - quite possibly more.

I look forward to the fix shipping soon in M61.

I've been hitting this issue pretty much continuously on my home laptop so I upgraded to M61 as soon as it was available on stable. The fix appears to be working as intended and I expect that this will slightly improve battery life. audiodg.exe now goes to sleep or closes when no audio is playing.