Additional comment is that I have no audio output from this website on Chrome or Safari and did not click anything.

And do not want any audio output, even though there is a clickable video.

I am attaching the source code of tawk.to, in case the website changes before this bug is verified. It happens on other sites as well, but I only have recorded this one so far.

Deleted: twak.to.html 29.8 KB

twak.to.html 29.8 KB View Download

@Ssamanoori It has been two weeks on this and no Triage. This bug is 100% reproducible, and I think it would be very easy to trace.

The HTML attached in #3 is not the complete source code - there are a number of scripts that get loaded as well. It's not clear that the browser is blocking sleep when it wasn't directed to.

Yes, the code is certainly loaded in one of the foreign scripts. It is not my site though. I do have the issue with the html file just as well as the site.

The browser itself does not have an accessible API for blocking sleep, rather, the browser is directing coreaudiod in a way that causes coreaudiod to block sleep. There is no sleep assertion set directly within Chrome itself.

The question here is why the process coreaudiod is active in a way causing it to block sleep when the browser is not playing any audio. I don't think that it is playing in the background an inaudible audio track, but we can't rule out some other error on the part of the website owner until we know what is keeping coreaudiod active.

By contrast, when a Youtube video is paused, the coreaudiod process drops the assertion. Here, no audio is playing and yet there is a coreaudiod assertion.

We base the power monitor on audibility of the audio signal, but if a video is created and playing (even if hidden) a power save blocker will be created.

It's possible that coreaudiod is holding the block even though the audio is silent; likely though WebAudio.

coreaudiod is holding the block, as established by the assertion (pmset -g assertions):

Listed by owning process:
   pid 249(coreaudiod): [0x0003e2ec00010240] 00:00:18 PreventUserIdleSystemSleep named: "com.apple.audio.AppleHDAEngineOutput:1B,0,1,4:1.context.preventuseridlesleep"
	Created for PID: 726.

where PID 726 is Chrome.

The question is why. Note that there is no audio "playing" icon on the tab.

To give you a sense of what a problem this bug is, the average user can't just print out the assertions and see that Chrome is the offender. There computer will just stay on until they by chance remove this tab. If you manually press "sleep" it does work, but the idle timer will be overridden.

Yeah, not sure what to do here unless we pause silent streams. On Windows power save blocking is manually controlled by holding the power lock. We also don't show the audible icon for silent audio streams.

It seems like we might want some sort of notification that a site is playing silent audio and shut it down somehow.

I agree, although, can you confirm here that the site is playing a silent stream? The visible elements are a video player (paused/unloaded) and a chat mechanism. I don't seem to have the debugging capacity to see streams.

I'm also not aware of what context would be for a silent stream, except as a kind of web developer mistake, and how one could be created. Maybe a test script could be created with a silent stream, much more focused than this 3rd party site.

Thank you for providing more feedback. Adding requester "shrike@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can confirm the site is creating silent streams. I don't have enough logging on this machine to tell if it's from WebAudio or WebRTC. I'd guess the site is creating an audioContext and then not suspending it.

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

The sleep block is triggered on line 4601 of the attached screenshot "this.audioContext = new AudioContext);" and I have confirmed via console test that "a = new AudioContext();" reliably triggers this block.

I'm not sure if this is what you meant by "not sure what to do here unless we pause silent streams" or if there would be another way to handle this.

In this application's code, the AudioContext appears to be used only for its "decodeAudioData" method which decodes an .oog file loaded later in the script.

Upon reading the API description of "suspend", it is clear that this is an API level mistake for assuming that the AudioContext will "power up" audio hardware AND do CPU decoding not requiring that hardware. ("The suspend() method of the AudioContext Interface suspends the progression of time in the audio context, temporarily halting audio hardware access and reducing CPU/battery usage in the process — this is useful if you want an application to power down the audio hardware when it will not be using an audio context for a while.")

That reads "power up the audio hardware when a new instance is created". I am 90% sure that there is no real need to power up hardware long in advance, but for continuous streams of course you don't want them to be powered down while the stream is sending audio.

So internally pausing audio contexts after 1-15 seconds is a great idea and probably a must. Even pausing 58 seconds to would allow the computer to idle sleep in all cases.

The mentioned screenshot is not needed.

Yes, once an AudioContext is created, audio HW resources are enabled, and silent audio is output.  This is intentional to provide the lowest latency possible for WebAudio.

If all you really want to do is to use decodeAudioData, create an OfflineAudioContext instead.  You can use decodeAudioData with an offline context. This won't start up any audio HW.

However, you may want to make sure the sample rate for the OfflineAudioContext matches the sample rate the audio files.  Otherwise, the decoded audio is automatically resampled to the context rate. (I guess that was happening already for the AudioContext case anyway.)

I'll keep that in mind if I ever use AudioContext, but this happened to me on a website I have no control over. I setup a background application to monitor the sleep triggers because I had so often had my computer refuse to idle sleep. Something like this sits in the background and is totally unidentifiable to the average user.

In that case, I think WebAudio and Chrome is working as intended.

@dalecurtis: Android will sleep if there's enough silence, but we don't do that on desktop right?

Correct, I think you were worried about what this might do to DJ apps, etc. We can easily turn this code on for desktop as well.

Yeah, we (and cwilso@) don't want that.

We've already seen some issues on Android about missing audio because of that. (Can't remember if this issue still exists or was fixed, though.)

Per comment #23 and #24, this is working as intended.

Apps that are using AudioContext just to run decodeAudioData should use OfflineAudioContext instead.

Closing as WontFix (WAI).

Please reopen or file a new bug is this is incorrect.

@dakecur / @rtoy

How about adding the speaker icon for AudioContexts? I'm not sure if the icon appears at all for non-silent AudioContexts, but it should be up to the developer to suspend and/or use offlinecontext (and thus control the speaker icon). If we are using resources for silent streams, we should show the speaker for them also.

I've added another bug report with this suggestion.

https://bugs.chromium.org/p/chromium/issues/detail?id=631277&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=