Restore mic-capable audio session after in-recorder preview

[morepriyam]

Addresses the preview-induced silent-mic failure from #124 (the .playback session flip named in that issue's title). #124 also documents a second, separate failure mode — the micBlocked latch in use-call-state.ts staying set after non-call interruptions — which this PR does NOT touch; the issue stays open to track that.

Problem

Clips recorded after using the in-recorder preview captured a silent audio track. ffprobe/volumedetect on exported segments showed the dead clips contain a flat ~-66 to -70 dB noise floor for their full duration — the mic input delivered digital silence with no error surfaced.

Root cause

expo-video's VideoManager.setAudioSession() forces the shared AVAudioSession to .playback / .moviePlayback whenever one of its players changes state. .playback has no microphone input, and the preview player (use-preview.ts) lives on the recorder screen — so previewing clips mid-session silently flipped the session out of .playAndRecord. VisionCamera kept capturing without error.

The app couldn't recover because useAudioFocus.acquire() short-circuited on heldRef ("already held"), so nothing ever re-applied the recording config until something rebuilt the session (mute toggle, camera flip, screen leave). Same failure mode as mrousavy/react-native-vision-camera#3560.

Fix

• use-audio-focus.ts: acquire() always re-applies the session config instead of returning early when focus is already held.
• recorder.tsx:
  • the audio-focus effect keys on previewing, so closing the preview re-runs acquire() and restores .playAndRecord
  • record start awaits a session re-assert before the mic attaches (reacquireThen wrapping onToggle / onHoldStart) — cheap, idempotent insurance against any other session-stealer

Testing

• tsc, eslint, full jest suite pass
• Diagnosed on device: instrumented session reproduced silent clips after preview; per-segment ffprobe confirmed full-length silent audio tracks with identical encoder params

Repro to verify: record a clip → preview it → record again → second clip should now have audio.

Related upstream reports

• 🐛 Audio is not getting recoded while video recording in IOS mrousavy/react-native-vision-camera#3560 — same symptom (audio missing from recordings on iOS); resolved there by stopping the video-player library from managing the audio session (disableAudioSessionManagement in react-native-video — expo-video exposes no equivalent)
• [expo-audio] expo-audio installation causes AVAudioSession interrupt/resume failure expo/expo#42709 — expo-audio/AVAudioSession interrupt-resume failure leaving a "zombie" mic state
• [expo-video][expo-audio] expo-audio pauses expo-video expo/expo#38671 — expo-audio and expo-video fighting over the shared audio session

[Copilot]

Pull request overview

This PR addresses an iOS recording reliability issue where using the in-recorder preview (expo-video) could flip the shared AVAudioSession to a playback-only category, causing subsequent clips to record silent microphone audio until the session was rebuilt.

Changes:

• Updates useAudioFocus.acquire() to always re-apply the recording-friendly audio session configuration (even when focus is already “held”).
• Adjusts the recorder screen’s audio-focus effect to re-run acquisition when leaving preview mode.
• Adds a pre-capture “reacquire then record” wrapper to re-assert the recording session config immediately before starting capture.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/features/recorder/use-audio-focus.ts	Removes the “already held” short-circuit so acquire() can re-assert the audio session after expo-video alters it.
src/app/recorder.tsx	Re-keys audio-focus behavior around preview state and adds a pre-record reacquire wrapper to reduce silent-mic risk.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/features/recorder/use-audio-focus.ts:37

• acquire()/release() are invoked in recorder.tsx via void ... (not awaited), so their async bodies can overlap. If release() is in-flight and an acquire() happens (e.g. focus/preview/mute toggles close together), the tail of release() can complete after acquire() and re-apply allowsRecording: false / mixWithOthers, leaving the session in a non-recording category and potentially reintroducing silent clips.

  const acquire = useCallback(async () => {
    heldRef.current = true;
    try {
      await setAudioModeAsync({
        allowsRecording: true,

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/features/recorder/use-audio-focus.ts:59

• release() can still clobber a later acquire() because the heldRef check happens after await setIsAudioActiveAsync(false). If an acquire() starts while release() is awaiting, release() may deactivate the session and then return early when it notices heldRef is true, leaving the “held” state with audio inactive (and making the doc claim “LAST requested state wins” untrue). This needs a stronger serialization/token approach so stale async continuations can’t apply side effects after a newer request.

    heldRef.current = false;
    try {
      await setIsAudioActiveAsync(false);
      if (heldRef.current) return; // acquire() won while we awaited — leave its config alone
      await setAudioModeAsync({

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

src/app/recorder.tsx:219

• reacquireThen returns an async callback. useRecorderGestures triggers onToggle via runOnJS without awaiting, so rapid taps can start multiple overlapping toggles and make start/stop ordering depend on when the awaited acquireFocus() resolves. Serializing the reacquire+action work avoids overlapping toggles and keeps tap order deterministic.

  const reacquireThen = useCallback(
    (action: () => void) => async () => {
      if (!muted && !callActive) await acquireFocus();
      action();
    },
    [muted, callActive, acquireFocus],
  );

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/features/recorder/use-audio-focus.ts:48

• acquire() only checks heldRef before awaiting setIsAudioActiveAsync(true). If release() runs while that await is in flight, the native calls can complete out-of-order and leave audio active even though heldRef is now false (violating the "last requested state wins" intent described in the comment). Add a post-await guard that reverts to the released state when heldRef flipped during the await.

        interruptionMode: 'doNotMix',
      });
      if (!heldRef.current) return; // release() won while we awaited — don't re-seize focus
      await setIsAudioActiveAsync(true);
    } catch {

src/features/recorder/use-audio-focus.ts:60

• release() can race with acquire() while awaiting setIsAudioActiveAsync(false) / setAudioModeAsync(...). In particular, if acquire() re-flips heldRef to true during the await, release() currently returns without ensuring audio is active again, and if heldRef flips during the setAudioModeAsync await there’s no post-await guard to restore recording mode. Add after-await checks that (a) re-activate audio when heldRef became true during deactivation, and (b) restore recording mode if it became true during the mode reset.

    try {
      await setIsAudioActiveAsync(false);
      if (heldRef.current) return; // acquire() won while we awaited — leave its config alone
      await setAudioModeAsync({
        allowsRecording: false,