decodeAudioData brief main thread block before resolving with long AudioBuffer
Reported by
jana.tb1...@gmail.com,
Jul 27 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. open https://jsfiddle.net/Lv6Lumfj/6/ 2. take note of the 3 animated lines, memorize their order of anim cycles (in particular in which order they are at their peak appearance) 3. open a long (not necessarily large) audio file (30-40 minutes or more) supported by decodeAudioData 4. wait a few seconds until decoding is complete, then notice that some animations pause briefly What is the expected behavior? The audio thread should resolve with an AudioBuffer efficiently after decodeAudioData completes, without blocking the main thread briefly. The above animations should keep their previous sync. What went wrong? The main thread is blocked for an unacceptable duration (can be more than 1 second with a long AudioBuffer), causing the demo animations to come out of sync. Perhaps this is because the AudioBuffer is not transferred? Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: The animations are obviously there to showcase which threads are affected by the decodeAudioData pause: it seems that the CSS-based opacity animation keeps running on the GPU, while both the background-color anim and the main thread are completely blocked for a brief duration.
,
Aug 1 2017
I can reproduce this. Ended up using an mp3 file consisting of 1 hr of white noise. (50+ MB compressed)
,
Aug 1 2017
In current versions, I think there are two primary causes for this. First, decodeAudioData needs to copy the decoded data from the background thread to the main thread. This costs some time. Second, the AudioBuffer that is created to hold the returned data is being initialized to zero wastefully since it will be immediately replaced by the decode data. This initialization can be removed (and we have a CL, coincidentally, to do this).
,
Aug 14 2017
The fix for issue 736561 included the fix where decodeAudioData doesn't wastefully zero-initialize the result before overwriting it with the decoded Data. We can't get rid of the copy because the decode thread can't create the AudioBuffer itself (because it doesn't have a Javascript context), so there's nothing we can do about that.
,
Jan 10 2018
> We can't get rid of the copy because the decode thread can't create the AudioBuffer itself (because it doesn't have a Javascript context), so there's nothing we can do about that. This will be a shot in the dark, but how about *mitigating* the impact to some extent, by tapping into requestIdleCallback before unleashing this beast?
,
Jul 31
Was there any update/progress on this one? It's quite an extreme issue considering how long it blocks with longer audio. decodeAudioData was created to do decoding asynchronously in the first place, without the need to do the decoding on the main thread using createBuffer, precisely to avoid blocking the app. It's a VERY piss-poor job if we still get such atrocious blocks. Even though the blocks are considerably shorter, but they are still there, and their occurrence is unpredictable. |
||
►
Sign in to add a comment |
||
Comment 1 by rtoy@chromium.org
, Jul 27 2017