Repository navigation
Prevent Atom audio faults after delayed Stop cleanup - #46
Merged
Merged
Conversation
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.
Summary
Stopping Atom audio can leave the I2S channel transmitting after its worker exits. Delayed main-loop cleanup can then overflow the completion queue and latch the volume fence failed, blocking automatic playback until restart. The opted-in worker now disables the channel before publishing its exit; the main loop retains task/channel deletion and bus release. Genuine overflow and disable failures remain fail-closed.
Hardware impact
Scoped to the calibrated Atom/Voice Pyramid standard speaker. Gain, saved settings, prayer history, partitions and shared audio are unchanged by the implementation.
Standalone impact
Stop returns to a healthy idle speaker and permits subsequent playback without a reboot. Offline scheduling and Home Assistant independence remain intact.
Testing
Automated: the delayed-cleanup regression failed on the original driver in production and isolated modes, then passed with the fix. All 20 UBSan CTests, 135 Python tests, calibrated schemas, forward/reverse pinned-source provenance and production Quran/volume integration checks passed. All 13 exact-head CI checks passed.
Seven matched Atom build pairs passed capacity checks using the same pinned toolchain and dependencies. The official-profile OTA grew from 1,305,952 to 1,306,048 bytes (+96), leaving 266,816 application-budget bytes. Static RAM delta is zero across the matched pairs; both application slots and shared audio remain intact.
Hardware: the exact official candidate was installed through one preserving application-only write. Independent full-flash readback verified every byte outside its erase extent unchanged. Bottom-only startup retained 70%, settings, prayer history and preferences. Three attended 70% Play/Stop/replay cycles passed without a restart, fault or read error; the owner confirmed clear audio, effective Stop and successful replay.
The earlier 90% Stop fault motivated this investigation, but its underlying physical fault bit was not exposed, so exact attribution remains unconfirmed. Runtime heap, fragmentation, PSRAM and worker-stack headroom remain unmeasured. Full scheduled playback on this new source has not been observed; this is bounded development validation.
Licensing/media
Pinned ESPHome GPLv3 notices and maintained patch provenance are preserved; no media is added.