diff options
| author | skal <pascal.massimino@gmail.com> | 2026-02-04 16:36:34 +0100 |
|---|---|---|
| committer | skal <pascal.massimino@gmail.com> | 2026-02-04 16:36:34 +0100 |
| commit | eb5dee66385760953f3b00706318fe0e4ce90b0e (patch) | |
| tree | a8cad58cf064efd98224362d5e73209a20b8138d /src/tests/test_dct.cc | |
| parent | 09230c434e8d23b6eac3bdf97c3e5fd779d1e5a4 (diff) | |
fix(audio): Add pending buffer for partial writes to prevent sample loss
Implemented pending write buffer on main thread to handle partial ring buffer
writes, preventing sample loss during high-load scenarios (acceleration phase).
Problem:
Even after checking available_write(), partial writes could occur:
- Check: available_write() says 1066 samples available
- Audio thread consumes 500 samples (between check and write)
- synth_render() generates 1066 samples
- write() returns 566 (partial write)
- Remaining 500 samples LOST! Synth advanced but samples discarded
- Result: Audio corruption and glitches during acceleration
Solution (as proposed by user):
Implement a pending write buffer (ring buffer on main thread):
- Static buffer holds partially written samples
- On each audio_render_ahead() call:
1. First, try to flush pending samples from previous partial writes
2. Only render new samples if pending buffer is empty
3. If write() returns partial, save remaining samples to pending buffer
4. Retry writing pending samples on next frame
Implementation:
- g_pending_buffer[MAX_PENDING_SAMPLES]: Static buffer (2048 samples = 533 frames stereo)
- g_pending_samples: Tracks how many samples are waiting
- Flush logic: Try to write pending samples first, shift remaining to front
- Save logic: If partial write, copy remaining samples to pending buffer
- No sample loss: Every rendered sample is eventually written
Benefits:
- Zero sample loss (all rendered samples eventually written)
- Synth stays synchronized (we track rendered frames correctly)
- Handles partial writes gracefully
- No audio corruption during high-load phases
- Simple and efficient (no dynamic allocation in hot path)
Testing:
- All 17 tests pass (100%)
- WAV dump produces correct output (61.24s music time)
- Live playback should have no glitches during acceleration
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Diffstat (limited to 'src/tests/test_dct.cc')
0 files changed, 0 insertions, 0 deletions
