[miguel-heygen]

What

Follow-up to the merged decode-first change. A WebKit source is now decoded when its decoded audio fits a 256 MB memory budget shared by all sources, in place of a fixed 600 s length. A source over the budget stays on its element, as before.

Why

The length limit was a stand-in for memory. Two 9-minute sources fit it one by one and together held 400 MB, while one 11-minute source was refused with room to spare. The budget counts what is held (decoded buffers) and what is being decoded (stereo float estimate from the duration), and a source already decoded or decoding keeps its verdict for all of its clips.

Measured

Unit level only. Decoded size of a 321 s source is 62 MB mono or 123 MB stereo. The budget is my number, not measured on a phone.

Not covered

• A source over the budget still plays sound about 300 ms late on Safari. Constant lag compensation on the element path does not fix it: with +0.3 s on the audio seek target, sound vs timeline moved to -55, -103 and -189 ms in three plays, so the lag is not one fixed number.
• iPhone memory under the budget is unconfirmed.

Tests

fails without the fix: "bare audio in WebKit > hands a 650 s source to a decoded buffer, past the old 600 s limit". On main it reports expected "releaseRouted" to be called with arguments: [ <audio> ], the sound never leaves its element. New in webAudioTransport.test.ts, "decode budget": a ten minute source fits and one hour does not, a source that is decoding counts against the next, an unloaded clip is left to its source.

Size

About 75 changed lines in two files plus tests; it replaces the 600 s constant the merged change introduced.

[heygengenesis]

Approving at b03b74e8. I found no blocker.

Fails without the fix: confirmed. I put init.ts and webAudioTransport.ts back to the parent (d548e356) and kept the new test. "bare audio in WebKit > hands a 650 s source to a decoded buffer, past the old 600 s limit" then fails with expected "releaseRouted" to be called with arguments: [ <audio …> ]. At the head, webAudioTransport.test.ts and init.test.ts pass locally (402/402).

Checked:

• No race in the accounting. In init.ts the only caller that checks the budget calls decodeAudioElement straight after fitsDecodeBudget, in the same tick. _pendingDecodeBytes is set before anything awaits, so two sources can't both pass on the same headroom.
• A source keeps its verdict for all its clips. A source that is cached or decoding short-circuits to true, so a clip whose duration is still NaN follows its source.
• The estimate is sound. decodeAudioData resamples to the context rate, so the estimate (seconds × ctx rate × 2 ch × 4 B) is exact for stereo and twice the real size for mono. If it's wrong, it leaves sources on their element, which is the safe side.

Non-blocking nits:

• releaseDecodedExcept drops a buffer from _bufferCache even while an AudioBufferSourceNode is still playing it. The budget then counts less than is actually held. It's small and short-lived, but worth knowing on iPhone.
• The non-scheduled fallback decode (the effectiveRate === 1 path at the end of the capture callback) still decodes without checking the budget. That is unchanged from before, but its buffers now count against the budget for sources that do check it.
• As the description says, 256 MB is untested on a real device.

CI: the red Comments check is infrastructure. oven-sh/setup-bun got an HTTP 504, so typescript was missing for the ratchet script. It is not caused by this change and needs a re-run.

The base branch was changed.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 106 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (1)

• seqplainkeys-none-px-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Re-approving at 69b12fdc after the rebase onto main, now that #7225 has merged. I found no blocker.

• The patch is unchanged. Compared against its merge-base, the diff matches b03b74e8, which I approved, apart from hunk line offsets in init.ts.
• Fails without the fix, confirmed on main. With main's init.ts and webAudioTransport.ts, "bare audio in WebKit > hands a 650 s source to a decoded buffer, past the old 600 s limit" fails with expected "releaseRouted" to be called with arguments: [ <audio …> ]. At the head, webAudioTransport.test.ts and init.test.ts pass 402/402.
• CI on this head: every workflow has a successful run. The cancelled entries are duplicate runs that concurrency superseded.

My earlier non-blocking nits still apply:

• The budget counts less than is held when a released buffer is still playing.
• The fallback decode path still skips the budget check.
• 256 MB hasn't been tried on a phone.

[heygengenesis]

Re-approving at 33c8aa3b. This head is a rebase only, onto main after the 0.9.16 release.

• The change is unchanged. Compared against its merge-base, the PR's patch matches 69b12fdc, which I approved, apart from index hashes and hunk offsets. It's still the single commit "fix(core): decode WebKit sources by memory budget, not by length".
• The tests still pass on the new base. At this head, webAudioTransport.test.ts and init.test.ts pass 402/402. I confirmed on main at the previous head that the named 650 s test fails without the fix.
• CI: when I approved, PR captures was green and the other workflows were still running on this head.