[richiemcilroy]

On main, every Play renders the whole timeline mix again from 1 s before the playhead, then wraps to the start (crates/editor/src/audio.rs). Pausing drops the buffer, so the next Play repeats the same work. This PR replays the previous render on the next Play, but only when that provably gives the same samples a fresh render would.

flowchart TD
  Play[Play at P] --> Fresh[spawn main's render from P - 1 s<br/>exactly as on main]
  Fresh --> Check{origin independent project,<br/>key matches cache, cache already covers<br/>P - 1 s .. P + 0.25 s?}
  Check -- yes --> Replay[read the cached render,<br/>stop the fresh one]
  Check -- no --> Keep[play the fresh render]
  Keep --> Retain{origin independent<br/>and start rounds down?}
  Retain -- yes --> Cache[fresh render becomes the cache entry;<br/>old entry freed once it finishes or parks]
  Retain -- no --> Done[main behaviour]
  Pause[Pause] --> Park[cached render parks with its state]
  Idle[2 min paused, export, memory pressure,<br/>output stream dropped] --> Free[cache released]

Loading

When a replay is allowed

render_is_origin_independent (audio.rs:1972) requires every stage between the sources and the buffer to be stateless, so each sample is a pure function of its timeline position:

• 48 kHz stereo output, so the resampler only copies samples. Other rates resample with filter state that depends on where the render started.
• No Studio Sound: the denoiser carries state from the render origin, so main gives position-dependent samples.
• No retimed audio (unless that clip's audio is muted), no transitions, no fullscreen text holds.
• Segment starts not on a sample rounding tie, and a duration that matches the timeline.

Otherwise the Play runs main's code unchanged and the cache entry is dropped.

Why replayed samples match a fresh render

main's pass 1 writes into slot floor(O * 48000) while the renderer starts at source sample round(O * 48000). So a render from origin O holds v(f + d) in every slot f of pass 1, where d is 0 or 1, and v(f) in the wrap pass. The cache only keeps renders with d = 0, which hold v(f) everywhere. A replay with d = 1 reads one frame ahead from its own pass 1 start (origin_shift, audio.rs:2008):

let mut idx = self.read_position + i;
if idx >= self.shift_from {
    idx += self.shift;
}

Other details

• First audio: the fresh render is spawned before any cache work, so a cache miss starts exactly like main. A hit needs the cached render to already cover what main would have rendered at ready time (covers, audio.rs:1548), from 1 s before the playhead to 0.25 s after it.
• Cache key (audio_project_key, audio.rs:1901): track and music identity, output format, duration, and the serialized audio inputs (audio, clips, timeline segments, transitions, music segments, hold windows). ProjectConfiguration and TimelineConfiguration are destructured without .., so adding a field fails to compile until someone decides whether it affects audio. Visual edits (zoom, background, captions, clip names) keep the cache.
• Memory: while paused, the cached render is held, about 22 MB per minute of timeline. It is freed after 2 minutes paused (PLAYBACK_AUDIO_IDLE_RELEASE), before exports (release_playback_audio_caches), on macOS memory pressure, and when the output stream drops. A replaced entry is freed once the next render finishes or parks, never while playback is starting.

Results

M4 Max under shared load (load average 15 to 100), runs interleaved with main and a second main run as an A/A control, 20 to 24 rounds per case. Harness: PrerenderedAudioBuffer with 512-frame real-time pulls, plus AudioOutput::new_headless for the output path.

Replay (cache hit), Studio Sound off

Project	Audio ready, median main → PR	p95 main → PR	CPU per replay main → PR
60 s	0.43 → 0.054 ms	0.55-2.3 → 0.08 ms	16 → 1.1 ms
10 min	0.61-0.73 → 0.06 ms	2.0-10.2 → 0.1-0.3 ms	130-160 → 3 ms (2 s play)

First Play, plays after an audio edit, and Studio Sound on (cache miss). These run main's code. Across 104 interleaved timing cases (audio ready and first audible block), none is significantly slower than main (Mann-Whitney p < 0.05). The A/A control misses main's own median and p95 more often than the PR does.

Audio: 2,696 plays compared sample for sample. They covered play from start, fractional start positions, pause and play, near end, seeks during play, every edit type in the editor (split, delete, reorder, trims, clip/mic/system volume and mute, stereo mode, offsets, isolation, speed in three modes, transition, text hold, music and music volume, Studio Sound toggle, and visual edits), Studio Sound on and off, and 60 s and 10 min projects. All are identical to main, except three seeks into audio a Studio Sound render had not reached yet. There, both sides play main's code and differ only in how long the silence lasts, which varies run to run on main too (A/A: 853 vs 75 ms, 203 vs 1003 ms).

Memory while paused (Studio Sound off): 60 s 19 → 40 MB, 10 min 308 → 528 MB, back to main after the idle release. With Studio Sound on nothing is cached and footprint matches main.

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issue was found.

Summary

The PR keeps eligible rendered audio across pause and play.

• Matching playback starts can reuse the rendered audio mix.
• Paused audio renders stay ready briefly and are cleared when needed.

_{Reviews (10) · Last reviewed commit: "fix(editor): read the progressive render..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cap-status	Ready	Preview	Oct 23, 2026 5:15pm UTC

[capy-ai]

Capy found no issues.

View 2 other findings in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 3 other findings in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 2 other findings in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found 1 potential issue (1 high).

[richiemcilroy]

@greptileai review (fixed the merged-in rendered() field access, and cache hits are now looked up before a fresh render is allocated)

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[richiemcilroy]

@greptileai review

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.