meet-bot: implement POST /play_audio streaming endpoint

[siddseethepalli]

Summary

• Adds skills/meet-join/bot/src/media/audio-playback.ts with startAudioPlayback/stopAudioPlayback/flushSilence spawning pacat into bot_out
• Replaces 501 stub in http-server.ts with streaming POST /play_audio and DELETE /play_audio/:streamId for cancellation
• Unit tests cover ordering, cancellation, and silence flush

Part of plan: meet-phase-3-voice.md (PR 1 of 6)

---

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 000519e64f

ℹ️ 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".

[chatgpt-codex-connector]

Keep replacement stream registered on stream_id reuse

When two POST /play_audio requests reuse the same stream_id, the first request’s finally block always executes activeStreams.delete(streamId). If the second request has already stored its own controller in the map, this unconditional delete removes the new in-flight stream entry, so DELETE /play_audio/:streamId can no longer cancel it (returns 404) and barge-in semantics break under overlap. Only clear the map entry if it still belongs to the current request’s controller.

Useful? React with 👍 / 👎.

[devin-ai-integration]

Devin Review found 2 potential issues.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🔴 Superseded stream's finally block unconditionally deletes from activeStreams, removing the replacement stream's entry

When POST /play_audio receives a stream_id that matches an in-flight stream, it aborts the old stream (line 264) and overwrites the map entry with the new stream (line 276). However, the old stream's finally block at line 352 unconditionally calls activeStreams.delete(streamId). Because AbortController.abort() fires its listener synchronously (setting cancelled = true and resolving abortPromise) but the old stream's read loop only processes this on the next microtask, the new map entry is always written (line 276) before the old stream's finally runs. The old stream therefore deletes the new stream's entry, making DELETE /play_audio/:streamId return 404 for the superseding stream. This silently breaks barge-in cancellation for any stream that reuses an ID.

Execution trace showing the race

1. New POST: existing.controller.abort() — sync, marks old abortPromise resolved
2. New POST: activeStreams.set(streamId, { controllerB, handle }) — overwrites entry
3. (await yields to microtask queue)
4. Old stream: Promise.race settles with "abort", breaks loop
5. Old stream finally: activeStreams.delete(streamId) — deletes stream B's entry
6. DELETE /play_audio/:streamId → 404 (stream B is gone from the map)

Suggested change

	activeStreams.delete(streamId);
	const current = activeStreams.get(streamId);
	if (current?.controller === controller) {
	activeStreams.delete(streamId);
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Concurrent streams interleave PCM on shared pacat stdin — intentional but undocumented at HTTP layer

The playbackFactory (backed by startAudioPlayback) is a singleton — all concurrent POST /play_audio requests write to the same pacat stdin. If two streams overlap, their PCM bytes are interleaved, and when one is cancelled, the trailing silence flush (line 356) injects zeros into the middle of the other stream's audio. The module-level comment in audio-playback.ts:142-145 explicitly states mixing is "a daemon concern, not the bot's", but the HTTP route doesn't document this or guard against it. The daemon should ensure only one stream is in flight at a time (or the bot should reject concurrent streams), but that's an API contract decision for Phase 3, not a bug in this PR.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[siddseethepalli]

Follow-up fix merged in #26267 — addresses stream_id reuse race, barge-in overlap tracking, ffmpeg probe cache transient errors, playbackChain deadlock, and cancel DELETE timeout.