Conversation
Serialize native hardware cleanup, preserve cancellation while a pending audio call retires, and retry route discovery within bounded recovery waits. Keep ordinary startup and stop free of recovery deadlines. Add hosted ASR and controller regression coverage for fallback, stale completions, cancellation, and normal capture compatibility.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
The PR Policy check is blocking this PR because required template information is missing. Please update the PR description with:
Visual files detected:
Screenshots or video are required for UI, UX, settings, onboarding, overlay, menu bar, or visual behavior changes. If this PR has no visual changes, check the no-visual-change box in the template. If this remains incomplete for 48 hours after opening, the PR may be closed. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 99ccb0fbe5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Greptile SummaryThis PR rebuilds microphone capture after Core Audio topology changes and strengthens cancellation, recovery serialization, fallback selection, failure presentation, and media-playback restoration.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0c11cb11e6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c7b15e8578
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| self.publishSnapshot(phase: .shutDown, input: nil, fingerprint: nil) | ||
| } | ||
| Self.log("Direct capture interrupted operation drained status=\(status)", level: .info) | ||
| return status == noErr && self.isPoisoned == false |
There was a problem hiding this comment.
Treat quarantined stopped hardware as recovered
When a known-stopped notification interrupts a blocked prepare/start and the subsequent input.invalidate() returns an error, invalidateLocked consumes that stopped marker and deliberately leaves isPoisoned false because replacement is safe, but this expression still reports recovery failure solely because status != noErr. BoundedAudioHardwareQueue then latches cleanupFailed; the queued notification no longer has its marker, and the topology fallback requires isPoisoned, so every later recording attempt is rejected until restart. Recovery should succeed when the failed teardown was safely quarantined rather than requiring noErr unconditionally.
Useful? React with 👍 / 👎.
| name: NSNotification.Name("ASRServiceStartFailed"), | ||
| object: nil, | ||
| userInfo: ["errorMessage": errorMessage] | ||
| self.presentAudioCaptureFailure( |
There was a problem hiding this comment.
Can you post a system notification maybe instead of directly focusing the main app window ? Clicking on it could take users to the main app
There was a problem hiding this comment.
Yeah, technically this shouldn't even be popping up at all. But the recovery doesn't happen for the same user I mentioned below and this seems to help. If they have notification suppressed - this will go unnoticed and since it's fatal, it made sense to make the app pop up in front so the user is aware of issue - if it happens - seems to be very rare occurrence.
| let topologyRevision = self.snapshotLock.withLock { self.hardwareTopologyRevision } | ||
| if let input = self.input, input.isRunning == false, | ||
| topologyRevision != self.lastStartedTopologyRevision |
There was a problem hiding this comment.
Do we want to rebuild the pipeline even if the preferred is mic available (and topology changed due to some device coming/going) ? What would be the latency impact of rebuild this ?
There was a problem hiding this comment.
There is some weird issue with one user that doesn't work if I don't do the whole build and gets stuck. the current build I have works for now. If this problem happens, I am not sure about the extra delay as I don't have that info or can reproduce this on my side. So still tinkering with this.
Description
Rebuild microphone setup after audio-device changes and fix cancellation and playback restoration when recording recovery fails.
Type of Change
Related Issue or Discussion
Stacked on #955.
Testing
swiftlint --strict --config .swiftlint.yml Sources Tests Package.swiftswiftformat --config .swiftformat SourcesScreenshots / Video
Notes