[WebAudio] Web Audio timer "currentTime" is occasionnaly stuck
Reported by
coren...@tutteo.com,
Apr 21 2017
|
||||||
Issue descriptionChrome Version : 57.0.2987.133 (not only happening on Chrome) URLs (if applicable) : https://flat.io/score/567877b261eda9c353d7ca80 (for example) OS version : MacOs / Windows / ChromeOS / Android / iOS Network (such as Cable/DSL/Dial up etc): Every kind Audio format : Usage of OGG and MP3 sound samples Special chrome flags : None Behavior in Safari (if known): Same than in Chrome Behavior in Firefox (if known): Same than in Chrome Video issue, Audio issue, both, neither? Audio issue Flash or HTML5? HTML5 What steps will reproduce the problem? (1) Create an audio context (2) Save the value of the AudioContext's "currentTime" property (3) After several seconds, compare the saved value with the current currentTime value I attached the code we deployed to detect this issue (test.js) What is the expected result? The new value must be greater than the saved value What is the actual result? The new value is equal to the saved value. The web audio timer may be randomly stuck leading to an inability to use the Web Audio API (in our case, playing samples through the API) Any additional information (anything else which may help us debug the issue)? This is an issue that nobody in our team has succeed to reproduce in the same conditions than our users. I, however succeed to reproduce the same kind of issue by launching a desktop software using the audio card on a Windows computer, while Flat was running in Chrome. It automatically stopped the audio timer letting the Audio Context instance state to "running". In that special case, there is a workaround described in the file test.js (l.15) We started logging the issue with Sentry a little more than a month ago after several reports that they couldn't play back any sounds. We are detecting the issue by setting up a timeout and checking values of context.currentTime before and after the timeout. We consider it as "stuck" when context.currentTime hasn't increase. We then log the current state property of the AudioContext instance, it is sometimes "suspended", sometimes "running" (but stuck in both cases). We also log the timer value which is, in most cases, stuck at 0, and in some cases stuck at a positive value. Since we started logging it, the issue happened about 3000 times to 1500 users (for a total number of about 40 000 people who used the app) Most of the times, asking them to restart their web browser or to restart their computer/device fix the issue. We first thought it may be a memory limitation, but some users even send us screenshots of their task managers and we couldn't spot anything abnormal (checked the disk, memory and cpu information) Since that issue is happening on every major browser, we also thought that we had wrote some erroneous code, but we couldn't find any misuse of the API. If it can help I attached files provided by Sentry regarding distribution of that issue among browsers, devices, and OSs. I'm not sure if it will be a great help, it seems that the issue happens more frequently on mobile devices. Files attached : test.js : The test we deployed to detect that issue browser.csv : The issue distribution among browsers (file provided by Sentry) device.csv : The issue distribution among devices (through Sentry) os.csv : The issue distribution among OSs (through Sentry)
,
Apr 21 2017
Do you actually have a repro case? test.js doesn't really seem to help since it's just the detection routine. Also browser.csv includes various versions of Safari, Firefox, Edge and others. This seems to imply that the underlying issue is not with Chrome, but possibly related to the device (computer, phone) itself.
,
Apr 21 2017
Thanks for your quick reply Raymond. Unfortunately, in most of the cases just initializing the AudioContext (through new AudioContext() ), then running the test causes the issue to happen.
,
Apr 21 2017
What test? test.js?
,
Apr 21 2017
Thank you for providing more feedback. Adding requester "rtoy@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 21 2017
Yes, running Dacapo.throwIfWebAudioStucked()
,
Apr 21 2017
Where do I get Dacapo?
,
Apr 21 2017
Dacapo is our own audio library which is unfortunately not open-sourced yet. But just consider it as a namespace. I was referring to the function contained in the test.js file.
,
Apr 21 2017
Raymond, I just found a case in our code where an issue may not be thrown. I just changed the behavior and I will get back to you as I get more information on how it could affect the current issue.
,
Apr 24 2017
,
Apr 24 2017
Let me know when you get more information. Also, it would be great if your repro case were more self-contained. As it is, I'm not exactly sure how to initialize everything and how to run it to reproduce the issue.
And looking at the code, I wonder if the issue is not a timing issue in Chrome because you do:
if (context.state === 'running') {
console.log("Suspending");
context.suspend();
}
context.resume();
If suspend() handling is delayed, then it might happen after resume(), and thus you get stuck. Not sure if this is possible, though. Because they're asynchronous, I'd certainly use promises to make sure things happen in the order you want them to.
,
May 9 2017
,
Sep 19 2017
Need feedback since May 9. Closing (Archived) Please re-open or file a new bug if this shows up again. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dalecur...@chromium.org
, Apr 21 2017