WebAudio in chrome drops samples now because the spec was updated to require running JS on the mixer thread (https://www.chromestatus.com/feature/4588498229133312 …) Great.
-
-
Replying to @antumbral
If you were doing any sort of ScriptAudioProcessorNode before, you'd drop samples because of main thread contention; this is strictly better
1 reply 0 retweets 0 likes -
Replying to @slightlylate
No, ALL audio drops samples now, because the mixer thread can't be realtime priority anymore, because it can run JS
2 replies 0 retweets 0 likes -
Replying to @antumbral @slightlylate
There are lots of bug reports about it. My high-end machine can reproduce it with a simple HTML file that plays one sample in a loop.
1 reply 0 retweets 1 like -
Replying to @antumbral @slightlylate
I'm sure changes will be made to mitigate it, but the architecture-dev thread has some people saying it's okay to glitch.
1 reply 0 retweets 0 likes -
Replying to @antumbral
I think it's OK to glitch the app/site that's offending, but not all audio.
1 reply 0 retweets 0 likes -
Replying to @slightlylate
Yeah. In this case no AudioWorkers are in use anywhere in the browser.
1 reply 0 retweets 1 like -
-
Replying to @slightlylate @cwilso
Maybe I misinterpreted the discussion thread and spec allows JS run on its own thread(s) like VST plugins? That would mitigate the damage.
2 replies 0 retweets 0 likes
The spec allows the impl to run the Audio Worklet code to run on ANY thread, but unlike the old design isn't fused to the main thread
-
-
So then it's a question for the impl to decide where to run them. To prevent over-buffering, want it to have cheap access to samples.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.