fix(example): wait for the mic fill before returning samples - #20
Open
ACEFGI wants to merge 1 commit into
Open
Conversation
M5.Mic.record() is asynchronous: it queues the destination buffer and returns while M5Unified's mic task fills it in the background. M5MicDriver returned maxSamples immediately, so every read handed back a buffer the task had not written yet. Worse, the destination was the *caller's* buffer, which the mic task went on writing after read() returned — a write into memory the caller already considered its own. Record into a buffer the driver owns and copy out once the fill completes. The completion poll needs a tick first: isRecording() is gated on a flag the mic task sets itself, so it reads 0 until the task dequeues the request and the wait would otherwise fall straight through. Co-Authored-By: Claude Opus 4.8 (1M context) <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
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
M5MicDriver::read()returnedmaxSamplesthe instantM5.Mic.record()returned.record()is asynchronous — it queues the destination buffer and returns while M5Unified's mic task fills it in the background — so every read handed back a buffer that had not been written yet.The destination was also the caller's buffer, so the mic task kept writing into memory the caller already considered its own, for as long as the fill took.
Fix
Record into a buffer the driver owns, and copy out only once the fill has completed.
The completion poll needs a tick before it starts:
Mic_Class::isRecording()is gated on_is_recording, a flag the mic task sets itself once it has dequeued work. Betweenrecord()queueing a request and the task starting it,isRecording()reads 0 with the fill still pending, so an immediatewhile (isRecording())falls straight through and copies an unfilled buffer.Notes
This keeps the example simple — one request in flight, waited to completion — which is correct but does leave the mic task's queue empty between reads. A driver doing continuous capture wants the queue kept non-empty instead, since M5Unified's mic task silently discards the partially consumed DMA chunk it is holding whenever it parks. The Hawthorn firmware's production
M5Microphonedoes that with a three-buffer rotation over M5Unified's two-request lag.Found while reviewing the same defect in that production driver.
🤖 Generated with Claude Code