Skip to content

Revert "fix(room_io): frame output audio by a cap, not a fixed size (#7261)" - #7271

Merged
longcw merged 1 commit into
mainfrom
longc/revert-room-io-cap
Sep 15, 2026
Merged

longcw merged 1 commit into
mainfrom
longc/revert-room-io-cap

Conversation

@longcw

@longcw longcw commented Sep 14, 2026 •

Copy link
Copy Markdown
Contributor

Problem: #7261 turned RoomIO's 50 ms frame into a cap with a 10 ms floor, so the emitted frame size now mirrors the incoming packet size. capture_frame never waits between pushes, so a source sending 20 ms packets produces 20 ms frames for the whole session, however far ahead of realtime it runs.

Fix: This reverts the commit, restoring fixed 50 ms framing with the progressive ramp. The startup gap from #7259 returns until #7272 lands, which releases a partial frame on a deadline instead of by size.

Reverts #7261. Reopens #7259 until #7272, stacked on this branch, merges.

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Devin Review

num_channels,
samples_per_channel=sample_rate // 20,
min_samples_per_channel=sample_rate // 100,
sample_rate, num_channels, samples_per_channel=sample_rate // 20, progressive=True

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Startup framing inserts playback gaps

With realtime-paced 20 ms packets, progressive=True holds the second packet until 40 ms accumulates. The source drains its first frame before the next arrives, inserting a 20 ms playback gap.

Learn more

The room output receives frames through capture_frame, which permits callers to push audio at realtime speed. Progressive framing emits the first 20 ms packet immediately, then raises the required frame size to 40 ms. A realtime source supplies the next 20 ms only when the first frame has finished playing. The byte stream retains that packet until another 20 ms arrives, leaving the audio source empty between frames. clear_buffer() resets the ramp, so interruptions can trigger the same gap again.

Example: At 0 ms, a 20 ms packet is emitted and plays through 20 ms. The packet arriving at 20 ms remains buffered because the next target is 40 ms. The packet arriving at 40 ms releases a 40 ms frame, after listeners have already heard 20 ms of silence.

Recommended fix: Do not use size-only progressive framing for realtime-paced room output. Release buffered partial frames on a playback deadline, or retain capped framing until the deadline-based implementation is available.

Devin Review

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

@longcw
longcw added this pull request to stack #7281 September 15, 2026 00:26
@longcw
longcw merged commit 181b2d2 into main Sep 15, 2026
27 checks passed
@longcw
longcw deleted the longc/revert-room-io-cap branch September 15, 2026 06:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants