[kixelated]

Problem

Nightly's Audio quality job fails just test push-to-talk with native: an utterance did not resume on its head (runs 43041909115 and 42842827718), with 8 native underruns and 8 stalls where it used to have none. It is a regression from moq-dev/moq#8362, not a flake: it reproduces every time locally, the parent commit passes, and that PR's commit fails.

Each back-to-back press resumes one delay after the old tail drains, so the replacement segment's held grows by about 250 ms per press. Once the queue behind it passes the age budget, the consumer evicts media, the hole is too large to fill, and play_audio resets the sink and calls Track::reset. The reset clears the anchor but kept held, so the next arrival anchored the clock that much late. Since #8362, media due past the sink's cap waits in play_audio until it is due, so the player sat out about 1 s while a fresh 300 ms sink drained. It stalled, evicted again, and repeated, losing the heads of the following presses. Before #8362 that media was written right away, which hid the stale hold.

The comfort numbers in the report (median about 32 s, max about 60 s) are correct: they are milliseconds of comfort noise across the 5 s and 60 s mutes.

Approach

Track::reset zeroes the segment's held. Media after the break was not held behind any tail, so its arrivals are the live edge again. A unit test in sync.rs covers it and fails without the fix.

Local just test push-to-talk: native 0 underruns, 0 stalls, and every utterance resumes on its head (it was 8/8 and failing before the fix).

Impact

• No public API or wire change. moq_mux::sync::Track::reset now also drops the hold behind a tail. Players that reset after a loss re-anchor at the live edge instead of up to the accumulated hold later.

Alternatives

• Dropping the held-back wait that fix(cli): moq play holds each rendition's catalog delay #8362 added also passes, but it gives up holding a shared delay past the sink's cap. It also leaves the clock anchored late.

Follow-ups

• Back-to-back presses still add about 250 ms of latency each, because each resume starts one delay after the old tail drains. It recovers only at an eviction or a long mute. This was already the behavior before this PR; whether a zero-gap resume should continue the old schedule is worth its own quest.

(Written by Opus 5.5)

[kixelated]

@codex review

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-11T18:16:53.375060Z	ccf28b0	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: ccf28b0ea3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".