Lead program audio by the jitter buffer's own depth

[ustacode]

The bug

Program audio reached viewers as a fraction of the real audio interleaved with digital silence — "robotic and stuttery" in the user's words.

BufferedAudio.getSampleBuffer selects by timestamp: it walks the queue consuming every buffer whose PTS is at or behind the output clock, returns only the newest one consumed, and when it finds the queue empty it re-emits the previous buffer with its samples zeroed.

We were stamping program audio at capture time. That is by definition always behind "now", so:

• every tick consumed the entire queue and discarded all but one buffer
• the queue could never accumulate the 200 ms it was configured to hold
• the gaps came back as zeroed buffers

The fix

Shift the presentation timestamp forward by the source's own target latency before queueing — which is exactly what the built-in path already does:

// AudioUnit.appendBufferedBuiltinAudio, existing vendored code
let presentationTimeStamp = presentationTimeStamp + CMTime(seconds: bufferedBuiltinAudio.latency)

Program audio simply never got the same treatment.

Applied inside the engine rather than pushed onto the caller: the caller stamps at capture time, which is the honest thing for it to know, and the engine owns its own jitter buffer.

Verification

• 38 tests in 9 suites pass; new test pins the lead (appendLeadsByTargetLatency)
• FakeStreamEngine models the shift and exposes lastProgramAudioPresentationTime — a fake that skipped it would let a consumer pass against audio the real engine throws away
• Scripts/check-containment.sh clean

🤖 Generated with Claude Code