Fix vdsd speaker audio pacing drift#4
Merged
Merged
Conversation
The Linux speaker/haptics sender computed each 0x36 send deadline as now + 10ms, where now was sampled after the epoll wait. Wakeup and processing jitter therefore accumulated on every cycle, so the effective send cadence fell below the 100 Hz the controller consumes at 48 kHz. The pending-audio queue overflowed continuously (~1000 dropped 0x36 packets/min in the field log), and each dropped packet is a lost 10 ms Opus speaker frame -> audible crackle. Advance the deadline from the previous deadline (prev + interval) so the long-run cadence stays exactly 100 Hz and a backlog drains back-to-back until caught up. A fresh deadline or one that has fallen more than kMaxAudioCatchup (50ms) behind resyncs to now + interval instead of replaying stale audio.
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
1 participant
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.
Problem
DS5 controller speaker crackled/dropped. The field log showed vdsd dropping ~1000
BT 0x36packets per minute — all queue-overflow drops (blocked=0). Each 0x36 packet carries a 10 ms Opus speaker frame, so every drop is an audible gap.Root cause
flush_pending_audio_chunkset the next send deadline tonow + 10ms, wherenowwas sampled after the epoll wait. Scheduler + processing jitter accumulated every cycle, so the effective send cadence fell just below the 100 Hz the controller consumes at 48 kHz, and the 8-slot pending queue overflowed continuously.Fix
Advance the deadline from the previous deadline (
prev + interval) so the long-run cadence stays exactly 100 Hz, with a bounded catch-up: fresh deadlines or ones more thankMaxAudioCatchup(50 ms) behind resync tonow + intervalrather than replaying stale audio. Deadline math covered by a standalone test (drift-free across jittery wakeups, catch-up, resync guard).Result
Overflow drops fell from ~1000/min to ~0; clearly audible improvement.
Not fully fixed
A residual periodic crackle remains that this does not resolve — investigation and evidence tracked in #3 (leading theory: Bluetooth-transport / MediaTek adapter bound, not host-side).