Bug 190552 – UI / DOM blocks audio thread, causing crackles

• Status: NEW
• Component: Web Audio

We're developing a WebAudio-based DAW running in a WKWebView. This works amazingly well and we're thrilled how far the Web Audio API has come.

However, when the engine is under high load (roundabout 500 nodes for the entire loaded project), interacting with the DOM (scrolling, adding / removing elements, etc.) in any way causes severe buffer underruns, even at 1024 frames buffer size (set by starting another app that sets that buffer size and records in the background).

Shouldn't the audio thread run with high priority and not be blocked by the UI / DOM thread?

[Radar WebKit Bug Importer]

<rdar://problem/45342528>

[Jer Noble]

(In reply to ae from comment #0)
> We're developing a WebAudio-based DAW running in a WKWebView. This works
> amazingly well and we're thrilled how far the Web Audio API has come.
> 
> However, when the engine is under high load (roundabout 500 nodes for the
> entire loaded project), interacting with the DOM (scrolling, adding /
> removing elements, etc.) in any way causes severe buffer underruns, even at
> 1024 frames buffer size (set by starting another app that sets that buffer
> size and records in the background).
> 
> Shouldn't the audio thread run with high priority and not be blocked by the
> UI / DOM thread?

Can you provide sample code? Unless you're using javascript-based nodes, WebAudio should be entirely off the main-thread.

(In reply to Jer Noble from comment #2)
> (In reply to ae from comment #0)
> > Shouldn't the audio thread run with high priority and not be blocked by the
> > UI / DOM thread?
> 
> Can you provide sample code? Unless you're using javascript-based nodes,
> WebAudio should be entirely off the main-thread.

Thanks, I will try to put together a testcase. Essentially though, it should be easy: Just create ~ 500 mixed nodes (oscillators, gains, filters, etc.), start all the oscs and make connections so it all actually uses CPU, run all of that in a WKWebView, and then do some manipulation on a DOM with ~ 1000 nodes, or some heavy redrawing in a <canvas>, that should be enough to trigger the problem.

Oh, not using any ScriptProcessor nodes!

I've realized that this is not even related to the DOM at all -- even pressing one of the volume buttons on a connected headset leads to massive crackles during the fade in and fade out animations of the iOS volume overlay! So it seems like in general, the whole WKWebView Web Audio thread is not decoupled from UI rendering, no matter where it happens...