Issue metadata
Sign in to add a comment
|
Web Audio API - Automatically suspended AudioContexts still sometimes play audio
Reported by
pstephan...@gmail.com,
Dec 18
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Save the attached html file 2. Open it in Chrome 71 on Windows 10 (the OS is probably not important) 3. Open dev tools 4. Click the "start oscillator" button on the test page Note: this sometimes behaves as expected if the audio policy change warning is not shown in dev tools - it seems there's some kind of race-condition. In that case, it seems it can be reliably reproduced by refreshing the page with the dev tools focused and the mouse over the dev tools assuming they are opened in a separate window. What is the expected behavior? There should either be no audio until the user clicks the "start context" or the state of the context should change to "running" when the oscillator starts playing sound. What went wrong? The audio context claims to be suspended but is actually playing sound. Did this work before? Yes 70 Does this work in other browsers? Yes Chrome version: 71.0.3578.98 Channel: stable OS Version: 10.0 Flash Version: This is caused by the autoplay policy change in chrome 71. There is no way for an app to compensate for this behaviour since the audio context lies about its state.
,
Dec 18
,
Dec 18
Thanks for finding the bug. This is a simple oversight and I will start working on a fix.
,
Dec 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9bc8872d010e31e30a233a6e6b75cc0c1cd72305 commit 9bc8872d010e31e30a233a6e6b75cc0c1cd72305 Author: Hongchan Choi <hongchan@chromium.org> Date: Wed Dec 19 01:10:34 2018 Change context state after a source node starts A simple fix to change the context state after the source node starts correctly. Bug: 916156 Test: webaudio/AudioContext/autoplay-state-change.html Change-Id: I1e2230661b08c26521873b49e84d0f4f2e1aa059 Reviewed-on: https://chromium-review.googlesource.com/c/1382430 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Hongchan Choi <hongchan@chromium.org> Cr-Commit-Position: refs/heads/master@{#617699} [modify] https://crrev.com/9bc8872d010e31e30a233a6e6b75cc0c1cd72305/third_party/blink/renderer/modules/webaudio/audio_context.cc [add] https://crrev.com/9bc8872d010e31e30a233a6e6b75cc0c1cd72305/third_party/blink/web_tests/webaudio/AudioContext/autoplay-state-change.html
,
Dec 19
As per comment# 4, fix seems to be landed, hence removing Needs-Bisect label to it. Thanks!
,
Dec 19
Just to be clear on the new behaviour, if the context is explicitly suspended then starting a sound source shouldn't cause it to resume on its own, right? Automatically resuming makes sense to me if the context was suspended by the autoplay policy, but not if it was suspended by an explicit call by the developer.
,
Dec 19
,
Dec 19
Re #6: I'll take up this issue to the Audio WG. These corner cases need to be sorted out in the spec.
,
Dec 19
The spec issue: https://github.com/WebAudio/web-audio-api/issues/1802 |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by pstephan...@gmail.com
, Dec 18