Repository navigation
Size the native device buffer in real frames, and relabel the latency table - #77
Merged
Merged
Conversation
The check added in #74 compared UNDERTONE_PLAYER_BUFFER against deviceBuffer, the duration handed to oto. oto converts that duration at the int16 rate but sizes the buffer in float32 samples, so it is twice the time the buffer holds: 23.2 ms for 512 frames at 44.1 kHz, which plays in 11.6 ms. Read-aheads of 12-23 ms at the default device size were refused. deviceLatency gives the play time, and the check and its message use it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The table in latency.go and the README's 820 -> 130 ms figures were measured 2026-08-24 in headless Chromium through oto's web backend, timed by Playwright, and read as native numbers. Replace them with medians from a speaker-to-mic loopback on a MacBook Air, 2026-10-26, and say where the old figures came from. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mparrett
changed the title
The first commit here had oto's conversion backwards. oto turns BufferSize into bytes at 8 a frame (stereo float32, context.go), so deviceBuffer's duration was the buffer's true play time, and its 4-byte arithmetic was what doubled the frame count: deviceFrames = 512 opened a 1024-frame device, and UNDERTONE_DEVICE_FRAMES=N opened 2N. The round-trip tests modeled oto at 4 bytes too, so they agreed. deviceBuffer and the tests now convert at oto's 8 bytes, deviceLatency is gone, and deviceFrames is 1024 so the device stays the size it has been. The override check is the one #74 shipped. The measured table and the README now give the frame counts the device actually got. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mparrett
changed the title
…est comment from 512 frames Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #74. The first commit is superseded by the third; the last labels the 821 ms header figure as a browser measurement.
Device frames.
deviceBufferconverted frames to a duration at 4 bytes a frame, but oto convertsBufferSizeback at 8 (stereo float32,context.go). SodeviceFrames = 512opened a 1024-frame device, andUNDERTONE_DEVICE_FRAMES=Nopened 2N. The round-trip tests modeled oto at 4 bytes as well, so they agreed with the bug.deviceBufferand the tests now use oto's 8 bytes (otoBytesPerFrame). The round-trip test now fails against the old arithmetic.deviceFramesis now 1024, the size the device has always had, so default behavior is unchanged. A speaker-to-mic loopback at this head gave a 147 ms median, against 149–158 ms before.deviceLatency) misread the conversion in the other direction; the third commit removes it.Latency table.
latency.go's "90 ms + 1.4×" table and the README's 820 → 130 ms were measured 2026-08-24 in headless Chromium through oto's web backend, timed by Playwright, but read as native. Both now give native medians from a speaker-to-mic loopback on a MacBook Air, 2026-10-26 (15 blips each, matched-filter onset), in real device frames:🤖 Generated with Claude Code