Reaction: Fix volume stuck low after talking with one AirPod in case#610
Merged
Conversation
With one AirPod in the case the pod deterministically drops the terminal 0x4B frame: the wind-down flurry ends on a transitional status (1,2,3,0xB,4 then nothing), so the reaction never disengaged and the volume stayed low until the 5-minute backstop (#608). Reproduced on Pro 3 (fw 6589, 6503) and Pro 2 USB-C (fw 6814) — all three share one firmware train; with both pods worn the terminal always arrives. The pod sends no frames during active speech, so any non-START frame means the wind-down has begun and a terminal is imminent. A HOLD now arms a short 6s fuse instead of the 5-minute backstop: if no terminal (or fresh START) follows, the reaction disengages anyway. The fuse must stay above ~5s — gaps up to 2.8s were observed between consecutive wind-down frames. STARTs still arm the long backstop, since the pod stays engaged and silent against ambient noise for 20-30s+ and a short timeout there resumes media mid-conversation. Validated on hardware on both models: 7/7 single-pod conversations restored exactly 6s after the last wind-down frame.
The conversation volume slider committed a profile write on every drag frame — laggy dragging, and racing async writes persisted stale mid-drag values (observed: 78 stored while the UI showed 70). Use local state while dragging and commit on release, matching the adaptive-noise and tone-volume sliders.
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.
What changed
When Conversational Awareness lowered the volume (or paused media) while you talked, the volume could stay low after the conversation ended — until you took the AirPods out of your ears. This happened reliably when one AirPod was in the case. Volume now comes back a few seconds after you stop talking.
Also fixed the volume-reduction slider feeling laggy while dragging and sometimes saving a different value than the one shown.
Closes #608
Technical Context
0x4Bstop frame — the wind-down ends on a transitional status. Since Reaction: Fix Conversational Awareness resuming media too early #601 disengages only on an explicit terminal frame (with a 5-minute backstop), the reaction stayed engaged and the volume stranded low. Reproduced on Pro 3 and Pro 2 USB-C; with both pods worn the terminal always arrives.0x4Bframes during active speech, so any non-START frame means the wind-down has begun. A transitional frame now arms a short 6s disengage fuse; if the terminal never arrives, the reaction restores anyway. STARTs still arm the long backstop, preserving Reaction: Fix Conversational Awareness resuming media too early #601's protection against resuming mid-conversation (the pod stays engaged and silent against ambient noise for 20-30s+).